Hey, I tried out the demo. The cloth looks cool falling, and hanging from the object, but there appears to be a rendering bug (running on a TNT2) as you can see in the following screenshot:



The ball is still drawing through the cloth after it falls on it...

Same here on a G400. It also happens when the cloth is close to, but still definitely clear of, the sphere.

Other than that, it's a very realistic simulation (Better than many others I've seen).

Jeroen

That is VERY nice!! I get the same problem of the overlapping thing. I'd love to see that in a game.

I was unable to replicate the bug. I am using a ATI Rage 128 GL w/the latest and greatest drivers for Windows2000.

Anyways, nice work. Looks nice. If you can speed it up a bit it would be very nice :) Take care.

Looks great!

I don't get the bug with the Ball and the cloth but the cloth has artifacts where polygons are coplanar. (when lying on the plane)

This is on a Voodoo 5 5500 by the way.
I get 49fps when I maximise the window in 1280x960, 32 bit. :)

Phillip

looks great,
but i get this bug too. i got a intel cel 333 and a tnt card.
i get 100 fps if i max the window in 1280x960, 16 bit...

Same problem on my Voodoo3, I get 80fps on 1280*1024 16bits - 733Mhz.

Bij de Weg (By the way) it looks great and realistic !!!

i'm impressed! it looks so cool - this is one of the first really decent IOTD's i've seen for ages :)

i have to say that i don't get that sphere showing through the cloth problem, and i have a TNT2... which is strange. I do get the polygon artefacts when the cloth is in an untidy heap.

does the cloth collide with itself? maybe this is one way of solving the last problem.

I don't get the error on my TNT2Ultra/Win'98 machine either and it looks soooo cool! Great work!

((mice

Hi and thanks for all the great comments.
The bug with banded artifacts on the cloth showed up on my system after an OpenGL related crash a while ago (Counter Strike), strangely enough only my sim was affected, nothing else that used OpenGL. It looks like a glPolygonOffset bug, but I'm not using glPolygonOffset! I thought my driver was toast but re-installing didn't help either. Finally it was solved by changing a few of the OpenGL settings in the driver. Try turning stuff on and off again, and try using the alternate z-buffering technique. If that doesn't solve it I'm stumped. The reason you get z-fighting when the cloth is on the floor is that it doesn't collide with itself yet.

Joakim

You guys who have problems with the ball showing through the cloth - try running in a 32bit mode and see if the problem remains. I've found that in many applications the depth of the Z-buffer depends on the depth of the screenmode.

Kurt : Are you checking for and using W-buffer when available ?

Kasper Fauerby

Heya all.
Well a 32 bit Z buffer would certainly make a difference here. Under direct3D a W-buffer wont work (whereas a z buffer will) if the projection matrix isn't set up to be W friendly - The DX7 SKD has some more info on that. Anyways - great demo - Can you imagine hiding behind real curtains in a camper-strike style game?

I'm have a Geforce2 MX card and I get the same overlapping problem. But to me it seems like a Z-Buffer problem, if I get up close, the overlapping dissapears.

Have you had a look at Stephen Bakers Z-Buffer FAQ?

Learn to Love your Z Buffer

and other good stuff,
The Omniverous Biped's FAQ's

Btw. Kasper, more precisely, it depends on which videocard, f.ex Nvidia cards can only do 24bit ZBuffering in Truecolor modes, because then they can use the remaining 8bits of a DWORD, for the Stencil.
I think that it is ATI cards that can do arbitary ZBuffer bitdepth.

Isaack

Following Kasper's suggestion, I tried the demo in 32-bit mode and the problem I mentioned before is no longer there. Looks great Joakim!

Yep, I've verified it's a z-buffer precision problem. Can't believe I missed that, but I did. There's a new version up that should work in 16-bit now. Just try downloading again and it should work better, id it doesn't set your desktop to 32-bit and it'll definetly work.

Joakim

It sure helped here, I was running 32bit before and still does, and I see absolutely no overlapping anymore.

What did you do... just a reduction of the distance between far and near?

Are you recalculating the normals each frame? If so, what is your algorithm for that?
I'm looking for fast ways to recalculate 3D normals(besides the one at gamedev.net),

Isaack

May I just say that that IOTD does absolutely no justice to the demo...you have to download this demo to appreciate it. That is amazing!

I don't get the clipping problems, and I get 151fps at 1280x1024 in 32bit. Damn nice fps, imo :) GeForce2 GTS AGP 32Mb RAM, PIII 933, 256 RAM.

I still running that damn demo over and over again ;) I'd really like to see a demo on a sloped rugged surface.

James.

The z-buffer precision problem was fixed by moving the near clipping plane further away (for an explanation on why this works see the previous links posted). And yes, I recalculate the normals every frame, I pretty much have to since the cloth changes shape all the time. I just average the face normals (recomputed every frame) to get the vertex normals, it doesn't look that bad. It's actually not that much overhead doing all this every frame since the face normals are needed for the wind and air resistance calculations, so I'd have to do it anyway. I use absolutely no frame to frame coherence optimisation for normal calculation at all, is that what the gamedev method does?

Joakim

I haven't seen the clip error "live" but a qualified guess is that its a Z precision error. On NVIDA cards the Z buffer must be the same same depth as the color depth is so a 16bpp screen creates a 16 bpp depth buffer. That's most likely why the problem goes away in 32 bpp because then the depth buffer gets 32 bpp precision. You could try to narrow down the min/max Z range in opengl but it would probably be better to increase the collision boundary for the ball.

But anyway it's a damn cool demo!

Not that I know much about how these things are done but my guess is
that he can't apply the method to arbitrary geometry. Obviously there is alot of normal calculations involved (?) which suggests that he is limited to objects for which it's very fast to calculate a normal given any point on a surface.

The sphere have this property as the normal for any given point on a sphere is just the normalized vector going from the center of the sphere to the point on the surface.
This property is a special case of a general formula saying that any regular surface for which it holds that all points on the surface is given by f(x,y,z) = k, where k is constant then the normal for a point p=(x,y,z) on the surface is given by :
N(x,y,z) = (f'x(p), f'y(p), f'z(p))
(If you're interrested in this you can check my latest tutorial on collision detection at www.peroxide.dk - in contains a section about exactly this formula)

This suggests that his demo would work either immidiately or with very little change on ellipsoids too, but not on an arbitrary object.
But again, this is just me guessing...

Whatever he does it looks damn nice !!!

Kasper Fauerby

It looks really amazing, even on my PII 300 with an old ATI card!

I don't have the w-buffer problem and I think it's 16-bit deep. I think that in a modern graphics card that is designed to work with a 32-bit w-buffer, there is no sub-pixel accuracy applied for the w-value. So in 16-bit mode this causes precision problems if not handeled correctly. The sollution would be that the card does every calculation in fixed-point 16.16 format and stores only the upper 16-bit, instead of only using 16-bit integers from the beginning. Or maybe they don't scale the frustum correctly (if you put the far clipping plane closer and the near plane farther it's possible to have more w-value precision).

The normal generation thing on gamedev.net is pretty much as nice an effect for smooth shading as your going to get in run-time, I think. For a regular grid mesh, however, you can get a very convincing shading normal per vertex happening though, by generating the normal for a vertex by the triangle defined by that vertex, the vertex south of it, and the vertex to the right of it (excluding the south and right edges, I guess). So you have Tri(A,B,C) - you can calculate a normal for that like so: (It's been a while, but I think this is it..
Normal=Normalize(CrossProduct(B-C,A-C));
And that should be cheap enough to generate on the fly at pretty good speeds. Actually - depending on the order of A B and C, I think the normals might need flipping. Hope that helps.

First of all the normals I talked about are for the cloth mesh, not the object it's colliding with. The collision object needs to be able to send it's normal at a specific point to the cloth for collision response, but that doesn't exclude arbitrarily shaped objects. The cloth would be just as happy with a polygon mesh or a nurbs surface, it has no concept of shapes just the interface it uses to communicate with objects it's supposed to collide with. The only reason I use a sphere is cause it's simple to implement and fast. And yes, ellipsoids could be implemeted with very little effort.

Secondly, I don't know what "the gamedev method" is (does anyone have a link?) but the formula Number27 described is basically what I use.

This is truly AWESOME. I could spend hours just playing with this demo! Is there any chance you might post the source?

PS. Depending on the view angle, I got 40-68 FPS with no display bugs. I am running a Voodoo3 2000 AGP on a AMD K62-350Mhz machine.

The Gamedev.net Normal doc

The method that Number27 mentions, isn't that just the ordinary one... I'm looking for methods without the ugly sqrt.
I have parametric-surfaces that I would love to tesselate in realtime with dynamic lighting.
That's why I need the fastest way to calculate (vertex)normals,

Isaack

Wow, this stuff is awesome!

I can almost feel the wind...

I was already running in a 32-bit mode, but when I also turned on the 32-bit z-buffering (That's an option in the Matrox OpenGL settings) the problem was gone.

Jeroen

I get maximized at 1280x1024x32 60fps. It wanted to go higher but my refresh stops at 60 at that res. :) Im on a GeForce 256 DDR w/ a p3 600.

yeah..i love games that have realistic cloth movement, at least then when I get 3 fps at least I know that the 10 people on the screen have moving cloth :) I seriously doubt that this effect could be used with the usually number of people on a screen in a game. It would be better suited for a cut-scene or scripted stuff don't you think.

35 fps on high precision was the lowest it went on my PII 350 with Geforce2 card.

Very cool. The people in this group are right, you have to see it :)

No rendering errors here (Except for the self colision stuff)