Can someone help me make sense of how and where certain variables are accessible in Houdini?

I was recently trying to increase transparency of a particle as it neared death, and I found that I couldn't access the $LIFE variable in the color POP, from which I wanted to pass over the alpha channel into the SHOP. I couldn't get the poppoint() function to access this variable either. I ended up having to use a point() function in a point SOP to alter the alpha channel from there.

Could someone help me understand why the original approach of accessing the $LIFE variable from a color POP to pass to the shader wasn't working? Is the point SOP really the only way to go about increasing transparency with a particle's age?

Thanks

Perhaps you could specify how exactly you were trying to use the $LIFE variable. It should work fine.

If you're using a ramp to vary the color over life just type $LIFE in the lookup field, still would help to know how and where u're using the $LIFE variable tough

cheers
tallkien

I guess I wasn't as clear about my problem as I had originally thought. I was trying to use the alpha value in the color POP to drive the opacity of the shader I'm applying to metaballs in my scene. It appears that $LIFE was being read fine by the color POP. The problem was that only a single value was being passed to the opacity channel of the SHOP rather than a different value for each point/particle, or so it seems.

I'm not sure that I fully understand the problem, and I found a workaround using a point POP with a point() function calling the life of the particles. I just wondered if someone could help me understand what I clearly don't grasp quite yet: the rules in Houdini for passing data from one network to the other.

I would really appreciate a good explanation of this aspect of houdini, or perhaps just pointing me to a good reference that explains it well.

Thanks

Ah I see. If you MMB on the SHOP in question, you'll see a list of Parameters in the popup window. These are the internal names of the arguments to the shader. If your geometry has attributes of these names, then those values will be used as the arguments for the shader. I'm not sure how you instanced your metaballs on the particles, but if you used the copy sop, there is an Attribute tab. Make sure that the “Copy Template Point Attributes” parameter is toggled on in the tab.

If we use the constant SHOP as an example, one of its arguments is “alpha”. Unfortunately, the default alpha attribute created by POPs is called “Alpha”, and because of case-sensitivity, this can mess you up. To fix this, you can use an attribute SOP to rename the “Alpha” attribute to the “alpha” attribute, and you should be good to go.

Hope this helps.

hi there!
i have a similar problem but i want to use the color pop's ramp on the fog color of a VEX 3D Texture Fog shader. is this possible (as the shader gets it's source data from i3d files theres no direct link to the pop)?

what i did: i created a particle simulation, and copied metaballs onto the particles using the copy sop. i then rendered .i3d textures and used them in the 3d texture fog shader.

many thanks in advance

Actually, this is one the biggest hurdles you can encounter in learning Houdini. I've seen many people very confused about which variables are available in which Op. Once you get used to $PT and $PR in the Point or Primitive SOPs, you kinda assume they're available everywhere and it takes quite a while to learn about which Ops support which variables. It would be ideal if $PT and $PR and such were supported across all SOPs, but do to the manner in which some of the Ops process geometry, this cannot be the case. In POPs you are always handling particles and so all POPs process the particles one by one. In SOPs, there are many Ops which process geometry of various types in various ways.

That being said, there are some steps SESI could take to prevent this confusion, either by making more of the SOPs attempt to support more local variables (say, the Blend (or Seq Blend) SOPs could support $PT or point-attribute mapped local variables - this could make it easy to do something which make require a custom VEXsop to do this otherwise), or somehow make it easier, either by documentation or categorisation, to know which type of SOP iterates over points as opposed to iterating over primitives. I realise that making some of these SOPs support more local variables may slow them down a bit, but it may be worth it. If not, perhaps there is some way to label/group SOPs which have them available?

I field a lot of questions to Houdini newcomers at my place of work which relate to which variables are available where and only a ton of experience with all the SOPs helps. Newcomers to Houdini will struggle with knowing the limitations of each SOPs until this is sorted, I think. This is part of the voodoo of Houdini.

Anyone else have comments on these thoughts?

Cheers,
Jason

I just re-read my previous reply and realised that it doesn't really help you

POPs is the easiest context to learn about the variables since all particle attributes have local variables defined in ALL the POP operations. The only things to learn are the additional POP-specific local variables, like say, the orbit axis in the Orbit POP.

I'd recommend you go through all the SOPs and examine how they work while looking at the available local variables in the help-card. Just looking at the local variables, you can kind of tell how the SOP is processing the geometry. You seem to get a couple of types of algorithms - those that process point-by-point, primitive-by-primitive, or “other” (like the Poly* modeling operations). The quintessential ops for these are the Point SOP and the Primitive SOP. After that, only some common sense will help.

thanks a lot for the insight
after digging around in the help cards i think i'm beginning to understand now (i understood, that i still have to learn a lot )
i'll continue doing some research and hope i'll find a workaround

thanks again