Hi,

Sorry for the lame question, but how do I access attributes in the Attrib Wrangler SOP from anything than the 1st input?

cheers

You can use a function to pull what you want out of the inputs. Have a look at the Wave tank object_fluid1 object. It does this:


// Copy attributes from particles to surface
int handle;

handle = pcopen(@OpInput2, “P”, @P, 1000, 1);
@v = pcfilter(handle, “v”);
// @Cd = pcfilter(handle, “Cd”);
pcclose(handle);

Thanks for the info – although I was afraid of the answer is going to be something like this (my guess was getattribute(), though ).

If you allow me some criticism (intended to be constructive), the problem with this is that although this solution works for particular cases, it's not as elegant as the ‘@’ notation that seems to be preserved for the 1st input only.

The elegance of the ‘@’ notation is that you don't have to know what class you're working with (point, primitive, vertex, detail), and your code will still be the same.

You think I could ask an RFE for this? A shorthand syntax for the other inputs would make the wrangle node(s) even more powerful. (Though I'm aware this would make sense only if all input geometry had the same topology… probably there's other related issues to think about here, too… hm hmm…)

Anyhow, let's say I'm just thinking out loud about having an unified syntax for those non-primary inputs… In the meantime I'll dig into those fluid OPs, perhaps I'll find some other tricks of the trade in the wrangle business Thanks for the help!

Cheers

If there will be a new syntax, here is an idea:

@Cd(2)

To get the Cd attribute from the second input.

@attribute(inputNumber)

if left out, then it's implicitly the first input just like now.

I thought I would post this if people were looking for some syntax ideas.

You would use getattribute if you needed attributes directly as opposed to a point cloud lookup. The Attrib vop works the same way, you either use Bind or GetAttrib.

Previously I had troubles with getattribute() in an AttribWrangler SOP, but after giving it the good ol' time-and-patience combo, it seems to be working for me. Examples:

Getting the Cd attribute from second input (point class):

getattribute(@OpInput2, @Cd, “point”, “Cd”, @ptnum, @vtxnum);

Same but for primitive class:

getattribute(@OpInput2, @Cd, “primitive”, “Cd”, @primnum, @vtxnum)

Add some hscript-expressions as syntactic pepper, and you have a line that works for both points and primitives:

getattribute(@OpInput2, @Cd, “`chs(”class“)`”, “Cd”, @`ifs(!strcmp(chs(“class”),“point”),“pt”,“prim”)`num, @vtxnum);

My apologies for the last one – but it truly works! Although I doubt anyone would want to conjure that up each time a class-independent getattribute is needed.

My vote goes for @Cd(2) instead…

Not context-flexible, but I would think that most of the time you're looking for this:

point(@OpInput2, “Cd”, @ptnum);

riviera
Add some hscript-expressions as syntactic pepper, and you have a line that works for both points and primitives:

getattribute(@OpInput2, @Cd, “`chs(”class“)`”, “Cd”, @`ifs(!strcmp(chs(“class”),“point”),“pt”,“prim”)`num, @vtxnum);

Heh - that's pretty clever.

In general, does evaluating HScript within a wrangle node like that slow things down? Or is the HScript evaluated before the VEX gets compiled? And how the hell does that work if you have backticked HScript within a VEX loop, or something?

zachlewis

riviera
In general, does evaluating HScript within a wrangle node like that slow things down? Or is the HScript evaluated before the VEX gets compiled? And how the hell does that work if you have backticked HScript within a VEX loop, or something?

Gets evaluated when the vex is compiled.

You can see exactly what is happening if you dive inside the asset and RMB on the VOP SOP and choose: View VEX Code…

In the View Code dialog, your code passed in to the Snippet VOP (which is actually supplying the UI at the top) is declared as a void expression with a unique name to the path to this VOP.

As you can see the hscript has already evaluated and constructed the correct result in this void function.

Hi

I wanted to push this thread a bit further , with the point sop you can use attribute match and then select your attribute. How would you replicate this in the wrangle sop.

Rob

match by attribute will find the point in second input whose attribute value matches that attribute value of current point of first input
so if your matching attribute is id then basically this
int matching_pt = findattribval(@OpInput2, “point”, “id”, @id);
now you can import any attribute from that matching point of second input and you should have the same result as with Point SOP

Thanks ,

I have been trying to get my next part running without success

// turn on point matching and look at the 2nd inputs id attribute

int matching_pt = findattribval(@OpInput2, “point”, “id”, @id);

// Then in point sop workflow I would add $TX2 , $TY2 , $TZ2 . I thought ok so as we are using point matching now id will be used instead of the default ptnum in the second input I would add

@P = point(@OpInput2, “P” , @id);

Thinking P will now get its value from the 2nd inputs “P” and match to Id . But something is not correct with my vex !

Rob

well, the ptnumber of matching point is stored in matching_pt variable, so you need to use that to import the attribute you want

int matching_pt = findattribval(@OpInput2, “point”, “id”, @id);
@P = point(@OpInput2, “P” , matching_pt);

Thanks Tomas ! , so much to learn with vex , keeping in tune with the attribute line of questions

v@position_real = @P;
addvariablename(“pos_real”,“POS_REAL”);

The above returns in the details view pos_realpos_realpos_real If I declared the attribute as a vector surely is should be pos_realpos_realpos_real . As when using a attribute create sop set to vector with values $TX,$TY,$TZ .


Rob

maybe for that you'd need to use
addattribute(“pos_real”, @P, “type”, “vector”);
addvariablename(“pos_real”,“POS_REAL”);

tamte
match by attribute will find the point in second input whose attribute value matches that attribute value of current point of first input
so if your matching attribute is id then basically this
int matching_pt = findattribval(@OpInput2, “point”, “id”, @id);
now you can import any attribute from that matching point of second input and you should have the same result as with Point SOP

:shock: Thank you Tomas!!!

I refuse to give up my stabbing around in the dark ! thanks Tomas

Rob