[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