GMVC - General Mean Value Coordinates

[sibarrick]

Something about posting always seems to jog my head into action. No sooner had I posted than I had a brain wave and found the issue with my hdk version. Something I always do wrong, declare a UT_FloatArray the wrong way round. It always catches me out as it so nearly works even when its wrong!

Anyway here's a first cut, I'll try and upload some compiled versions later, this is just the code and a test hip file.

I need to tidy everything up and probably combine all this into the PMVC node and just make it an option on that one since its a bit slower to calculate. The hdk version shouldn't be much slower but the python version is so I'll keep it optional.

PGMVC_HDK.zip

[michael]

awesome stuff simon!

I can't decide what I'm more excited by...your GMVC or johner's 'splodey-smashy stuff...

[sibarrick]

awesome stuff simon!

I can't decide what I'm more excited by...your GMVC or johner's 'splodey-smashy stuff...

that sounds interesting what's johner's splodey-smashy stuff?? link?

[michael]

http://forums.odforce.net/index.php?showtopic=9119

:balloon:

[sibarrick]

http://forums.odforce.net/index.php?showtopic=9119

:balloon:

Very cool, wish I had to smash stuff up

I'll be very interested in how he makes the internal surfaces though. We don't smash stuff up but we do chop it a lot, also using the clip sop.

Actually one of the motivations of this thread (trying to bring it back on topic) is that it can be used to transfer uv's etc. onto cut surfaces and do a better job of interpolating them than the divide/bricker sop.

[johner]

Very cool, wish I had to smash stuff up

I'll be very interested in how he makes the internal surfaces though. We don't smash stuff up but we do chop it a lot, also using the clip sop.

Actually one of the motivations of this thread (trying to bring it back on topic) is that it can be used to transfer uv's etc. onto cut surfaces and do a better job of interpolating them than the divide/bricker sop.

Hi Simon. Really interesting stuff; I want to take a closer look once I get a first release of my "'splodey-smashy" stuff out (I quite like that), which should be Real Soon Now. As I said in that other thread, the Clip SOP is the workhorse of the fracture operation. All the points are created by it, I just do some capping with polygons at every step of the way, so the interpolation will only be as good as the Clip SOPs.

I've done only minimal testing of the interpolation results. Mainly just assigning "bounding box" colors to the surface before fracturing and rendering (the viewport display was botched), and applying rest coords to the surface and rendering the fractured pieces with a solid texture to make sure it looked like the pieces were part of the solid. It worked well enough to move on to more pressing matters, but I wouldn't be surprised to find that ultimately I need a more powerful approach like you've got here.

[sibarrick]

If you aren't actually adding any new internal points then you should be ok, its when you bricker or otherwise need to create internal points that you need good interpolation from the edge points.

[Wolfwood]

Thanks for all the R&D you've put into this Simon!

Since I've been doing a little bit of production work using your hard work I figured I try to give back a little. I've taken your PGMVC capture HDA and replaced most of it with a single VEX node. Since this eliminates the need the for the ForEach SOP and the Ray SOP it runs significantly faster. Capturing a 128k point mesh, with 256 samples, on a 500 vertex cage takes about a minute running on 4 threads.

Couple of notes:

- I removed the need for a third input (the sphere samples) as the sample points are now determined within the VEX node. The algorithm I choose was a spiral based distribution, http://www.ogre.nu/pack/pack.htm. (I'm using the Golden Sectors, the middle one.) At some point I'm going to build a library of sphere samplers that way a I can pick which ever approach I want.

- Since the samples are being determined within the VEX node the number of samples can be set as a point attribute. In other words, you can set a low number of samples over your surface, but for problematic areas you can set those points to a much higher sampling rate.

- Threading! This threads like a champ. Running on 1 thread the above test took just under 4 minutes. Setting it to 4 threads and it finished in just over a minute.

- The cage needs to be prepped with the following attributes:

vertPos - Vertex Attribute, $TX,$TY,$TZ stashed in the vertex

ptNum - Vertex Attribute, the point number that corresponds to that vertex

numVerts - Primitive Attribute, the number of verts the current primitive has.

(Technically, vertPos isn't needed as the point position that corresponds to the vertex can be fetched indirectly via the ptNum map but I was lazy.)

Simon's example that he provided:

3 minutes to capture on my machine using the Python SOPs

35 seconds to capture using HDK SOP.

4 seconds using the VEX SOP. (Yea SIMD!)

As a side note, the only reason I even pursued the VEX approach for capturing is cause I avoid the HDK at all costs. I used to love working in it...until I had to start supporting 3 different versions of Houdini across 32bit / 64bit on two different platforms.

Thanks again Simon!

PGMV_1000_alt.hipnc

Edited July 4, 2009 by Wolfwood

[sibarrick]

That's awesome! So much good stuff here.

Thanks for re-writing the capture node, I had thought about it, and in fact started with a vex node, but really couldn't be bothered 4 seconds versus 3 minutes! that is an amazing speed up.

That's so cool you can vary the capture detail using an attribute.

It's also cool it's now all VEX! this makes it so much easier to distribute to other people. It reminds me that now we have arrays I could easily re-write the wrap deformer and maybe other useful tools.....

Thanks for the link to the sphere distribution stuff as well very interesting.

But mostly it's cool it got used in production. I don't suppose you are at liberty to say where?

Out of interest why did you choose the Golden section packing? I haven't look at the algorithm yet, so is it the easiest to implement or did it give the best results?

Edited July 5, 2009 by sibarrick

[sibarrick]

Be aware in Wolfwood's example the second input to the capture node is animated and so the capture is forced to happen every frame, making the whole thing seem a little sluggish. Although pretty amazingly fast if you know what it's actually doing.

If you make the second input the peak1 sop all should be good, and the deformer part should run at interactive speeds.

PGMV_1000_alt.hipnc

[Wolfwood]

haha Sorry about that animated second input. I did that to force recaptures so I could do timings and forgot to take it out. :cry2:

[Wolfwood]

But mostly it's cool it got used in production. I don't suppose you are at liberty to say where?

Out of interest why did you choose the Golden section packing? I haven't look at the algorithm yet, so is it the easiest to implement or did it give the best results?

All those spiral packing algos are really simple to implement. (Even more so since there is example code all over the net. ) The Disc ball had the best packing but it looked a bit too biased latitudinally. (Same goes with Saff & Kuijlaars, but the packing was even worse.) So I went with the Golden Sector. FWIW I have no idea if that bias would actually matter for our purposes. My gut said "maybe" and that was good enough for me. At some point I want to build up a nice library of a bunch of different methods, the various spiral approaches along with dart throwing, etc. Once I do that I can actually do some proper tests. I was also thinking about having an optional 3rd input to the capture that allows you to specify your own "sample pattern."

Can't say what its being used on yet since the production is just starting and will run for the next 6 months or so.

That said... I'd love to do a Technical Evening on my current project where the GMVC is just one part of.

[edward]

That said... I'd love to do a Technical Evening on my current project where the GMVC is just one part of.

Shall I notify Jenny?

[Wolfwood]

Shall I notify Jenny?

Once our current project gets closer to completion and I get the "ok" from the overlords.

[sibarrick]

Interesting related link

iBind

might look into this at some point....