A simple Cloth sceneNode for Irrlicht!

fmx · Post by **fmx** » Mon Oct 01, 2007 7:35 pm

Hi everyone!

this is my first REAL contribution to the Irrlicht community: a CClothSceneNode to simulate Simple Cloth Physics!

Quick Screenshot of my demo in action:

Get the Demo and Sources here:
(link removed, sortof died, need to reupload)

What is it?

It allows you to create a Cloth entity from any Irrlicht IMesh, and then after setting a few simple parameters, you can make it behave like Cloth (well, almost

its very fast considering the results it can achieve).

I'm not very good at explanations, so I'll just say that try out the demo to see what its all about (source included)

A picture can tell a thousand words, so check out my MSPaint skillz:

How to use it?

Check out the sources I've included: its a simple 3 step process really

1: Create the CClothSceneNode
2: Apply Pinners
3: Apply Forces

How does it work?

I've used a very simple Verlet integration method (somewhat similar to the Cal 3D approach) to manipulate a set of Springs created based on the Polygon data of the IMesh which you pass in.

Mathamatically speaking, its not at all 100% fail-safe, because it should be using very accuratly calculated timed steps, but it gets the job done the way it is...

Known Limitations, Bugs, stuff still To Do

-Doesn't work with all Model Formats?!
I tested it with an OBJ format file, but it gave very odd results; X files seem to work fine though... still need to do a lot of testing.

-Only uses the FIRST Mesh-Buffer of an IMESH!
which means, its practically useless for large, complex meshes. But should be good enough for simple things.

-Pinner shapes
only uses Spherical Pinners for now, but Box and Cylindrical Pinners can be more helpful sometimes too

-Collisions!
self-collisions dont occur so you can sometimes endup with strange behaviour, like corners folded over, etc.
and offcourse, collisions with OTHER objects would be nice to have too...

-Cloth parts for IAnimatedMeshes
wouldn't that be cool...

OK, I admit it.

I've made a premature public release; a lot of things simply haven't been implemented which should have been;

but I have my own reasons.
Simply put, I just won't have the free time after this week, so I figured I'd just make it public ASAP and let everyone help out to make this as useful as it can be for the future... the potential is immense.

I'd love to see Irrlicht become more recognised - Niko and the team deserve more credit than they are given, and only by sharing these kinds of implementations, we can ALL help to achieve that, and make Irrlicht better for everyone at the same time.

The spring system is more-or-less complete and can be used for other things; as I said before, i'm interested in creating a FastLSM softbody implementation for irrlicht, and an implementation could be build using this spring-system instead of the stuff outlined in their paper.

oh
sorry for using the GB-flag, but the Irrlicht Logo just didn't feel right... well, you get the point.

Any problems, Ideas, improvements, Tests, etc, let them loose in this topic so its easier to keep track of.

Have fun!

hybrid · Post by **hybrid** » Mon Oct 01, 2007 7:51 pm

Sounds very interesting

And with pretty much potential, still!
The problem with .obj might be the vertex duplication occuring in the loader. There's a patch available which will make its way into the core sometimes. So now you might have overlapping vertices which will hence get wrong forces. same holds for several mesh buffers, because they don't have any information about inter-vertex relations anymore. So I guess it's reasonable to make such stuff per buffer.

omaremad · Post by **omaremad** » Mon Oct 01, 2007 8:12 pm

Hehe nice work, i haven't looked at the code in detail here are a few points:

I accelerated some water nodes i had via some tricks like using non square root distance(good for high resolution meshes since the error decreases while being faster). For low res meshes where vertices are far apart this method becomes less accurate.

Your spring system is constructed only once which is very good (not regenerated every iteration), however a memcopy here might yield a speed increase(maybe compiler spots this)

Code: Select all

for( u32 n = 0;  n < NumNodes;  n ++ )

        {	

        	 Vertices [ n ].Pos = NODE[ n ].Pos;

        }

Time corrected verlet might come useful (only a tiny change to the verlet equation) if you have a variable frame rate.

As for collisions i have tried impulse based methods (but didn't seem to very reliable or fast)

. so i made my own method where i moved the particle during a collision to its final position after a collision using reflection of velocity vector and simple vector math, verlet has implicit velocity so my position modification didn't ruin the physics. I dont really think you need to add collision since this will be dependent on the user's coll detect solution.

The LSM technique was using spring bound cubes, vertices's inside the cube were affected by the cube's transformation (their technique gives a smooth effect so maybe also other neighboring cubes had an effect). So this can be like lsm (infact here 1 "bounding box" = "1 vertex").

As for obj strangeness, it maybe duplicate vertices, i have some code that removes them via hashing vertex positions and tcoords. (or use blender and rem doubles.

Thanks for the contrib. I also have something baking but

I just won't have the free time after this week

hehe because of studying.

omaremad · Post by **omaremad** » Mon Oct 01, 2007 8:15 pm

The problem with .obj might be the vertex duplication occuring in the loader

Damn beaten

omaremad · Post by **omaremad** » Mon Oct 01, 2007 8:27 pm

Most physics stuff also precalculates inverse mass to save on real time divides

Code: Select all

 NODE[ n ].Force / NODE[ n ].Weight

, however the code is very clean and nicely commented

fmx · Post by **fmx** » Mon Oct 01, 2007 9:20 pm

thanks hybrid for that info about the duplicate faces: that's *exactly* the problem I experienced. Hopefully Irrlicht-1.4 will have it fixed by default.

and wow, thanks so much for your tips and useful bits of advice omaremad

!

I knew there were ways to optimise it, but just doing this much made me lose focus a bit... I'll try them for the next release.

regarding collisions, I've already got a simple sphere-sphere implentation working with one of my older trials (sounds similar to what you did); it doesn't affect the physics at all, but I'm not sure how CPU intensive it will prove.

yup, best to leave it till later. I don't want to complicate things yet, still too early.

You seem to have quite some experience with spring-based systems... I'm greatful that you're willing to share your experience and help improve this. thanks a lot.

I'll make another release just before the weekend, maybe adding in the collision-system i was talking about,
but feel free to add / improve / criticise at will!

koller202 · Post by **koller202** » Tue Oct 02, 2007 8:17 am

so cool !
________
How To Roll Joints

Virion · Post by **Virion** » Tue Oct 02, 2007 11:20 am

Nice!!

IPv6 · Post by **IPv6** » Tue Oct 02, 2007 12:36 pm

Nice stuff!!! Worth experimenting

lester · Post by **lester** » Tue Oct 02, 2007 12:58 pm

Ma-a-an, you're da Ma-a-an!

Now there is a problem how to integrate your cloth with existing physics engines, such as ODE, Newton, Bullet etc.

JPulham · Post by **JPulham** » Tue Oct 02, 2007 1:34 pm

wow

now I have to find an excuses to put this into my project

drac_gd · Post by **drac_gd** » Thu Oct 04, 2007 12:03 am

Great Work

Now if I could only get breasts to bounce like in Neverwinters hack

JP · Post by JP » Thu Oct 04, 2007 8:21 am

You can do bouncy breasts using Physx!

MasterGod · Post by **MasterGod** » Fri Oct 05, 2007 11:19 am

Very Cool.

PS: I was like 10-15 minutes playing with it and I just couldn't stop!

monkeycracks · Post by **monkeycracks** » Fri Oct 05, 2007 11:29 am

Very nice