Mean Value Coordinates

[edward]

In answer to your much early question about speed versus Vex, it's way quicker, like realtime, once the mesh is captured, but the capturing is only about twice as quick, which I thought would be better. Just goes to show how good vex actually is. With a dual proc there's not much in it capturing wise.

19298[/snapback]

If you have a dual proc, you should try turning on multi-threading in VEX. VEX SOPs are actually pretty fast as they use SIMD extensions which a normal HDK SOP won't take advantage of. And then they can be multi-threaded as well. The only real slow thing about VEX SOPs is that they don't make any input copy optimizations and duplicate their inputs on every cook. An HDK SOP can use duplicateChangedSource() to avoid that.

[Wolfwood]

If you have a dual proc, you should try turning on multi-threading in VEX. VEX SOPs are actually pretty fast as they use SIMD extensions which a normal HDK SOP won't take advantage of. And then they can be multi-threaded as well. The only real slow thing about VEX SOPs is that they don't make any input copy optimizations and duplicate their inputs on every cook. An HDK SOP can use duplicateChangedSource() to avoid that.

19299[/snapback]

Actually I tried this morning. =D

2 s per cook (2 threads) on the VEX version

(plus another 4ms for the additional prep SOPs for the vex version)

1.5 s per cook on the HDK version with Capture/Deform mode

12 ms per cook on the HDK version on just Deform mode

The capture takes about (1.3 s)

[sibarrick]

Just using duplicatesource doesn't seem to force any unnecessary cooks anyway. But I guess duplicateChangedsource will ignore attributes changing and only recook if the actual geometry changes? But since if the geometry changes i'd need to recapture anyway I don't think there will be much advantage to this in this case. I'll try it.

If you have a dual proc, you should try turning on multi-threading in VEX

Yes that was what I was saying, and Wolfwood confirmed, the code is about half as quick but with two processors you can wipe out the difference. That's why I'm so impressed with vex. The real benefits kick in when you can store the result of the calc. 12ms per cook is not bad.

If there was some sneaky way of making arrays and storing the results via vex I wouldn't have bothered with the hdk version at all.

Still it was a good sop to write to get into it.

Sorry posted the wrong zip file up before, it doesn't have the lastest version in it, please ignore it.

This should be the correct latest version.

Warp.zip

Edited July 6, 2005 by sibarrick

[edward]

No, duplicateChangedSource() will duplicate if anything has changed in the input. duplicateSource() will always copy the geometry. Neither of them will cause extra cooks if the input has not changed. The difference is in the copying. For 12 ms per cook, how many points are you deforming? My guess is that your geometry is small enough that you're not noticing the copying cost.

[sibarrick]

My test have been about 3000 points. I did just notice on one large piece of geometry that it did seem to be cooking when ever I changed frame which I hadn't noticed before. I put duplicateChangedSource in the deform sop, haven't checked if its quicker.

By the way I got the detail attribute in the end

int

[edward]

Nope, floats are single precision even in VEX.

[sibarrick]

Ok I think I've solved it. There was a float not initialising correctly although I can't see why since it always seems to get a value. Anyhow it appears to be better.

One odd thing, when I used duplicateChangedSource I would get one of my error traps called every second frame if I destroyed the capture attributes (which I've added as an option) Even though they got wiped after the error trap is called Using duplicateSource removed the error completely so I've gone back to that instead.

Here's the source and win compiled versions, I've taken it out of beta now.

Hopefully I've uploaded the right one this time.

Still don't know how to add help though.

Any suggestions for improvement or bugs (i'll do what i can) just let me know.

odWarp.zip

[edward]

One odd thing, when I used duplicateChangedSource I would get one of my error traps called every second frame if I destroyed the capture attributes (which I've added as an option) Even though they got wiped after the error trap is called    Using duplicateSource removed the error completely so I've gone back to that instead.

Looking briefly at the code, it's because duplicateChangedSource() won't modify gdp if the input hasn't changed. So if DELATT() returns true, it already deleted the capture attributes from gdp from the last cook. The way to handle this is to check the changed parameter that is returned from duplicatePointSource(). If it changed, then you make a wholesale copy of all the necessary capture attributes as member data of your deform sop. Then when performing the deform, you use your cached capture attributes instead.

You should try this with a tetrahedron on a model of say 500,000 points. I would be interested in (animated) speed comparisons with say 500,000 points captured by 4 bones.

Any suggestions for improvement or bugs (i'll do what i can) just let me know.

odWarp.zip

19331[/snapback]

Oft-hand, why are you using fpreal16? That's less precision than a regular "float" which is fpreal32 for 32-bit platforms.

[sibarrick]

Did a test with 96,000 points captured with a tetrahedron and 4 bones but thats the limit of what my laptop can handle.

odWarp sop = 457ms per frame and 469ms if I turn on delete capture att. This is without using duplicateChangedSource - which may improve things.

Deform sop = 270ms in fast deform mode and 692ms in normal mode

So pretty close

But.... the thing with mean value stuff is that you can't really take advantage of storing sparse attributes, since you need every point to do the calculation, so as the control mesh gets more and more points in it I suspect performance will get hit more and more.

Oft-hand, why are you using fpreal16? That's less precision than a regular "float" which is fpreal32 for 32-bit platforms.

19334[/snapback]

It was the only way I could do nan checking. Is there a sesi version of nan checking for floats? I couldn't find one.

Looking briefly at the code, it's because duplicateChangedSource() won't modify gdp if the input hasn't changed

Shouldn't that mean that the error is raised on the first frame and then just stays on? Why is duplicateChangedSource doing anything after it first duplicates the gdp since the input never changes?

[edward]

Looking briefly at the code, it's because duplicateChangedSource() won't modify gdp if the input hasn't changed

Shouldn't that mean that the error is raised on the first frame and then just stays on? Why is duplicateChangedSource doing anything after it first duplicates the gdp since the input never changes?

19339[/snapback]

It's because once you hit an error, it seems to delete all cooked data afterwards so it needs to re-duplicate the next time.

For nan checking with float/double, use the standard C math library. Unfortunately, it seems to be slightly different depending on the platform. In the HDK, I think you can include <SYS_Math.h> and then use the isnan() and isfinite() functions.

[sibarrick]

For nan checking with float/double, use the standard C math library. Unfortunately, it seems to be slightly different depending on the platform. In the HDK, I think you can include <SYS_Math.h> and then use the isnan() and isfinite() functions.

19448[/snapback]

These are all the functions listed on doxygen for SYS_Math

Functions

Export bool SYSisInt (const char *str)

Export bool SYSisFloat (const char *str)

Export fpreal32 SYSroundAngle (fpreal32 base, fpreal32 source)

Export fpreal64 SYSroundAngle (fpreal64 base, fpreal64 source)

Export bool SYSisPrime (uint num)

Export bool SYSisPrime (uint64 num)

Export uint SYSmakePrime (uint num)

Export uint64 SYSmakePrime (uint64 num)

Export bool SYSisPow2 (uint num)

Export bool SYSisPow2 (uint64 num)

Export uint SYSmakePow2 (uint num)

Export uint64 SYSmakePow2 (uint64 num)

I suppose I could use the standard C library one, I wonder if it matters if it's different on different platforms?

[edward]

There's some magical macro stuff in SYS_Math.h and the file it includes to allow isnan() and isfinite(). I'm guessing that DOxygen is not showing you that from some reason.

[Mario Marengo]

There's some magical macro stuff in SYS_Math.h and the file it includes to allow isnan() and isfinite().

Yeah, I think isnan(), isinf(), etc are all part of the C99 extension (and so not standard c++). In gcc you can compile with -D_GLIBCPP_USE_C99 to include these but... not very portable. This is all such a pain! esp. if you're trying to write your own generic math stuff -- these kind of numerical properties should all be part of <limits> and let the implementors figure it out... arrrgh.

One interesting tidbit is that I believe the standard *does* say that the value NaN should be "unordered", meaning that it is not greater, lesser, or equal to any other value, including itself. So that a poor-man's check could look like this:

if(!(x==x)) cout<<"I'm a NaN and I can't deny it!";

No such hack for inf that I know of though... and not that I would trust the above much either. So I guess all attempts at a generic math module are doomed to have endless macros trying to cobble together stuff from C, C99, C++, and varying those according to platform... it bears repeating: arrrrgh!

</rant>

... pet peeve...sorry for hijacking your thread like that.

[Jason]

Just for your information, I have uploaded this SOP to the Sourceforge Project : http://sourceforge.net/projects/odforceplugins/

[sibarrick]

Hi i found another new paper on this

Spherical barycentric coordinates

And have done a first implimentation of it

Warp.zip

compiled on windows for H8.1.768

Check out the example hip file.

Many thanks to Torsten Langer who wrote the paper, he helped me sort out a couple of confusing things in the method.

The main thing this new version brings is that the control mesh no longer needs to be composed of triangles. Any convex planar polys will do the trick.

enjoy!

And let me know of any bugs you find, this is only a first pass.

Edited February 28, 2007 by sibarrick

[edward]

Sorry, I don't have time to try it. I've heard that 3D mean value coordinates can suffer from precision issues when the deforming geometry close to the cage. Have you tried that with this new method?

Another problem with using these types of coordinates is that they don't necessarily perform "intuitive" deformations for these type of applications. Scott Schaefer's SIG'06 paper deals with performing "as rigid as possible" deformations. It's mostly focused with 2D because it provides nice closed form solutions. It would be cool if he or someone else works out really nice ways to do this in 3D. At Siggraph, I recall them mentioning that they're close to some 3D results. I'm not sure if anything has come out since then.

Another interesting approach is harmonic coordinates which has certain better characteristics (over mean value coordinates) for deformation as well. Their solver sounds lot more complicated though.

[sibarrick]

It is true that the last method definetely had problems when geometry was close to the cage, but by close it needed to be very close. So it was never much of an issue for me. Also, the solution matches the 2D solution for each poly of the control mesh so with some clever blending (which I never implimented properly) you can smoothly switch from 3D to 2D and avoid those issues.

I haven't check this new version yet, the code I posted is hot of the press so to speak. I suspect the same issue will occur because the weights can get very large and very small when the cage is close to the mesh. But the same solution is available if i or anyone else wanted to fix it

Personally I use this deformer for things where i want very smooth deformations in a volume so these coordinates work perfectly for me. The only extension that would be nice ( but I think very difficult) would be to be able to define internal child control mesh that could clamp volumes inside the parent one that I don't want to move. Some kind of csg but for coordinates weights.

I'll take another look at harmonic coordinates but I think they were a bit beyond me when I last looked at them.....

Actually thinking about it some more, this new construction is suppose to be able to handle generating harmonic coordinates too, Torsten doesn't outline exactly how I don't think but i could look at that as an option....

Edited March 1, 2007 by sibarrick

[sibarrick]

Couple of updates

I've fixed the threshold option - note that this only really works when the mesh is very close to the control cage - or when some of the mesh is a very long way from the control cage - its not much use in the teapot example in the previous post because A. it was broken and B. all the points are a similar distance from the cage.

I've included a new example and you can try 2 things - one is bypass the subdivide sop this will show the capture and deform with the captured points *very* close to the control cage. It works fine. Don't bypass the peak sop though.

second - turn on use threshold - with the subdivide on you won't see the effect very well but with the subdivide off you will see that it uses way fewer attributes to do the capture. This is more useful if you have a large control cage with lots of points and the captured mesh comes close to only part of it. Be aware that with this option you lose some accuracy - sometimes all accuracy - how much error is involved depends on the precise relationship of the mesh to the control cage and what the threshold is set to.

I've also changed the name to SBC capt and SBC deform, and made new icons. I hope to add an SBC transfer soon.

SBCdeformer.zip

As for harmonic coords, I had another look at them, and I can see how to impliment them but for my purposes the approximations introduced by using a sampling grid will not be acceptable. But I admit being able to put interior points into the volume would be handy.

I'm rather dubious of their claims for increased speed, for one thing it only gets quicker when there are lots of points involved and more importantly you could use the same technique for sampling SBC or MVC coordinates and gain the same speed improvements so they aren't comparing like with like.

[edward]

I've also changed the name to SBC capt and SBC deform, and made new icons. I hope to add an SBC transfer soon.

I haven't looked or remember from the paper. Is the SBC capture attributes something like just 1 long vector of weights where each weight corresponds to a primitive on the cage? If it is, then AttribTransfer should work off the bat.

[sibarrick]

Nearly, its just a long list of point weights rather than primitive ones, so yes it shouldn't be hard to add, which is why I thought I might as well do it

Do you mean there is an hdk AttribTransfer that takes a list of weights, or do you mean the sop takes weights on the input. Could you explain more?

Edited March 8, 2007 by sibarrick