How can i retrieve the normals of a secondary object into the attribute VOP of an other geometry? I have a building shaped geometry (vertically rescaled cube) and i'm scatering geos onto its sides, but instead of using the cube's normals i'd rather have it follow the normals of a tube place in the center/core of that building, so thiungs get scattered/copied in a more circular fashion. I thought plugging the tube to the second input of the attribute VOP and forwarding that to the N would be enough, but apparently not.

Cheers,

A.

Is the second geometry identical in topology/point count? Only then can you reference the input's attributes by index in a predicable way. Any other input, you will need to define the relationship yourself. Is it one of proximity? Or one of direction? You can send rays with the intersect vop to find what surfaces are intersected along the ray. From there you can query any attribute from the intersected surface. If you want the closest surface, regardless of direction, you can use xyzdist to find the closet surface to a position, such as the “P” value of the current point. xyzdist outputs an index and coordinate to allow query of interpolated surface attributes, usually using the primuv function (primitive attribute vop).

A tube has a rather simple formula for its normal, so instead of trying to look it up from an input mesh, why not calculate the implied normal directly?


You could even derive tube center and axis from a connected input, since tube primitives have a transform intrinsic.

Thanks Jsmack.

Most parameters of The tube i'm generating in the core of that building for normals orientation purpose only are pasted references from the dimensions of the cube building, to make sure that all normals calculated between the two surfaces are circular horizontally at all heights of that building. So i think it's a relationship of orientation i'm trying to get. Now I figured i could also just look at the center point pivot of my building to do so instead of bringing a tube, but then i'd have to restrict the normals orientation to the Y axis in order to get circular horizontally aligned normals for every level of the building instead of spherical orientation like i'm getting now. I think i'm getting most of the logic behind this, just really don't know what nodes and structure to use in the VOPs to do so. I'm going to stay away from VEX for a bit longer if you don't mind. Vex leads to more Vex, which leads to more Vex, and before yo know it you're not pushing buttons anymore and start seeing everything around you as little green lines of codes floating down everywhere… creepy.

Cheers,

A.

The code snippet is easy to translate to nodes, it is much harder to paste nodes into a forum post.

Here is an example scene for how you might grab normals from a tube primitive, using no vex code!

This example might be more like what you are trying to achieve. A tube is resized, and translated to match the input squabe using the matchsize sop. Then attribvop does some magic to find tube normals, and an up axis from the tube major axis. A scatter, copytopoints, attribinteroplate later, and you've got teapots in circular orientations.

Thanks again, jsmack.

Needless to say your examples do exactly what i was trying to achieve. Much appreciated. I looked into the VOPs and some bits i understand, but I feel without a decent math background it is hard to come up with such nodes structure intuitively.

Cheers,

A.

I have to admit I have no math background other than highschool. Every bit of matrix and vector math I learned by trial and error in VOP networks just like this. So don't be discouraged if you don't understand it right away. I built this network without really knowing the correct solution, but I had enough houdini familiarity to know that things like a transform exists as a prim intrinsic, and was familiar with the concept of vector projection from past solutions to houdini problems. Even for this simple setup, I wired and rewired the network until I got the result I was expecting.

Thanks for sharing that insight, it's a bit reassuring to read that. I'm sure i'll get more comfortable with the notions and functions of Matrices and Vectors and the intertwined relationships between them all eventually. But i feel that for a generalist freelancer it is hard to keep your head wrapped properly around all these set ups and remember them, when not having the need for them on a daily basis for such intricate structures, even if it's meant for something as simple as controlling normals. It's the conflict between knowing how necessary that stuff is to achieve serious work in Houdini, and the obvious overkill it can be to improvise myself as a senior TD knowing that 90% of my output is built on off the shelves solutions. I'm literally spending 2 hours a day fishing around the net for references and bits of code/vops on every projects lately. Makes me feel so dependent on others, not sure i quite like that feeling after jumping out of 15 years of 3ds Max (nightmarish and frustrating) experience, where at least i knew my stuff.

Cheers,

A.

I notice now that if i change the Tube primitive from Primitive to Polygon Mesh, im' not getting any normals from that geo. They all point the same way. I added normals to it just in case. but nothing. I'm trying to understand why but i can't see any obvious reason for that.

Cheers,

A.

I'm afraid the VOP network in the example scene is a bit of a one trick pony. If you look at the two nodes that are fetching information from the second input (tube input), you will find one is a point attribute query for “P”, and the other is for a primitive intrinsic, “transform.” Both are getting the value from the 0th index, the first point and first primitive of the second input, since the setup is assuming there will be only one of each. A primitive intrinsic is a bit like an attribute, but instead of an arbitrary value, the intrinsic holds a value that is a definitive property of the primitive itself. It is a property that cannot be removed or changed without changing the primitive itself. Some intrinsics cannot be changed at all. For example the bounds of a primitive, or its size or area are intrinsic properties of the primitive. You cannot change the area of a polygon without moving it's points around. Some primitives have special intrinsic properties that are modifiable. Our tube primitive has a property ‘transform’ that is used by primitives whose shape is not determined by the points and vertices therein. The tube's shape is a property of it being a tube, the transform gives it a rotation and scale. A sphere primitive similarly uses it's sphereness to determine its shape, and a transform to say how large and how it is rotated. The example I gave used the transform property to transform the input points into the space of the tube, and project onto the local tube axis. The transform is used again to rotate and scale the projected vectors back into the original space.

Polygonal input cannot function the same way as the tube example because a mesh is composed of many points and primitives, and is not defined by a simple transformation matrix. If you open the geometry spreadsheet, under primitives, you can list primitive intrinsic that are present on the geometry. The polygon mesh has no ‘transform’ intrinsic, as its size and orientation is determined by the individual vertices' points.

Sorry if this is really long and complicated, but basically the setup uses an assumption about the nature of the input to take certain liberties for how the normal is constructed. A different input would require an entirely different set of assumptions.

Here's another version with attributeVops, though AttributeTransferSop(in yellow) is probably the easiest solution. Hope it helps.

jsmack
I'm afraid the VOP network in the example scene is a bit of a one trick pony. If you look at the two nodes that are fetching information from the second input (tube input), you will find one is a point attribute query for “P”, and the other is for a primitive intrinsic, “transform.” Both are getting the value from the 0th index, the first point and first primitive of the second input, since the setup is assuming there will be only one of each. A primitive intrinsic is a bit like an attribute, but instead of an arbitrary value, the intrinsic holds a value that is a definitive property of the primitive itself. It is a property that cannot be removed or changed without changing the primitive itself. Some intrinsics cannot be changed at all. For example the bounds of a primitive, or its size or area are intrinsic properties of the primitive. You cannot change the area of a polygon without moving it's points around. Some primitives have special intrinsic properties that are modifiable. Our tube primitive has a property ‘transform’ that is used by primitives whose shape is not determined by the points and vertices therein. The tube's shape is a property of it being a tube, the transform gives it a rotation and scale. A sphere primitive similarly uses it's sphereness to determine its shape, and a transform to say how large and how it is rotated. The example I gave used the transform property to transform the input points into the space of the tube, and project onto the local tube axis. The transform is used again to rotate and scale the projected vectors back into the original space.

Polygonal input cannot function the same way as the tube example because a mesh is composed of many points and primitives, and is not defined by a simple transformation matrix. If you open the geometry spreadsheet, under primitives, you can list primitive intrinsic that are present on the geometry. The polygon mesh has no ‘transform’ intrinsic, as its size and orientation is determined by the individual vertices' points.

Sorry if this is really long and complicated, but basically the setup uses an assumption about the nature of the input to take certain liberties for how the normal is constructed. A different input would require an entirely different set of assumptions.

Thanks a bunch, Jsmack. No worry about the chapter, all gold, very instructional. I didn't reply earlier cause i thought i could find a way to use your method while somewhat replacing the primitive tube by a polygon mesh version to make the best of the amount of columns parameters, so instead of having normals facing circular, i could chose 8 sided polygon tube to have only 8 directions of normals, or even 4 by settings the tube to 4 sides. Anyway, to do that i wanted to scatter some circle “primtive” on that polygon tube's points and throw that into your pipe… but that just didnt' work. Anyway, much appreciated, very educative convo anyway.

Cheers,

A.

fuos
Here's another version with attributeVops, though AttributeTransferSop(in yellow) is probably the easiest solution. Hope it helps.

Great stuff, Fuos, I really like the transfer attribute approach, also the simplest and the most flexible, it gives a little more creative options when playing with the transfer attribute conditions. I'm definitely going to remember that one, very handy. Only really used the transfer attributes to transfer colors so far and that was a bout it so it really didn't cross my mind to use those for normals. But it makes a lot of sens to go for that method.

So thanks a bunch to you both, here's a pic of what this was intended for. I built a rough Scifi/industrial/megacity procedural building generator based upon the Hreeble tools from the ever generous Alexey Rusev. It's not yet full proof as some assets being scattered are still a bit too dependent on the original scale of the main structure, and also bumping into some issues working with Hreeble and “groups”, but as soon as my deadline is met and the tool is functional i'll be more than glad to share it here with everyone as most of the content was only done thanks to the help of this forum. I've been spamming lately. I wanted a quick way to generate multiple building by just copying the main geo node and paste it. Most paramaters that have a seed just refer to the digit behind the name of the main geo node to set the randomness. I'm instancing them all across a terrain, and render the entire thing as Redshift point instances.

So i basically need to control the normals that are used to orient the antennas on the sides of the building toward the outside of that building, but i wanted the option to have them pointing out in a circular fashion, but also be able to chose to just have them pointing out toward the 4 sides of the building in case the shape of that building would indeed be more squarish than octagonal or circular.

Thanks again,

A.