sorry for the basic question but what is the obvious reason why this isn't working. I can't seem to get a point attribute from a POP to a SOP, but from SOP-to-SOP works just fine (using the delete SOP)
So, how does one promote an attribute create from a pop to a sop (example attached, “turn me on and off” is what I don't understand, it should be the same variable)
basic question, why delete can't recognise attribute
3823 6 1- andrewlowell
- Member
- 537 posts
- Joined: Dec. 2005
- Offline
- edward
- Member
- 7725 posts
- Joined: July 2005
- Online
- andrewlowell
- Member
- 537 posts
- Joined: Dec. 2005
- Offline
- edward
- Member
- 7725 posts
- Joined: July 2005
- Online
I tried 8.1.802 and 8.1.866. I load the hip file and I note that there's no points in the spawnParticleCollisions SOP. I didn't look into why. Anyhow, so I hit play until there's a point generated. Then I middle-click on the delete1 SOP and note that the point was deleted. No errors on anything that I can see.
- andrewlowell
- Member
- 537 posts
- Joined: Dec. 2005
- Offline
thanks emmensly for taking the time to look it over .. I hate asking basic questions like this but I tried for hours last night and searched many forums so I think I'm still missing something.
When the “turn me on and off” node is turned off, there should be an error on the delete saying that it cannot recognise the local variable. the “turn me on and off” node is a test to make sure the expression is correct for the delete …
Inside the pop network I'm attempting to set that local variable, with no luck. It shows up in the details view, but the delete can't seem to get it.
When the “turn me on and off” node is turned off, there should be an error on the delete saying that it cannot recognise the local variable. the “turn me on and off” node is a test to make sure the expression is correct for the delete …
Inside the pop network I'm attempting to set that local variable, with no luck. It shows up in the details view, but the delete can't seem to get it.
- edward
- Member
- 7725 posts
- Joined: July 2005
- Online
Ah ok, I see what you're saying now. By turning “off” you mean “bypassing” it. The reason why you need the AttribCreate SOP I think is mostly tied with historical implementation decisions.
In POPs, the local variables are added as “context data” which is owned by the POP Network SOP itself. Inside this “context data” is also the actual particle geometry. So this particle geometry is pushed through the whole POP network each time it cooks for the next frame. When a POP parameter is evaluated, the local variable is looked up through the POP Network's context data in order to find the attribute value to return.
Now enter in SOPs. Each SOP has its own copy of the geometry data and are largely independent. They don't share any context data. so for SOPs, it was implemented differently. Instead of storing the local variable to attribute mapping inside some global “context data”, it is stored inside the geometry data itself as a specially named detail attribute. When a SOP parameter is evaluated, it looks through this detail attribute (called “varmap” which is created by the AttribCreate SOP) in order to find the value of the variable. This varmap attribute simply gets copied from SOP to SOP with the regular geometry data.
So basically, they use completely different local variable lookup mechanisms. I'm pretty sure there's been requests for this gap to be bridged already logged. There's a couple of possible ways to fix this but no one has yet. In the meantime, you'll need to bridge them manually using AttribCreate SOPs.
In POPs, the local variables are added as “context data” which is owned by the POP Network SOP itself. Inside this “context data” is also the actual particle geometry. So this particle geometry is pushed through the whole POP network each time it cooks for the next frame. When a POP parameter is evaluated, the local variable is looked up through the POP Network's context data in order to find the attribute value to return.
Now enter in SOPs. Each SOP has its own copy of the geometry data and are largely independent. They don't share any context data. so for SOPs, it was implemented differently. Instead of storing the local variable to attribute mapping inside some global “context data”, it is stored inside the geometry data itself as a specially named detail attribute. When a SOP parameter is evaluated, it looks through this detail attribute (called “varmap” which is created by the AttribCreate SOP) in order to find the value of the variable. This varmap attribute simply gets copied from SOP to SOP with the regular geometry data.
So basically, they use completely different local variable lookup mechanisms. I'm pretty sure there's been requests for this gap to be bridged already logged. There's a couple of possible ways to fix this but no one has yet. In the meantime, you'll need to bridge them manually using AttribCreate SOPs.
- andrewlowell
- Member
- 537 posts
- Joined: Dec. 2005
- Offline
-
- Quick Links