Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Joakim Hårsman, posted on December 10, 2000




Image Description, by Joakim Hårsman



This is a shot from the latest version of my cloth simulation, based on spring dynamics. There's air resistance and wind (that's why it's billowing so beatifully :-) ) and decent friction. Oh and ignore the 9.6 fps in the titlebar that's just my timer that's confused since I paused the sim for the shot. The sim can be downloaded from:

http://hem.passagen.se/harsman/index.html

Joakim hårsman


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Kurt Miller

December 10, 2000, 01:55 AM

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...

 
Jeroen

December 10, 2000, 02:46 AM

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

 
StiNKy

December 10, 2000, 03:23 AM

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

 
Refractor

December 10, 2000, 03:30 AM

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.

 
Phillip Jordan

December 10, 2000, 05:34 AM

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

 
SnAkE

December 10, 2000, 05:48 AM

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...

 
MgFun

December 10, 2000, 06:38 AM

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

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

 
remo

December 10, 2000, 06:44 AM

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.

 
mice

December 10, 2000, 07:13 AM


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

((mice

 
Joakim Hårsman

December 10, 2000, 07:16 AM

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

 
Kasper Fauerby

December 10, 2000, 07:53 AM

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

 
Number27

December 10, 2000, 08:18 AM

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?

 
Isaack Rasmussen

December 10, 2000, 08:24 AM

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

 
Kurt Miller

December 10, 2000, 08:35 AM

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!

 
Joakim Hårsman

December 10, 2000, 08:48 AM

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

 
Isaack Rasmussen

December 10, 2000, 09:47 AM

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

 
James Matthews

December 10, 2000, 10:04 AM

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.

 
Joakim Hårsman

December 10, 2000, 10:23 AM

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

 
Joakim Eriksson

December 10, 2000, 10:29 AM

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!

 
Kasper Fauerby

December 10, 2000, 10:35 AM

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

 
Nick

December 10, 2000, 10:46 AM

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).

 
Number27

December 10, 2000, 11:00 AM

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.

 
Joakim Hårsman

December 10, 2000, 11:40 AM

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.

 
Vorteks

December 10, 2000, 12:35 PM

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.

 
Isaack Rasmussen

December 10, 2000, 01:04 PM

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

 
richard

December 10, 2000, 01:10 PM

Wow, this stuff is awesome!

I can almost feel the wind...

 
Jeroen

December 10, 2000, 01:54 PM

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

 
SirKnight

December 10, 2000, 02:05 PM

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.

 
Tim Wojtaszek

December 10, 2000, 02:46 PM

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.

 
WillyWonka

December 10, 2000, 02:59 PM

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)

 
This thread contains 48 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.