A Bug In The Copy Sop?

[ofer]

Hello.

I tried to create a SOP network that uses the copy SOP with stamping parameters to copy a POP network.

I ran into a very big problem: The stamped parameters seems to hold only for the first frame, after

that, houdini can't find them. The stamping values are constant, and completely time independent.

I added a very simple hip file, to ilustrate the problem. You can the particles are spreaded at the first frame, and them concentrate to three lines, because the radius of their emitters becomes zero (the default value in the stamp funciton).

Am I doing something wrong?

Thanks.

problem.hipnc

[Visual Cortex Lab]

well... it looks as a bug to me too.. but you can easly solve it by putting the PopNet after the copy..

cheers

[stevenong]

Hi,

I don't see what you're describing in the hip file you attached. The main thing I noticed is only one circle is passed to the POP network and not three. The result of the Copy SOP is three copied particle systems.

I think you should copy the circle first then pipe that into the POP Network. If I'm not understanding you, please explain more in detail.

Cheers!

steven

[ofer]

This might work in this simple example, but it won't always work. My true goal is

to take a spline, with an unknown number of branches, and then to make particles

flow across all its parts.

I'm almost done, what im doing is separating the spline to it's different branches, make a tube from the branch, the particles then flow inside this tube. I then copy this whole thing so the a new brach is handled with each copy. This 'bug' is the only thing stoping me.

I can't put the POP net after the copy, because the particles will collide other branches tubes.

I didn't want to attach my real hip file, because its somewhat complex, and doesn't show off the problem right away.

PS. Im sorry for the spelling mistakes, im really not used to the keyboard here.

[Jason]

Without looking at your hipfile (I'm at home on the couch), you could try to turn on the PerformanceMonitor and look for cyclic expression errors or other SOP errors you're not able to catch.

Good luck,

Jason

[edward]

It's not exactly a bug per se although the behaviour takes a bit of explaining. Take a look at the attached scene file. It's similar to yours except it's even further simplified. We have an open circle that has it's radius set to $F which is then used to emit particles from on each frame (impulse only). I've coloured the particles to show which frame they were created. Now advance a couple of frames. Notice that all we're getting is a *new* ring of particles with the increased radius from the circle sop.

This is happening because the POP networks maintain their geometry and simply modify/add to it each successive frame. It nevers actually goes back to recook the entire simulation. You have to go back to frame one to reset it if you change parameters that only take effect starting from frame 1. Unlike SOPs which are NOT history dependent, they recook _all_ its geometry every frame as necessary.

So now go back to frame 1 and display the copy1 sop which is more like your example file. This is frame 1 (the reset frame), so the POP network cooks the circle at the 3 different radius. However, once you go to frame 2, the circles are all the same now because the first copy is now working off of the last cooked geometry of the popnet, ie. the third circle. It then emits a new ring using the first copy's radius. Finally, this is geometry copied two more times by the copy sop, which doesn't recook the pop network because it's already up to date for the current frame. For the next frame, you see the same thing because it simply keeps working off of the last cooked geometry, resulting in the same two rings.

Note if the POP network actually recooked completely from frame 1 on each changing radius, then the first example I talked about would just show rings of increasing radius every frame, losing the results of the older radius.

problem2.hipnc

[ofer]

Well, thats too bad. I'll have to find a way around it. and thats not going to be simple, Im afraid.

But thanks for the explanation, it's very good. I also didn't know the performance monitoring tool. thanks for that.

I hope this bug will be fixed.

[edward]

Sorry, I had meant to say it's _not_ a bug per se. One can argue that the increasing rings behaviour is equally valid and desirable. Consider your situation, for it to work the way you want it to as you currently have it set up, the particle network will need to recook completely from frame 1 to your current frame for each copy, for *every frame*. This means that the amount of computation required will be proportional to the number of frames you have _squared_. eg. to cook up to frame 100, you will need work proportional to 10,000 frames of work. That's extremely *slow*.

A better way is to figure out how to run the particle simulations so that the particles don't interact. However, my knowledge of POPs is deep enough so I don't know how you would go about doing that.

[ofer]

Thank you. Maybe its not exactly a bug. but some documentation of this behaviour in the Copy SOP help can be usefull.

I will try to find a more efficient way to handle this.