how to replicate this ICE network in VOPs?

[Netvudu]

At the following video, someone is using an ICE network to create a simple deformer. I wanted to make the Houdini tool in VOPs but I found a problem. I´m using an Import Attribute to get the point position of the second sphere connected through the second of the VOP network. Now, I can´t find a tool to replicate ICE´s "Get Closest location", even though I´m possitive it is possible. My money is on a point cloud-related thingy.

could anyone help a bit with this? I wanted to take this chance to learn a bit more of VOPs...

[Mzigaib]

Maybe this could help, I recommend.

http://www.cmivfx.com/tutorials/view/101/Houdini+VEX+Volume+1

[anim]

there is no such function in VEX as far as I know

the pointcloud is close, but it'll get you closest point, not closest location on geometry, which can be huge difference, mainly for low poly geometry

but you can(or need to) use Ray SOP in Minimum Distance Method, and feed it's output as second input on your VOP, then you can import point positions from that input knowing that they represent closest locations and do some math

EDIT: this would be the case if you want to use that location for something else than moving points, otherwise (as in video) Ray SOP is all you need, then you can use VEX for smoothing part so connect it to first input

for Get Array Average as in video, you can use for loop in VOPs summing all neighbour positions and divide them by number of neighbours

instead of repeat in ICE, you'll probably need to use For Each SOP to repeat the whole thing many times

and of course, due to Ray SOP and For Each SOP your speed will probably be a lot slower than in ICE

Edited January 17, 2011 by anim

[pclaes]

perhaps you could try to do the ray operation in vops too.

Can't see a way around the foreach though.

[symek]

This is quite simple in VEX. See attachment. Surely needs some love, but real challenge would be to make it robust, as such tools have this bad habit to not work in production scenes .

edit: I should add that the same can be done in Vops, but I hate it. Not to mention RaySOP does exactly the same thing (with interpolation or "smoothness" as mentioned in ice talk).

ICE_deform_example.hipnc

Edited January 17, 2011 by SYmek

[sanostol]

Hi SYmek,

I'm not sure if this is what he wants, intersect needs a ray direction to get a position. closest location just gives You the closest location, just like the raysop in minimum distance mode.

if it is not that important to be accurate, scattering points onto the targetsurface and using pcfilter on three points give You a good approxiamtion, but to get exact, it would need more. I first thought I could use the barycentric coordinates to get something like closest location on surface, but unfortunately there is no way to get the closest triangle on a geometry. just querying three points on the surface is not enough as You can not be sure that You get the points of a triangle.

This is quite simple in VEX. See attachment. Surely needs some love, but real challenge would be to make it robust, as such tools have this bad habit to not work in production scenes .

edit: I should add that the same can be done in Vops, but I hate it. Not to mention RaySOP does exactly the same thing (with interpolation or "smoothness" as mentioned in ice talk).

[symek]

Hi Martin,

you're right, sure this is not the same at this point, but as you said it can be approximated with point clouds or centroids. I mean, my question would be what was the intension of that tool, because the example used there was so limited, that I'm not sure how this should work anyway. As far as I see it, closest distance, the accurate one, wouldn't be much useful, as it's a reason they have to iterate to project smoothly after all. So to the extend of that particular example, point cloud approximation suits even better. Well at least as I look at it at the moment .

cheers!

skk.

ps What would be probably useful for a deformer is an orthographic projection from one mesh into another, wouldn't it?

[Netvudu]

Thanks for the help so far, although I admit I wasn´t expecting ICE to be ahead in the game (in some of the terms, I know, and I do know point cloud computing is so much faster in VOPs than in ICE) so soon.

Symek, regarding the use of the tool, AFAIK it´s an example of something more elaborated that would eventually be used to deform...a base for muscle and/or fat deformation.

[edward]

3 nodes: AttribTransfer w/P, Smooth, Blendshape. I think it's a flaw to compare ICE to VOPs for geometry and then ignore SOPs.

[edward]

PS. If one really needs to get the closest position on the geometry to a point, there's hou.Geometry.nearestPrim().

[symek]

Thanks for the help so far, although I admit I wasn´t expecting ICE to be ahead in the game (in some of the terms, I know, and I do know point cloud computing is so much faster in VOPs than in ICE) so soon.

Symek, regarding the use of the tool, AFAIK it´s an example of something more elaborated that would eventually be used to deform...a base for muscle and/or fat deformation.

Not that I want to defend Vops for any price, but I wouldn't call it that way. Chances for missing bits of functionality are always on both sides. Maybe I don't see it enough generally, but after all it seems that the missing part is a closest distance function, which is present in other parts of Houdini (like Edward mentioned), and most importantly is already implemented in HDK GU_Detail::intersectRay, which theoretically makes it trivial to re-implement it in VEX for anybody familiar with it. I suspect sending RFE by someone on AUP has a good chance for fast response. It looks like no one has really needed it before.

Saying that, it seems that ICE is much more general and functional than VOPs itself by design.

skk.

Edited January 18, 2011 by SYmek

[sanostol]

still think this would be a valueable function. 3 pointids of a triangle and 3 weights would be sufficent to interpolate quite anything on geometry in vex and You would have the benefit of multithreading

[Macha]

Perhaps this kind of stuff could be made easier in vops if we could loop through primitives (and edges!) rather than just points. We could then just find nearest point on a prim with a simple few vector operations.

Edited January 18, 2011 by Macha

[symek]

Including prims and edges in vex would be quite a bit of change, not sure if SESI is willing to make such effort.

Anyhow, making the same thing with a help of hou.Geometry.nearestPrim() works as expected, but introduces the same problem as in the video: closest distance distorts mesh. So these distances need to be interpolated anyway. Python is much slower though, even if you find nearest poly with it, leaving the rest work for vex.

[anim]

hou.Geometry.nearestPrim() is slow, Ray SOP is much faster, but not multithreaded so something like minimum distance method from Ray SOP will be great to have in VEX

[Jason]

This is no technical reason why VEX couldn't have more functions like nearestPointOnSurface, etc. The fact that it processes point-by-point shouldn't limit it's functions to querying points -- and there are some functions which prove it, like intersect(), etc.

SESI should definitely bring VEX's feature set up to encompass all that you can do in python and hscript.

[symek]

I got curious, so I committed *somehow* working prototype. I'm completely blind with HDK/custom VEX, so that's not a surprise I've faced some issues. This is merely basic vex wrapper around HDK/GU_RayIntersect library, which doesn't have to be the best approach, not to mention quality of the wrapper itself.

The function has two flavors:

vector4 minimum_distance(string, vector, int)

(returns ray hit position)

float minimum_distance(int&, float&, float&, string, vector, int)

(returns distance, prim id, u, v, so it can be used with other vex functions (like prim_attribute)).

I attached my tests for comparison:

switchMode (on vex node):

0 - hit position is computed by dso.

1 - hit position is computed by prim_attribute() from hit details.

2 - hit position is computed by prim_attribute() from hit details provided by hou.Geometry.nearestPrim()

The code was tested on Linux x64, and in a current state has some limitations:

1) it's not multi-thread safe (will blow up Houdini if you turn on threading on Vex node).

2) it doesn't work with operators (op:/), target geometry must stay on disk.

ad1. the issue comes from my clumsy optimization with keeping GU_Detail around for vex, so I assume it can be fixed once someone kind will tell me how to fix it.

ad2. well, cooking issue, which I'm disrupting while accessing nodes from dso (trouble code is commented out in a source), so I disabled op:/ for a moment. The whole geometry access is complete mess and it's a subject of change anyway. It's much beyond my scope for now, how to keep gdp away from vex and thread save in a consistent manner (file or op:)- among other things...

Help appreciated,

skk.

ndist.tar.gz

mdistance.mpg

Edited January 20, 2011 by SYmek