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

May 10, 2001, 07:52 PM

Very nice.

 
Vorteks

May 10, 2001, 07:55 PM

Sweet picture. 16 million triangles is a lot. It kinda looks like something you'd see in the introduction to Star Trek: Voyager.

 
frost

May 10, 2001, 08:28 PM

the stones always appear behind the planet on my ati rage mobility 8mb. good fps tho, im impressed.

 
Steve 'Sly' Williams

May 10, 2001, 11:48 PM

~55 fps with default options on a P3-550 and TNT2-M64. 7.7 fps at 32-bit 1024x768 with 10,000 stones. :)

Very impressive. Seeing 10,000 separate objects circling that planet is quite the sight indeed.

I noticed something strange with the light. Is there a lightsource circling around the scene somewhere? And shouldn't the stones on the dark side be in shadow?

 
Kail

May 11, 2001, 12:04 AM

I love it! I'd love to try it with more than 10k stones though...:)

Of course, I'd love to drive a spaceship through there too...:)

 
John S.

May 11, 2001, 12:42 AM

I'm curious about your r2->r3 function. Care to elaborate on it a lil more? how do you get it to wrap around in 3 space?

 
Akiratf

May 11, 2001, 02:59 AM

wow, it's greate, 10k objects all dancing through the space, impressive!
but where is the space ship, the enemy and .... ;)


Akira

 
Joachim Hofer

May 11, 2001, 03:04 AM

to frost:
I think this is a zBuffer problem. I use wBuffering, but it seems not to work quite well with those ATI cards. I hope to be able to fix this today...

to John S.
this is really not that difficult. I am not at home, so I cant post you the exact function, but I can explain how it works.At first I create spheres with something like:
f(x, y).x = (sin(x*2*Pi) * abs(sin(y*Pi)),
f(x, y).y = sin(y*Pi),
f(x, y).z = cos(x*2*Pi) * abs(sin(y * Pi)))
I am not sure whether this is correct, but I hope you know what I mean, its just a simple sphere tesselation.
Then I perform some parameterized "noise":
x = p1 * x * (y + p2 * z); // this is just an example, the real thing doesnt look like that
y = ...
z = ...

And then for every stone I only have to store the parameters (I think its three parameters that were randomly created at startup).

When it comes to tesselation, I simply put a regular grid over a [0,1]x[0,1] texture (this is also the texture coordinates).
To calculate the positions in 3D I simply calculate f(x, y) on those coordinates and get the positions in 3D.

For now, I only put a regular grid over the texture, but you may of course use any tesselation of a plane, and then I can also create planets (for the Planets I will of course use a different function, to generate real mountains and so on)

 
D.P.

May 11, 2001, 03:26 AM

Sounds impressive, What you need to do is add a Deathstar, not a planet. Add to that a couble of star destroyers, a few tousand tie-fighters and x-wings with lasers flying everywhere and you will have a great game.

Dx vs OpenGL war? sounds interesting for a uni. And as far as I see DX is winning!!! Oh no!!. At my Uni it is the oposite, there is an anti micro$oft war and so ALL PCs run Linux and non ms software.

 
Joachim Hofer

May 11, 2001, 03:41 AM

;-)
At our Uni it is the same. Linux and Unix everywhere (there is only a little WinNT Multimediapool).
There is only a small "Microsoft rocks, Linux sucks" group, but we are about 1 against 100. Now please do not understand me wrong, I have nothing against Linux, and my Windows machine crashes as often as yours does. I just cannot stand this "Microsoft sucks - I am so cool to have Linux" attitude. Well, our only luck is that most guys at our Uni know little about 3D programming. They are indeed impressed by a textured cube ;)
So in the 3D section the minority (Microsoft crew) probably wins over the majority (Linux crew) :)

 
Invhunter

May 11, 2001, 03:50 AM

Very impressive!

 
RyseFtk

May 11, 2001, 04:16 AM

ATI Radeon cards (even though the program was developed on a ATI Radeon... thatīs DirectX).

Ah, I dunno. The Radeon Cards we had here suffered from their badly designed drivers during the first months. I could not see anything that was wrong with my installed version of DX ;)

About the shot. Did you say that you generate the meshes for the stones everytime they switch their LoD? That would mean that a the scene performance would be great as long as the camera is static. A moving camera, e.g. from a viewer inside a fast spaceship that is dashing through the asteroid belt to evade some persuader, would suffer from a lot of CPU load for regenerating the stones, no?

 
Joachim Hofer

May 11, 2001, 04:46 AM

Indeed the meshes are created every frame. That means at the beginning of the frame there is no vertex or triangle data present and is created every frame. So the moving speed is not relevant, as there is nothing saved from the previous frame. This is necessary anyways, as there are presently 40 different LOD details of every stone, so the LOD changes nearly every frame anyways :)

 
Invhunter

May 11, 2001, 04:46 AM

How about precalculating some meshes with different LOD before start rendering. That should be evene faster than generating them new every time!

 
Joachim Hofer

May 11, 2001, 04:53 AM

Well,
the cool thing (in my opinion) is that all those 10000 Stones look different. This results in the fact that there would be nearly one GB of Mesh data (which would not really be fast :).
For now this is not really important, as 10 different Stones would look pretty the same. But as soon as I will be able to do whole planets with several million polygons, this will no longer be like that. Even though you are right. It would be much faster, and also simpler :)

 
Tobias Franke

May 11, 2001, 05:26 AM

Muahahahaaa! Die Directxpussy's die!!! =)

 
Fabian Giesen

May 11, 2001, 08:36 AM

Didn't work on my machine till I switched to DX8 Retail (had Debug running), so I guess there's something wrong with your startup or whatever :)

Ran quite fine though (Geforce 1 DDR) and reasonably fast (24.4 fps with 3000 rocks).

 
Leon Rauis

May 11, 2001, 08:36 AM

You're able to pump 50000 triangles per frame @ 18 fps recreating the geometry every frame on hardware a little faster than mine.

Doing the same (creating geometry each frame) I can get around 20000 triangles per frame @ ~20 fps. Kudos.

You are a better man than I :)

 
henry ludemann

May 11, 2001, 09:22 AM

Very nice program... even run on my machine with an intel 82815 graphics card at 43fps with 20000 tri per sec, though the depth buffering wasn't working.

Just to say again, congrats, as that really looks pretty at a nice speed. (and I don't know what you changed to your inhomogenuous specular highlighting demo, but that works for me now too)

 
treething

May 11, 2001, 10:25 AM

Screenshots look great.:-) I cant run it though.. It doesnt get past the little setup dialog, no matter what settings i choose.

Im running win2K, with a GeForce2, DirectX8.

Chris

 
Punchey

May 11, 2001, 11:12 AM

How are you storing the vertex data for rendering? One of the most common and quickest methods is to try and store large clumps of your vertex data in a single array. Are you doing creating such an array each frame or do you just keep the vertex data in seperate arrays for each object? And if so, how are you managing the memory for all these allocations since I can imagine allocating and re-allocating memory for all these vertices each frame would KILL your app. Thanks! GREAT IOTD BTW! One of the best!

 
EGreg

May 11, 2001, 11:29 AM

I have to say, very nice comments. Very ncie comments indeed.

ER, I MEAN THE IMAGE! I like the fact that there are so many stones and they look different. I don't get how uploading new texture coords (and calculating them) oper frame could be that fast though.

-Greg

 
EGreg

May 11, 2001, 11:30 AM

I have to say, very nice comments. Very ncie comments indeed.

ER, I MEAN THE IMAGE! I like the fact that there are so many stones and they look different. I don't get how uploading new texture coords (and calculating them) oper frame could be that fast though.

-Greg

PS: TELL US ABOUT THE WAR AT UNIVERSITY!!!!! YEAAAAAH!

 
EGreg

May 11, 2001, 11:34 AM

YOU SHOULD ADD DIRECTXSTAR!!!!!!!!!!!

AND HAVE OPENGL FIGHTERS!! :)

-Greg

 
The Wolf

May 11, 2001, 11:48 AM

Very Impressive, this is top-notch work with a future.
what kind of function f are you using? looks like it's quadratic in nature.

 
himh

May 11, 2001, 11:55 AM

The depth problem is probably due to the fact that the 815 doesn't
support W buffering which he stated is used above. I can confirm as
I work on Intel's Direct3D drivers.

 
Buster

May 11, 2001, 11:57 AM

"planetal systems" ??

 
Punchey

May 11, 2001, 12:03 PM

I like the idea of star-voyaging persuader and trying to evade them. :-) Seriously though, this IOTD is EXCELENT! I would still ilke to know how the memory management is working and how the newly generated vertex data is handled in memory and in the rendering. Are brand-spakin' new arrays of vertices created each frame??? If so, how is the memory allocation not a serious bottleneck?

 
mbk3de

May 11, 2001, 12:04 PM

nice, except:)... its all relatively large rocks... what about smaller rocks all the way down to the little rocks that look probably more like dust/fog when not very close to camera...
having 'fog' around distant rocks would give the illusion of there being millions of billions of rocks all up (hehe... i'd like to see hardware that can draw that bruteforce rock by rock)
You'd probably could get away with only drawing 'larger' distant rocks because the 'fog' would blur things up a bit. You'd have to be careful not to blur too much as to kill the effect of there being lots of individually distinguishable rocks (u know what i mean no?;)

 
henry ludemann

May 11, 2001, 12:28 PM

Thanks, I was wondering why some of my programs had no depth buffering going ;-)

You just saved me from tearing out some hair.

 
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.