ICE cage deformer

[pooby]

Hi.

I'm doing a project where I need to cage deform some detailed clothes to a simulated cloth mesh.
I have it working but it's really really slow (takes about 5 mins to apply the cage deformer etc) and the scene file is HUGE because of the envelope weights of the cage deformer. and it takes ages to save.
The strange thing is that Lightwave has something which does the same as a cage deformer (fx metalink) It doesn't have any stored weights and it's practically instant.

I wonder if anyone has a clue how to make one in ICE and if they think it would be faster than XSI's original. (preferably one that doesnt need to store a bunch of weights in the scene.)

[Helli]

Can you post a screencapture of what you want to do and of your solution. Not sure actually what you want to achieve.

[pooby]

I can, but it's just as easy to describe.

I have a jacket, with lapels and such. this isn't easy or appropriate to do a direct cloth sim on, so..

I have a proxy of the jacket which doesn't have anything fancy on it, just a plain mesh that is similar to the jacket but without lapels and pockets.

I run the sim on the second, and I cage deform the first to the second.

There is no problem with this. It works fine except for the issues stated in my first post. Ie that it saves a bunch of weights with the scene, making it very slow.

I imagine that ICE would be able to do a similar job by weighting to proximity of nearby points instead of saving an envelope. thereby keeping the scene light and fast.

If that still isn't clear I can post images.

[Helli]

Its clear now, I am new to ICE too but this seems like something I want to try. Give me some time :)

[ThE_JacO]

Speaking of cage deformers: ICE would still have to save the weights if you wanted performance.
A cage deformer works based on a delta, at some point you have to store a relationship between meshes in their base state, otherwise results wouldn't be consistant.
The weights are heavy because you're talking of an NxM relationship (weight table is points in one mesh by points in the other) for a proper cage, which easily ends in the tens of millions entries or more.

FX metalink in LW probably integrates and maps point velocities from one mesh to the other. It will still have a lookup table of sorts somewhere, just not the same way you have with a cage deformer since it doesn't need to arbitrarily map the weights in both directions, it's a much easier to optimize situation in terms of lookup.

You can reproduce a simulated effect like FX metalink in ICE anyway, but the maths for proper integration might be a bit tricky, or if you're happy with some primitive interpolation it's a fair bit of work with arrays, nothing out of reach though.
I might give it a go if I find sometime this week. Moving between continents again though, so no promises :)

[pooby]

well, thanks very much both of you.

[rray]

Ben's "binder" addon might work for that: http://shaders.moederogall.com/

[takita]

Pooby -

I just did something similar. My solution only worked in playback but it did the job.

Not in XSI right now but I'd suggest you look in to creating two ice trees, one in the modeling stack to initialize positions based on proximity from the slave to the master mesh (set particle stick node sets a lot of useful data) and another one in the simulation stack to actually stick the points to the master mesh.

note that this requires the simulation engine to evaluate proper but you can probably explore similar ideas to get one that is more interactive and doesn't need to play fwd to work (mine worked so I stopped and moved on to something else)

if you like contact me offline I can send you a scene later.

-T

[pooby]

That sounds great..
The only issue would be if Lapels and things get flattened onto the master mesh.

[takita]

Somewhere in one of the stick compounds also there is an example of how to store and accomodate the offset matrix of your point to the surface.

-T

[ThE_JacO]

Alright, got some time, was bored, and started working on a compound or two.
In the meantime, here's a 2m job on an uninterpolated cage deformer you can play with.
Interpolation will come when I get bored again, or you can work on it yourself now that you have the barebones of what I was talking about with deltas.
Doesn't need to be simulated, only needs a reference object to describe the cage's base state.

[pooby]

That works well. How can I make you bored?

have a read through this

http://www.stampsales.co.uk/

[ThE_JacO]

Playing with stuff, so not too bored yet.
For the time being just switch the get closest point node for a get closest location, remove the array pick (no need since get closest location returns a single location) and you should get the mesh following closely.
It's still not in full what the cage deformer does, that's a bit trickier with the context limitations, but it might get you where you want to be in terms of speed and overhead (lack thereof).

Scene attached if you're that lazy you need one :D, but it really is a matter of swapping a node and deleting another.

[mocaw]

And TDs thought they'd get more sleep with ICE out! Nope just like anything else- the more efficient it is the more they/we demand!

This is looking awesome esp. given how long you've been working at it. Amazing!

[pooby]

Excellent work. thanks very much ..

[ThE_JacO]

That is one of the coolest things about ICE (no pun intended).
If you know what you need to do, it takes seconds to do it and it computes blazing fast.

When I said 2m to put it together I meant 2 actual minutes to wire things together and maybe reconnect one thing that was connected out of retardation.

"code less create more" was the wrong slogan imo, "f*** around at the speed of thought" would have been better.

[halim]

Were the hell did you pull this ReinterpretLocationToNewGeometry Node from ?
thx,
H.

[halim]

Ok, I guess it's a private compound... I'm still a newbie when it comes to ICE.

[grahamef]

No it's there. It's just not exposed directly. Hunt around in the \Data\Presets\ICENodes directory of your install location and you can drag it into an ICE tree.

[halim]

Ok, I got it... ICE is like Doom, full of secret crossings :)
Thanks a lot.
H.

[Ahmidou]

hi Halim, it's an undocumented regular node
you can find it with the others :C:\Softimage\XSI_7.0\Data\DSPresets\ICENodes

edit: arf, I was too late.....

[miles-simage]

Hi ThE_JacO,

I'm trying to link up a UV based cage deformer base inspired from the "nonInterpolatedCag (http://community.softimage.com/attachment.php?attachmentid=568&d=1218568247)e". Right now I am using nurbs as cage, because the "UV to location" doesn't support poly mesh.
I used the closest point location to get the UV coordinate and the offset data. But the performance is not very good.

My guess is ICE need to find the closet location all the time.
Is there a way to save out the data and read it back, the initial value of the UV and offset, to improve the speed?

Thanks
-miles

[ThE_JacO]

What do you mean exactly with a UV based cage? Just to understand what functionalities you want to add that are UV dependant. Also nurbs being higher order and detached from the control vertices (in most configurations) doesn't make for a very good cage usually.

As for the problem:
Closest location on a surface is a different problem from doing it on polygons.
On polygons it's relatively cheap and easily accelerated, on surfaces you're up against an integration/minimization problem, which is a bit of a bitch, so that's where you're losing your performance.

Now, what exactly do you want to save?
I'd assume you want to save a lookup table of sorts between your deformer and the target. You could probably put the bottom part of the tree together as it is now, but instead of writing from the closest location to the position (with the objects in their base state), you could write the U and V values to two weightmaps, or to one CAV property.
Freeze that off, and then instead of using closest location just look up those maps you saved, pipe them (after conversion) into a UV to location, and then look up the delta the same way I do now. I'd probably go with two weightmaps personally as it's a vertex property (vs a sample one for cav), and is more likely to interpolate the way you want it to.

[miles-simage]

thanks ThE_JacO~

Sorry to make thing complicated, the uv based cage is almost like a surface deform op in XSI. It should look up the UV location and the offset from the cage to perform the deform.
The idea to use Nurbs is that it didn't need to be interpolated to get a smooth result.

I will try to write out the cloest location data to a weight map/cav tonight, I trid "cach on file before", but I don't unstandand it quite well and it doen't seems to cach the data...

Here is the orginal scene I did.
I am really excited that I can create a deformer that really work! Because I have no programming knowege/3d maths knowege at all, I just learn that bit by bit in Ice.

-miles

[ThE_JacO]

If you look at the second scene I posted a form of interpolation is already provided by ice reading things like the delta at intermediate locations.

A deform by surface is a very different thing from a cage and it should consist of mapping a planar projection of a space to a surface's UVs. That doesn't require a "base state" to work, it only needs to project your mesh onto a plane of your choice, normalize that space, and then translate it to the equivalent position of that UV on a surface with the elevation as a multiplier of the surface's normal at that point.

[khanibal]

Hi The_Jaco,
thank you for sharing your compound !:smile:
Just to clarify something:
I see the attribute "PointDelta" on your connections.
By Default this attribute doesn't exist, so if I understand you have just typed this attribute ("PointDelta") on Set Data Node and now you can store the values of deltas vectors on this added attributes on the object?
Does it means that we can store any values in any new attribute that we have created ourself ?
Thanks,
Stephane

___________________________________
Stephane Hoarau
3d Technical Director
Cyber Group Animation

[ThE_JacO]

By Default this attribute doesn't exist, so if I understand you have just typed this attribute ("PointDelta") on Set Data Node and now you can store the values of deltas vectors on this added attributes on the object?
Does it means that we can store any values in any new attribute that we have created ourself ?

Correct, if you use a data node and set it to something that isn't reserved it becomes a custom attribute.

[PhilTaylor]

Just a note on this graph.

You don't need to use the 'Reinterpret Point Location' node. That node takes a location value, and converts it between 2 meshes. so you can access a separate mesh and ues this data in the context of the mesh you are operating on.

I just re-arranged this graph to use the 'switch context' node. this node is fine for this task.
I'm not sure exactly where you should use the 'Reinterpret Point Location' over 'switch context', but at least 'switch context' is documented and fully supported.

[PhilTaylor]

And for another implementation again I have uploaded another version of the cage deformer.


The cagedeformer 1 and 2 method stores a delta per point on the cage ref object. this delta gets updated during animation or when the user edits the mesh points.
Then there is another tree that executes on the higher-rez mesh that interpolates the delta and applies it to the hi-rez mesh point position.

What this means is that there are actually 2 subgraphs that execute, even though they are stored on on one object. the fact that 'deformer_refPos_geo.PointDelta' was specified as the target caused another operator to be installed on the refpos mesh. you can see it in the explorer in italics because its a slave operator.

The other thing that comes out of this is that you were using closest point each frame to find the point on the low-rez meshes that you would use to access the delta value. Closest location will start to cause slowdowns on huge meshes.


I re-built it so that only the hi-rez object has 2 operators. 1 in the modeling region, that finds the closest point on the reference mesh and stores the point locator, and another graph in the animation region that updates the mesh each frame during animation.

The update graph compares the position of the point locator on the ref mesh and the animation mesh and applies this as the delta to the hi-res mesh point position.
This setup should be significantly faster on big meshes, and instead of ICE interpolating a delta value, we are actually accessing the 2 low rez meshes in the middle of the polygons and extracing the position values. This should give much more accurate results( I haven't checked, so don't hold me to it.)

You can also do a bit more preprocessing on the stored point locator. For example, you could check normal values and other things like weight maps to make sure you get the location you want, but this only ever happens once and not during playback.

I think its so cool that you can solve problems a variety of ways. ICe is very powerfull tool. I think its so impressive that in the cagedeformer2, ICE automaticly interpollated the delta value when accessed from the middle of a polygon.

finally, this is a perfect example of where you can't simply use 'Switch Context'. We have a point locator on mesh A, and we want to use it to access mesh B.

[thiago]

Hi Phil, thanks for the explanation and share your solution. That was a really good example.
Did you post that in the compound section? would be nice...
Thanks!
And we missed to see you at Siggraph!

[PhilTaylor]

Thanks Thiago

Actually, I realized that there was another flaw in the current implimentation.

If the base polys get rotated, then the offset gets all skewed. Thats because the offset needs to be rotated also, or at least be in the context of the polygon.

So now I store the distance between the the 2 low rez meshes, and then offset the high res mesh from the animated lowrez mesh using a property called the 'GeometricNormal'. This is a special 'un-smooothed' normal. The normals are smoothed for rendering purposes, but in this case, we wan the unsmoothed normal for accuracy. the un-smoothed normal is guaranteed to be perpendicular to the polygon face.

Now when polys are rotated, the offset is always in the coordinate frame of the polygon.

Phil

[PhilTaylor]

The cage deformer that I have implemented still has many flaws. It will really only work well when the cage fairly closely fits the higher rez mesh. It will not work well when deforming geometry inthe middle of the cage.

This is because simply sing closest point means that each point in the high rez mesh is bound to 1 polygon in the cage, and will move with respect to that. If 2 points close to each other are bound 2 different polygons, you might find issues such as tears in the high rez mesh when the cage deforms a lot. The 2 points might actually overlap, and their movement will not be closely correlated.

For anyone who has a bit of time (not me), and a solid understanding of math(not me), implementing the pixar harmonic coordinates paper would be really cool.

http://graphics.pixar.com/HarmonicCoordinates/paper.pdf

http://graphics.pixar.com/HarmonicCoordinatesB/paper.pdf

[Edit]

Actually, the paper on Positive Mean Value Coordinates might be more interesting here.

http://www.math.tau.ac.il/~lipmanya/pmvc/PMVC.pdf

"The running times of PMVC are generally in the same order
of magnitude as MVC, and about 10–100 times faster
than HC,"


Phil

[ThE_JacO]

The pixar harmonic coordinates paper is interesting for a number of things, but I wouldn't want it to be a replacement to a generic cage deformer.
The way a cage deformer like XSI's work probably doesn't deserve the name cage, since the pointcloud is largely responsible for deformations.

Pixar's cage deformer is an actual cage, but there are rules on how the cage has to be built (all enclosing, not intersecting, all tris etc) and some people might not be too happy with the restrictions.

It would be an interesting exercise though, and it would definitely push ICE to its limits in terms of complexity of the network.

[vfortin]

A bit late I know but in case you haven't seen it already, this paper could spark some interest.
http://www.rhythm.com/~tae/smashfinal.pdf