Robert

Point clouds in Houdini already sort the found points by distance. If you search for 9 points you know you end up with a 3x3 grid of points where the diagonals will always be the last 4 points in the list. You can use this information to get a weighted average by assigning the last 4 points a lower weight.

This seems like a good subject to do with L-systems. You can get the nice growing effect and the secondary vines are aligned to the growing vector if you specify no further rotation. You can also get some nice fractals/recursion with just a single shape.

For general usability I'd suggest projecting the curve to the tube first and THEN adding a polywire to it. If you can somehow get the intersection normal from the curve to the collision you can peak the curve a certain amount so that any polywire tube appears to "rest" on the surface instead of penetrating it (which you are getting somewhat with the current setup). The method with the control grid resembles the creep method where you use the UV coordinates to project your curves on which then folds the curve around the geometry nicely (requires nurbs geo to project against though).

As long as you are using a wrangle it's much better to do the deletion inside the wrangle too, way more efficient. You can use an if statement to check your condition and then use removepoint(0,@ptnum).

You can put a "bind export" node in your shader with the plane you want to export. But, this is only how the shader will interpret your input (like color maps). If you want some more detailed information you need to hack the surface model node and have a look inside there. Here you can still put down bind export nodes but it becomes a bit trickier to identify exactly what you want. It's still a normal network but there is just a LOT going on inside there. After you got your bind export set up you can go to extra image planes in the mantra node and put the name & type that you used in the export. Note that I am talking about "image planes" here. After a bit of digging in the surface model it seems like the components are also interwoven somehow with the BSDF. I think that what what you need is in the dropdown list and if not, shouldn't require altering of the surface model but just a bind export and an image plane.

Thanks for your explanation! So does that mean that the default mantra surface shader is actually bad to use for metals and you should use some sort of custom fresnel function? Or does houdini already have this functionality hidden away somewhere? I know there is a disney BRDF (or BSDF) in the BDSF bonanza thread here that also abandons the IOR values and just uses a constant value for F0. Does that mean they have some curve that fits most purposes baked in there? In the PBR texture guide from substance designer (https://www.allegorithmic.com/pbr-guide) they seem to take IOR into account but just to get the base reflective value. Is this value (this is F0 right?) what you would normally put into the reflection intensity in the mantra shader? Sorry for the large amount of questions, I find this quite interesting but I can't get it to "click" yet inside my head

Well the basic components are in that field by default: diffuse reflect coat refract volume. From the tooltip it seems you can put your own exported components here too if you defined them inside your shader but I haven't tried that myself. I just make separate entries under "Extra image planes".

Excuse my ignorance but do you know how the native fresnel function approaches this curve or am I mixing multiple things together? I tried looking in the include files where most functions are defined but couldn't find it. Does this also mean that whenever you start to make more complex materials that require such a custom curve the IOR value becomes useless and you have to fall back to a custom fresnel solution like the one posted here?

It won't properly write out .pc files if there are still groups present on the geometry. Put a group SOP before your ROP output set to edit -> delete-> * and it should work.

You can try to carve your curve into multiple segments and then loop through them to use the uvtexture node with a separate scale. If you give each piece of the curve the new scale attribute you can reference it using the prim() expression inside your loop. When local variables aren't supported it usually means the SOP doesn't operate on that context. After using wrangles and/or vops you tend to get spoiled and forget that not many nodes loop over all points by themselves to allow the use of $PT to get the current processed point.

The x scale in the UV texture node is a global scale. It stretches your UV's from 0..1 to 0..xscale. It's a bit hard to imagine what this would look like on a per-point basis. If you want to shrink or stretch a segment somewhere in the middle of your curve the rest that comes after it has to somehow shrink/stretch with it. Just a few remarks on your current setup, the ends node was added to "disconnect" the first and last point of the circle so that the UV's don't wrap to create the stretching that occurs with point UV's, it has nothing to do with the perimeter measurement. Second, the uvtexture nodes before the sweep were set up to automatically UV the skinned tube as a product of its profile and backbone, adding another uvtexture right after it renders that process useless. I'm not saying you can't put a uvtexture after your sweep but just realize that you might just as well remove the setup from before the sweep

I'll just include a file to show you what I meant. The measure SOP goes before the sweep on the backbone. The circle is mapped from 0..1 in the v-direction but when you do the same in the u direction for the backbone the aspect ratio gets messed up. So to get the correct aspect ratio the UV's of the backbone need to be proportional to the circle. In your case the circle already has a circumference of 1 unit so that makes the math easier but for completeness I added a measure SOP to the circle too. So to get the right coverage of the backbone UV's you take its length (the first measure SOP) and divide it by the circle's circumference (measure SOP 2). You can put this number in the scale parameter of the backbone's UVtexture node. To calculate this you can use the prim() expression because we are using a regular SOP node, not a wrangle. Because we are iterating over each curve within the foreach SOP we can always take the first primitive (number 0) so prim("../measure1",0,"perimeter",0). I added an ends node set to unroll for the circle to get rid of the stretching caused by point UV's. This still leaves an obvious seam but I'm sure there are many other methods to get around the stretching. ap_tubes_overlap_foreach_ray_RobertEdit.hipnc

To get a nice non-stretched UV you can use the current curve perimeter (measure SOP) and put that into the x scale of the UV texture node of the backbone curve and disable the UV texture node after the sweep. For this UV with sweep method to work you need to use point UV's but you probably want to convert them to vertex UV's afterwards somehow to get rid of the seam area.

Hi this seemed like an interesting problem so I gave it a try. The first fun problem to pop up was that when you are using the reflected vector you are using the hemisphere as a lens. You need to move your object somewhere before the focus point or adjust your lens to get a non-inverted/ non infinitely small projection. Now this solution might be really convoluted but it seems to get close to your idea. To keep it simple I assumed that the camera was shooting rays from its origin (ignoring any and all camera attributes) and calculated a reflected vector for each point. I stored the reflected vector for the sphere and the test object in the "up" attribute so turn on visualizations to see it. The next problem is to edit the UV's of the test object you need to let a wrangle run over the object itself, thereby not having access to the reflected vector from the sphere. In my solution I run over all the points in the sphere and test for the smallest dot product between the direction from the test object point to all the points of the sphere to get the vector that would have been reflected onto it. This might be way easier than I'm making it but hey it works. Then when you have the reflected vector on the test object I use a raycast/intersect to get the position on the sphere that would have been reflected onto the object. While I'm writing this I realize I could just use the point() expression since I stored the best match point number on the sphere but I already did this so I'm rolling with it. When you have the position on the sphere you can get any attribute from it like the UV's or color. I also tried the same method but with the sphere's normals as the reflecting vector. In many cases this works better than the actual reflected vector but it's up to you. I hope I explained it enough for you to take it further or for you to call me stupid because I misinterpreted the problem. bounceUV.hiplc

I got a sort of similar setup in a python SOP to load a sequence of .txt files. The code that loads the file is: filepath = hou.pwd().parm('file').eval() Takes the file from the "file" parameter that I added to the SOP. In this parameter you can just enter your file with `$F` as the sequence number to load a new version. For example: C:/Users/robert/MosselProject/PDE_`$F`.txt For attributes you first have to create them: velocity = geo.addAttrib(hou.attribType.Point,"velocity",0.0) And afterwards you assign the values you read from your .txt file with point.setAttribValue. When your points are created you can use the attributes like any other through expressions or in wrangle nodes.