[Sidefx-houdini-list] I3d Opacity

Louis louis at realisestudio.com
Tue Aug 8 06:48:29 EDT 2006

The only slightly off context thing I would like to add to this is that 
in DOPs, local variables are very sparse indeed apart from things like 
the RBD State DOP where you do have local variables for things like 
velocity position acceleration and very standard data like that.  
Creating your own custom data/attributes becomes quite cumbersome 
indeed. Also, the fact that you need to express vectors (not only) as 
strings makes it all a bit painful at the moment. Of course, DOPs is 
very much in it's own world! Seeing as it's spiffingly brand new, I 
thought I'd throw that out there again. Anybody else come across this?

But yes, more local variables are great! A good trick (in case it's not 
crystal clear already) to re-create local variables for an attribute 
"foo" that already exists is just to put down an Attribute Create SOP 
with $FOO in the value field. Better than having to muck around with 
something like point(opinputpath(".",0),$PT,"foo",0) etc etc..


Peter Bowmar wrote:
> Hey Pablo,
>   Actually, SOPs not supported local variable in all SOPs is due to
> SOPs being written first, long before the concept of having local
> variables existed. The POPs engine was written specifically with local
> variables in mind, the SOPs were "retro-fitted" to support them, but
> as you notice, not all SOPs use them. This is mostly due to those SOPs
> not having the work done on them. Some SOPs just don't make sense to
> have local variables but generally the ones that do make sense, do
> have the ability to use them.
> Cheers,
> Peter B
> On 07/08/06, Pablo Giménez <pablogipi at gmail.com> wrote:
>> Hi Andrew, thanks for your complete reply.
>> Only to add my 2 cents to this discussion, I think that the only
>> reason to use Local variables instead of global variables in context
>> is memory.
>> The only thing, I think, that Andrew firget to say is why you can't
>> access to some variables in some circustances.
>> In Houdini there are some global variable, like $F, $FF, $FEND, $T, 
>> etc ...
>> But the variables that map attributes, regardless the context, are
>> always local, this means that are only availablr if the operator
>> enables it.
>> This problems is very noticiable in SOP context where always you can
>> find the problem to not be able to acces easily to an attribute
>> because the SOP you are using doesn't crate the local variable, then
>> you have two options:
>> - Use the point() expression: horrible and you need to have access to
>> the $PT variable.
>> - Use Attribute Create SOP: this actually creates global variables
>> instead of local variables.
>> In POP context is the same problem, the onlyu difference is that
>> almost all (ALMOST) POP operators creates the needed local variables,
>> but for example if you create your own VEX POP operator, because the
>> variables are local, you can't access to the $LIFE, $AGE, $V, etc ...
>> you have to use an Attribute POP  prior to your VEX POP to create
>> another global varible that maps to your needed attribute.
>> So, like Andrew have said, we have the problem to not be able to
>> access easily tou our date everytime, everywhere.
>> The only two reasons because I think SESI do this in this way are:
>> - Memory: to have all the attributes mapped to global variables needs
>> memory all the time to mantein these.
>> - The want to avois to have so much global variables.
>> Finally I am agree with andrew, much of the time we want to have an
>> easy access to our data so I think that to have automatically global
>> variables to all of our attributes will be solution.
>> -- 
>> Un saludo
>> Best Regards
>> Pablo Giménez
>> _______________________________________________
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list

More information about the Sidefx-houdini-list mailing list