bobbybob

So just to understand 100% Maybe I just don't understand the way Houdini has implemented vex, but it makes sense to you that we can create a material node, that create the attribute "shop_materialpath" of type string, and we from vex itself, at run time are able to access that attribute and get the type of that it?, but to read from it, we need to define it again? Because it makes absolutely no sense to me. I am sure that you know Houdini much better then me. I know programming, and from a programmers standpoint it makes no sense do declare a variable that already exist...

Hmm I am not completely sure what you are trying to say here. but let me try to explain. I edited some of my ansvar out after I posted the last post, and I am not sure if you are replying to some of that, or it's just the part about defining the attribute that is already defined, but let me get back to that (It's normally not how it works) When you declare an attribute, you have to define it's type, as you said yourself, if you don't define a type Houdini will default to float. The type of the attribute will always be the same, as long as it lives. You don't need to specify the data type of an attribute when you wanna read from it, because it already has a data type. When you talk about that you need to define what type you wanna read from an attribute, I can see why you think this way, and it can be a bit tricky even if you have tried to code in other languages. This is actually because of the way Houdini have implemented the attributes in vex, because it's syntax is a bit different. When you do this: s@a = s@b; You are not asking to get value of "string" type from attribute b, you are actually declaring (creating) two attributes with the data type of string, and then giving "a" the value of "b" You will never need to define the data type that you need to have returned to you from a attribute, so the surprise that you mentioned will never happen. You can always print the type of the attribute via vex or take a look at the "node info" So back to the "shop_materialpath" issue. The thing here is not about the way programming works, or the vex compiler, I am talking about how the Houdini framework handle this. The string is defined as a string in Houdini. We have to "declare" it in vex, to read from it. That would make sense if vex could not see the attribute because it wasn't declared (declared in Houdini but not in vex), but we can still pull the data type of the attribute in vex without declaring it, you see, we can't pull the data type of an attribute that does not exist, and the datatype is returned, so when we then have to declare it again to read from it, it's a unnecessary step, you see? If you declare the "shop_materialpth" attribute as a float, after you created it with a material node, and then pull it's type it will still return that it's a string. This is not because you have a attribute that have no data type, btw

This is actually pretty interesting, the attribute "shop_materialpath" (when generated in Houdini) is a string, if you pull the type info of the attribute via Vex, before you specific it's type, it will return that it is of type "string", but you cannot read from it before you define it's type... Houdini's Vex compiler reads the type just fine, but it still insist that the user define the type... Is there a deeper mening of this? From a programmers standpoint, it really just looks like the programmer who implemented this was a bit lazy? :/ You can try this yourself: printf("Date type: %d\n", attribtype(0, "prim", "shop_materialpath"));

Well, normally in programming you are defining the data type of variables when you declare them. Languages like HLSL and GLSL is a bit different then Vex that way. It's simply not possible to change the type when it's defined. I don't think that Houdini ever would create an attribute and not give it a type. If Houdini creates a string attribute, you can be sure that the type of that attribute are of the type string, so this problem will only emerge if you get data from outside Houdini or, you don't define your own attributes correct. So no, "the fact that it is generated in another program is not the issue", but the issue will only arise when you get data from another program, or you write code that is not type safe yourself It would however be nice to get a warning if Houdini finds an attribute where no type is defined

So the answer is that the attribute are from geometry that is generated in another program, so the data type is not defined. I guess that Houdini is able to auto detect the type when it fetches the data to the spreadsheet, but the vex compiler are defaulting the data type to be a float. The solution is to tell vex the type when using the attribute. s@result = s@shop_materialpath;

Okay, that make sense I am trying to get the string value via Vex, but the attributes returns "0" event that the spreadsheet shows the correct string value, so I thought the "unique" value was a way to inform about the size of some kind of custom array structure.

I am trying to get the value of a string attribute, but it returns "0". I then noticed in the node info window that it was marked with "(4 unique)" What is this "unique"? how to handle it? I am just trying to get the string value that is represented in the spreadsheet.

How are you managing your caches? If I have 4-5 sims that builds on top of each other, all of them has a cache, and I change something in the first sim, I need to go and re-cache all the other caches (That maybe are located different places in my network). Are there a way to manage this "chain" of caches, so it's possible to have a better overview of all caches in the sim, and be able to quickly re-cache the sims that need it? What is a good workflow for this?

@toadstorm, the lines is still sharing points. I would like to have 4 lines, where no lines share it's points with other lines, so 8 points in total.

Is there an easy way to convert a grid with a res of 2x2 to 4 individual lines that does not share points?

@3dome, Ahh of course, the pop drag is instanced on every object. I thought it as a global value. Thank you so much, hurray for vex

@3dome, Is the "*" a way to reference all points? Because it's a RBD Packed, there could be more then one object? In a pop wrangle it would look like this Because it iterates over all the object, we could just reference the object we need to look at. But in the pop drags parameter, there is no way to know what object we are referring to... Is there a way to use something like the "point" vex function, to tell it to look at the position of "object 1"? Maybe I just don't understand the "*= @P.y" expression, can you elaborate?

Is it possible to control the activation parameter of a POP Drag, based on the position of a RBD Packed object? I am trying to activate a POP Drag, when a RBD Packed object is under a specific Y position.

Try using the position for calculating the length. If you create an attribute vop and use the UV as the color (at sop level), you can see why you are getting this distortion.

We can use a modify data node, and get the velocity data with the dopfield function/expression, and use it as a condition