I’m questioning how may I generate ribbons from an different emitter that appear to be hair / grass strand on the floor of a skeletal mesh for instance.
I’ve a primary emitter that spawns particles on the floor of the mesh and a second emitter that creates the ribbon for every particle.
Nonetheless I’ve to make use of add velocity to make them appear to be strands and use a spawn charge. It makes it transfer loads and feels glitchy.
What I want to use is a spawn burst instantaneous with infinite lifetime.
I think about I would like to put and offset particles of the ribbons utilizing RibbonID and execution index, however that appears pretty onerous. So I used to be questioning if there was a neater resolution or if there’s somebody who already did that that might give some hints?
I’d have finished precisely what you might be discribing right here.
You may in all probability do it even with out the supply emitter, however having the supply emitter makes it simpler.
You don’t essentially must spawn from the supply emitter, however moderately simply use the positions coming from these particles by way of AttributeReader.
So one thing like this:
- Spawn supply particles on SkelMesh
- Spawn ribbon particles as burst (quantity = nr of supply particles * nr of particles per ribbon/strand)
- Divide the ribbon particles into particular person ribbons by giving them a RibbonID (each ‘nr of particles per ribbon/strand’ you up the RibbonID by 1) & additionally a customized index/ribbon (0->‘nr of particles per ribbon/strand’)
- Seutp the RibbonLinkOrder (0->1) for every Ribbon (customized index / ‘nr of particle sper ribbon’)
- Now setup the positions. Pattern the supply particle positions and snap your ribbon particles to these. ParticleID of supply particle = RibbonID of ribbon particle.
- Offset the ribbon particles e.g. Sampled regular of supply particle * strand/ribbon-length * RibbonLinkOrder
- Add any motion to this on prime, e.g. gravity.
You would additionally check out the Niagara chain instance, which has spring forces and so forth. to regulate motion. Is perhaps helpful on your usecase. Is perhaps some points with CPU vs. GPU particles although as there’s nonetheless no official GPU ribbon resolution.
That is excellent data, thanks loads!
Only one query, concerning the Ribbon ID, it’s a Niagara Id with 2 parts.
Index and Purchase Tag.
If I perceive this proper, Index is an ID per strand? Can’t we simply use the identical as supply particle ID?
As for the purchase tag, it’s a distinctive ID per ribbon particle proper?
While you say:
Divide the ribbon particles into particular person ribbons by giving them a RibbonID (each ‘nr of particles per ribbon/strand’ you up the RibbonID by 1) & additionally a customized index/ribbon (0->‘nr of particles per ribbon/strand’)
So the RibbonID != Supply Particle ID?
The index could be: each ‘nr of particles per ribbon/strand’ you up the RibbonID by 1
How will you hold a reference of that variable accessible between particles so you understand the present quantity?
And Purchase Tag: a customized index/ribbon (0->‘nr of particles per ribbon/strand’)
Once more, how do you generate this distinctive customized index?
The vary is between 0 and variety of particles per strand so it’s not a novel ID per strand hyperlink for the entire emitter?
Sorry for all of the questions, I’m very confused about ribbons and the way they work!
I’m honeslty undecided what Purchase Tag is definitely for. I often use Index (which is what I really ment with RibbonID). Index is what I take advantage of.
Ribbon.Index = SourceParticle ID. You may instantly match up the RibbonID(Index) with the SourceParticle ID (UniqueID? Execution Index, whichever goes from 0->nr of particles).
Every particle solely is aware of details about themselves (apart from when utilizing an AttributeReader), however that’s sufficient data on this case. Simply add an Int particle parameter to maintain observe of this index.
So, let’s say you’ve gotten 10 particles per ribbon/strand and 10 supply particles. Which means we spawn 100 ribbon particles. Now, to get the RibbonID seutp, we principally need the primary 10 particles to be ribbon/strand 0, the subsequent 10 particles to be ribbon/strand 1 and so forth.
So that you simply do one thing like this:
Received it working, thanks a lot!
Good work! That appears tremendous cool
You may even do cool issues like make the particles bend away from the participant with this. It’s very handy to have this as Niagara particles as manipulating them is simple!
Yeah I had that thought as effectively!
I ponder how they had been in a position to make use of ribbon and distance area on the identical time since one is CPU solely and the opposite one is GPU solely
Yeah, they in all probability have their very own resolution for it. It might be attainable to create your individual GPU Ribbons, however that’s moderately difficult.
One other resolution could be, to make use of GPU particles to write down their place right into a render goal, then pattern these (in BP for exapmle) and feed that knowledge into your CPU system. However none of that shall be tremendous low-cost, I assume, because it at all times has to shuffle knowledge round between GPU & CPU. Is perhaps price taking the perf hit although, relying on how essential it’s
Hey guys little bit of a very long time because you visited this however I used to be questioning should you keep in mind how you bought them to be seperate strands, I’ve acquired a niagara setup that may spawn a number of ribbons constrained to one another however a problem im working into is that the tip of the earlier ribbon needs to hook up with the beginning of the subsequent ribbon, or they’re getting tangled making an attempt to attach to one another
I used to be simply questioning should you guys had some perception on how to ensure they’re seperate ribbons
I realized this bug too. My band-aid repair is to scale back the scale or opacity of the beginning and finish particles of every strand of ribbon to be zero.