Jump to content

Particle Birth Distribution Clumps


Recommended Posts


thanks to Bern [1] I currently can gain an deeper insight to inter dop pop sop communication.

The effect is scaling quite nice, but I have a question about the birth of the particles:

http://proforma.preset.de/tai-chi-hou-dini/pandora/ [2]

The particles are born if the box gets to rest.

The first box got all particles at one, then it seems that the particle counts get averaged over all sources. I tried different combinations of impulse/constant. What can I do to get around this first burst?

As I copy the rbds back into sop I tried to copy the popnetwork onto each box, but that didn't work neither.

Another question:

I test against the velocity of the rigidbody if particles can be emited.

Should I but this into chops to see if the motion has stoped for a longer time segement to get rid of short stops?



[1] http://forums.odforce.net/index.php?showtopic=5230

[2] http://proforma.preset.de/tai-chi-hou-dini/pandora/p4.mp4

Link to comment
Share on other sites

I think this is very simple. Imagine that your scene is from 1 to 100. and your first box start emmiting particles at frame 50 (because it falls earlier than the other boxes). If in your pop network you set the constant activation to 1, the first box will birth the particles that the system didn't birth in the range 1-50. So you should write in the constant activation $FF>=50.

Edited by MIguel P
Link to comment
Share on other sites

Nice system you setup!

Miguel and Alvin,


What Miguel says makes absolute sense. Along with Alvin's question I think I see the point.

I currently have a popnet that takes *all* copies of the rigidbodies as input and birth location.

I think this has several drawbacks.

But my tests and tries to put the particles (particleSOP or POPnetwork) inside the copy branch didn't solve my problem as particles seem to be stamp resistant?

I think I need to find a way to tell the particles to start birthing at first box stop and then multiply the particle rate with each additional box that comes to rest.

I just started reading CumulativeMovement into a dynamicsCHOP.

Though I see the examples in the help I cannot read this values back into POPnetwork.

I think this is just a generic confusion. :blink:

I attach my current setup. I think there are many points that could be optimized.

I appreciate every tip and hint.



Link to comment
Share on other sites

confusion solved.

I use chops to see when the first box stops and then multiply the particle count by the number of stop boxes.

Well, this assumes that the boxes don't start moving again.

To detect a new movement in the box is just a matter of math and chops, I guess.

I should take the anguluar movement into account.

This shows how important it is and how much it helps to know what a effect should look like.



Link to comment
Share on other sites

There is another way to approach this issue that is far more accurate and doesn't require the use of CHOPs (although I am partial to CHOPs approaches :) ): calculate the total area of the emission geometry. As the number of emitter surfaces are fed in to your Source POP you just calculate the total area of the surfaces and embed it in a new detail attribute. You then multiply your particle birth rate by the area.

I clipped a few SOPs from some of the tools I am working on so that explains some of the "odd" comments.


Link to comment
Share on other sites

There is another way to approach this issue that is far more accurate

It took me some time to realise why this would be far more accurate:

Using the area as base for this calculation uncouples the tool's effect from the size/form of the emitter.

My solution would only work if all emitter have the same size.


Link to comment
Share on other sites

  • 2 weeks later...

I tried to use your approach. But I got stuck.

I tried to count the area of grouped primitives but that didn't work.

I started deleting the primitives and it worked in a small example setup.

In my real setup it doesn't work or gives me strange results.

I copy a grid n times depending on the number of dropping boxes.

I group and delete them to make them appear the moment the boxes come to rest.

Before this moment the grids are deleted.

I put your three nodes (measure, scale area and sum_area) at different places in my network

but the area_sum is either 0 or a strange value that changes at strange times.

I would have expected that the area rises every time a grid appears as I measure only the primitives that are in the emitter group.

I attached a simplified setup.



Link to comment
Share on other sites

Yep busted.

I have an even better idea. Instead of using the Attribute Create and the loop through the points, use the Attribute Promote SOP.

Wire the Attribute Promote to the attribcreate__area_scale1, set the Original Name to area, Original Class to Primitive, New class to Detail and the Promotion Method to Sum.

More reliable. I have changed my assets.


Link to comment
Share on other sites

  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...