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

Tom Nixon ignivomous at gmail.com
Fri Sep 1 14:32:07 EDT 2017


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
>



More information about the Sidefx-houdini-list mailing list