Moin,
there are quite a few caveats with Houdini's current cloth solving setup. For one, if you are using volume based (“tets filled”) cloth objects, the resolution of the cloth object itself (the render object that is) does not matter that much (except for shape definition), but the number/size and shape of the tets does. In a setup where you are going both for folds (one “job” for a cloth sim) *and* collisions (another “job” for cloth sim) you will have to balance both goals, since folds obviously want smaller distance thresholds and thus probably way more substeps (or even a stretched timeline, since, as you noticed, substeps can only take you that far, while simulating in “slow speed” can get you to another level of detail). However, collision detection works best if there is enough room/distance between the objects you are testing.
Also note that if you are using position based collision detection, you are bound to those elements that get checked (often only the points), so resolution of the mesh does play a role for collision detection (position based) and you will get “jitter” much faster and less controllable with low-resolution meshes.
Don't neglect the actual cloth attributes. If for example you introduce bending resistance, you are *actually* introducing a force into your system. With low-resolution meshes, this can (and probably will) lead to “explosive behavior”.
When starting to learn cloth simulations, my suggestion is to concentrate on one of the goals first: Collision behavior or folding (the latter being a matter of self-penetration / collision detection), with this order seeming the easiest approach.
I hope any of this is of some help!
Marc
(who's creating a cloth sim workshop for H …)
Found 590 posts.
Search results Show results as topic list.
Technical Discussion » Cloth on a character not working well at all
- malbrecht
- 806 posts
- Offline
Technical Discussion » clothstitchconstraint woes
- malbrecht
- 806 posts
- Offline
Moin,
quick thought I had when walking the dogs … wouldn't, at least in your specific example, a “closest point” iteration based on one set of points to get the order of the other set of points be the simplest approach?
I haven't used H much over the last couple of weeks, so I am not sure if there is a “closest point” node that you could “nodally” wire in, but a VEX snippet that reorders one of the two group lists should be pretty straight forward.
For more complex situations this probably wouldn't work, but then again might …
Marc
quick thought I had when walking the dogs … wouldn't, at least in your specific example, a “closest point” iteration based on one set of points to get the order of the other set of points be the simplest approach?
I haven't used H much over the last couple of weeks, so I am not sure if there is a “closest point” node that you could “nodally” wire in, but a VEX snippet that reorders one of the two group lists should be pretty straight forward.
For more complex situations this probably wouldn't work, but then again might …
Marc
Technical Discussion » clothstitchconstraint woes
- malbrecht
- 806 posts
- Offline
Oh, sorry - that's why I full heartedly dislike pseudonyms on the interwebs
I'll have a dive into Houdini's stitching logic later next week, would love to share thoughts and experiences with you, can't help right now though, sorry!
Marc
I'll have a dive into Houdini's stitching logic later next week, would love to share thoughts and experiences with you, can't help right now though, sorry!
Marc
Technical Discussion » clothstitchconstraint woes
- malbrecht
- 806 posts
- Offline
Moin,
“Atom” has recently published a (documenting his work in progress) video on this topic, I think that might be helpful:
Marc
“Atom” has recently published a (documenting his work in progress) video on this topic, I think that might be helpful:
Marc
Technical Discussion » Volume Masterclass
- malbrecht
- 806 posts
- Offline
A volume (at least a 3d volume) is just a set of data (1 component or more) indexed or indexable by three indices. That's all there is to a “volume”.
Any multi-dimensional array (list) will do as a volume. Obviously by “volume” you could also mean the content of a body
It's what you *DO* with a volume that can get complex, look good or eat up all your memory.
You can use “volumes” to give distances to surfaces (distance fields or signed distance fields), you can store arbitrary data (1 component like for density or fuel, more components for velocities and so on).
Still, the “volume” is just a set of data and means to access it.
Volumes are context-dependent, else they are just building blocks for anything …
Marc
Any multi-dimensional array (list) will do as a volume. Obviously by “volume” you could also mean the content of a body
It's what you *DO* with a volume that can get complex, look good or eat up all your memory.
You can use “volumes” to give distances to surfaces (distance fields or signed distance fields), you can store arbitrary data (1 component like for density or fuel, more components for velocities and so on).
Still, the “volume” is just a set of data and means to access it.
Volumes are context-dependent, else they are just building blocks for anything …
Marc
Technical Discussion » How to load in UDIM texture displacement in Houdini?
- malbrecht
- 806 posts
- Offline
Moin,
as I just responded to your PM, I'm going to do a video on this topic ASAP.
In general you will probably need to adjust your UDIM pipeline to match Houdini's naming convention (please read the documentation linked above, it is quite clear that you cannot use U values for the UDIM offset greater than 8 for example, if the docs are correct).
Flipping U and V readout is possible as your screenshot shows, but that does not affect the texture file naming (as far as I know), because the flipping is done on READOUT, not on filename creation (for example: Reading coordinate 0.1/0.2, when flipped, turns into 0.9/0.8 but NOT into 9.1 or 9.9 or what, since the “value” left of the digit isn't applied to the UV map but to the texture file map, i.e. the naming convention).
As for the naming of the files, you may have missed the logic of “printf” used there. In computer languages, the term “%d” stands for an integer value that gets filled in by the program, not the user (yes, I know, there is sreadf, but let's not get into semantics).
So using “%(UDIM)d” is a slightly convoluted way of saying “give me an integer value made from the UDIM name”. This term (%(UDIM)d) simply *reads* *out* the UV coordinates from your geometry UV attributes and “extracts” the part left of the digit (since that is what a cast to integer does: Cut off everything right to the digit including the digit itself).
A value of 4711.0815 turns into 4711.
A value of 91.123 turns into 91.
If you are having a U value of 5.1 and a V value of 6.4, your %(UDIM)d will yield 1066. Your texture file name for the UV coordinate 5.1/6.4 therefor has to be “whatever_1066_whatever.whatsnot”
Note tha a U value of 9.x and a V value of 0.y will turn into the same texture filename (UDIM) as a U value of 0.a and a V value of 10.b
I hope any of this is of any help …
Marc
as I just responded to your PM, I'm going to do a video on this topic ASAP.
In general you will probably need to adjust your UDIM pipeline to match Houdini's naming convention (please read the documentation linked above, it is quite clear that you cannot use U values for the UDIM offset greater than 8 for example, if the docs are correct).
Flipping U and V readout is possible as your screenshot shows, but that does not affect the texture file naming (as far as I know), because the flipping is done on READOUT, not on filename creation (for example: Reading coordinate 0.1/0.2, when flipped, turns into 0.9/0.8 but NOT into 9.1 or 9.9 or what, since the “value” left of the digit isn't applied to the UV map but to the texture file map, i.e. the naming convention).
As for the naming of the files, you may have missed the logic of “printf” used there. In computer languages, the term “%d” stands for an integer value that gets filled in by the program, not the user (yes, I know, there is sreadf, but let's not get into semantics).
So using “%(UDIM)d” is a slightly convoluted way of saying “give me an integer value made from the UDIM name”. This term (%(UDIM)d) simply *reads* *out* the UV coordinates from your geometry UV attributes and “extracts” the part left of the digit (since that is what a cast to integer does: Cut off everything right to the digit including the digit itself).
A value of 4711.0815 turns into 4711.
A value of 91.123 turns into 91.
If you are having a U value of 5.1 and a V value of 6.4, your %(UDIM)d will yield 1066. Your texture file name for the UV coordinate 5.1/6.4 therefor has to be “whatever_1066_whatever.whatsnot”
Note tha a U value of 9.x and a V value of 0.y will turn into the same texture filename (UDIM) as a U value of 0.a and a V value of 10.b
I hope any of this is of any help …
Marc
Technical Discussion » Bones won't lay in straight line
- malbrecht
- 806 posts
- Offline
Moin, “m”(?),
make sure that your “placement” option (top right of 3d viewport when in bones-tool mode) isn't set to “view based”, because - contrary to what the phrasing suggests - that means that bones try to get into the “center” of the geometry you are placing them on. You want “freehand” if you want to have them stick to the plane you are facing.
Marc
make sure that your “placement” option (top right of 3d viewport when in bones-tool mode) isn't set to “view based”, because - contrary to what the phrasing suggests - that means that bones try to get into the “center” of the geometry you are placing them on. You want “freehand” if you want to have them stick to the plane you are facing.
Marc
Technical Discussion » Rigid Body object colliding with FEM object..
- malbrecht
- 806 posts
- Offline
Houdini Indie and Apprentice » Orienting Geometry to Look Along a Curve
- malbrecht
- 806 posts
- Offline
Gleep?
I mean, people, come on - it's getting frustrating to invest time into at least *trying* to answer if you keep talking into voids. At least have the decency to tell me to shut up!
Marc
I mean, people, come on - it's getting frustrating to invest time into at least *trying* to answer if you keep talking into voids. At least have the decency to tell me to shut up!
Marc
Houdini Indie and Apprentice » Orienting Geometry to Look Along a Curve
- malbrecht
- 806 posts
- Offline
Moin,
like Konstantin states, the video is unavailable - maybe you set it to private?
In general, one “standard” way of having geometry “look ahead” on a curve is to have a second locator/null/handle move along the same curve as the geometry, but slightly ahead (if you are using a percentage value for the current position of your geometry based on the timeline, you can grab that value and just add some arbitrary small value on top).
That way you have a goal for a “look at” constraint for your geometry.
One problem with this approach is, of course, that narrow turns can create problems, if the look-at-target is coming back at the geometry, passing it by too fast. But that's a) a layout question for the curve, b) a question for fine-tuning the offset between the two components on the curve and c) shot-dependent
I hope this helps. Let me know if I should make a video …
Marc
like Konstantin states, the video is unavailable - maybe you set it to private?
In general, one “standard” way of having geometry “look ahead” on a curve is to have a second locator/null/handle move along the same curve as the geometry, but slightly ahead (if you are using a percentage value for the current position of your geometry based on the timeline, you can grab that value and just add some arbitrary small value on top).
That way you have a goal for a “look at” constraint for your geometry.
One problem with this approach is, of course, that narrow turns can create problems, if the look-at-target is coming back at the geometry, passing it by too fast. But that's a) a layout question for the curve, b) a question for fine-tuning the offset between the two components on the curve and c) shot-dependent
I hope this helps. Let me know if I should make a video …
Marc
Houdini Learning Materials » What are the seed, global seed and get attribute?!
- malbrecht
- 806 posts
- Offline
Moin, peach,
your question is a bit out of context - it's like asking “I'd like to know the meaning of pressure, temperature and espresso, please”.
Just taking the terms you mentioned, I can suggest a) to read the documentation, b) watch some introductory tutorials and c) experiment. And d) these:
seed/global seed: A “seed” usually is used as a starting point to generate virtual random numbers. On modern computers there is no such thing as a “random number”, instead most programs use (large) internal look up tables with pre-created “random numbers” from which they then take a sequence of numbers to provide you, your program or whatever with “what looks and feels like random”. Unfortunately you will get the same sequence of numbers every single time you start the program with the same starting parameters, so “seed” defines *where* inside the huge lookup table this sequence should start.
So in animation, simulation etc, basically everything that is time- or frame-dependent, you will most likely use the frame number as a “seed”, aka “starting point” for randomization. Yet, that will still give you exactly the same sequence everytime you start the simulation (which might be exactly what you want to get, but maybe not so). If you can get hold of your system's time, adding that into the mix will obviously enhance your random-experience.
Anyway, “seed” is the starting point for a random-number sequence.
“get attribute”: Houdini uses “attributes” on “things” (points, primitives), which basically are VARIABLES with their respective VALUES. An example would be the color of a point on some geometry, which would be the point's “Cd” attribute, which would usually hold a 3 component vector (for r, g and b color values).
Since you have to read out the current state (value) of variables (attributes) in any semi-complex setup (“has that particle hit the ground yet?” would be an attribute of a particle-point), you need to be able to “get attribute”. That's what “get attribute” is about: It reads out the value of an attribute either of geometry on disk (cached) or in the current graph (a node's).
I hope any of this was helpful. Have fun learning Houdini!
Marc
your question is a bit out of context - it's like asking “I'd like to know the meaning of pressure, temperature and espresso, please”.
Just taking the terms you mentioned, I can suggest a) to read the documentation, b) watch some introductory tutorials and c) experiment. And d) these:
seed/global seed: A “seed” usually is used as a starting point to generate virtual random numbers. On modern computers there is no such thing as a “random number”, instead most programs use (large) internal look up tables with pre-created “random numbers” from which they then take a sequence of numbers to provide you, your program or whatever with “what looks and feels like random”. Unfortunately you will get the same sequence of numbers every single time you start the program with the same starting parameters, so “seed” defines *where* inside the huge lookup table this sequence should start.
So in animation, simulation etc, basically everything that is time- or frame-dependent, you will most likely use the frame number as a “seed”, aka “starting point” for randomization. Yet, that will still give you exactly the same sequence everytime you start the simulation (which might be exactly what you want to get, but maybe not so). If you can get hold of your system's time, adding that into the mix will obviously enhance your random-experience.
Anyway, “seed” is the starting point for a random-number sequence.
“get attribute”: Houdini uses “attributes” on “things” (points, primitives), which basically are VARIABLES with their respective VALUES. An example would be the color of a point on some geometry, which would be the point's “Cd” attribute, which would usually hold a 3 component vector (for r, g and b color values).
Since you have to read out the current state (value) of variables (attributes) in any semi-complex setup (“has that particle hit the ground yet?” would be an attribute of a particle-point), you need to be able to “get attribute”. That's what “get attribute” is about: It reads out the value of an attribute either of geometry on disk (cached) or in the current graph (a node's).
I hope any of this was helpful. Have fun learning Houdini!
Marc
Technical Discussion » Rigid Body object colliding with FEM object..
- malbrecht
- 806 posts
- Offline
Moin, no,
could you give more details about what exactly you mean by “collision”?
Houdini's documentation states that solid objects using FEM as their solver system can be affected by other dynamic simulation objects (like RBDs driven by bullet), but if they are expected to also effect other objects (being repelled and repell) the other objects need to be FEM driven, too. Or, in short, the documentation says that “off the shelf” you don't get FEM-to-RBD collision, only the other way around.
So, what “kind” of collision do you expect (energy transfer in both directions? If so, according to Houdini's documentation both objects need to be FEM solved).
Also make sure that, if you are using geometry based collision detection, Houdini usually only considers collisions on the “outside” of polygons, i.e. where the normals are pointing towards (point order of geometry is of essence here).
Marc
could you give more details about what exactly you mean by “collision”?
Houdini's documentation states that solid objects using FEM as their solver system can be affected by other dynamic simulation objects (like RBDs driven by bullet), but if they are expected to also effect other objects (being repelled and repell) the other objects need to be FEM driven, too. Or, in short, the documentation says that “off the shelf” you don't get FEM-to-RBD collision, only the other way around.
So, what “kind” of collision do you expect (energy transfer in both directions? If so, according to Houdini's documentation both objects need to be FEM solved).
Also make sure that, if you are using geometry based collision detection, Houdini usually only considers collisions on the “outside” of polygons, i.e. where the normals are pointing towards (point order of geometry is of essence here).
Marc
Houdini Lounge » Character animation
- malbrecht
- 806 posts
- Offline
Sigh - I was sure to have said what I wanted to say, but …
> … a few hundreds of hours wasted into nothing …
You know, *sometimes* the problem sits in front of the screen, not on the harddrive. Just saying.
And with that (because this attitude of “wasting time” and “NOBODY has unlimited time” really gets me everytime) I'm out.
Marc
> … a few hundreds of hours wasted into nothing …
You know, *sometimes* the problem sits in front of the screen, not on the harddrive. Just saying.
And with that (because this attitude of “wasting time” and “NOBODY has unlimited time” really gets me everytime) I'm out.
Marc
Houdini Lounge » Character animation
- malbrecht
- 806 posts
- Offline
I know two kinds of animators working in Maya: Those who came from a different tool and feel the joy and power of something – original quote – that “just works, is fast, reliable and gives me everything I need” (those often moan about the user interface being weird and counterintuitive). And those who have been working in Maya for a long time and feel the pain and frustration of something – original quote – that “is outdate despite the coating on virtual performance in the viewport, but when you really want to push it, you have to rewrite almost all of it anyway. Which is what Maya is about: A reason to rewrite it from scratch.” Those are the ones who don't use standard Maya but some heavily customized versions to bypass the problems the “standard user” often doesn't even realize.
Interestingly I know two kinds of animators working in Houdini, too: Those who constantly want to compare it to Blender, claiming “but the next version of Blender will even be better than better and why doesn't Houdini have this or that, but I want to learn Houdini because I want to get PAID for my work”. And those who come from a different tool (like, just as an example, modo), claiming “yeah, well, it does need some better deformation performance in the viewport for sure, but if you throw in a cache node or two at the right place, you can actually work quite nicely – now please give us a user interface that does not resemble a SGI from the early 1990, will you?”
My personal impression is: It actually *IS* the availability of “developer tools” in Houdini that make its rigging and animation department so interesting and promising. It isn't “up to date” for sure, its user experience leaves a lot to be desired (and I did file RFEs on those topics).
But I am also realizing that Houdini has experienced a fundamental paradigm shift over the last two releases, and its community is trying to cope with that: You still get the famous “we know better than new users what is RIGHT and by definition the Houdini way is right” from time to time, but it is more of a anachronism now. Houdini development is, now, looking over the rim of their teacups, seeing that their tool isn't the exclusive, only one in a pipeline and that they may have to cater for riggers, animators and artists who need some “consistency in user interfacing”.
In my eyes we are seeing the second generation of Houdini for animation now (15 being the first with some more modern approaches) and I consider it promising, in some areas even powerful. I do believe that feedback (RFEs and discussions) will help development a lot – because, different to some other tool one gets the impression that Houdini development is very much interested in making its tool WORK for the user, not just for marketing.
Marc
Interestingly I know two kinds of animators working in Houdini, too: Those who constantly want to compare it to Blender, claiming “but the next version of Blender will even be better than better and why doesn't Houdini have this or that, but I want to learn Houdini because I want to get PAID for my work”. And those who come from a different tool (like, just as an example, modo), claiming “yeah, well, it does need some better deformation performance in the viewport for sure, but if you throw in a cache node or two at the right place, you can actually work quite nicely – now please give us a user interface that does not resemble a SGI from the early 1990, will you?”
My personal impression is: It actually *IS* the availability of “developer tools” in Houdini that make its rigging and animation department so interesting and promising. It isn't “up to date” for sure, its user experience leaves a lot to be desired (and I did file RFEs on those topics).
But I am also realizing that Houdini has experienced a fundamental paradigm shift over the last two releases, and its community is trying to cope with that: You still get the famous “we know better than new users what is RIGHT and by definition the Houdini way is right” from time to time, but it is more of a anachronism now. Houdini development is, now, looking over the rim of their teacups, seeing that their tool isn't the exclusive, only one in a pipeline and that they may have to cater for riggers, animators and artists who need some “consistency in user interfacing”.
In my eyes we are seeing the second generation of Houdini for animation now (15 being the first with some more modern approaches) and I consider it promising, in some areas even powerful. I do believe that feedback (RFEs and discussions) will help development a lot – because, different to some other tool one gets the impression that Houdini development is very much interested in making its tool WORK for the user, not just for marketing.
Marc
Edited by malbrecht - Sept. 11, 2017 03:19:15
Houdini Learning Materials » What is the workflow of Houdini artist?
- malbrecht
- 806 posts
- Offline
Hmm … if you watched the series, you know a good part of the answer, technically.
You know, in life - when you try something out for the very first time, in order to understand how it works and how it works *for* *you* - you don't always go the easy way. You will take paths that look familiar enough that you feel confident that you can cope with surprises behind the next bush, tree or red exclamation mark in the network view.
But the further each path takes you, the more unknown, and often fascinating terretory you discover. Taking the “slow road”, the pathes you think you know, will help you grow understanding for the wonders of a world you haven't visited yet. Seeing one “new” plant at a time allows you to appreciate its color, smell, maybe taste - if you were shocked by all of them at once, all you'd see is a mix of crazy something, undisctinctable stink and you'd probably die from eating it all.
I took the hard road first, which you already know if you watched the videos (I tried solving it all through a python node). Now, that I have done some python in Houdini and have a better understanding of its evaluation logic, I would actually *do* a bit of it in Python, creating a good part of the rig from a HDA, instancing instead of copy&pasting, referencing, using CHOPs, allowing for arbitrary control elements. Make it all more complex, more flexible, more wonderous.
You need to learn to put butter on toast before you can make proper couscous.
There probably is no “correct” way to do (almost) anything in Houdini. Houdini is a tool that you can use to solve problems (or to create art). You learn something new and helpful (almost) every day. That doesn't mean that the way you did it yesterday was wrong or inferior. Some people do (almost) everything in CHOPs. Others refuse to use Python (I'd like to know and hang out with those). Some people throw in a volume even if they just want to split a quad into two triangles, others only use Houdini to create obj files that they then render in Blender.
Tell me: Who is “wrong”? Who is “better”? Who is the “experience Houdini user”, based on how he does things in Houdini?
There has been a nice report about an old man who uses Microsoft's graphic editor to create beautiful (computer) paintings. Is he a not-as-good artist compared to someone “breathing” Photoshop?
Whatever road takes you to your destination and you feel comfortable with: Take it. Sometimes doing things the “wrong way” teaches you more interesting new stuff than you expected. Do things the wrong way every once in a while.
Marc
You know, in life - when you try something out for the very first time, in order to understand how it works and how it works *for* *you* - you don't always go the easy way. You will take paths that look familiar enough that you feel confident that you can cope with surprises behind the next bush, tree or red exclamation mark in the network view.
But the further each path takes you, the more unknown, and often fascinating terretory you discover. Taking the “slow road”, the pathes you think you know, will help you grow understanding for the wonders of a world you haven't visited yet. Seeing one “new” plant at a time allows you to appreciate its color, smell, maybe taste - if you were shocked by all of them at once, all you'd see is a mix of crazy something, undisctinctable stink and you'd probably die from eating it all.
I took the hard road first, which you already know if you watched the videos (I tried solving it all through a python node). Now, that I have done some python in Houdini and have a better understanding of its evaluation logic, I would actually *do* a bit of it in Python, creating a good part of the rig from a HDA, instancing instead of copy&pasting, referencing, using CHOPs, allowing for arbitrary control elements. Make it all more complex, more flexible, more wonderous.
You need to learn to put butter on toast before you can make proper couscous.
There probably is no “correct” way to do (almost) anything in Houdini. Houdini is a tool that you can use to solve problems (or to create art). You learn something new and helpful (almost) every day. That doesn't mean that the way you did it yesterday was wrong or inferior. Some people do (almost) everything in CHOPs. Others refuse to use Python (I'd like to know and hang out with those). Some people throw in a volume even if they just want to split a quad into two triangles, others only use Houdini to create obj files that they then render in Blender.
Tell me: Who is “wrong”? Who is “better”? Who is the “experience Houdini user”, based on how he does things in Houdini?
There has been a nice report about an old man who uses Microsoft's graphic editor to create beautiful (computer) paintings. Is he a not-as-good artist compared to someone “breathing” Photoshop?
Whatever road takes you to your destination and you feel comfortable with: Take it. Sometimes doing things the “wrong way” teaches you more interesting new stuff than you expected. Do things the wrong way every once in a while.
Marc
Houdini Learning Materials » What is the workflow of Houdini artist?
- malbrecht
- 806 posts
- Offline
Moin,
> you need to forget everything you know about other softwares in order to understand Houdini
… sorry to be so blunt, but that sounds ridiculus. Why should you forget everything you learned about MS Word when you want to understand Houdini?
Oh, you meant other 3d software? Sorry to be so blunt, but that sounds even more ridiculus. Why should you forget everything you learned about normal vectors when you want to understand Houdini?
I don't know how an artist thinks or works. But I love to get a job done - and forgetting things I know isn't on the agenda, ever, if I want to get a job done.
(It is different when I want to hit a target with a self made arrow on one of my self made archer's bows. THEN I want to forget about EVERYTHING and just “be the arrow”. But that moment passes, as soon as the arrow hits the target (hopefully). I would not want to transfer that feeling to working on a computer. Definitely not. Neither the hitting the screen with an arrow nor the forgetting about anything.)
If you look at my videos on Vimeo, you can see how I approached my first small project in Houdini without really having used Houdini much before (I used it for a couple of hours, maybe days, counted all in). If I hadn't known anything about 3d software in general, I probably wouldn't have gotten the project done (I am speaking of the “spider leg rig” project I documented: https://vimeo.com/210490392 [vimeo.com] and the two following videos). Obviously today I would do some things differently, because you learn something new every day - often enough you learn something new in another (3d) software and just apply that newly learned stuff to your work in Houdini.
Everything works together. Houdini is not a singularity.
Marc
> you need to forget everything you know about other softwares in order to understand Houdini
… sorry to be so blunt, but that sounds ridiculus. Why should you forget everything you learned about MS Word when you want to understand Houdini?
Oh, you meant other 3d software? Sorry to be so blunt, but that sounds even more ridiculus. Why should you forget everything you learned about normal vectors when you want to understand Houdini?
I don't know how an artist thinks or works. But I love to get a job done - and forgetting things I know isn't on the agenda, ever, if I want to get a job done.
(It is different when I want to hit a target with a self made arrow on one of my self made archer's bows. THEN I want to forget about EVERYTHING and just “be the arrow”. But that moment passes, as soon as the arrow hits the target (hopefully). I would not want to transfer that feeling to working on a computer. Definitely not. Neither the hitting the screen with an arrow nor the forgetting about anything.)
If you look at my videos on Vimeo, you can see how I approached my first small project in Houdini without really having used Houdini much before (I used it for a couple of hours, maybe days, counted all in). If I hadn't known anything about 3d software in general, I probably wouldn't have gotten the project done (I am speaking of the “spider leg rig” project I documented: https://vimeo.com/210490392 [vimeo.com] and the two following videos). Obviously today I would do some things differently, because you learn something new every day - often enough you learn something new in another (3d) software and just apply that newly learned stuff to your work in Houdini.
Everything works together. Houdini is not a singularity.
Marc
Houdini Indie and Apprentice » Cloth doutb
- malbrecht
- 806 posts
- Offline
Moin,
the target object can be found in the deformation tab just about where it was in the geometry tab (see attached screenshot).
Marc
the target object can be found in the deformation tab just about where it was in the geometry tab (see attached screenshot).
Marc
Houdini Learning Materials » FEM mixamo animation
- malbrecht
- 806 posts
- Offline
Moin,
I assume you solved your problems by now - but just to complete and follow up on my promsie to publish a walkthrough on how I do cloth sim for the Trollbridge project, here's the video:
Maybe it is helpful (although it is pretty much straight forward anyway)?
Marc
I assume you solved your problems by now - but just to complete and follow up on my promsie to publish a walkthrough on how I do cloth sim for the Trollbridge project, here's the video:
Maybe it is helpful (although it is pretty much straight forward anyway)?
Marc
Houdini Indie and Apprentice » Houdini's Modeling Capabilities?
- malbrecht
- 806 posts
- Offline
Moin,
I think the answer to your question is a question:
How good are you when it comes to modelling semi-realistic characters?
I have seen some very, very realistic characters being modelled in Houdini by professionals and I have seen my own modelling work, which is just as akward in Houdini as it is in any creative tool.
In a pipeline you will still want to have something like zBrush available to do “freehand sculpting”. Some people prefer a subD modelling tool like Rocket3d or modo or whatever works for you, others are perfectly fine with Blender or, well, Houdini.
It comes down to what *you* can do. Most of the *tools* are there in Houdini. Whether or not they work for your specific needs depends on how “adoptable” you are.
Marc
I think the answer to your question is a question:
How good are you when it comes to modelling semi-realistic characters?
I have seen some very, very realistic characters being modelled in Houdini by professionals and I have seen my own modelling work, which is just as akward in Houdini as it is in any creative tool.
In a pipeline you will still want to have something like zBrush available to do “freehand sculpting”. Some people prefer a subD modelling tool like Rocket3d or modo or whatever works for you, others are perfectly fine with Blender or, well, Houdini.
It comes down to what *you* can do. Most of the *tools* are there in Houdini. Whether or not they work for your specific needs depends on how “adoptable” you are.
Marc
Houdini Learning Materials » FEM mixamo animation
- malbrecht
- 806 posts
- Offline
Moin,
OK, as far as I understand you don't want to add a “solid” object but some kind of “soft body” object to your animated object. In general the “easiest” approach here would be to anchor points on the simulated body to points of the animated body. This is usually known as the “attach flag to pole” job (in the video below I am mainly addressing the “wind” thing, but attaching the flag to the pole is covered, too).
Another approach would be to combine point positions from animation and simulation to recreate what bullet calls “follow pose” (I think Houdini has a feature for that in FEM, too, I can look it up if you cannot find it). The advantage of this is that you could even simulate PARTS of an otherwise fully animated body simply by applying a weight map that defines which points should follow the simulation - and how strongly so.
If you only want some jiggle effect, it might be easier to use a jiggle deform on the points in question - faster for sure, since FEM isn't exactly mind blowing quick
Marc
OK, as far as I understand you don't want to add a “solid” object but some kind of “soft body” object to your animated object. In general the “easiest” approach here would be to anchor points on the simulated body to points of the animated body. This is usually known as the “attach flag to pole” job (in the video below I am mainly addressing the “wind” thing, but attaching the flag to the pole is covered, too).
Another approach would be to combine point positions from animation and simulation to recreate what bullet calls “follow pose” (I think Houdini has a feature for that in FEM, too, I can look it up if you cannot find it). The advantage of this is that you could even simulate PARTS of an otherwise fully animated body simply by applying a weight map that defines which points should follow the simulation - and how strongly so.
If you only want some jiggle effect, it might be easier to use a jiggle deform on the points in question - faster for sure, since FEM isn't exactly mind blowing quick
Marc
-
- Quick Links