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

Gregory Ecker gregory.ecker at gmail.com
Fri Sep 1 16:16:32 EDT 2017


 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



More information about the Sidefx-houdini-list mailing list