Archived post by mattiasmalmer

how do i get the cameras uv space in a materialx shader? i want to do projective texturing in the shader.

This works half-assedly but only on CPUkarma. I load the hit position in worldspace. transform it to cameraspace (using space:camera in the transformpoint) then divide that with hit distance to get a projection. (using ray:hitPz in the mtlxdot) but the camera:space thing does not work in XPU.
I thought this would be the easiest thing ever. anyone having any better tricks?

generating precooked uv data on the geo from the camera is not as good as one tends to get projection errors over larger polygons and such.

ok after the longest time mucking about I found how it is actually done:
You use the coordsys node in LOP:s to define the coordinate system and reference the camera. Then use that coordsys in a mtlxposition and use myCoordinateSysName:ndc to get it in the camera projection space. Neat because then you can use any camera as a projector and so forth.

aw frekk. does not work in xpu.

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20232109/07/23/image.png

Archived post by sniperjake945

If you do find use in this thing, I updated the above vex to fix the numerical issues, so definitely use that. the project file i posted is using the old method which has issues numerically…. And then you can set mu to be something low, like .05 and it’ll resolve really quickly and with much fewer issues…

okay this one fixes the issue ive been talking to myself about

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20235908/15/23/FlattenPrims5_jr_v0003.hiplc

Archived post by sniperjake945

@paqwak i wish houdini had a built in nearest point on single prim function… you can make one yourself by manually computing the barycentric coords…

the local solve from the paper i linked above seems to work pretty well. the idea is to generate prim normals using a normal sop, and then use the following vex in a for loop: @paqwak “`c //run over points int nbs[] = pointprims(0, @ptnum); matrix3 nTn = 0; vector dTn = 0; foreach(int prim; nbs){ vector n = prim(0, “N”, prim); vector p = prim(0, “P”, prim); nTn += outerproduct(n, n); dTn += n * dot(p, n); }
3@A = nTn; v@b = dTn; v@P = invert(3@A) * v@b; //solve Ax=b “`

if you use enough iterations on the above idea, you’ll end up at a point where your for loop with the fuse and stuff no longer really affects the mesh. the only problem with this method is that it requires the geometry to be like manifold and not poopy

the paper wrote the algorithm in matrix form, which does also work (though the normal building step that uses eigenvalues/vecs is really annoying so we skip that and just use a normal sop)
and since we can use a normal sop, really only the bottom half of the algorithm is what we need, and i’ve translated it to the vex above

I also omitted the `mu` stuff since that’s just like a lerp from non-planar to planar… which is a parameter we don’t really need

the above method can be problematic if the matrix A has a really stupid inverse… since i’m solving by inversion, it will cause like crazy results

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20232608/15/23/FlattenPrims5_jr_v0002.hiplc
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20232608/15/23/image.png