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

Submitted by Joshua Shagam, posted on August 19, 2000

Image Description, by Joshua Shagam

Even with 9268 unique objects of which about 3500 are visible at this time, only about 35 unique LOD mesh retesselations are being calculated. (Oh, and even though they're all spheres, they're stored as a generic mesh, not as a procedural generator.)

Obviously, this isn't a typical scenario. Good thing, too, since even on my 525MHz Celeron with a 32MB G400 it's only getting 1.5fps. :) (I would have sent an image using shadows to gloat about the fact that even the shadow volumes would have only contributed a minimal increase to the number of LOD retesselations, but stencils are currently broken on the Linux G400 driver and I gave up on waiting for this to render a single frame using software Mesa after about 10 minutes...)

Oh, and one of the (many) things I'm working on right now is an actual mesh editor for my funky mesh-representation scheme. Maybe I can eventually put in screenshots where the models aren't all procedurally-generated. :)

This is all on Solace, my thesis project 3D engine. More screenshots are available at

Image of the Day Gallery


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

August 20, 2000, 04:21 PM

Man, that's a lot of spheres !

Where you thinking about an Asteroid field, when you did that ? ;)

Maybe you could generate a fractal landscape and animate it with some noise function.
Like I'm imagening, it should be cool.

Good luck for your thesis.

See ya


August 20, 2000, 05:36 PM

It would seem that the number of spheres is inversely proportional to the number of comments. ;)

Rui: Actually, I originally set up that scene to test my lighting to see how the light was diffusing through the scene. :) It also gave me a good excuse to finally write a proper LOD cache and test that as well. I don't think that in actual runtime use the LOD cache will see much activity, but it doesn't cause any performance hit either, so it's not really a bad thing to have just in case it does become useful. It's also nice to have a stress-test like that to force myself to implement several speedups which are necessary (for example, since that screenshot I've done a lot to speed up shadow volume generation by a good factor of 2 by eliminating a lot of useless memory copying).

Oh, and one thing I did notice is that a large field filled with perfectly-cubically-spaced objects looks very much like a fractal when viewed from various angles. It'd probably be faster to just model the fractals directly though. ;)

My engine isn't really suited for landscapes. I don't have any sort of landscape rendering, just pure object rendering. I don't plan on adding in landscapes, either, since for the sorts of thing the engine will be used for (namely a 3D MUCK system), having any landscapes as objects will likely be more useful anyway. This engine is more about being reasonably interactive with pretty visuals and complete flexibility rather than being fast and hardcoded. There isn't even a proper occlusion-checking system (I've tried quite a few algorithms, but none of them work at all well for a completely-dynamic environment; you can read about my most recent experiment with a beamtree on my development diary).

Also, I've got plenty of time for my thesis (a few years at least) - I'm getting an early start on it, unlike most grad students. :) By the time I'm ready to present this (2-3 years), I think hardware will have definitely caught up with my somewhat lofty goals, no less, and even with today's hardware it should be quite usable when the reflections and shadows aren't turned on. (Those two features are both the prettiest and the most bandwidth-sucking parts of the engine...)


Code. Music. fluffy.

Rui Martins

August 21, 2000, 09:40 AM

Hi, again

As far as I'm concerned, the Number of comments as nothing to do with the quality of the software.
Usually the more eye candy you have, the most comments you get, or the more playability the most comments also.

An image is worth a 1.000 words, but a video is worth 10.000, and a playable demo is worth 100.000 wordies.

You are right about making stress tests, they do provide a solid source for improvements.

I usually develop my stuff (OGL) with a software driver, because it allows you to find the best transforms performance, due to the fact that the fill rate is complettly stressed out.
When you feel good about the performance you are getting, then switch to hardware driver, and then everything flies. But this configuration will also help you to find some extra speed increases by messing arround with your setup and optimization paths.

The ideia is: always try several approaches, this will help you find the bottlenecks of your app.

Currently I'm only using software rendering, because I'm forced by circumstances. My current board only has a QuakeGL driver, which I can't make to work with my OGL programs, it has something to do with the way GLUT does the FrameBuffer Swap. And also because I'm waiting for the new PowerVr board to come out, with full ICD support.

See ya


August 21, 2000, 01:42 PM

Heh, I know all this about performance comparisons and the like. ;) However, your statement that using a software OpenGL driver to test your transform speed is quite incorrect... when 99.9% of your frame time is taken up by fills, it's VERY hard to determine how fast your transforms are.

However, while Utah-GLX's stencils are broken, I don't have any choice but to use software OpenGL for testing my shadow code anyway. Actually, what I use to identify bottlenecks is a good old profiler. gprof is very useful. :)


Code. Music. fluffy.

Rui Martins

August 24, 2000, 10:27 AM

>However, your statement that using a software OpenGL driver to
>test your transform speed is quite incorrect... when 99.9% of your
>frame time is taken up by fills, it's VERY hard to determine how fast
>your transforms are.

Well, that' exactly the ideia,if you are maxing out the fills already than you won't have any speed variance due to the fill rate, since it's maxed out.
What you say is true, is that it's harder to see small improvements, due to the lack of processing proporcinality bettween the transforms and the fills. That's why I use huge geometry, but with small area by poly. This way I can distinguish better the small improvements.

if you don't maxout the fills, than you will have a variance within your tests, because the actual Frame Rate may vary unexpectedly if you improve the geometry transforms.
Of course, you can always ashure that you have a lot of available fill rate, by having very few polys, but then, that will make it more difficult for you to check the geometry performance, since there are so few vertexs.
It's all a matter of balance, trying to make tests with only one of the variables actually changing.

>Actually, what I use to identify bottlenecks is a good old
> profiler. gprof is very useful. :)

Profilers are good, but as in any other science, when you start measuring the experiment from within, your readings will get some kind of distortion. if the distortion relates with cache trashing, you will get a much lower frame rate then expected.

This thread contains 5 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.