bobbybob

I just found that I can use the "Remove inline points, Distance" to do this, but it would be nice to know why the lines are "connected" even if they are made unique with the facet sop, just to get a better understanding of how the geometry works

Hi I have a polygon circle, arc type: Sliced arc. I'am trying to remove all the lines by the red markings (see image) so I only have the lines going from mid and out. I have tried to use a facet node, to create unique points, but when I blast the outer lines, the lines that goes from the center also get deleted.

Thanks @ThomasPara

Hi everyone Is it possible to tell how many lines/edges a point is "attached" to?

Thanks @doc

Hi When simulation cloth I often think that adding some thickness to the cloth looks much better then just rendering a flat plane. But what is best practices when adding thickness? To extrude the plane before simulating and adding load on the simulation, or adding it afterwards? I am asking this because I am having a hard time controlling uvs, intersections and adding bevel to the plane after its simulated, because it is in constant change...

Is it possible to not "record" display flag changes when editing a take?

How is it possible to have two (High viscosity) fluids interact with each other, without mixing. Not mixing in the dop's or mixing in the "Particle fluid surface". I am trying to arrive at a result that have the quality of this: See image

Is it possible to create some kind of attribute like "curveu" that takes branching into account when creating lines with L-System. I am trying to generate polywire on the lines generated by the L-System, so that the bottom trunk will be the thickest and the tip of the branches will be thin.

How can I open a Python panel from a shelf item/icon, In a new floating panel?

I have a Vellum sphere bounce at the floor, where I simulate hair on. The hair is interpenetrating at some areas. How can I reduce the interpenetration? hair_interpenetration.hipnc

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