Is @opinput1_P.y a valid thing to want to do?

It seems that it makes houdini quite angry at the moment.

since P is a vector you need to use
v@opinput1_P.y

We have a list of auto-guess names which go to specific types. P is one of them, so @P goes straight to vector without v@P.

This system doesn't know about the @opinput_ prefix, so @opinput1_P binds as a float.

jlait
We have a list of auto-guess names which go to specific types. P is one of them, so @P goes straight to vector without v@P.

This system doesn't know about the @opinput_ prefix, so @opinput1_P binds as a float.

Thanks for the input gents.

I think it might be worth considering extending the auto-guessing to the sub-components of the ‘globals’.

G

subcomponents are fine, you can use @P.y with no problems
what Jeff meant is that auto-guessing is not yet applied to other inputs bound with @opinput prefix, so for those you need to precisely specify the type for now

tamte
subcomponents are fine, you can use @P.y with no problems
what Jeff meant is that auto-guessing is not yet applied to other inputs bound with @opinput prefix, so for those you need to precisely specify the type for now

I'm talking about @y = @opinput1_P.y (which, doesn't not work).

@y = v@opinput1_P.y works.

G

exactly

what I meant is that it's not about subcomponents, but about extending auto-guessing for the same attributes with @opinputX prefix as well
which might have been what you wanted to say

what is this @opinput1_ voodoo?

Does that syntax work with any input and attribute?

great stuff

Similar to how you can say
@group_foo
to create a binding to the group “foo”, the
@opinput1_P
will create a binding to the second input's P attribute. This works with any attribute of matching type. The Attribute To Match parameter can be used to specify how to line up the two geometries. For example, you can use it to match by “id” attribute.

This voodoo was added to help replace the Point SOP. $TX2 was a common use case that was not cleanly handled in Attribute Wrangle, but now the Attribute Wrangle makes it even easier than the Point SOP.

jlait
Similar to how you can say
@group_foo
to create a binding to the group “foo”, the
@opinput1_P
will create a binding to the second input's P attribute. This works with any attribute of matching type. The Attribute To Match parameter can be used to specify how to line up the two geometries. For example, you can use it to match by “id” attribute.

This voodoo was added to help replace the Point SOP. $TX2 was a common use case that was not cleanly handled in Attribute Wrangle, but now the Attribute Wrangle makes it even easier than the Point SOP.

I think using 0 based indices for this new feature will create some confusion among new users. I assume it's done this way because of opinput:0 syntax but the string versions start from 1 and looks the same except the casing.

@opinput1_P -> Input 2
@OpInput1 -> Input 1

Something to consider.

I think using 0 based indices for this new feature will create some confusion among new users. I assume it's done this way because of opinput:0 syntax but the string versions start from 1 and looks the same except the casing.

This is an excellent point. All things should be 0-based all the time for consistency. :wink:

G

forget @OpInput1, that's not the droid you are looking for

just use zero based 0, 1, .. instead
so instead of npoints(@OpInput1); you simply use npoints(0);
pretend as if it never existed and your life will be easier and consistent

tamte
forget @OpInput1, that's not the droid you are looking for

just use zero based 0, 1, .. instead
so instead of npoints(@OpInput1); you simply use npoints(0);
pretend as if it never existed and your life will be easier and consistent

I agree, integer input indices are nicer to use but aren't there some VEX functions that only accepts a string input path? This forces us to be aware of which type to use. I can't remember all of them but I do come across some and report them to SESI.

For instance osd_* functions do not allow integer inputs:

osd_facecount(@OpInput1);

will work but:

osd_facecount(0);

will not compile.

I reported this one on Jan 30

pusat
…
there some VEX functions that only accepts a string input path?
…
osd_facecount(@OpInput1);
will work but:
osd_facecount(0);
will not compile.
…

in that case you can use:
osd_facecount(“opinput:0”);
to still stay zero based

thanks SESI for another quick fix

Wednesday, October 28, 2015
Houdini 15.0.278: The auto-binding of @opinput1_ prefixed attributes will now use the same type-guessing that is used with out the prefix. In particular, @opinput1_P will default to vector type.

tamte

pusat
…
there some VEX functions that only accepts a string input path?
…
osd_facecount(@OpInput1);
will work but:
osd_facecount(0);
will not compile.
…

in that case you can use:
osd_facecount(“opinput:0”);
to still stay zero based

Yes but this still has the mental load of @OpInput1, and some people could call you out for not using @OnInput1 since it's more common.

Another thing, I think, such as addpoint(geohandle,..) should be simplified as addpoint(…). I can't find any usage about geohandle.

jerry7
Another thing, I think, such as addpoint(geohandle,..) should be simplified as addpoint(…). I can't find any usage about geohandle.

maybe not yet, but once you are able to specify other outputs or filename as a geohandle it will start making sense

don't want to hijac such an important thread

is there another somewhere with more info (and hopefully examples) of the @group_foo syntax in use?

http://www.sidefx.com/docs/houdini15.0/vex/snippets#idm140552840297168 [sidefx.com]
not sure what more you need
@group_foo = 1; assigns current element to group named foo, group type depends on current class
@group_foo = 0; removes current element from group
@group_foo; returns 1 if current element is in the group foo and 0 if not
so then
if (@group_foo) @Cd = {1,0,0}; sets color to red if element is in the group foo