Leon Amion Posted March 3, 2006 Share Posted March 3, 2006 We do have some current painting like functions hey MatrixNAN what painting like functions are you talking about? Quote Link to comment Share on other sites More sharing options...
Lyr Posted March 13, 2006 Share Posted March 13, 2006 The muscle asset in Houdini 8 is cool but I'd really love to see this implemented in Houdini: http://www.cs.wisc.edu/graphics/Gallery/SkinFromExamples/ Quote Link to comment Share on other sites More sharing options...
MatrixNAN Posted March 14, 2006 Share Posted March 14, 2006 We do have some current painting like functions hey MatrixNAN what painting like functions are you talking about? 25329[/snapback] Well actually I would love to be able to paint with shaders in Houdini as a sculpting method which would give houdini an advantage that even ZBrush does not have. So basically you would just go into sculpting mode and instead of having the alpha brushes like they do in ZBrush we could have VOP SOP brushes and if we want we could load alpha images into the actual brush. I would also like another feature that they don't have in ZBrush which is to directional brushes where you can set the radius of the brush by holding down a key and moving the mouse back and forth to increase and decrease the radius. Holding down another and moving the mouse would indicate the direction of the brush in which you wanted to paint in. I would also like to have some standard brushes like they do in ZBrush the standard brush, the inflate brush, the pinch brush, the layer brush, and the dot brushes but again I would like to have with the radius and rotate features. Then if we could have something like ZAppLink in Houdini to project the photoshop images ontop of the model that would be nice too. The end result would create a VOPs color shader with the new texture saved and loaded in and a VOPs Displacement shader in which case we could just pipe the map over into the normal channel if we wanted normal mapping . In addition, it would be cool if we could paint our reflections, our speculars, etc. Its a different system than ZBrush that falls more inline with Houdini and makes a lot more sense. Basically I would not want SESI to make another ZBrush but take the best parts and apply it to their application. Lets face it Houdini has a much stronger shading system which could be directly applied to the painting system which would give it more power because basically anyone that knows how to shade can make their very own cool painting brushes and our own set of attribute sliders that we can manipulate while we paint. I think the system in a lot of respects would be better than the ZBrush one. Its a bit more sophisiticated but heck it would be really cool and powerful as all get out. Lyr I don't think that is a very good system because its so general it does not capture details. You can't capture lots of fine details with a Lattice system. Its cool and all but not so pratical. Right now you can get that speed and do far more detail with just VOP SOPs with displacement map images. Which are going to be far more detailed and you can switch at render time to a displacement shader. That makes a lot more sense if you need the speed reaction time stuff. You can currently do this type of stuff in Houdini. Cheers, Nate Nesler Quote Link to comment Share on other sites More sharing options...
thekenny Posted March 14, 2006 Share Posted March 14, 2006 Lyr I don't think that is a very good system because its so general it does not capture details........... You can currently do this type of stuff in Houdini. I agree on this one. I skimmed through the paper and thought the same thing. Sure it talks about doing more a posed-based deformation system, but you can do the basics of this in Houdini now. However, like a lot of the more advanced things, it is not fully complete and something you have to do a lot of setup to do. To go further you need a HDK or SESI programmer to do some work for you. That being said a posed based deformation system isn't necessary the best way to solve the problem. Really if this is the Houdini 9 wish list thread, then I would much perfer for them to stream line the character tools and the interaction between Objects/Sops much more than put in some 'new' systems. Sure there are things which could be improved, ie captureAttributes etc. but really you would get more bang from the buck if they streamlined the usuablity of those things. I'm sure there will be new things in the next release which will help a lot, but I would love if they found a way to mix and match attributes for deformation in an eaiser way so a user can manipulated them faster/easier. As for the Painting things... sure I would love it as well. I tried Zbrush out one night and found it bizzare. I'll have to go back and give a second chance the models look great, but nothing can compare with modeling then rigging a mesh you have made to see how it all works. I would also be curious to find a way to get more HDK developers making things for the package. If SESI could get 1/2 of the development cycles 3DMAX did from all those plug-ins.. it would make more interesting. -k Quote Link to comment Share on other sites More sharing options...
thekenny Posted March 21, 2006 Share Posted March 21, 2006 okay, after doing somethings I haven't had to do in a while here's a new thought for H9. Hopefully someone will read this and consider it as a "good thing" improve the view port display speed. there are things you can do now with graphics cards which will speed things up. I've seen XSI and it handles tonnes of geometry very fast. Imagine if they implemented (fully) fragment code for the 3d/2d view... oh and while they are at it... please make the cooking dependencies smarter. IF I'm in the SOP land view and I'm not viewing anything other than the contents of that network, there shouldn't be any cooking time spent on a CHOPnetwork loading in a bclip which is being used in COPs, or a CHOPnetwork referencing a piece of geometry to move around a light rig. If I'm at SOP level there should be a reason to have the performance monitor cook the either of those things to advance a frame. and yes i know it sounds like a rant. i'm on a streak at the moment -k Quote Link to comment Share on other sites More sharing options...
Lyr Posted March 22, 2006 Share Posted March 22, 2006 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. Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 22, 2006 Share Posted March 22, 2006 Surely modelling shapes is slower than painting weights. Besides I think you will find in H9 they have eliminated the need for painting weights anyway Quote Link to comment Share on other sites More sharing options...
Lyr Posted March 22, 2006 Share Posted March 22, 2006 Surely modelling shapes is slower than painting weights. Besides I think you will find in H9 they have eliminated the need for painting weights anyway 25841[/snapback] Making example skin shapes is real easy, as you have all the deformers available and you only have to describe a range of motion, not every little finger bend. I am now very anxious to see how the need for weight painting has been eliminated in H9! Quote Link to comment Share on other sites More sharing options...
MADjestic Posted March 22, 2006 Share Posted March 22, 2006 I wish Houdini to cook pizza Quote Link to comment Share on other sites More sharing options...
michael Posted March 22, 2006 Share Posted March 22, 2006 I am now very anxious to see how the need for weight painting has been eliminated in H9! 25852[/snapback] notice the there will always be a need to paint weights...and to employ me to paint them Quote Link to comment Share on other sites More sharing options...
peship Posted March 22, 2006 Share Posted March 22, 2006 weights ? or you mean walls ? 'cos i'm thinking about pink spots on a sharp green background for the bedroom ... Quote Link to comment Share on other sites More sharing options...
edward Posted March 22, 2006 Share Posted March 22, 2006 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. 25839[/snapback] I'd be interested in hearing from anyone who has had experience with such a system (ie. someone who has worked at PDI). I've heard of people saying bad things about a similar system (albeit different algorithm) at ILM. Quote Link to comment Share on other sites More sharing options...
peship Posted March 22, 2006 Share Posted March 22, 2006 I think i can bring you pretty detailed information about poseDeformers. It is a wide topic. Let me know if you are interested in some specific areas to shortern the typing. Quote Link to comment Share on other sites More sharing options...
edward Posted March 22, 2006 Share Posted March 22, 2006 Does it work in practice? Quote Link to comment Share on other sites More sharing options...
peship Posted March 23, 2006 Share Posted March 23, 2006 Does it work in practice? 25873[/snapback] yes, it does - all big studios ( and many others also ) are using PSD's in production. pose based deformations require two things - pose readers and pose deformers. the well designed pose readers measure vector angles between transforms. each poseReader represents a pose stored inside the poseDeformer. You know there are unlimiteed combinations of Euler angles for exactly the same orientation of a transform in the space - why that using Euler angles to control PSD's is unacceptable. Each poseDeformer blends point positions of a geometry in conjuction with previously stored poses. These poses are some sort of snapshots of the geometry in a given skeleton pose. there are different algorithms for blending poses ( search google for RBF deformations for example ). as bigger is the value returned by a given poseReader as stronger will be represented the connected to it pose in the final deformation. The really cool thing with PSD's is that the output deformation is normalized. If you try this with blendShapes, after applying few of them to the same points - they will literally explode, while PSD's take care about that and the mesh will look nice and cool. In most cases the regular worklow is to make as good as possible skinWeighting and on top of that to add PSD's. Let's take a shoulder rig for example - the arm joint has a hemispherical freedom of motion - in the common case you will need to cover with PSD poses this hemisphere using some step - to say - every 15 or 30 degress along each rotation axis of the shoulder bone. Another approatch is to use PSD's only to fix bad deformations in extreme poses. A more complicated example ( not so far ago i had real troubles with something similar ): Very often you will need to grade layers of blendShapes and PSD's. Let's look again at the shoulder rig case - if the clavicle is in basic position and one setup bunch of poses - everything will work fine, but if the shoulder bone is rised up, then the base shape will change and the local point coordinates will be different than the ones stored in the poseDeformer. Why that we need a blendShape to undeform the geometry, and then to apply another PSD deformer and to start setting new poses from this new position. With driven keys we need to control both poseDeformers - as mutch we are moving up the shoulder bone - as mutch we are lovering the affection of the first poseDeformer over the gometry and as mutch we are rising it for the second one. etc. As i said there are cases where are needed multiple layers of PSD's, blendShapes, whateverOtherDeformers - it is a real pain in the butt, but resulting deformations are, to say , ... unbrakeble. As far as i know some studios are going even further and buid massive libraries with stored poses, then making analisys of the position/orientation of multiple body parts in relation with each other, then extract and merge the needed poses to build the final deformation. PSD's are good friend and to the cloth sim. The last movie of Pixar is a good example for that. There are many weird moments where different poses overlap each other and you need to add more on top to fix the bad deformations prodcued by the overlapping, or to delete some - which will affect the deformations in other cases. etc. few links to check: http://comet-cartoons.com/melscript.php - check the plug-in area - very powerfull poseDeformer for no money ( here is a more detailed explanation - http://www.tokeru.com/twiki/bin/view/Main/MayaPoseDeformer ) http://www.fourthdoor.com/scripts/ - poseDeformer built with standart maya nodes only www.softimage.com - XSI comes with very good PSD's ( called shapeAnimation ), but the poseReaders are just not there. www.autodesk.com - MAX7 introduced PSD's too - i think that the poseReaders are not there too. /* EDIT: Just watched the presentation of the faceRobot thingie - i dont know what is this "tissue solver" they are talking about, but i can bet 5 bucks that this setup heavily relies on PSD's - it's obvious. EDIT */ tried to use simple words, hope the basic idea is somehow explained. Quote Link to comment Share on other sites More sharing options...
Mcronin Posted March 23, 2006 Share Posted March 23, 2006 I know from a rigging standpoint this sounds fantastic, but it seems that no matter how well the rig works, no matter how much you try to build in solutions for problematic deformations, the animators are going to find a way to twist it into some pretty messed up shapes. You are Sisyphus pushing that boulder up the hill. You'll put all this effort into making the skin behave perfectly but ultimately it doesn't seem to matter once an animator gets a hold of it. It seems like a lot of effort for little result. Quote Link to comment Share on other sites More sharing options...
peship Posted March 23, 2006 Share Posted March 23, 2006 checking this page at the same time - your message just popped-up - heh. Hey Mike, if you want, tomorrow at work i can show you some PSD stuff - you will see how the rigs respond very well far beyond than the phisical limits of a humanoid characters Quote Link to comment Share on other sites More sharing options...
edward Posted March 23, 2006 Share Posted March 23, 2006 @peship: What about their speed? Are you using PSD for the rigs at your workplace? When I spoke to someone there, he had some reservations about the deformation speed of those rigs. Quote Link to comment Share on other sites More sharing options...
peship Posted March 23, 2006 Share Posted March 23, 2006 yes, of course they are here - we are using them all the time. speedwise - realtime is a good approximation - think for them as a special sort of blendShapes. Quote Link to comment Share on other sites More sharing options...
edward Posted March 23, 2006 Share Posted March 23, 2006 What's the max examples that you have per character? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.