Jump to content
sibarrick

PMVC - positive mean value coordinates

Recommended Posts

Leading on from here

Mean Value Coordinates

I've started messing around with Positive Mean Value Coordinates.

Rather than have them GPU assisted as in this paper

GPU-assisted Positive Mean Value Coordinates for Mesh Deformation

I've started making them VEX assisted, by which I mean I made a vop sop that does ray casting and adds the result as an attribute rather than using texture maps.

It won't be as fast to calculate but as you can see from the attached file the implimentation is almost trivial. One vop node, two python nodes and a few other standard supporting nodes are all that is required. Therefore unlike the Mean Value Coordinates (which probably could now be re-written in python) this doesn't require the HDK at all.

So far I have only sketched in the basics, more to follow, there is an issue currently when the cage deformer isn't deformed my test sphere shrinks, which means I've got something wrong somewhere, or its an accuracy thing (i think the former), but I'll hopefully sort that out later. This is just a work in progress first look.

Currently when running it on my Mac if I change the vex node to use more than one processor Houdini hangs, so it will be interesting if that is a fixable bug in Houdini, and if multi-processors will work on any other platform. Using more than one core could nicely speed this up.

dev1001.hipnc.zip

Edited by sibarrick

Share this post


Link to post
Share on other sites

I've found a bug with the primitive attribute vop returning inconsistent values, until I get that resolved I think this won't work unless i can find a work around.

Share this post


Link to post
Share on other sites

Progress!

Dropped the vop sop in favour of the ray sop and fixed the issue with the shrinkage. I forgot to take into account the projection of the sample points onto the unit sphere (ie the distance the test points were from the surface)

I'll test with more complex geometry tomorrow....

dev1003.hipnc.zip

Share this post


Link to post
Share on other sites
Progress!

Dropped the vop sop in favour of the ray sop and fixed the issue with the shrinkage. I forgot to take into account the projection of the sample points onto the unit sphere (ie the distance the test points were from the surface)

I'll test with more complex geometry tomorrow....

I'm looking forward to trying to figure out whatever it is you're talking about here! :) But I always love your stuff.

I was pleased to see that if you refine/bricker your geometry after after the (slow) Capture process, the newly interpolated attributes deform nicely. Does this mean that you could potentially skip many capture points and interpolate the rest? For instance, scatter points on it, capture those and transfer weights to your high-res geometry. Or capture a low-rez "sock" and AttribTransfer the weights, etc.

Share this post


Link to post
Share on other sites
I'm looking forward to trying to figure out whatever it is you're talking about here! :) But I always love your stuff.

I was pleased to see that if you refine/bricker your geometry after after the (slow) Capture process, the newly interpolated attributes deform nicely. Does this mean that you could potentially skip many capture points and interpolate the rest? For instance, scatter points on it, capture those and transfer weights to your high-res geometry. Or capture a low-rez "sock" and AttribTransfer the weights, etc.

Cheers.

And well I hadn't even thought about that, but yes probably, although when you do that the quality of the capture will slightly degrade. How far you could push it will maybe depend on the sort of deformation you need I suspect.

Harmonic coordinates are interpolated off a voxel grid, the finest of the grid defines the accuracy, if you look at the PMVC paper there are pictures that show how this process introduces small errors in the deformed mesh, the points "wobble" very slightly, your interpolation idea I suspect would do much the same thing so it would all depend on how much you wanted to avoid that effect.

At the moment if you play with the frequency value (i need to change it to "number of samples") that is the current pay off between speed and accuracy. Just on that initial albeit very crude test I was very pleasantly surprised how low you could go and still get a decent result. Also I added in the effect of the slight variation in area of the triangles in the sampling sphere, and I actually think I could have a toggle to turn that step off which might well speed things up too without effecting the result too much.

Finally I don't know if the foreach sop is quicker than copy stamping but if Sesi fix the bug with using a python sop in a foreach loop that might make things quicker too.

I'm also thinking this could be extended to SBC - Spherical Barycentric coordinates to make them positive only too, that would be even better as they exhibit less distortion which can happen in MVC using very large deformations with long thin triangles in the control cage. SBC allows for any planar polygons to be used in the control cage, they don't have to be triangulated, this allows for smoother deformation, if I could make that work only using positive weights that would be very neat. I can't encode the weights in RGB attributes which means it wouldn't work using the GPU method but since I'm not doing that anyway this isn't an issue. It might be slow much if you don't have to recapture too often and you can work with approximations and sampling as you suggest it might all be very doable.

Share this post


Link to post
Share on other sites

....Actually thinking about this some more if you rayed your high res geometry onto the low res captured stuff (without moving the points, just pick up the hit attributes) then the interpolation would be pretty good as the attributes would be picked up using the barycentric coordinate of the hit point, since this is how the underlying method works anyway, only in 3d rather than 2D, the approximation would be very close.

The final deformer might be quicker in an HDK sop as well, I don't know how fast python is by comparison, the deformer is trivial, just multiple the existing cage point positions by all the weights on a particular point and sum the result to get the new position.

Edited by sibarrick

Share this post


Link to post
Share on other sites

...Well rather than thinking about it I tried it.

Raying and scattering suffer from problems, when you do it the deformed points move so that the final shape approximates the low res geometry as if you have actually rayed it on. In the case of the sphere this means even a high res sphere doesn't look perfectly round any more it looks like the straight edged low res one.

This might not be an issue if you are only trying to preserve fine surface detail but in the most part I don't think it is ideal.

What does work is subdividing but I guess if you are doing that you might as well subdivide after the deformation which rather makes it a waste of time.

The only other idea I can think of is to borrow from Harmonic coordinates and calculate the weights at voxel positions, this will then "fill" all of space with the "correct" weights, then when you attribute transfer or interpolate in some other way you are picking up the weights for that precise position in space and not the position of the low res proxy. So although it is still a low res proxy it is not defining it's own structure so strongly, you'll still get the "wobble" effect I mentioned earlier but it will be more disordered like noise in an image and less an artifact of the proxy shape. As in all things CG noise is often less troubling than recognisable structure.

Share this post


Link to post
Share on other sites

Ok last post for now. Here's the lastest version, and a little pic. I tried it on a really simple character style mesh. What this really needs is a way to store sparse weight attributes as I do for my other deformers. I can do that in the HDK but not in python yet. I think the deformer itself would then be way quicker as you get a ton of weights set to zero that don't add anything but take time to cook. I also now definitely think this would benefit from being an hdk node as I'm sure although python nodes are fast they are nothing like as quick as native hdk nodes.

But this test does show the process works, you can see where I have moved the leg up the cage points have only effected the moved leg and not the static one, and that is the whole point of Positive Mean Value Coordinates..

dev1004.hipnc.zip

post-509-1237110089_thumb.png

Share this post


Link to post
Share on other sites

Well of course I walked away and then had a flash of inspiration.

As the weights are all between 0-1 I've managed to make my own sparse coordinate system by adding the index of the point to the weight and then dumping all the zero weights.

I also noticed I was using iterPoints() where I should have used just points()

I now have it running at pretty much interactive speeds...

Next stop will be to try the positive sbc idea.

Python sops rock, this is so much easier than working in the hdk especially for r&d like this.

dev1005.hipnc.zip

Share this post


Link to post
Share on other sites

Hey Simon,

wow didn't even had time to blink, that you already got 5 test in here...wow!

I tryed the latest test: dev1005.hipnc, but I get some errors (I'm in houdini.9.5.400). I joined some screen grab so you can see...

First version was working fine thought...I'll be following this thread like my favorite soap opera!

Thanks for sharing! Cheers!

post-3220-1237150688_thumb.jpg

post-3220-1237150693_thumb.jpg

Share this post


Link to post
Share on other sites

Odd. Try turning off the sparse option, that seems to be throwing an error, I'm on H9.5.197, maybe something changed.... that's annoying. I'll check it out on some other builds tomorrow see if anything shows up.

Also can you try the attached version too.

dev1006.hipnc.zip

Share this post


Link to post
Share on other sites
Odd. Try turning off the sparse option, that seems to be throwing an error, I'm on H9.5.197, maybe something changed.... that's annoying. I'll check it out on some other builds tomorrow see if anything shows up.

Also can you try the attached version too.

Tryed the latest version, error still there but it's working when I turn off sparse attribute...LOOKING GOOD!!

Edited by jrgauthier

Share this post


Link to post
Share on other sites

Cool, I think I have an idea they have tightened up the addattrib function can you try this one, I'm being more careful to pre initialise the arrays to the right length first.

dev1007.hipnc.zip

Share this post


Link to post
Share on other sites
Cool, I think I have an idea they have tightened up the addattrib function can you try this one, I'm being more careful to pre initialise the arrays to the right length first.

Hey Simon,

still getting a problem with the sparse on..

See attached.

Very cool otherwise.

post-188-1237169957_thumb.png

Share this post


Link to post
Share on other sites

Well just duplicated this myself on windows, I'm going to have to defer to Sesi on this one unless someone else can spot what is wrong.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×