Community
Bifrost Forum
Welcome to the Bifrost Forum. This is the place for artists using Bifrost to ask and answer questions, browse popular topics, and share knowledge about creating effects procedurally using Bifrost. You can also visit the Bifrost Community on AREA to download an array of ready-to-use graphs, read Bifrost news and updates, and find the latest tutorials.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Particles and trails

10 REPLIES 10
Reply
Message 1 of 11
Anonymous
1774 Views, 10 Replies

Particles and trails

Is it possible to generate trails (or strands) from emitted particles? I successfully replicated the strands tutorial ( https://www.youtube.com/watch?v=V8suv8wTat8 ) generating strands from particles but what I would like is one particle one tail. Any ideas? Thank you!

 

10 REPLIES 10
Message 2 of 11
Dark__Night
in reply to: Anonymous

Good question. Would be nice to be able to create strands from particle motion rather than just point position, like MASH trails. 

Message 3 of 11
jonah.friedman
in reply to: Anonymous

Hi Remo,

 

There is in fact a compound that does this included in the rebel pack, called create_particle_trails! 

 

Rebel pack link: https://forums.autodesk.com/t5/bifrost-forum/rebel-pack-0-3-0-for-bifrost-2-1-0-0-released/td-p/9633...

 

The compound is called create_particle_trails.  

 

dust_motes_particle_trails.PNG

 

Copy and pasting the in-app docs from that node (in the info tab if you select it):

Edit: just noticed some leftover text in the docs from an Arnold node under the "particles" input, oops. 😋 Hopefully it's self explanatory what you plug in there. 

 

Creates strands trails behind particles.

If the particles have IDs (the point_id property), it can leave trails behind particles as they are emitted or die. This option is on particles solver settings as label_point_id.

Inputs

particles

Specifies the density property which Arnold will use to render. By default this is automatic and does not need to be specified manually. The automatic behavior is based on what the attached Arnold Standard Volume shader specifies as its density channel. However, if there is a different volume shader, or no shader is not applied, this allows it to be specified manually.

start_frame

Which frame is the start of the simulation. Will accumulate particle clouds starting from this frame.

num_frames

The length of the trails, in frames.

properties

Allows specifying custom user properties to copy to the strands. By default this is point_position and point_size - meaning the strands will have the sizes and postions of the particles they are emitted from.

Jonah Friedman
Bifrost Product Manager
Message 4 of 11

OMG it just gets better and better!!! 

Message 5 of 11
Dark__Night
in reply to: Dark__Night

Works a treat!

 

Now I am going to be greedy and ask how i would apply a random_value/set geo 'color'  setup to the trails to get random colors on each trail. I tried to use get_strands_structure as in your previous post on strands individual colors (using AiUserdatacolor) , but it doesn't seem to work- it won't return a 'point_strand_index' as with the strands. Is there a way to get an index/id for each trail so that i can use set geo 'color'? Sorry i hope that makes sense!!

Message 6 of 11

There's that hidden node I talked about in the other post - update_point_strand_index - which creates that data. Until we make it visible, you can get it from those scenes or from inside create_strands_from_counts or some other nodes. Sorry for that inconvenience. 

 

You can also add a color property to the input particles (either using the particle system or on the outputs) and transfer it to the trails using the property transfer supplied on that node. It'll even work if the points change color while in flight. 

Jonah Friedman
Bifrost Product Manager
Message 7 of 11

I got it working 😉  thanks!

 

Initially it wouldn't work - i had actually tried using update point strand index, and was scratching my head as to why it wouldn't work. I discovered the reason it didn't work was because the 'random value' node which opens by default just gives you a single (simple) number. I published the compound from your example and it has three (vector) numbers (ie for RGB). I wonder if they are two different nodes, or did i do something wrong?

Message 8 of 11

Ahh, the answer is type wrangling. The short version is, you can right click on the min and max ports on this node and use "set value type" to select the type of random value you want. 

 

For more detail and a more technical explanation, read on. I don't expect very many users to know the detail below, and certainly don't want people to have to know it, but I think it's nevertheless helpful to understand what's happening even if you don't ever create overloads of your own.  

----

 

If you create a random_value node, and dive in, you'll see that there's a hash called "jotun hash", which then converts the result of the hash into a float value. 

 

overloads_and_wrangling.png

 

If you go back outside again, right-click on "min", and set the type to Math::Float3, and then go back inside, you'll see a whole different implementation that creates three values from that hash. Creating a float3 random value is different from creating a float random value and a different graph does this, and having one node that represents multiple different graphs depending on types is called an "overload". 

overloads_and_wrangling_float3.png

 

This interaction of setting the type on the port is what we mean by "type wrangling", where you can control the type system by creating values on ports. Values are like invisible value nodes, so just as plugging a float3 connection in there would cause the types in the graph to change, you can do it without a value node as well. 

 

When you see "supported types" in the contextual "set value type" submenu, it's listing the different types a node has an overload for. "Suggested types", on the other hand, indicates that this port actually has the type "auto" and we've added hints. Lower level nodes tend to have overloads, and higher level nodes tend to have auto ports. 

 

More info: https://help.autodesk.com/view/BIFROST/ENU/?guid=Bifrost_Common_build_a_graph_set_port_type_html

Jonah Friedman
Bifrost Product Manager
Message 9 of 11

Thanks so much- and nice to have it all here as a reference so that I can use the random value in many different contexts. 

Message 10 of 11

Hi jonah.

There is something that make create_particle_trails works only with nParticles and not with basic particles bifrost?

first image bifrost start no problem screenshot on frame 22 is ok.

Second image bifrost on frame 55 weird

Third image no problem any frame with nParticles.

bifrost startbifrost start

frame 55frame 55

nPArticles with no problemsnPArticles with no problems

Message 11 of 11

Hi Remo,

 

It works if you use "label point ID" on the particle solver settings. The issue is that if particles die if needs a way to keep track of particles from frame to frame. 

 

Creates strands trails behind particles.

If the particles have IDs (the point_id property), it can leave trails behind particles as they are emitted or die. This option is on particles solver settings as label_point_id.

Jonah Friedman
Bifrost Product Manager

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report