[Sidefx-houdini-list] get attribute from second input

Gary Jaeger gary at corestudio.com
Fri Sep 1 23:38:54 EDT 2017


Thanks everybody. Much to digest. 

Gary Jaeger / 650.728.7957 direct / 415.518.1419 mobile
http://corestudio.com <http://corestudio.com/>

> On Sep 1, 2017, at 1:16 PM, Gregory Ecker <gregory.ecker at gmail.com> wrote:
> 
> 
> There's also another gotcha where if you reference an attribute  that doesn't exist,  it doesn't throw an error,  it just returns 0,  and creates that attribute for you !  Ouch.  This can be confusing.  Stick with the functions for now.
> 
> -G
> 
>> On Sep 1, 2017, at 2:32 PM, Tom Nixon <ignivomous at gmail.com> wrote:
>> 
>> Looks like you're in good hands with Gregory and Andy. I'd just like to
>> point out another gotcha for anyone who is tempted to use opinput syntax.
>> 
>> When specifying the input from which to read, @OpInput1 is the 0th input.
>> - eg. point(@OpInput2,"P", at ptnum) is the same as point(1,"P", at ptnum)
>> 
>> When using @opinput1_Cd, it pulls from the second input, so not only does
>> the index change in this instance, but also capitalization.
>> 
>> This inconsistency can bite you in the arse when you've not used one of the
>> cases in a long while. As Andy says, making it explicit is probably safest.
>> That being said, I tend to use the @OpInput1 syntax most often because some
>> more rarely used functions have numerous integer arguments, and I find it
>> easier to have the reminder right there of which is the input argument.
>> 
>> On Fri, Sep 1, 2017 at 11:10 AM, Andy Nicholas <andy at andynicholas.com>
>> wrote:
>> 
>>> I agree with Gregory. Although personally, I would always encourage
>>> avoiding VEX’s syntactical idiosyncrasies in favour of straightforward
>>> function calls and variable definitions.
>>> 
>>> So I always use
>>> 
>>>       vector @my_attr;
>>>       @my_attr = point(1,”P”, @ptnum);
>>> 
>>> instead of
>>> 
>>>       v at my_attr = @opinput1_P
>>> 
>>> All sorts of reasons really. To name a few:
>>> * Do you put the v in front of the @ all the time?
>>> * If not, what happens if you delete the line(s) where you did? Your
>>> attribute is now assumed to be a float. Oops.
>>> * If you do use it all the time, then if you ever want to change the
>>> variable type you have to do it in multiple places.
>>> * All other variables are declared using the longer syntax, so I like to
>>> be consistent with attributes too.
>>> * The @opinput_ syntax makes too many implicit assumptions for my liking:
>>> 1) That I want to iterate over the current entity (e.g. points in this
>>> case), and
>>> 2) that I want to use @ptnum to do it.
>>> I prefer to put this explicitly in my code. Particularly because it can
>>> cause a lot of confusion if you’re used to frequently switching between VEX
>>> contexts (vertices, points, primitives, etc). If you’re copy/pasting code
>>> you have to remember which ones you need to change and which ones you need
>>> to be kept to the original entity (more of an issue in longer VEX scripts).
>>> * Writing it out the long way has more similarity to other languages (e.g.
>>> C/C++) so it’s easier for people not familiar with VEX to get up to speed,
>>> as well as being easier to convert (if necessary) to another language with
>>> a few simple search/replace operations.
>>> * I have a crappy memory for whether the @opinputN_ starts at 0 or 1.
>>> Whenever it comes up I always ask myself: if they made that bit of
>>> syntactical convenience, did they go further and make it more intuitive by
>>> starting at 1? Whereas with the point() function I know I'm firmly in
>>> programmer territory where everything always starts at zero :)
>>> 
>>> To be honest, if you’re just writing 15 line VEX snippets or shorter then
>>> I really don’t think it’s much of a problem. It’s just when you’re putting
>>> together something bigger that you start to notice these issues more.
>>> 
>>> Again, this is all just personal preference. I don’t pretend to believe
>>> that it’s some sort of gold standard (…I’m lying, I do).
>>> 
>>> Cheers!
>>> A
>>> 
>>> 
>>>> On 1 Sep 2017, at 18:22, Gregory Ecker <gregory.ecker at gmail.com> wrote:
>>>> 
>>>> 
>>>> I would say if you're just starting out,  use the point function until
>>> you get a handle on it.  So:
>>>> 
>>>> 'vector mycd = point(1, "Cd", @ptnum)'
>>>> 
>>>> Is the same as '@opinput1_Cd'.
>>>> 
>>>> -G
>>>> 
>>>>> On Sep 1, 2017, at 10:41 AM, Gary Jaeger <gary at corestudio.com> wrote:
>>>>> 
>>>>> Thanks Zoran. Have seen it but not watched it. Will do that now.
>>>>> 
>>>>> Gary Jaeger // Core Studio
>>>>> <x-apple-data-detectors://0/0>249 Princeton Avenue
>>>>> <x-apple-data-detectors://0/0>
>>>>> Half Moon Bay, CA 94019 <x-apple-data-detectors://0/0>
>>>>> 650.728.7957 (direct)
>>>>> 650.728.7060 (main)
>>>>> http://corestudio.com
>>>>> 
>>>>> On Sep 1, 2017, at 7:19 AM, Zoran Arizanovic <
>>> zoran.arizanovic at gmail.com>
>>>>> wrote:
>>>>> 
>>>>> Did you see this Gary
>>>>> https://www.sidefx.com/tutorials/houdini-illume-webinar-vex/
>>>>> here Jeff Wagner explains when to use point and it has lots of nicely
>>>>> documented files with it
>>>>> helped me a lot with vex
>>>>> 
>>>>> 
>>>>> Zoran Arizanovic
>>>>> LinkedIn <http://www.linkedin.com/pub/zoran-arizanovic/4/177/295>
>>>>> 
>>>>> 
>>>>> On Fri, Sep 1, 2017 at 4:10 PM, Gary Jaeger <gary at corestudio.com>
>>> wrote:
>>>>> 
>>>>> Thanks Gregory (or just G!)-
>>>>> 
>>>>> 
>>>>> I think that makes sense. As you can probably tell I’m new at this. But
>>>>> 
>>>>> then what about Cd?
>>>>> 
>>>>> 
>>>>> I’m probably thinking about this all wrong, but really I was just
>>> messing
>>>>> 
>>>>> about trying different vex things to get my head around it. So when I
>>> did
>>>>> 
>>>>> @ptnum/@numpt to get a ramp on a grid I thought I’d do a sort on the
>>> grid
>>>>> 
>>>>> points to see what different results looked like. I took the output of
>>> the
>>>>> 
>>>>> sort into input 1 on my wrangle and wanted to mess around mixing the
>>> two.
>>>>> 
>>>>> 
>>>>> Something like @Cd = @Cd.r + @Cd.g(opinput1) i.e. make the color = (red
>>> of
>>>>> 
>>>>> input 0 + green of input 1)
>>>>> 
>>>>> 
>>>>> Gary Jaeger / 650.728.7957 direct / 415.518.1419 mobile
>>>>> 
>>>>> http://corestudio.com <http://corestudio.com/>
>>>>> 
>>>>> 
>>>>> On Aug 31, 2017, at 10:50 PM, Gregory Ecker <gregory.ecker at gmail.com>
>>>>> 
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> When you access attributes like this (i.e. With the 'op' syntax),  the
>>>>> 
>>>>> assumption is that the ptnums match between the inputs.  So if you are
>>>>> 
>>>>> accessing '@opinput1_Cd',  you are accessing the Cd attribute for the
>>> point
>>>>> 
>>>>> which matches the ptnum of the point currently being processed (when in
>>>>> 
>>>>> points mode).  In fact it doesn't make sense to access the 'ptnum'
>>>>> 
>>>>> attribute at all,  as you know what it will be ( always 0 through
>>>>> 
>>>>> numpoints-1).  Another way to think about it is that the wrangle is
>>>>> 
>>>>> iterating over all the points,  and if you access an attribute from
>>> another
>>>>> 
>>>>> input,  you are processing the same point number in that input.  If you
>>>>> 
>>>>> want to access a different point number from the second input ,  you can
>>>>> 
>>>>> use the 'point' function.
>>>>> 
>>>>> 
>>>>> -G
>>>>> 
>>>>> 
>>>>> On Sep 1, 2017, at 1:21 AM, Gary Jaeger <gary at corestudio.com> wrote:
>>>>> 
>>>>> 
>>>>> Hi. I’m struggling with the syntax of getting an attribute from the
>>>>> 
>>>>> second input of an attribwrangle. Say I have declared this
>>>>> 
>>>>> 
>>>>> f at ptn = @ptnum;
>>>>> 
>>>>> 
>>>>> in my snippet and it’s working fine. But now I want ptnum from input 1.
>>>>> 
>>>>> I’ve read the docs but I’m not getting it. My pea brain says it should
>>> just
>>>>> 
>>>>> be
>>>>> 
>>>>> 
>>>>> f at ptn = @ptnum(@opinput1) or @(1)ptnum but obviously those don't work.
>>>>> 
>>>>> Help!
>>>>> 
>>>>> 
>>>>> Gary Jaeger / 650.728.7957 direct / 415.518.1419 mobile
>>>>> 
>>>>> http://corestudio.com <http://corestudio.com/>
>>>>> 
>>>>> _______________________________________________
>>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 
>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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