Particle Birth Distribution Clumps

[rdg]

Hi,

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?

Thanks,

Georg

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

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

[MIguel P]

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 April 19, 2007 by MIguel P

[GallenWolf]

Hey rdg,

Nice system you setup! I have a question though, for your quicktime demo with multiple boxes, as you using 1 popnet to setup the particle system or 1 popnet per box?

Thanks!

Alvin

Edited April 19, 2007 by GallenWolf

[rdg]

Nice system you setup!

Miguel and Alvin,

thanks.

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.

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

I appreciate every tip and hint.

Georg

rdgrbddoppop_5.hipnc

[rdg]

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.

Georg

rdgrbddoppop_6.hipnc

[old school]

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.

area_birth_density.hip

[rdg]

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.

Georg

[old school]

Yep. I always try to make any approach work so that it can scale nicely. In your example the next logical step is to vary the size and shape of the boxes. Just thinking ahead.

[rdg]

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.

Georg

rdg_sum_area_copy.hipnc

[old school]

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.

Thank-you.

[patrickkrebs]

You should scale or deform the box at the same time so it looks like it's dissolving or blowing away in the wind.