Jason Caleb Posted January 7, 2003 Share Posted January 7, 2003 I've hit a wall while dealing with particle collisions. (Pun slightly intended) When working with POP collisions is there a way for the colliding particle to pass attributes to the SOP primitive that the particle collided with? If I have the collisions "stick", the particle has a little bit info like the SOP and primitive number, but I would like to kill off the particles after passing the attributes to the primitive. Any ideas? On a side note. There is a vertex, point, prim, function expression for fetching attributes of SOPs but no function for fetching detail attributes. (Did I miss it? Or am I misunderstanding what detail attributes are?) Thanks, Jason Quote Link to comment Share on other sites More sharing options...
plan9 Posted January 8, 2003 Share Posted January 8, 2003 this isnt too specific... have you tried the kill POP? perhaps using a condition expression in the "rule" field what have you tried so far? Quote Link to comment Share on other sites More sharing options...
Jason Caleb Posted January 8, 2003 Author Share Posted January 8, 2003 Sorry for not being specific. I was trying to be general. I guess it all comes down to is "how can I change SOP parameters when an event happens in POPs". Super snazy example.... Two objects connected to a switch, when a particle hits generate an event that switches between the two objects. Simple setup.... In SOPs, a box and a sphere both connected to a switch. (All default params). In POPs, location source... Coords, (2,0,0) Impulse Act. $F==1 Impulse Birth 1 Const. Act. 0 Velocity (-2,0,0) Variance (0,0,0) Connected to Collision POP Set the collision object to the Box Sop. Nice and simple setup. Now when the particle collides with the box, I want the switch parameter to change from the box to the sphere. ...Now to be greedy I would like the sphere to have some additional attributes....like, what frame collision occured at. I tried a bunch of different things but have not found a nice solution. My two approaches so far have been the following. Add a POP sop, then use the following expression for the switch channel. if(iscollided("../pop1",0), 1, 0).. if a collision then set the switch to 1 otherwise to 0. Now this works..but only for the frame that the collision occurs... Second approach was to write a custom expression which on the collision event [popevent("smackdown")], and if true use opparm and chcommit to set a keyframe on the switch SOP. While this worked if I started changing the particle's speed and stuff I would end up with lots of keyframes and it would get messy quick. Plus it would be nice if all this is was done procedurally. Any ideas? Jason. Quote Link to comment Share on other sites More sharing options...
Marc Posted January 8, 2003 Share Posted January 8, 2003 Sorry for not being specific. I was trying to be general. hehehe.... now that's funny..... sofunnyinfactthatIdecidedtouseitformysig Quote Link to comment Share on other sites More sharing options...
Marc Posted January 8, 2003 Share Posted January 8, 2003 ....*ahem*... as to your problem though. I'm assuming that iscollided returns back to zero after the collision frame, and therefore the sphere changes back? Why don't you try using one of the other attributes? For instance, hittime returns -1 until it hits something. So inside pops you could create an attribute that is equal to $HITTIME, and then say if($MYHITTIME > -1, blah, blah....) Not having actually tried your setup though, I can't really say . But in theory it should work. Cheers marc Quote Link to comment Share on other sites More sharing options...
anakin78z Posted January 8, 2003 Share Posted January 8, 2003 isn't there also something called $HASHIT? I recall seing it in the group sop, as one of the default options for grouping... I probably should just fire up houdini to check it out..... Lazyness got the better of me. Quote Link to comment Share on other sites More sharing options...
plan9 Posted January 8, 2003 Share Posted January 8, 2003 "isn't there also something called $HASHIT?" err ok that looks funny value of "ha shit?" iam shameless!! Quote Link to comment Share on other sites More sharing options...
Jason Caleb Posted January 8, 2003 Author Share Posted January 8, 2003 Thanks for tid-bits... Alright! I'm quoted in a sig... Why is it so easy to over complicate something? Here is another question. Say you have a 10 particles controlling the movement of boxes. Box SOP connected to a copy SOP with a POP SOP as the template. Now, have another particle system shooting particles at these moving Boxes. When one of these particles collides with a box have the particle controlling the box's movement to stop. I tried a couple of things but they all ended in Collision Error or Infinite Recurrsion Messages. Any takers? Jason. Quote Link to comment Share on other sites More sharing options...
plan9 Posted January 9, 2003 Share Posted January 9, 2003 "have another particle system shooting particles at these moving Boxes. When one of these particles collides with a box have the particle controlling the box's movement to stop. I tried a couple of things but they all ended in Collision Error or Infinite Recurrsion Messages. " interesting, id give RBDs a whirl as the particle collides with the box, & the box stops. keep the previous setup as POPs collisions. of course, in theory it works. Quote Link to comment Share on other sites More sharing options...
Jason Caleb Posted January 10, 2003 Author Share Posted January 10, 2003 I'll try RBDs next...I'm stubborn so I want to try everything... I attached an example file. It shows off the two basic problems I'm having. Just jump into POPs and advance a few frames. What is suppose to happen is the shooter particle collides with the box which causes the target particle to stop. Seems simple...but it keeps kicking me in the head. In SOPs there is a switch SOP to show off the two different problems. I added comments to most of the OPs so it should be easy to see whats going on. I'll try RBDs after I get done watching CSI Jason. jc_Test.hipnc Quote Link to comment Share on other sites More sharing options...
Mamoru Posted January 10, 2003 Share Posted January 10, 2003 In SOPs there is a switch SOP to show off the two different problems.I added comments to most of the OPs so it should be easy to see whats going on. I'll try RBDs after I get done watching CSI Hmmm. I can see how this could be a bit confusing. When your switch1 sop is set to 1, then it is cooking pop2, which cooks the state1 pop. This, in turn, cooks the collision pop, which attempts to cook the copy1 sop which is actually referencing the pop2 sop. If the switch1 sop is set to 0, then it is cooking pop1, which only cooks up to the collect1 pop, and so the collision and hence stop doesn't occur. To get this to work the way you want to, just copy and paste the entire sop network, and on the copy of switch1, ie. switch2, set it to 1, and it should do what you want when you display copy2. Hope that helps. Mamoru Quote Link to comment Share on other sites More sharing options...
Jason Caleb Posted January 10, 2003 Author Share Posted January 10, 2003 Interesting....very interesting.... When I first read you message I was thinking you missed my point concerning the switch OP. I had put that in there to show off two seperate problems I was having, nothing more. But I tried what you said and sure enough it works. The only problem that I see is that it only works up until the first collision. After the first collision the box stops like it is suppose to, however the collision box (which is still controlled by the collect POP) keeps on moving. So any other particles flying around in space would collide with the phantom box. Am I beating a dead horse? Jason. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.