Houdini 9 Wish List

[peship]

I cant remember the exact count, but lets see ...

the last hero character i rigged has ... around 8-10 poseDeformers with about 60-100 poses. Cant remember the exact numbers it was several months ago.

There are studios which are running muscle sims on the characters ( or brute force methods with remodeling the geometry pose by pose ), then baking everything up to PSD's and then applying them to clean, simplified rigs - Hulk was done this way. As far as i know - The Incredibles too ( one said that even the cloth sim was baked to PSD's ) - just for instance.

Kind of heavy and time consuming approatch.

We are not doing this - we are going as far as possible with the regular skinning methods and then on top of that applying PSD's.

In addition we are using and muscular systems for some of the characters to preserve body volume in extreme poses or to add fake dynamics.

There are some special deformers, part of the musclular toolset for skin relaxation/smoothing which are doing great job for cleaning-up facial deformations.

In fact i'm little surprised that you guys, at CORE, are not using PSD's.

[edward]

It was precisely because of Hulk that I heard bad things about example-based approaches. I would contend their formulation, through multi-weight enveloping (MWE) was the source of their problems though.

[edward]

BTW, all this talk is related to the second input of the Edit SOP as well if want a way to layer deformations on top of your (bone) deformed skin in a meaningful way. See also the "sopcreateedit" hscript command.

[peship]

BTW, all this talk is related to the second input of the Edit SOP as well if want a way to layer deformations on top of your (bone) deformed skin in a meaningful way. See also the "sopcreateedit" hscript command.

25886[/snapback]

Not really.

The biggest difference comes from that thing, i mentioned before, called RBF factorization. All the stored poses form a table with positions of each point of the geometry.

When couple of poses are going to be applied, the RBF algorithm extracts the positions of those points who are going to be used in the final deformation and creates a smooth curve representing their positions with Time as input parameter. In this way the positions of the points will be blended smoothly without poping.

For example - bending elbow - i have setup two poses - the first one starts at 0 degrees and ends at 120 degrees rotation of the elbow, the second pose starts at 30 and ends at 50 degrees.

If you use editSOP you will see that some of the vertecies affected by the second pose pop at angle of 30 degrees and start moving until the control joint reaches 50 degrees, then they immediatelly stop. If the amount of deformation of the second pose is big enough it will look really weird in animation.

Using RBF technique both deformations will be smoothly interpolated on per point level.

[sibarrick]

I gotta say this all sounds like a huge amount of stuff to set up, I'm sure the results are great but surely if you just need a system to quickly capture and model and deform it around easily then this isn't the way to go. 60-100 poses to setup that sounds like a huge number. If you are working in a shop on your own rigging caharacters that doesn't sound very feasible. How long does it actually take to set something like this up?

I guess it really breaks down into two things - totally believeable characters like the Hulk and simply cartoon stuff. Surely for the later you don't need to go to all this trouble? Or is it much easier to do than I'm imagining.

[edward]

@simon: well, if you're using some muscle sim's to create your examples, then it's not so hard.

@peship: I understand that, I was simply saying that they were *related*, ie. part of the solution.

[sibarrick]

@simon: well, if you're using some muscle sim's to create your examples, then it's not so hard.

25892[/snapback]

Yeah, not so hard, but what your basically saying is that the better your system for creating the initial poses the less work you have to do on top. That initial system could be a muscle sim (which maybe not so many people have access too, and itself takes time to set up) or a weight painted (or not) traditional capture setup. yes?

So this does sound like a great way to post-control what goes on after you have got as close as you can with you first pass setup. The better and quicker and more stable the first pass the better it is for your pose system.

So there is still room for capturing weights as quickly and effectively as possible.

[peship]

@sibarrik

No, it's not that big thing to setup. I'm saying it again - think for it as a blendShapes. And it depends very mutch on how the tools are implemented. Basicly you are moving your character in a pose then doing simple modeling - moving points around and tweaking those areas which look bad in this pose, and as last step you are pressing the "OK" button. Nothing extraordinary.

You dont need muscle stuff to help you out. You only need to decide what is looking bad in a given pose and to fix it out using very basic modeling.

Yes, a good skeletal structure with clean skinWeighting is the essence - once you have this part well done you can start adding more stuff on top.

60-100 poses are not big deal at all - you can turn them out for day ot two.

@edward:

I can see your point now.

Dont worry about how you are moving your points, better think of how to normalize the deformations produced by the blendShape SOP.

[thekenny]

In fact i'm little surprised that you guys, at CORE, are not using PSD's.

25882[/snapback]

Umm, I'm not sure how much to reveal without the all seeing eye coming down on me

But we did use a PSD for the mane in the wild. It was a 2D (parameter space) system which allows us to predetermine the best profile of the mane based on the animation of the critter. It was 2D in the sense of the lookup. Although it could have been a 3D system the 2D approach provided us with decent results. I'm sure Mike and Jason will tell you we still had to do a lot of corrective shapes for the mane afterwards and it was at times difficult and time consuming. In the end it got the job done and allowed use to have some automation rather than not at all. There was an HUGE deadline looming and we had to move forward like any production has to when things get tight with time. I'm sure we could have done more and improved what we used but in the end we had to get shots done.

I opted to go with fewer shapes rather than more. I came to the same conclusion that it would take about 70-100 shapes to solve the majority of problems. The more I added the more the interpolation was a problem and because it was only a 2D parameter space the angles left you hitting what I was calling sweet spots in the lookup. It had a hierarchical option to nest another lookup from with its own library to solve those issues with either a 2D or 3D solution. It's hard to really judge at times since there are multiple interpolations going on. There was a smooth option for blending the shapes I'm not sure if it was a radial basis function or not. I would have to back and look at the code and talk to a programmer.

I don't think it is the same kind of PSD you are talking about now since it only allowed for 2 or 3 parameter space reference, but it is a form of one.

Generally for characters we don't do any PSD per say. We have done the blendshape method, both pre and post deform with success. We have other techniques to help get around problem areas but like most solutions it depends on what you are trying to do and what the look is you want to achieve.

I would be interested in a solution IF there was a more fluid way to make shapes in Houdini and store them. Don't get me wrong I'v been using Houdini since 1.1 and I can do a lot with it including modeling, but if you are going to take this approach to solving deformations it would be nice to be able to do it cleanly and efficiently.

@peship

your point of how your blendshapes are moving is valid IMHO.

If there is a better way to do this I would be interested.

The deformSOP in the current build will allow you to deform vector attributes so you can create and define a perPt local axis. I think you will have to make your own (currently) SOP to transform those attributes if you do any other deformation on your geometry which would make those vectors invalid. So I guess what you need ontop of that is a better blend taking into acount the local coordinate.

correct?

otherwise you pretty much have it.

How many parameters do you take into account when you do the lookups?

just curious.

I took a quick peak at the maya links you posted and from the most part it seems like it is really just a blendshape based on joint angles, but the blend is happening using the local coordinate space and the difference between the different shapes and their coordinates.. call me crazy or is that cover the basics.

-k

[sibarrick]

Yes, a good skeletal structure with clean skinWeighting is the essence - once you have this part well done you can start adding more stuff on top.

60-100 poses are not big deal at all - you can turn them out for day ot two.

25895[/snapback]

Yup I think I get it now. I'm still thinking of also being able to do simple rigs that only take a couple of hours to setup not days. I think the two can live together, this pose method simply adds an extra layer of control for when you need it. I like it. Sesi please impliment for next week. Thankyou.

[peship]

Umm, I'm not sure how much to reveal without the all seeing eye coming down on me

But we did use a PSD for the mane in the wild. It was a 2D (parameter space) system which allows us to predetermine the best profile of the mane based on the animation of the critter. It was 2D in the sense of the lookup. Although it could have been a 3D system the 2D approach provided us with decent results. I'm sure Mike and Jason will tell you we still had to do a lot of corrective shapes for the mane afterwards and it was at times difficult and time consuming. In the end it got the job done and allowed use to have some automation rather than not at all. There was an HUGE deadline looming and we had to move forward like any production has to when things get tight with time. I'm sure we could have done more and improved what we used but in the end we had to get shots done.

Yeah, i heard about some pretty crazy stuff you guys did there - can we see that in the movie ? Somebody said that it was cut.

I opted to go with fewer shapes rather than more. I came to the same conclusion that it would take about 70-100 shapes to solve the majority of problems. The more I added the more the interpolation was a problem ...

Exactly !

I would be interested in a solution IF there was a more fluid way to make shapes in Houdini and store them. Don't get me wrong I'v been using Houdini since 1.1 and I can do a lot with it  including modeling, but if you are going to take this approach to solving deformations it would be nice to be able to do it cleanly and efficiently.

I can understand you very well. Day and night i'm dreaming about scripting abilities in H to query/edit whatever data is stored inside the nodes.

Never looked at the API ?!

@peship

your point of how your blendshapes are moving is valid IMHO.

If there is a better way to do this I would be interested.

The deformSOP in the current build will allow you to deform vector attributes so you can create and define a perPt local axis. I think you will have to make your own (currently) SOP to  transform those attributes if you do any other deformation on your geometry which would make those vectors invalid. So I guess what you need ontop of that is a better blend taking into acount the local coordinate.

I will spend later a moment to check how this PSD tool, built with standard Maya nodes only, actually works - then can try something similar in Houdini.

How many parameters do you take into account when you do the lookups?

just curious.

By default the poseReaders are reading only a vector angles or local/world spacePositions, but you have the whole freedom to build as complicated dependencies as you want and to connect the output value of that math to any of the inputs of the poseDeformer. For now i'm sticking with the the first case. As simple as better Only few times i needed more complicated setup in addition to the poseReaders.

I took a quick peak at the maya links you posted and from the most part it seems like it is really just a blendshape based on joint angles, but the blend is happening using the local coordinate space and the difference between the different shapes and their coordinates.. call me crazy or is that cover the basics.

Yup !

Each pose lives in the local space of the joint to where is parented the poseReader controling the pose. etc.

[thekenny]

Yeah, i heard about some pretty crazy stuff you guys did there - can we see that in the movie ? Somebody said that it was cut.

Everything you see with the lion... the mane is what we used the system on. I can't keep track of what is and what isn't in the movie.. been a long time. There is some crazy stuff for sure.

I will spend later a moment to check how this PSD tool, built with standard Maya nodes only, actually works - then can try something similar in Houdini.

By default the poseReaders are reading only a vector angles or local/world spacePositions, but you have the whole freedom to build as complicated dependencies as you want and to connect the output value of that math to any of the inputs of the poseDeformer. For now i'm sticking with the the first case. As simple as better  Only few times i needed more complicated setup in addition to the poseReaders.

So does the binding of the geometry transform the vector angles or is it recomputed every time in a standard method? I've seen/worked with both methods and have seen flaws in both... or rather different results with both, at times one would work better than the other and vice versus. I'm pretty sure the EditSOP uses a method of using diagonal vector from across the polygon and the normal and then a cross product to get the last axis... If you use the first edge and the normal you can get twisting coordinate space from shear on the deforming geometry. The vector deformation in the deformSOP should be a stable result, but I haven't used it enough to see when it comes to blendShapes. Setting up a restPosition with every point having a axis is easy and you can just supply that to the DeformSOP to get the deformation. The positions would be in local space at that point. Like I set you would have to your 'fancy' blendshape business. Plus, like I said before you would need to make something which could transform the coordintates based on rest and a arbitratry deformation on the geometry from any other sop other then a deform.

-k

[edward]

I think peship is talking about something different here ... more about how to make sense of the animation inputs in order to do the interpolation between different shape.s

[thekenny]

I think peship is talking about something different here ... more about how to make sense of the animation inputs in order to do the interpolation between different shape.s

25908[/snapback]

oh no. it is all part of it. you need the shapes blending well, that's what i discussed, but you still need a parameter(s) to drive that blend.

-k

[peship]

I think peship is talking about something different here ... more about how to make sense of the animation inputs in order to do the interpolation between different shape.s

25908[/snapback]

both.

This toolset exists from a very long time, but i never had chance to see how it actually works - at first sigth it seems to relies on blendShapes + per point vector/matrix math in addition.

@kenny - thanks for the info - for now i cant clearly understand everythin you are saying, i need to sit back and play a bit with these tools in the way you are talking about. In fact i'm not really sure how well they talk with the capture/deform SOPs. I have some fears, but cant sort and explain them at that moment.

thekenny said:

So does the binding of the geometry transform the vector angles or is it recomputed every time in a standard method?

Yes, it transforms the local space of each point. Not really sure what you mean with "standard method".

You can use PSD's in both ways - applied before or after the skinCluster - the reqular way is to use them after it.

I think that using them before the skinCluster has limited purpose - mainly to underform the geometry for some reason in specific poses - when is needed to layer deformers/skinClusters/PSD's/etc/etc and there are conflicts between the different deformers.

[edward]

@peship: Just so that there's no uncertainty on my part, when you say 60-100 poses in a day or two, those are 8 hour days right?

[peship]

@peship: Just so that there's no uncertainty on my part, when you say 60-100 poses in a day or two, those are 8 hour days right?

25955[/snapback]

yup, 8 hour days, but that's the case only when necessary

otherwise it takes more ... you know - talking with the guy sitting behind, spending extra time for lunch, playing on the game machine ( 'cos feel bored ), going home early because ... why not ...

[MatrixNAN]

A pose based deformation system is as fast as you can model the shapes, it can capture as much detail as you care to model, and allow helper bones for. It is far more robust than just a lattice based solution. The programmer art in the paper doesn't really do the idea justice.

Why do you think a pose based system isn't the best solution? It's a solution that moves control of the deformations to the modeler and away from the weight painter (eliminates the need for weight painting really). It doesn't rely on any dynamics solvers,  and the most elaborate deformer used is a bone so it's useful for run time applications like games.

25839[/snapback]

Hey Lyr,

I still disagree with you. I think it does not capture fine detail. I seriously doubt that it would capture the detail of a character that is millions of polys down to the actual veins and what not. You can just use a image based deformation system and that would be very light and fast and you can currently do that in Houdini. That would allow you to capture all kinds of detail and it just makes more sense to me.

Simon Solved the Weight Painting problem here:

http://www.sidefx.com/index.php?option=com...pper&Itemid=144

Cheers,

Nate Nesler

[sibarrick]

Don't forget you can still add the fine detail on top of any system by using a displacement after the deformation. Even with all the capture stuff I've played around I can see having a pose based system can add some candy on top of what you can get with even the most sophisticated capture system. And you wouldn't really want to be moving around millions of polys would you? Surely you need something more realtime?

[Jason]

And you wouldn't really want to be moving around millions of polys would you? Surely you need something more realtime?

25981[/snapback]

Is it too much to ask for both?

Seriously though, I've been an interested reader of this thread of late. I don't have a lot to contribute quite yet. I'm in a production hole right now.