Moin,
you can use a target geometry (which might be the original one you are starting with, doing a pre-roll simulation to deflate it first) and either increase the target strength over time (which may look unnatural - or in other terms “exactly like the director wants it to look”). Or you can increase the bending resistance over time to get a more believable behavior (simulating increasing pressure inside the object).
Marc
(Cloth course for different solver types in the works)
Found 590 posts.
Search results Show results as topic list.
Technical Discussion » Blow up/growing FEM
- malbrecht
- 806 posts
- Offline
Technical Discussion » A way to create static FEM?
- malbrecht
- 806 posts
- Offline
What do you mean by “static”? If it *reacts* to other objects, it's not static, by definition.
Marc
Marc
Technical Discussion » Self intersecting FEM - how to avoid it ?
- malbrecht
- 806 posts
- Offline
Hi,
I am on my way to a client (for a week) and won't have access to Houdini (unfortunately none of my clients are using H) - could you, please, help me with some detail? I didn't do anything “specific”, just uses a high enough number of control points to not create bumps (the spheres are only “visual helpers”, in H16 you can just switch off their geometry object node altogether - or, if you are having problems with the sprites, just bypass the sprite node).
I hope this helps!
Marc
I am on my way to a client (for a week) and won't have access to Houdini (unfortunately none of my clients are using H) - could you, please, help me with some detail? I didn't do anything “specific”, just uses a high enough number of control points to not create bumps (the spheres are only “visual helpers”, in H16 you can just switch off their geometry object node altogether - or, if you are having problems with the sprites, just bypass the sprite node).
I hope this helps!
Marc
Technical Discussion » Self intersecting FEM - how to avoid it ?
- malbrecht
- 806 posts
- Offline
Sorry, I don't have or use 16.5 - you might actually want to file a test scene to support. Even if you made a boo-boo in setting things up, such errors should be caught.
Marc
Marc
Technical Discussion » Self intersecting FEM - how to avoid it ?
- malbrecht
- 806 posts
- Offline
Moin,
I assume you created your scene file in 16.5 - it threw some errors for me (I don't have 16.5). But anyway, if you want to use FEM for this, the most likely problem is that your geometry isn't divided into small enough tets. When you embed the tets geometry (“solidembed” node), the default values are good for starting off, but you often have to change the min/max scale values to match the simulation requirements. Try basing your tets on 1 and then set max to 1.2 and min to 0.2 or something like that - might already solve the problem. You can also try to enlarge the collision geo, but given the slow solving of FEM simulations, my personal preference is to work with original sizes as far as possible.
Also, collisions often appear due to motion that is just too fast, so you may have to increase your substeps to catch all penetrations (but with your image given above I assume you have to tweak the tets size first).
If you do not want to use FEM for this specific simulation (for performance reason) I am sure you could get good results from Houdini's cloth solver (which, as I understand, isn't exactly a FEM solver internally) OR even a PBD (position based dynamics) solver like “grains”.
Marc
P.S. / Edit - attached is a frame from a quick “grain” (particle based in this case) solver setup. No intersections. But (as to be expected with a particle based solution) quite hard to control in terms of “haptics”. Dramatically faster than FEM, but still a lot slower than specialized solutions (like syFlex etc).
I assume you created your scene file in 16.5 - it threw some errors for me (I don't have 16.5). But anyway, if you want to use FEM for this, the most likely problem is that your geometry isn't divided into small enough tets. When you embed the tets geometry (“solidembed” node), the default values are good for starting off, but you often have to change the min/max scale values to match the simulation requirements. Try basing your tets on 1 and then set max to 1.2 and min to 0.2 or something like that - might already solve the problem. You can also try to enlarge the collision geo, but given the slow solving of FEM simulations, my personal preference is to work with original sizes as far as possible.
Also, collisions often appear due to motion that is just too fast, so you may have to increase your substeps to catch all penetrations (but with your image given above I assume you have to tweak the tets size first).
If you do not want to use FEM for this specific simulation (for performance reason) I am sure you could get good results from Houdini's cloth solver (which, as I understand, isn't exactly a FEM solver internally) OR even a PBD (position based dynamics) solver like “grains”.
Marc
P.S. / Edit - attached is a frame from a quick “grain” (particle based in this case) solver setup. No intersections. But (as to be expected with a particle based solution) quite hard to control in terms of “haptics”. Dramatically faster than FEM, but still a lot slower than specialized solutions (like syFlex etc).
Edited by malbrecht - Nov. 24, 2017 09:09:09
Work in Progress » Gorilla Fur and Cloth Simulation
- malbrecht
- 806 posts
- Offline
> I Kinda cheated it a bit, I was running very short on time for my submission so I made the collision between the gorilla and his clothes in Ncloth a bit wider and then when I imported into Houdini, I use a guide length node and bend node in hair groom to control the hairs so they would not stick out of the clothes.
… which is a nice way of saying: I did it like a professional does and only delivered those visuals that were required, not stuff that nobody would ever see on screen anyway :-)
Well done!
Marc
… which is a nice way of saying: I did it like a professional does and only delivered those visuals that were required, not stuff that nobody would ever see on screen anyway :-)
Well done!
Marc
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
contacting you directly - the “higher ups” right now aren't too keen on getting the final bits published before release.
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
before this gets out of hand:
I am in no way saying that Houdini's cloth is better, faster or more fluffy than anything else. I merely refuse to accept “it's unusable” (for cloth sims).
What I am trying to do with the tut is help people get started and, hopefully, get some problems solved. I am the first, third and last to keep repeating: USE THE TOOL THAT GETS THE JOB DONE. Don't be religious about tools, except maybe with religious tools.
If you don't have access to … xyz, but Houdini is a choice, you can use Houdini to do (good) cloth simulations. That's all I want to help people with. Not replace specialized solutions.
Plus I want to be fair. A general purpose tool - like Houdini - most likely will be inferior to specialized tools. The question is: DO you have the resources to go specialized? If yes, do so. If no, that's where I think cooperation, R&D and creating tutorials that help others comes in handy.
Marc
I am in no way saying that Houdini's cloth is better, faster or more fluffy than anything else. I merely refuse to accept “it's unusable” (for cloth sims).
What I am trying to do with the tut is help people get started and, hopefully, get some problems solved. I am the first, third and last to keep repeating: USE THE TOOL THAT GETS THE JOB DONE. Don't be religious about tools, except maybe with religious tools.
If you don't have access to … xyz, but Houdini is a choice, you can use Houdini to do (good) cloth simulations. That's all I want to help people with. Not replace specialized solutions.
Plus I want to be fair. A general purpose tool - like Houdini - most likely will be inferior to specialized tools. The question is: DO you have the resources to go specialized? If yes, do so. If no, that's where I think cooperation, R&D and creating tutorials that help others comes in handy.
Marc
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
You know, it seems - in recent years - that forums are being used to tell people what is NOT possible in a software. I don't know what you would call “good cloth simulation” (the problem being that a lot of cloth simulation I see in movies is, in my eyes, just plain bad - because it's “artistically directed”, not “physically plausible”), so I cannot really help you with examples.
However, I can tell you that the last Mica cloth sim I did on Trollbridge was using Houdini 16.0. It took me 24 minutes to do the complete shot including all import, export etc. - a shot that I had “simmed” two years ago using modo. In modo this shot took me, all in all, about 50 hours. And the TD was happy with the result. That is: in both cases.
It would have taken me roughly about 3 minutes to do it in syFlex, I know. But unfortunately I only have syFlex for modo, not for Houdini - and using modo would have pumped those 3 minutes up to 2 hours including all the crashes.
My “job”, when I work for companies, studios and whatsnots, usually is to solve problems, not to be the problem. Telling people what is not possible creates problems because it breaks creativity and stops people from THINKING.
Telling people what could be better and where exactly the problems are (omitting phrases like “good-looking” because that, obviously, is highly subjective) would be productive and might lead to improvements.
Marc
P.S. sorry for answering, I promised to shut up :-D
However, I can tell you that the last Mica cloth sim I did on Trollbridge was using Houdini 16.0. It took me 24 minutes to do the complete shot including all import, export etc. - a shot that I had “simmed” two years ago using modo. In modo this shot took me, all in all, about 50 hours. And the TD was happy with the result. That is: in both cases.
It would have taken me roughly about 3 minutes to do it in syFlex, I know. But unfortunately I only have syFlex for modo, not for Houdini - and using modo would have pumped those 3 minutes up to 2 hours including all the crashes.
My “job”, when I work for companies, studios and whatsnots, usually is to solve problems, not to be the problem. Telling people what is not possible creates problems because it breaks creativity and stops people from THINKING.
Telling people what could be better and where exactly the problems are (omitting phrases like “good-looking” because that, obviously, is highly subjective) would be productive and might lead to improvements.
Marc
P.S. sorry for answering, I promised to shut up :-D
Edited by malbrecht - Nov. 15, 2017 10:07:20
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
> Houdini's cloth is not a viable option for not only cloth in production, but any cloth whatsoever
wow. What a statement. I guess what I have done for the last production I worked on was all in my dreams.
With that I am out of this “discussion” - I don't have time for destructive dissing.
Marc
wow. What a statement. I guess what I have done for the last production I worked on was all in my dreams.
With that I am out of this “discussion” - I don't have time for destructive dissing.
Marc
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
Hi, Rich,
one thing to keep in mind when doing cloth simulations is that it often works quite well to get the LOOKS done first and the DETAIL later - meaning: If you can “orchestrate” the simulation WITHOUT collision first, to get the overall “feeling” of the fabric, it makes sense to get everything set up without collisions first and then only use collision detection on the final sim.
Also, check collision types. If your sail does not need to cause impact to whatever it collides with, the non-affected objects don't need to be FEM objects. Using a mix of FEM (for the cloth) and RBD can be significantly faster. It's possible that a grains solver is better suited for your specific setup, too.
And yes … syFlex is blazingly fast, I love it. Getting “realistic” results out of it can be challenging - but who cares if you can basically do everything in realtime :-D
Marc
one thing to keep in mind when doing cloth simulations is that it often works quite well to get the LOOKS done first and the DETAIL later - meaning: If you can “orchestrate” the simulation WITHOUT collision first, to get the overall “feeling” of the fabric, it makes sense to get everything set up without collisions first and then only use collision detection on the final sim.
Also, check collision types. If your sail does not need to cause impact to whatever it collides with, the non-affected objects don't need to be FEM objects. Using a mix of FEM (for the cloth) and RBD can be significantly faster. It's possible that a grains solver is better suited for your specific setup, too.
And yes … syFlex is blazingly fast, I love it. Getting “realistic” results out of it can be challenging - but who cares if you can basically do everything in realtime :-D
Marc
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
Hi, Rich,
it's hard to tell without having any really comparable data to tell if you hit a limitation of Houdini's two cloth solving methods (FEM and position/spring based) or haven't used all tricks available. Yes, I will try to address some optimization approaches in my cloth-course, but in general:
- the more “physically plausible” (if not to say “accurate”) you want a simulation to be, the slower it will run
- for “hero” objects a “plausible” simulation may or may not be what you want, this may be a fundamental decision. You *may* want to have a fully “artistically directable” solution (there are very, very fast “cloth solvers” out there that have almost nothing in common with real-world behavior but are considered “perfect” by art directors)
- for background objects, you might get much faster results with low-resolution simulations (small number of FEM objects or even a position based solver) and just project the result to your high-resolution geometry
- make sure to only use collision detection where you actually need it. Switch off collision detection if you only need the cloth simulation as such. Don't use self-collision detection when not needed, either.
- consider using a rig-based solution where applicable (i.e. rig your sail with bones and add a basic IK driving velocity-field to move the bones) if possible
- consider using a muscle based setup (Houdini's new muscles are quite capable of helping with cloth-look-alike stuff)
I hope any of these ideas are of help. Again: There are MUCH faster solutions out there but that isn't to say that they are *better*.
Marc
it's hard to tell without having any really comparable data to tell if you hit a limitation of Houdini's two cloth solving methods (FEM and position/spring based) or haven't used all tricks available. Yes, I will try to address some optimization approaches in my cloth-course, but in general:
- the more “physically plausible” (if not to say “accurate”) you want a simulation to be, the slower it will run
- for “hero” objects a “plausible” simulation may or may not be what you want, this may be a fundamental decision. You *may* want to have a fully “artistically directable” solution (there are very, very fast “cloth solvers” out there that have almost nothing in common with real-world behavior but are considered “perfect” by art directors)
- for background objects, you might get much faster results with low-resolution simulations (small number of FEM objects or even a position based solver) and just project the result to your high-resolution geometry
- make sure to only use collision detection where you actually need it. Switch off collision detection if you only need the cloth simulation as such. Don't use self-collision detection when not needed, either.
- consider using a rig-based solution where applicable (i.e. rig your sail with bones and add a basic IK driving velocity-field to move the bones) if possible
- consider using a muscle based setup (Houdini's new muscles are quite capable of helping with cloth-look-alike stuff)
I hope any of these ideas are of help. Again: There are MUCH faster solutions out there but that isn't to say that they are *better*.
Marc
Houdini Learning Materials » Maths & Programming in Houdini as an FX-TD
- malbrecht
- 806 posts
- Offline
Moin,
personally, I see a huge difference between “programming” and “programming in”. While the former is basically about the understanding that computer programs “work” in a specific way and that there is a fundamental (strict, simple) logic to “telling the computer what to do”, the latter is about learning languages with dialects, with phrases, even with “political correctness” (when it comes to Python, obviously).
Maths - in my world - is a fundamental thing, very much like programming. The advantage being that it does not come in “flavors” :-) Usually you should be fine with basic math like it is taught at school (OK, I admit, I am out of there for a few decades, I am not sure what they teach today), as long as you understood it and didn't just learn it for the next test.
Based on this perspective, I think that learning math and learning programming is kind of “the same thing”: You need to break down problems into chunks that you can deal with. If you have a complex mathematical term to solve, you start looking for expressions that you know how to solve. You look for rules that define what has to be done first and what comes next. Then you solve the problem step by step by step - et voila, you just wrote a program for yourself. Done.
I also think that “learning” math is easier when dealing with real-world problems, not with school book constructions. My father used to tell about schoolboys (students) at a road construction company he was working for that were sent to get “10 m of that cable” without any measuring device but the cable drum that had its diameter written on it. The cable was too stiff and way too heavy (the cable had 6cm diameter itself) to hold it against the drum to use the diameter as a ruler, so how would you know how to get 10 m? Pi would do the trick, of course. So with a problem like this and then learning the “tools” along the way you're having fun and won't forget how to get to a solution.
The beauty of “programming in Houdini” is that you can use the “industry standard” Python and a mentally sane programming language (VEX) at the same time (note, there is some slight sarcasm in this statement). VEX is similar to C, Javascript and many other languages out there (Python is not, more sarcasm!) - which is to say you are “free” to learn any of the similar languages and will feel at home in VEX pretty fast.
However, learning the language first without understanding the world it is spoken in (programming) will only allow you to write “snippets” like “how do I get 10 m out of a cable drum”, not “how do I measure the world from the back of a camel”. That is *another* point where Houdini shines: In my world, the “visual programming approach” (nodes, network view) is a *good* start into “understanding programming”. It is a *very* bad thing to solve complex problems by means of a “serviceable, well-documented program”, but it is perfect to grasp the fundamentals.
That said: Dive in, watch some tutorials on how Houdini's network view is used to “make something”. That *is* programming. Dive in deeper. Learn some Javascript, learn some Python basics, make yourself comfortable with the ideas of how computer languages - all of them - work, then learn the dialects you need. MATH comes along the way. My suggestion is: Whenever some tutorial uses some “magic” (like “take the dot product because that will …”), look that up and try to understand that specific thing. Don't just use it: Understand what it does - FOR THE CAUSE. Not theoretically, but practically for what you are doing. That way it will stick.
I hope any of this helps. I am currently writing a book on “learning how to program if that is exactly what you don't want to do”, if you like my “style”, you can read some work-in-progress chapters on my Patreon site.
Marc
personally, I see a huge difference between “programming” and “programming in”. While the former is basically about the understanding that computer programs “work” in a specific way and that there is a fundamental (strict, simple) logic to “telling the computer what to do”, the latter is about learning languages with dialects, with phrases, even with “political correctness” (when it comes to Python, obviously).
Maths - in my world - is a fundamental thing, very much like programming. The advantage being that it does not come in “flavors” :-) Usually you should be fine with basic math like it is taught at school (OK, I admit, I am out of there for a few decades, I am not sure what they teach today), as long as you understood it and didn't just learn it for the next test.
Based on this perspective, I think that learning math and learning programming is kind of “the same thing”: You need to break down problems into chunks that you can deal with. If you have a complex mathematical term to solve, you start looking for expressions that you know how to solve. You look for rules that define what has to be done first and what comes next. Then you solve the problem step by step by step - et voila, you just wrote a program for yourself. Done.
I also think that “learning” math is easier when dealing with real-world problems, not with school book constructions. My father used to tell about schoolboys (students) at a road construction company he was working for that were sent to get “10 m of that cable” without any measuring device but the cable drum that had its diameter written on it. The cable was too stiff and way too heavy (the cable had 6cm diameter itself) to hold it against the drum to use the diameter as a ruler, so how would you know how to get 10 m? Pi would do the trick, of course. So with a problem like this and then learning the “tools” along the way you're having fun and won't forget how to get to a solution.
The beauty of “programming in Houdini” is that you can use the “industry standard” Python and a mentally sane programming language (VEX) at the same time (note, there is some slight sarcasm in this statement). VEX is similar to C, Javascript and many other languages out there (Python is not, more sarcasm!) - which is to say you are “free” to learn any of the similar languages and will feel at home in VEX pretty fast.
However, learning the language first without understanding the world it is spoken in (programming) will only allow you to write “snippets” like “how do I get 10 m out of a cable drum”, not “how do I measure the world from the back of a camel”. That is *another* point where Houdini shines: In my world, the “visual programming approach” (nodes, network view) is a *good* start into “understanding programming”. It is a *very* bad thing to solve complex problems by means of a “serviceable, well-documented program”, but it is perfect to grasp the fundamentals.
That said: Dive in, watch some tutorials on how Houdini's network view is used to “make something”. That *is* programming. Dive in deeper. Learn some Javascript, learn some Python basics, make yourself comfortable with the ideas of how computer languages - all of them - work, then learn the dialects you need. MATH comes along the way. My suggestion is: Whenever some tutorial uses some “magic” (like “take the dot product because that will …”), look that up and try to understand that specific thing. Don't just use it: Understand what it does - FOR THE CAUSE. Not theoretically, but practically for what you are doing. That way it will stick.
I hope any of this helps. I am currently writing a book on “learning how to program if that is exactly what you don't want to do”, if you like my “style”, you can read some work-in-progress chapters on my Patreon site.
Marc
Technical Discussion » Houdini & Windows 10 ---> :(
- malbrecht
- 806 posts
- Offline
Going out on a limb here …
> Can this be related to my specific graphics card ?!
… my assumption would be: Yes. My own GTX970 has caused me a lot of trouble with some driver versions where other people with other (GTX970) had no issues in their setups with the same driver versions.
Marc
> Can this be related to my specific graphics card ?!
… my assumption would be: Yes. My own GTX970 has caused me a lot of trouble with some driver versions where other people with other (GTX970) had no issues in their setups with the same driver versions.
Marc
Technical Discussion » Houdini & Windows 10 ---> :(
- malbrecht
- 806 posts
- Offline
Moin,
I have been running Houdini 15, 15.5 and 16 without any issues (like the described, of course, there are issues at times) on Windows 10pro using two monitors, one with 2560x1440 (secondary screen) and one with 1920x1080 (primary screen). Using NVidia GTX 970 as the graphics card.
That would make me think that there is a system specific problem involved.
Marc
I have been running Houdini 15, 15.5 and 16 without any issues (like the described, of course, there are issues at times) on Windows 10pro using two monitors, one with 2560x1440 (secondary screen) and one with 1920x1080 (primary screen). Using NVidia GTX 970 as the graphics card.
That would make me think that there is a system specific problem involved.
Marc
Houdini Indie and Apprentice » on a model, how do I change setting to make selected faces pop out more?
- malbrecht
- 806 posts
- Offline
Moin,
open your Houdini installation directory, go into the houdini/config subfolder. There you find a few “3DSceneColors” files with endings like “dark” etc. Open the one you are currently using in a text editor and adjust colors to your likings. It's a bit fumbly but possible
Marc
open your Houdini installation directory, go into the houdini/config subfolder. There you find a few “3DSceneColors” files with endings like “dark” etc. Open the one you are currently using in a text editor and adjust colors to your likings. It's a bit fumbly but possible
Marc
Technical Discussion » VEX Precision Issues
- malbrecht
- 806 posts
- Offline
Moin,
I switched the (work in progress, to be seriously edited later on) chapter on “Floating Points” in my “Learn to program if that is the only thing you never ever wanted to do in your life” book that I am creating with my Patr(e)ons …
https://www.patreon.com/posts/15093066 [www.patreon.com]
Marc
I switched the (work in progress, to be seriously edited later on) chapter on “Floating Points” in my “Learn to program if that is the only thing you never ever wanted to do in your life” book that I am creating with my Patr(e)ons …
https://www.patreon.com/posts/15093066 [www.patreon.com]
Marc
Technical Discussion » Caching over SMB to a NAS is extremely slow.
- malbrecht
- 806 posts
- Offline
Moin,
you are not doing anything wrong, but making a false assumption. 350MB/s is a completely arbitrary measurement (i.e. “academic” or “not helpful”) in that context because what you want to do with caching is “random access”, not linear reading/writing (that value is only applying to linear access with optimized block sizes). TCP/IP, the protocol for ethernet, is not really well designed for lots of small(est) packages with constant back and forth communication.
If you want performance on caches, use the fastest possible SSD or RAM drive you can get, plug it into your PCI express port and give it all the IRQs it wants. Intel just released a cool new SSD system that boosts speed on random access by factors.
Using network drives for caching is, except for huge datasets that only get accessed in an exclusively linear fashion, never going to work well.
Marc
you are not doing anything wrong, but making a false assumption. 350MB/s is a completely arbitrary measurement (i.e. “academic” or “not helpful”) in that context because what you want to do with caching is “random access”, not linear reading/writing (that value is only applying to linear access with optimized block sizes). TCP/IP, the protocol for ethernet, is not really well designed for lots of small(est) packages with constant back and forth communication.
If you want performance on caches, use the fastest possible SSD or RAM drive you can get, plug it into your PCI express port and give it all the IRQs it wants. Intel just released a cool new SSD system that boosts speed on random access by factors.
Using network drives for caching is, except for huge datasets that only get accessed in an exclusively linear fashion, never going to work well.
Marc
Technical Discussion » Cloth on a character not working well at all
- malbrecht
- 806 posts
- Offline
Hi,
unfortunately, I don't have access (or think I don't) to H's cloth solver code, else I would just dig right in and answer your question :-)
But in general, yes, I assume that “overshoots” can cross thresholds. I have had situations in my own solvers where a simple resonance from neighboring points was sufficient to add up to volatile outward energy, though. Substeps are one side of the medal. Dampening is another one (introducing some averaging between “theoretical position change and control”). You may also have to check what other parameters you are using could introduce forces. An example for this would be bending resistance, which basically stores energy that is to be “released” when thresholds are crossed.
Maybe someone with internal knowledge of H's cloth solver can step in and answer the question of thresholds. In Bullet Physics those (hardcoded) thresholds are cause for a lot of irritation (4cm being the lower threshold for example).
Marc
unfortunately, I don't have access (or think I don't) to H's cloth solver code, else I would just dig right in and answer your question :-)
But in general, yes, I assume that “overshoots” can cross thresholds. I have had situations in my own solvers where a simple resonance from neighboring points was sufficient to add up to volatile outward energy, though. Substeps are one side of the medal. Dampening is another one (introducing some averaging between “theoretical position change and control”). You may also have to check what other parameters you are using could introduce forces. An example for this would be bending resistance, which basically stores energy that is to be “released” when thresholds are crossed.
Maybe someone with internal knowledge of H's cloth solver can step in and answer the question of thresholds. In Bullet Physics those (hardcoded) thresholds are cause for a lot of irritation (4cm being the lower threshold for example).
Marc
Technical Discussion » Cloth on a character not working well at all
- malbrecht
- 806 posts
- Offline
Hi,
> So would you recommend using a volume based approach?
actually … that depends :-)
It is important to understand the difference between actual “volume based collision detection”, which means that you are dealing with all the pros and cons of volumes (i.e. in the case of collisions you are using SDF fields, which are VERY fast to use but obviously only have limited mathematical accuracy) and “FEM based collision detection”, which means that you are “replacing” your geometry by an approximation of “atomic instances”. The latter, to my understanding, is what SideFX suggests for cloth simulations and to some extend I do agree.
H16 does not provide “volume based cloth simulations” (i.e. if you don't set that up yourself) - to my knowledge.
Advantages of FEM based simulations are obvious: You aren't limited by your actual (render) geometry's resolution (at least not for collisions, deformation, obviously you *are* limited by your render geometry when it comes to rendering), you can scale (resolution wise) quite easily, you can get as precise as you want (FEM collisions are surface collisions, because you are calculating “crossovers” of points and edges/planes). Since you are replacing geometry, FEM can be considerably slower than (original points based) point-collisions.
Volume = fast, surface = precise. Volume = not so explosive, surface = detailed.
You pick your cookie
> Am I correct in assuming that the points based approach is the same as the surface based collision detection, and that the parameters for these are set on the RBD tab in the static objects of the dopnetwork?
“Points based approach” in my world basically means that you are only calculation points (as in “geometry points”), concentrate mass on those and ignore any kind of penetration that might occur between two points forming an edge. That is fine for dense meshes and if you don't expect too much strain on the forces holding your points together.
By “points” you *could* instead mean particles. Cloth simulations using particles are a different beast, somewhere between points-based (as in “original points”) and atomic (“FEM”) based thingies … in my world, they combine the bad sides of both :-) YMMV.
“Surfaces” in Houdini's language, as far as I know, apply to what you would commonly understand as surfaces: Polygons. Houdini's technobabble likes to mess things up a bit, when used together with non-Houdini-apps … vertices versus points, primitives versus polygons versus ACTUAL primitives … argh. The way I see Houdini's “surface based collision detection” is just the math side of things: You are doing a cross-over check on every simulation step. Has one point (wherever you get that point from) crossed a plane/edge or has it not? If yes: Collision. If not: No collision. So I don't connect “surface” with what you *see* in that sense …
I also find Houdini's terminology for … well, let's call them “simulation entities”, just for the fun of introducing yet another arbitrary term - “steep to learn”: “Cloth” in Houdini is a solid body. When I tried to understand what the documentation is talking about, this threw me off in the beginning, because when I am thinking about “cloth simulation”, the only thing I do not have in mind are “solid bodies”.
Of course it makes sense, since a “cloth” is not a volume or liquid - but you *can* use a volume based collision detection for cloth, so you can use “volumes” on “solids”. That's Houdini for you :-D
Anyway, real “volume based” solvers are only available for static objects in H, if you don't create your own solution. The “cloth solver” is, AFAIK, a FEM solver that has been tweaked to deal with volume-free geometry (here “volume” means “single sided polygonal constructions that do not wrap some actual geometric volume”), but it *is* a FEM solver and it *is* a surface collision solver (when it comes to self-penetrations for example). Only if you want cloth to collide with static objects, the latter can be volumes.
The question about substeps versus frame count again depends on the implementation. In general (based on other cloth solvers I have used or written) substeps are always linear, so you are not getting any rotation values, any curved or dynamic animation/behavior AND you are not “piping back” your collision velocities the same way you do after you solved a FRAME. Because, in the end, what you store as animation data is frame based and inbound velocities (for your cloth and your collision objects) therefor are calculated on FRAMES, not subframes. That is one of several reasons for those infamous “exploding skirts”: The *actual* corrective velocity would have been much smaller, but what you get after your last subframe's calculation (perfectly adjusting the cloth's point position) based on the previous frame is … HIGH acceleration for the next frame. Giving you way too high velocities to start your next frame's first subframe.
… if that makes sense. If you have the time: Write a simple (spring-based, particle- or point-dependent) cloth solver and go through the subframe-problem yourself :-)
Again, I hope any of this is of some help. Excuse the babbling, please, I am trying to break it all down for the video I want to do, but there's so much stuff “in the background”, so trying to make it “simple” is so difficult :-D
Marc
> So would you recommend using a volume based approach?
actually … that depends :-)
It is important to understand the difference between actual “volume based collision detection”, which means that you are dealing with all the pros and cons of volumes (i.e. in the case of collisions you are using SDF fields, which are VERY fast to use but obviously only have limited mathematical accuracy) and “FEM based collision detection”, which means that you are “replacing” your geometry by an approximation of “atomic instances”. The latter, to my understanding, is what SideFX suggests for cloth simulations and to some extend I do agree.
H16 does not provide “volume based cloth simulations” (i.e. if you don't set that up yourself) - to my knowledge.
Advantages of FEM based simulations are obvious: You aren't limited by your actual (render) geometry's resolution (at least not for collisions, deformation, obviously you *are* limited by your render geometry when it comes to rendering), you can scale (resolution wise) quite easily, you can get as precise as you want (FEM collisions are surface collisions, because you are calculating “crossovers” of points and edges/planes). Since you are replacing geometry, FEM can be considerably slower than (original points based) point-collisions.
Volume = fast, surface = precise. Volume = not so explosive, surface = detailed.
You pick your cookie
> Am I correct in assuming that the points based approach is the same as the surface based collision detection, and that the parameters for these are set on the RBD tab in the static objects of the dopnetwork?
“Points based approach” in my world basically means that you are only calculation points (as in “geometry points”), concentrate mass on those and ignore any kind of penetration that might occur between two points forming an edge. That is fine for dense meshes and if you don't expect too much strain on the forces holding your points together.
By “points” you *could* instead mean particles. Cloth simulations using particles are a different beast, somewhere between points-based (as in “original points”) and atomic (“FEM”) based thingies … in my world, they combine the bad sides of both :-) YMMV.
“Surfaces” in Houdini's language, as far as I know, apply to what you would commonly understand as surfaces: Polygons. Houdini's technobabble likes to mess things up a bit, when used together with non-Houdini-apps … vertices versus points, primitives versus polygons versus ACTUAL primitives … argh. The way I see Houdini's “surface based collision detection” is just the math side of things: You are doing a cross-over check on every simulation step. Has one point (wherever you get that point from) crossed a plane/edge or has it not? If yes: Collision. If not: No collision. So I don't connect “surface” with what you *see* in that sense …
I also find Houdini's terminology for … well, let's call them “simulation entities”, just for the fun of introducing yet another arbitrary term - “steep to learn”: “Cloth” in Houdini is a solid body. When I tried to understand what the documentation is talking about, this threw me off in the beginning, because when I am thinking about “cloth simulation”, the only thing I do not have in mind are “solid bodies”.
Of course it makes sense, since a “cloth” is not a volume or liquid - but you *can* use a volume based collision detection for cloth, so you can use “volumes” on “solids”. That's Houdini for you :-D
Anyway, real “volume based” solvers are only available for static objects in H, if you don't create your own solution. The “cloth solver” is, AFAIK, a FEM solver that has been tweaked to deal with volume-free geometry (here “volume” means “single sided polygonal constructions that do not wrap some actual geometric volume”), but it *is* a FEM solver and it *is* a surface collision solver (when it comes to self-penetrations for example). Only if you want cloth to collide with static objects, the latter can be volumes.
The question about substeps versus frame count again depends on the implementation. In general (based on other cloth solvers I have used or written) substeps are always linear, so you are not getting any rotation values, any curved or dynamic animation/behavior AND you are not “piping back” your collision velocities the same way you do after you solved a FRAME. Because, in the end, what you store as animation data is frame based and inbound velocities (for your cloth and your collision objects) therefor are calculated on FRAMES, not subframes. That is one of several reasons for those infamous “exploding skirts”: The *actual* corrective velocity would have been much smaller, but what you get after your last subframe's calculation (perfectly adjusting the cloth's point position) based on the previous frame is … HIGH acceleration for the next frame. Giving you way too high velocities to start your next frame's first subframe.
… if that makes sense. If you have the time: Write a simple (spring-based, particle- or point-dependent) cloth solver and go through the subframe-problem yourself :-)
Again, I hope any of this is of some help. Excuse the babbling, please, I am trying to break it all down for the video I want to do, but there's so much stuff “in the background”, so trying to make it “simple” is so difficult :-D
Marc
-
- Quick Links