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


Submitted by Joachim Hofer, posted on May 10, 2001




Image Description, by Joachim Hofer



Currently I am working on an engine to display planetal systems. Whole planets can not yet be calculated correctly, but the LOD algorithm already works quite well with small stones. In all screenshots except the bottom right one you see a scene with 5000 stones (each of them having a different shape). Each stone consists of up to 3200 triangles, which means the scene consists of 16 million triangles. If I look at the scene like in the topright image, I get 18 FPS with average 50000 triangles rendered per frame (not counting triangles that are clipped away) on a PIII 1GHz and ATI Radeon SDR. The bottom right screenshot shows the scene in wireframe (you can see the LOD). Itīs only 1500 stones, where I get about 55 FPS with average 18000 triangles per frame. The rather low framerates come from the fact that no two stones are equal (at least theoretically) and that each stone rotates around a random axis and around the planet (and all those transformation matrices must be calculated...)

So, how does it work? I use functions f : RxR -> RxRxR that means from 2D to 3D to represent the stones, where the surface of the stone is the image of the function (I could calculate the normals through derivation of the function even though I do not use this method so far). You may think of these functions as the inverse texture mapping function (The texture mapping function maps the 3D vertices to 2D texture coodinates, my functions map 2D texture coordinates to 3D vertices). All I need to do now is calculate a tesselation for the texture, and then the function makes a 3D tesselation. So far the 2D tesselation is equal-distant over the texture, and so I cannot display big meshes like planets yet. I am currently working on a 2D tesselation depending on the position of the camera in order to make a planet consisting of several million polygons. You may download a demo at the download page on www.crowsoft.de itīs just 300 kB.

The program there still has some bugs, like for example 32bit mode doesnīt work with most video cards. Moreover I heard that it doesnīt work with Savage cards and with some drivers on ATI Radeon cards (even though the program was developed on a ATI Radeon... thatīs DirectX). Ah yes, it requires DX8, and no port for OpenGL is planned (this is due to a small DX vs. OGL war at our university :-)

Joachim Hofer


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

May 11, 2001, 12:48 PM

Or How about DX-Wings?

 
Comanche

May 11, 2001, 01:17 PM

The rocks aren't correctly shadowed. They should turn dark in the shadow of the planet.

 
Punchey

May 11, 2001, 01:25 PM

No kidding?

 
Joachim Hofer

May 11, 2001, 01:51 PM

I suppose he isnīt kidding, well, I _could_ write a real shadowing algorithm, but itīs kinda difficult (and time-taking). Well, I could write some fake. I could just say if the asteroid is between angle x and y, make it dark. I think this would be an acceptable idea, even though it would for sure look bad when the asteroids enter/leave the planet shadow... Has anyone an idea?

 
Joachim Hofer

May 11, 2001, 02:09 PM

Hi,

first of all, thank you for your nice comments. I didnīt think you would like it that much. I already showed it to some of my friends, and what they said was more or less "aha". So thanks.

The thing about the smaller stones, the "fog". This is for sure a great idea. It is just somewhat difficult :) I will think about how to do this, I already think it should work that you use some transparent texture if you are far away and real stones when you are closer. Hm. Anyways, this will be quite some work to do :-)

About the zBuffer problem. As I promised, I coded a workaround. I couldnīt find anyone to test it yet, but it might work (Iīm using a zBuffer now and different near/far clipping planes). I would be greatfull if anyone who encountered problems would download it a second time and post me whether something changed.

It seems I was not exact enough with the explanations about how the meshes are created. I basically use one Vertex Buffer that can store up to one full-LOD stone (and of course its index buffer). And then I do the following:
1) fill vertex and index buffer with the current lod, and save the number of created triangles / vertices
2) Set up the world matrix depending on the stones current rotation around itself and the planet
3) call drawPrimive()
4) move to next stone and then 1) until all stones are rendered
5) flip

As there seems to be so much interest in the topic I am thinking about removing all speed hacks (to make the program better readable) and post the source code on my homepage. If there is any demand (mail me or whatever) I will do this within the next weeks.

Thanks again for your comments,
Joachim

 
337

May 11, 2001, 02:12 PM

I've got gf 256 and it doesn't work, it switches display modes and then dies out with no error.

 
sulphur

May 11, 2001, 02:15 PM

Cool demo man..

10,000 stones @ 25fps (53619 tris) on my athlon 1333/geforce2gts (win2k/dx8)... lovely ;-)

sulphy.

 
Punchey

May 11, 2001, 03:28 PM

I agree that it would be very difficult. I don't see any real high-performance way of doing smooth shadow transitions. I'd say use the idea you just mentioned. You could poll for the position of the asteroid and update it's shadowed/nonshadowed state only every few seconds rather than every frame. That would help. Also, you could perhaps smooth it out a bit by using a metric such that as the asteroid gets closer to the edge of the planet's shadow, it could be progressively shaded brighter/darker. That way, even though the whole astroid would have the same shade, it would at least provide for a less abrupt transition. And when you think about it, a real asteroid being several miles away from the planet would probably be shaded in just such a way. I'd bet that for the most part on a real asteroid you'd have a hard time actually seeing any kind of "line" where the shadow begins and the light ends. But if you polled for the position of the asteroid relative to the edge of the shadow, and only did so every several frames rather than every frame, and then made the shading a gradient propertional to the distance from the shadow volume, that would be a very acceptable approximation IMHO. And should be rather performance friendly as well.

 
Joachim Hofer

May 11, 2001, 03:39 PM

Your ideas seem perfectly correct for me. Many thanks to you! :)

 
Punchey

May 11, 2001, 04:44 PM

You're quite welcome. I'd love to see how it looks when/if you implement something like this.

BTW, note to everyone else: notice how easy it is for people to give constructive input to IOTD posters on ways to potentially improve their apps when the IOTD posters themselves help the flipcode community by shedding even the dimmest of light on their own projects? I think flipcoders are much more inclined - not to mention ABLE - to lend some help when they themselves have been slightly clued into what's going on? Nobody can help you with your app if they don't know the first thing abot how it's being done. And on that note, I'd like to thank Joachim Hofer VERY MUCH for posting this image and for helping to share the knowledge and insight with all of us in the flipcode community! We greatly appreciate your willingness to share your insights with us! And in turn, we should be kind enough to step forward with any help we may offer you.

 
Tobias Franke

May 11, 2001, 05:39 PM

About releasing the source: I'd certainly be interessted (even if it's DX =)!!!

Oder um es noch mal auf den Punkt zu bringen: Es wäre extrem geil und interessant den Source zu lesen, vor allem da es sich mal nicht um eine Terrain Engine handelt =)

 
phizch

May 12, 2001, 01:49 AM

What drivers do you use?
I was unable to run almost all demos until I upgraded to Detonator 3 v10.80 (I skipped quite a few :)
I still use an aging TNT2Ultra though, so it might be a different problem..

 
The Wolf

May 12, 2001, 09:09 AM

Definitely, I would love to see the source code.
Again, 1st rate job!!

 
Joachim Hofer

May 12, 2001, 09:19 AM

Sadly I have no time at the moment to change the code so that I can publish it till Thursday.

Even though I will hopefull do this the next weekend (I hope I find the time). I will post a message to this IOTD as soon as it is finished, so check it a few times (or my homepage) if you are interested in the source.

 
klaudius

May 14, 2001, 10:15 AM

This doesn't work on my GEFORCE2 GTS (ASUS V7700 Deluxe). Gasp...
compatibility problems ?

 
Joachim Hofer

May 17, 2001, 03:19 PM

To everyone who still reads this:

The most evil spead hacks were removed from the source, and it was sligtly commented. Even though it still remains "demo code". So you should take some time to read it.
Even though you should be able to be download it from
www.crowsoft.de
If anything is missing or not working, please contact me.

 
This thread contains 46 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.