A simple Cloth sceneNode for Irrlicht!
I'm afraid not, and i've not actually seen them done in Physx but know it would be possible using soft bodies or cloth simulation of a mesh with internal pressure which basically makes a bag full of air which can be squished about. I guess you could make two bags of air and hang them off the chest of a model 
It would be difficult but I think it could be done something like this:
A point of influence at the nipple.
The further the distance the from the point of influence the stiffer the springs.
At the end of each step animation cycle a downward impulse of gravity is applied to the point of influence.
The spring system should take care of the rest of the movement.
The mathematics for a stable system would hurt my brain so I can only dream
A point of influence at the nipple.
The further the distance the from the point of influence the stiffer the springs.
At the end of each step animation cycle a downward impulse of gravity is applied to the point of influence.
The spring system should take care of the rest of the movement.
The mathematics for a stable system would hurt my brain so I can only dream
I dont really endorse the use of this info 
, but a sphere of cloth can be maintained uncollapsable by adding extra springs to each vertex along the vertex normal
new spring point = sphere point + sphere normal
make spring (start sphere point ,end sphere normal).
, but a sphere of cloth can be maintained uncollapsable by adding extra springs to each vertex along the vertex normalnew spring point = sphere point + sphere normal
make spring (start sphere point ,end sphere normal).
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
-
fmx
thanks for all your appreciative comments everyone! 
I don't think I'll update this now until Irrlicht 1.4 (stable) comes along; shouldn't be too long now anyways
and lol, all this discussion about boob-physics
that's a pretty innovative idea omaremad...
if a spherical-ish mesh can be made, where edges are also created INSIDE the sphere, then you could use my CClothSceneNode as it is, and it should behave "accordingly" if you set the spring-strength to a value closer to 1 (theoretically);
offcourse, you would have to find a way of correctly attaching / pinning it to an animated mesh so it looks 'correct'...
I'm curious: has anyone used this scenenode in their projects yet?
I'd love to see some screenshots of how people are using it (flags are nice and all, but its not the only thing that's made of cloth)
I don't think I'll update this now until Irrlicht 1.4 (stable) comes along; shouldn't be too long now anyways
and lol, all this discussion about boob-physics
that's a pretty innovative idea omaremad...
if a spherical-ish mesh can be made, where edges are also created INSIDE the sphere, then you could use my CClothSceneNode as it is, and it should behave "accordingly" if you set the spring-strength to a value closer to 1 (theoretically);
offcourse, you would have to find a way of correctly attaching / pinning it to an animated mesh so it looks 'correct'...
I'm curious: has anyone used this scenenode in their projects yet?
I'd love to see some screenshots of how people are using it (flags are nice and all, but its not the only thing that's made of cloth)
-
christianclavet
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
Hi, FMX.
Checked your demo and it look great. The source is very easy to read.
I had lots of fun playing with your flag.
Do you plan to add vertices collision in the future? (Heard that Rogerborg had added more capabilities for collision detection inside a mesh)
This could be used for:
- Long hair simulation (IRRlicht Guitar Hero? )
- cloth ( ) like a skirt.
- For boats (sails)
Exept the sail that should not collide with the rest of the geometry the other will and a simple collision, sould be required so it will not go thru.
If this work. I could use it for some of our animated characters that will have some kind of egyptian skirt (Egyptian Anubis Jackal Headed warrior). The skirt will have to move like the flag but not go thru the legs of the character.
So when they will move, we'll see the egyptian skirt behave correctly. We could also create bones and animate it (we would not have the latency in the cloth when the character is stopping and moving, like you have in your flag).
Checked your demo and it look great. The source is very easy to read.
I had lots of fun playing with your flag.
Do you plan to add vertices collision in the future? (Heard that Rogerborg had added more capabilities for collision detection inside a mesh)
This could be used for:
- Long hair simulation (IRRlicht Guitar Hero?
)- cloth (
) like a skirt.- For boats (sails)
Exept the sail that should not collide with the rest of the geometry the other will and a simple collision, sould be required so it will not go thru.
If this work. I could use it for some of our animated characters that will have some kind of egyptian skirt (Egyptian Anubis Jackal Headed warrior). The skirt will have to move like the flag but not go thru the legs of the character.
So when they will move, we'll see the egyptian skirt behave correctly. We could also create bones and animate it (we would not have the latency in the cloth when the character is stopping and moving, like you have in your flag).
-
fmx
Glad to see *someone* remembered my little contribution to the community
(jk, actually, I was kinda hoping everyone forgot and this post ended up in the dog-pile of ancient works gone AWOL, 'cos I really don't like it)
Collision and such would be really easy to implement, but optimising it based on my current code (which is soo simple its terribly un-efficient) would cause drastic FPS-drops if you try using it with complex meshes for collision purposes
My initial plan with this was to build up a Fast-LSM softbody-dynamics system, since the code to handle and manipulate the nodes/springs would be identical; but I got empolyed (no really, I got a full-time job), and now I get virtually no free time for anything (DGEN and JP could testify to that )
I don't suppose you're in any hurry to add these kind of dynamics to your characters yet?
Have you even documented how you're intending to use such Physics in your game/demo/engine?
I ask because there might be other alternatives, such as using the Aegia PhysX physics-API, which can actually support these kinds of things, and would be much faster too.
but if you're still interested in my apprach, then let me know - I guess I can always continue with this as a fun hobby project (crap as it would be)
(jk, actually, I was kinda hoping everyone forgot and this post ended up in the dog-pile of ancient works gone AWOL, 'cos I really don't like it)
Collision and such would be really easy to implement, but optimising it based on my current code (which is soo simple its terribly un-efficient) would cause drastic FPS-drops if you try using it with complex meshes for collision purposes
My initial plan with this was to build up a Fast-LSM softbody-dynamics system, since the code to handle and manipulate the nodes/springs would be identical; but I got empolyed (no really, I got a full-time job), and now I get virtually no free time for anything (DGEN and JP could testify to that
)I don't suppose you're in any hurry to add these kind of dynamics to your characters yet?
Have you even documented how you're intending to use such Physics in your game/demo/engine?
I ask because there might be other alternatives, such as using the Aegia PhysX physics-API, which can actually support these kinds of things, and would be much faster too.
but if you're still interested in my apprach, then let me know - I guess I can always continue with this as a fun hobby project (crap as it would be)
Hmm, just curious, but I am wondering why cloth simulation would not be considered as a dropback from GPU computations? I am sure you can easily post this code over to GLSL, and HLSL for cloth simulation which is hardware-accelerated, and if you can't, then you could always refer to the nVidia SDK 10.
I just think that software simulation of cloth should be left as a fallback only for when the user's system does not support shaders.
I just think that software simulation of cloth should be left as a fallback only for when the user's system does not support shaders.
TheQuestion = 2B || !2B
-
christianclavet
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
I'm still interested in it FMX. I just need a simple thing for the warrior "skirt".
Perhaps even use it without the collision. The collision, could be specified points on the mesh (Like you specify the position of FIX). If it's collisionning all the points in the cloth mesh, it would be too much CPU intensive as you pointed out. If we could define up to 8 collision points on the cloth mesh and I think it would be ok.
Now, we'll also need to do this placement in IRRedit. Someone (perhaps me )Will have to write something to attach and set the collision point on the mesh.
Perhaps even use it without the collision. The collision, could be specified points on the mesh (Like you specify the position of FIX). If it's collisionning all the points in the cloth mesh, it would be too much CPU intensive as you pointed out. If we could define up to 8 collision points on the cloth mesh and I think it would be ok.
Now, we'll also need to do this placement in IRRedit. Someone (perhaps me
)Will have to write something to attach and set the collision point on the mesh.@Halifax
Cloths as shader?
@JP
I got an physx card and you need lots of CPU on software mode to see the cloth renders with a nice fps, (but you can break them wich needs some more calculations than only physics ofcourse)
@ fmx, if you add option for collision is that practicel for software? I mean, 1 flag is nice, but what if you got more than 1 cloth simulator in the application like a full clothed human?
Cloths as shader?
@JP
I got an physx card and you need lots of CPU on software mode to see the cloth renders with a nice fps, (but you can break them wich needs some more calculations than only physics ofcourse)
@ fmx, if you add option for collision is that practicel for software? I mean, 1 flag is nice, but what if you got more than 1 cloth simulator in the application like a full clothed human?
Compete or join in irrlichts monthly screenshot competition!
Blog/site: http://rex.4vandorp.eu
Company: http://www.islandworks.eu/, InCourse
Twitter: @strong99
Blog/site: http://rex.4vandorp.eu
Company: http://www.islandworks.eu/, InCourse
Twitter: @strong99
-
fmx
strong99, this is EXACTLY the reason why I'd like to see this topic and my code dissapear into oblivion - its sooo simplistly unefficient even its current state, subjecting it to collisions of various magnitudes would be overkill for the CPU
You wouldn't need to do collision-checking for the WHOLE of a human body, just the parts directly near it (and that is why the FastLSM approach would be far more practical approach, because there would be less collisions to test for)
Christian
it seems a simple enough premise, but the processing requirements can easily rise to powers of magnitudes for multiple characters / cloth-objects / collisions
I suggest you wait until you can get as far as having a demo which shows multiple jackel-warriors (all normal-mapped) running around in your demo, before rushing into demanding physics of these sorts.
Halifax
I'm just as confused as strong99. could you clarify it a bit?
but if what you're saying is what I think you're saying, then i'd say that it would probably be a bad idea - Ageia PhysX have their own range of cards which use hardware for physics, but trying to use a Graphics device would probably not leave you with muh room/power for all the rendering requirements.
computer processors are quite fast these days, so it might be wiser to leave the GPU to get on with its own tasks.
You wouldn't need to do collision-checking for the WHOLE of a human body, just the parts directly near it (and that is why the FastLSM approach would be far more practical approach, because there would be less collisions to test for)
Christian
it seems a simple enough premise, but the processing requirements can easily rise to powers of magnitudes for multiple characters / cloth-objects / collisions
I suggest you wait until you can get as far as having a demo which shows multiple jackel-warriors (all normal-mapped) running around in your demo, before rushing into demanding physics of these sorts.
Halifax
I'm just as confused as strong99. could you clarify it a bit?
but if what you're saying is what I think you're saying, then i'd say that it would probably be a bad idea - Ageia PhysX have their own range of cards which use hardware for physics, but trying to use a Graphics device would probably not leave you with muh room/power for all the rendering requirements.
computer processors are quite fast these days, so it might be wiser to leave the GPU to get on with its own tasks.
Ah, yes, after looking back at my post I don't know what I was trying to convey.
Either way, I would like to say yes I think cloth simulation should be offloaded to the GPU. And have you seen how many shaders games use these days? It would not cut back on rendering much at all, and would in fact be an increase over that of software simulation. I am in no way suggesting doing cloth simulation with PhysX, as I don't support PhysX right now.
If you need more proof of cloth simulation on the GPU, then you should check nVidia's demo, but as I said software simulation could always be kept as a dropback if the user so chooses to reduce it.
Either way, I would like to say yes I think cloth simulation should be offloaded to the GPU. And have you seen how many shaders games use these days? It would not cut back on rendering much at all, and would in fact be an increase over that of software simulation. I am in no way suggesting doing cloth simulation with PhysX, as I don't support PhysX right now.
If you need more proof of cloth simulation on the GPU, then you should check nVidia's demo, but as I said software simulation could always be kept as a dropback if the user so chooses to reduce it.
TheQuestion = 2B || !2B
-
fmx
Halifax
I've checked up on it, and it might be really useful to have a GPU based implementation (via vertex shaders)
thanks for letting me know about it
I've decided I'm going to update this scene-node, especially considering that Christian is interested in using it for First-King, so it needs be somewhat decent and usable
Here's what I'm planning for the next version:
- based on Irrlicht 1.4 (1.5 if it comes along anytime soon )
- optimised sofware implementation of the main class (might become unclear as to what's happening in the code, but I'm moving on now from having explained the theory, to making it practically useful)
- an optional GPU based implementation (for cases where its available, would significantly boost speeds)
I haven't talked about collision, because if anything, collision functions will be the true bottleneck. I'm going to be experimenting with diferent approaches to do quick collisions (with animated models ofcourse), and only if I can get acceptable results, will I include it with the code.
As usual, sources will be made available (or it wouldn't be a Scene-Node, would it?)
I've checked up on it, and it might be really useful to have a GPU based implementation (via vertex shaders)
thanks for letting me know about it
I've decided I'm going to update this scene-node, especially considering that Christian is interested in using it for First-King, so it needs be somewhat decent and usable
Here's what I'm planning for the next version:
- based on Irrlicht 1.4 (1.5 if it comes along anytime soon
)- optimised sofware implementation of the main class (might become unclear as to what's happening in the code, but I'm moving on now from having explained the theory, to making it practically useful)
- an optional GPU based implementation (for cases where its available, would significantly boost speeds)
I haven't talked about collision, because if anything, collision functions will be the true bottleneck. I'm going to be experimenting with diferent approaches to do quick collisions (with animated models ofcourse), and only if I can get acceptable results, will I include it with the code.
As usual, sources will be made available (or it wouldn't be a Scene-Node, would it?)