I'm surprised to see SESI directly involved in conversations, usually provocated by overcomplicated people.
Is not that Apple's “we are special” attitude, in your words Jeff ?
Where is Apple now ?
As mutch as i like Houdini, as mutch i dont like most of the Houdini users. They are just too “special” for me.
:arrow:
Found 15 posts.
Search results Show results as topic list.
Houdini Lounge » Houdini>>Maya
- some
- 15 posts
- Offline
Houdini Lounge » The Great Divide in CG Facilities: Adapt or Die
- some
- 15 posts
- Offline
Houdini Lounge » The Great Divide in CG Facilities: Adapt or Die
- some
- 15 posts
- Offline
hi,
I agree with some of your points, you are right.
Also, i really dont want to turn this topic in software war, discussing particular software features. I talked about Houdini in general, in the same way how did it mr.Christiano.
I agree with some of your points, you are right.
Also, i really dont want to turn this topic in software war, discussing particular software features. I talked about Houdini in general, in the same way how did it mr.Christiano.
Houdini Lounge » The Great Divide in CG Facilities: Adapt or Die
- some
- 15 posts
- Offline
While Houdini is one of the best frontends to PRMan and seems that the OTLs are working fine, few other very important things are too unefficient ( at least for my taste ).
The overal modeling workflow is unbelieveble heavy - i cant see how people will choose Houdini for organic modeling over Silo, XSI or Modo. Even Maya with its relativelly weak polygonal toolset is way mutch better option. Laying down tons of SOPs to get a simple result is not an option at all.
C'mon, the modeling is all because of the artistic side of the things and the modelers are artistic people mostly. They are screwed-up by any technical stuff.
The overall viewport behaviour is another negative reason - extremelly slow subdivisions, clumsy manipulation tools and non customizable navigation hotkeys and mouse buttons.
Houdini has some nice SOPs doing cool things and sometimes modelers ( or FX guys ) are using them, but thats not enough at all.
The rigging is another weak area. H7 put some fresh air in the room, but the rigging is still weak. Just how the transformation system works in Houdini is not good for rigging purposes. Maya is totally unbeatable here - the transformation system and the overall hierarchy are mutch better designed there. Also the deformers in Houdini need a lot more work. Maybe you will disagree with me here, but i think that those of you, hard involved in the character setup can understand my point.
I can see how SESI is picking good features from Maya ( especially in H8 ) and thats all good, but i think we need more and need it soon - Maya7 is coming and this will change a lot some things.
Animation. The animation must be easy - it must be the easiest and most strightforward thing in the software package. Most of the animators are very weak technicians, some of them have not even basic understanding about 3D space, etc. ( and i think it should be in this way - they, the animators, must care about the animation, not about the tools ).
Houdini must come with well automated animation tools right out of the box ! Cant really see how the overall CHOPs workflow is going to match what the good animation workflow consists of.
Dynamics - the particle system itself is just great, but outside of that Houdini has almost nothing to offer. We must cheat at any step. Is this efficient ?
But yeah … i know, i know - the DOPs are coming.
Customizability - all the UI should be totally scriptable, every single tool, node and action also. Powerfull scripting language - thats the most powerfull tool one application can offer - we can program everything inside the software to work for us in the way we like it. Thats really efficient.
Rendering - while Mantra has bunch of nice features, its motion blur still totally sucks, … why ?
Based on what i said above and regarding the point about efficiency, i will ask - which is better ?
To use other applications, wich offer better content creation tools, or to use Houdini and to compensate with good pipeline workflow ?
Or maybe to use both of them ?
From what i can see around me i can say that pipeline based on multiple animation platforms is not really efficient. Too mutch extra work and restrictions are going for and back between the packages - not good.
Thanks for the attention.
P.S. Keeping in mind all the strong points of Houdini, i'm talking here only about what i dont like and want to be improved.
The overal modeling workflow is unbelieveble heavy - i cant see how people will choose Houdini for organic modeling over Silo, XSI or Modo. Even Maya with its relativelly weak polygonal toolset is way mutch better option. Laying down tons of SOPs to get a simple result is not an option at all.
C'mon, the modeling is all because of the artistic side of the things and the modelers are artistic people mostly. They are screwed-up by any technical stuff.
The overall viewport behaviour is another negative reason - extremelly slow subdivisions, clumsy manipulation tools and non customizable navigation hotkeys and mouse buttons.
Houdini has some nice SOPs doing cool things and sometimes modelers ( or FX guys ) are using them, but thats not enough at all.
The rigging is another weak area. H7 put some fresh air in the room, but the rigging is still weak. Just how the transformation system works in Houdini is not good for rigging purposes. Maya is totally unbeatable here - the transformation system and the overall hierarchy are mutch better designed there. Also the deformers in Houdini need a lot more work. Maybe you will disagree with me here, but i think that those of you, hard involved in the character setup can understand my point.
I can see how SESI is picking good features from Maya ( especially in H8 ) and thats all good, but i think we need more and need it soon - Maya7 is coming and this will change a lot some things.
Animation. The animation must be easy - it must be the easiest and most strightforward thing in the software package. Most of the animators are very weak technicians, some of them have not even basic understanding about 3D space, etc. ( and i think it should be in this way - they, the animators, must care about the animation, not about the tools ).
Houdini must come with well automated animation tools right out of the box ! Cant really see how the overall CHOPs workflow is going to match what the good animation workflow consists of.
Dynamics - the particle system itself is just great, but outside of that Houdini has almost nothing to offer. We must cheat at any step. Is this efficient ?
But yeah … i know, i know - the DOPs are coming.
Customizability - all the UI should be totally scriptable, every single tool, node and action also. Powerfull scripting language - thats the most powerfull tool one application can offer - we can program everything inside the software to work for us in the way we like it. Thats really efficient.
Rendering - while Mantra has bunch of nice features, its motion blur still totally sucks, … why ?
Based on what i said above and regarding the point about efficiency, i will ask - which is better ?
To use other applications, wich offer better content creation tools, or to use Houdini and to compensate with good pipeline workflow ?
Or maybe to use both of them ?
From what i can see around me i can say that pipeline based on multiple animation platforms is not really efficient. Too mutch extra work and restrictions are going for and back between the packages - not good.
Thanks for the attention.
P.S. Keeping in mind all the strong points of Houdini, i'm talking here only about what i dont like and want to be improved.
Houdini Lounge » Question for the developers: FBX Support?
- some
- 15 posts
- Offline
you're going to be surrendering all the true procedural capabilities
Proceduralism and character animation are two concepts which cant live together.
Instead of FBX support i would be glad to see working character setup and animation tools. Everything in our industry is because of the character animation.
Sorry if i sound to direct.
Houdini Lounge » ehh... why not paint-brushing in HALO?
- some
- 15 posts
- Offline
good point …
part of problem is that Halo has relatively weak colorCorrection and keying tools
Isn't it a shame that D&D uses Digital Fusion (afaik) as a primary compositing software, instead of using HALO as the choice of Houdini might suggest?
part of problem is that Halo has relatively weak colorCorrection and keying tools
Technical Discussion » VOPs Flocking
- some
- 15 posts
- Offline
http://www.kolve.com/mp_brainbugz/brainbugz.htm [kolve.com] - open source plug-in for Maya doing some nice behavioural animation applied to Maya's particles. It is easy to use and works as expected.
Will not be that hard to catch-up some ideas and to extract the math from there.
EDIT: Forgot to mention - take a look at the Thesis page - it is based on CraigRaynolds papers.
Will not be that hard to catch-up some ideas and to extract the math from there.
EDIT: Forgot to mention - take a look at the Thesis page - it is based on CraigRaynolds papers.
Houdini Lounge » ExMaya user struggling to simulate falling money.
- some
- 15 posts
- Offline
heh, my bad, somehow i got the impression he is going to animate coins, not a paper money … too tired these days
Sorry about the spamming.
The studio where i'm working on is in the alpha program.
You talked about DOPs and i just continued.
Sorry about the spamming.
The studio where i'm working on is in the alpha program.
You talked about DOPs and i just continued.
Houdini Lounge » ExMaya user struggling to simulate falling money.
- some
- 15 posts
- Offline
The particles cant help you here.
I think the answer of your question is to use combination of rigid and softBodies+springs applied to your coins.
The rigidBody solver will bring you nice dynamic control - sliding, bouncing, good collisions, etc. The softBody stuff will give you the soft deformation of the coins.
On top of that you can add and particle instances on background to fill-up the screen with falling money
You can try and Houdini's DOPs, but they are on early development stage. The RBD collision detection is too bad for now.
I think the answer of your question is to use combination of rigid and softBodies+springs applied to your coins.
The rigidBody solver will bring you nice dynamic control - sliding, bouncing, good collisions, etc. The softBody stuff will give you the soft deformation of the coins.
On top of that you can add and particle instances on background to fill-up the screen with falling money
You can try and Houdini's DOPs, but they are on early development stage. The RBD collision detection is too bad for now.
Technical Discussion » Another Sprite question
- some
- 15 posts
- Offline
I think one of the rules behind the sprites rendering ( actually for most of the FX stuff ) is to not mess too mutch with the alpha channels. Just create another variation of your shaders and tweak them a bit until you get a result close enough to what you think should look as your alpha. Then render two image sequences and merge the color/alpha channels in compositing.
Actually in many cases is enough to render only the color channel, then just extract the alpha with keying. Should work fine.
Actually in many cases is enough to render only the color channel, then just extract the alpha with keying. Should work fine.
Technical Discussion » I need your suggestions
- some
- 15 posts
- Offline
Hey, Bruce, please dont feel offended, but you are the first guy who spent 30,000$ for Houdini Master and RenderMan ( and already own Maya Unlimited + RAT ) and without any idea how to use this investment.
Something is wrong here.
Please reduce your posts a bit, and try to ask questions which make sense.
Thank you.
Something is wrong here.
Please reduce your posts a bit, and try to ask questions which make sense.
Thank you.
Technical Discussion » Hair?
- some
- 15 posts
- Offline
The curve solver is very fast ( relatively of course ).
The trick is to find the best relation between solver's samplingQuality and CV count of the curves.
for example: 100 curves * 50 CVs * 3 iterations = 1500 cycles ( more CVs = detailed simulation, less samples means that some curves can penetrate )
100 curves * 20 CVs * 5 iterations = 1000 cycles ( less CVs = less detailed simulation, but more iterations means no more intersecting curves )
if the CV count is too low, the solver cant do nice looking hair-to-hair collisions.
Of course, it is not that simple, but there is a big space for optimizations and tweaks.
How you are handling all this ?
I cant remember the end of the paper last siggraph, if you remind me we can laugh togather.
The trick is to find the best relation between solver's samplingQuality and CV count of the curves.
for example: 100 curves * 50 CVs * 3 iterations = 1500 cycles ( more CVs = detailed simulation, less samples means that some curves can penetrate )
100 curves * 20 CVs * 5 iterations = 1000 cycles ( less CVs = less detailed simulation, but more iterations means no more intersecting curves )
if the CV count is too low, the solver cant do nice looking hair-to-hair collisions.
Of course, it is not that simple, but there is a big space for optimizations and tweaks.
How you are handling all this ?
I cant remember the end of the paper last siggraph, if you remind me we can laugh togather.
Technical Discussion » Hair?
- some
- 15 posts
- Offline
Yeah, it is definitelly difficult to get proper collisions when the hair primitives are generated at rendertime.
The dynamic curves have “collision width offset” called thing, It defines the “volume” of the curve. Some tweaking will be needed to match this “volume” to the volume of the hair strand controled by the curve. The curves will start colliding when their volumes penetrate.
I agree with you, the hair is tricky thing - there is no perfect solution. The clever hair design and workflow helps a lot - the incredibles is a good example.
The dynamic curves have “collision width offset” called thing, It defines the “volume” of the curve. Some tweaking will be needed to match this “volume” to the volume of the hair strand controled by the curve. The curves will start colliding when their volumes penetrate.
I agree with you, the hair is tricky thing - there is no perfect solution. The clever hair design and workflow helps a lot - the incredibles is a good example.
Technical Discussion » Hair?
- some
- 15 posts
- Offline
The collisions are very accurate.
As far as i can remember the first thing i tried was to test the perHair collisions, because we already know few commercial products which totally suck in this area and i was worried that the dynamic curves are just another half baked solution.
Every dynamicCurveSolver has sampling attributes controling the collision quality, As mutch push them as precise is the simulation. It is fast. You can override the solver values on per follicle basis - local perHair control. I cant describe everything with few words. Here is not the right place to talk so mutch about Maya.
As far as i can remember the first thing i tried was to test the perHair collisions, because we already know few commercial products which totally suck in this area and i was worried that the dynamic curves are just another half baked solution.
Every dynamicCurveSolver has sampling attributes controling the collision quality, As mutch push them as precise is the simulation. It is fast. You can override the solver values on per follicle basis - local perHair control. I cant describe everything with few words. Here is not the right place to talk so mutch about Maya.
Technical Discussion » Hair?
- some
- 15 posts
- Offline
From my poin of view:
As far as exist the hair solutions for houdini remain as inhouse developments in the studios - little bit slow, little bit buggy, little bit restrictive worklflow.
Seems that the Hair stuff in Maya is very good solution - kick-but hair-to-hair collisions, constraints, hair-to-geometry collisions, rest curves ( goals -startPosition, restPosition, currentPosition ) - very handy for modeling of curves and preanimating the dynamic simulation. The worklflow is very open and you are not forced to fallow it at all - just organize a new one, which will meet your needs better.
For example - attach the curves to nurbs geometry and style the hair as you want easily.
We can mimic part of this functionality in Houdini, but will need its time to be done.
As far as exist the hair solutions for houdini remain as inhouse developments in the studios - little bit slow, little bit buggy, little bit restrictive worklflow.
Seems that the Hair stuff in Maya is very good solution - kick-but hair-to-hair collisions, constraints, hair-to-geometry collisions, rest curves ( goals -startPosition, restPosition, currentPosition ) - very handy for modeling of curves and preanimating the dynamic simulation. The worklflow is very open and you are not forced to fallow it at all - just organize a new one, which will meet your needs better.
For example - attach the curves to nurbs geometry and style the hair as you want easily.
We can mimic part of this functionality in Houdini, but will need its time to be done.
-
- Quick Links