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

Submitted by Brebion flavien, posted on May 18, 2001

Image Description, by Brebion flavien

These are screenshots from my 3d MMORPG engine. They were taken on a P2-400 with a GeForce. I tried to show a few interesting effects, such as true volumetric clouds and detail objects (grass) on the ground. The performance is rather low due to many factors: no LOD (this will be my next big task), true 3d meshes for everything (including the landscape), on-the-fly computed soft shadows (look the mountains and the house; the sun can be moved), and mostly, everything is dynamic (vertex buffers are refilled every time). The application is CPU limited.

The sky and grass are animated. I tried to not abuse of the lensflare effect, which can be disabled by users anyway. There is also the usual stuff (particles, 3d sound, procedural terrain textures, detail textures, collision detection, frustum culling, 3ds importer, shaders, state groups, etc..). I am sorry for the poor quality of the models/colors/textures used -i'm definately not an artist-.

I am seeking a job in the game industry in France. If you are interested, or know someone that could be, feel free to drop me a mail. I'll release a public demo in a few days.


F. Brebion

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

May 18, 2001, 06:19 PM

Agreed, stalling the pipeline will probably be much better than the speed hit from raycasting (including any raycasting you do against non terrain objects ;)

Mike Taylor

May 18, 2001, 07:05 PM

I've been tracing rays to the sun in several places in my engine. It really doesn't hurt you unless you bump it against EVERY poly in the world. Use a hierarchical scheme and store the maximum height of each nose of the tree (I am using a quadtree-like algo, so this is easy). Then tracing the ray is just a matter of walking the tree and checking the height of the ray against the height of the terrain node's maximum height at each node. Works for me, may not work for everyone...



May 18, 2001, 07:15 PM

Does it also check for trees and building that might occlude the sun?

Not to mention grass... ;)


May 18, 2001, 07:30 PM

I like. The top left scene (with that pillar type thing) reminds me of part of Ultima 9, so if your engine can do it at all you've already got one proffesional (ha!) engine almost squarely beaten.

The on the fly soft shadows are cool, but are you recomputing them all the time or saving yourself the work and only doing it every now and again when needed? (in which case, going off on a tangent, you might as well do some nice time slicing to help with other things like AI etc).

Animated grass sounds very funky though. I've been considering something like that with splines given stiffness and weighting, then a lot of calculus beforehand, followed by some simplified recursive application of forces (like wind) to the far end of the splines (although that's mainly an idea for a tree, not grass, which wouldn't need to be that complicated. The only thing that I can think of in your images is that you might want to vary the colour of your grass a little.
Another thing worth mentioning is your clouds - do they cast shadows on the ground? they certainly look really good from the views we can see here, and I was dissapointed with the ones in B&W.

Very nice work. I'll be suprised if we don't see you in the credits of a game within the next few years.


May 18, 2001, 07:44 PM

Reading the zbuffer from a graphics card is very slow. The fact that you only need 1 pixel from it has no effect on it.


May 18, 2001, 07:59 PM

Seems to be great, I just want to see it in motion. It would be cool if you manage to get a job.

Ca le fait :)


May 18, 2001, 08:00 PM

What is 'very slow'? If a floating point multiplication on a PC takes 100 nanoseconds, then that PC is 'very slow', but if this was the time needed for reading a value from the z-buffer...

The elegance, simplicity and precision are already reason enough for me to avoid casting a ray, even if it's a bit slower (which I doubt).



zed zeek

May 18, 2001, 08:04 PM

excellant work. like everyone else i luv the grass. im guessing its hundreds of blending polygons + not the normal detail texture technique. looks excellant (must kill frame rate though?) the atmosphere looks very similar to what im doing aaargggh competition :)

zed zeek

May 18, 2001, 08:30 PM

i do sort of the same thing ie run a line segment through my scenegraph finding out all the nodes it passes through then test all the polygons in the nodes for a test. incredibly quick , u might even say it takes no time :). yes it works for everything the landscape,trees, building etc.


May 18, 2001, 08:35 PM

Thanks for all of the info. I'll run speed tests with reading from OpenGL. My hypothesis is that it will be slow, but this should be tested.

Getting correct results when inside of a building is very important to me. If the depth buffer can't be read efficiently, I'll try ray casting on the terrain and then testing against objects. A ray-bounding sphere test takes about 200 cycles, so I should be able to test against a thousand objects or so.



May 18, 2001, 09:14 PM

'very slow' is causing a pipeline stall, ruining parallelism. Reading the zbuffer requires the card to flush all remaining operations in the queue before it can send the zbuffer across the bus. During that time the cpu is idle.

Most terrain engines use a hierarchial structure of some sort, which lends itself very nicely to speeding up ray casting(see Mike Taylor's response above). You can also store information about the horizon within each node, and that can be used for occulsion culling too.

There are also other uses for quick ray casting(item picking, enemy LoS, and projectile impact points spring immediately to mind).


Brebion flavien

May 18, 2001, 09:36 PM

Wow, i really didn't expect so many replies in a so short time. Thanks everybody for your kind comments :)

I'll try to answer each question in order:

1) It is true that textures are blurry, that's because i use a low-res procedural texture for the terrain ( 768x768 i think in the shots ) with a somewhat bad detail texture (true that you almost don't see it). Colors also definately need more work but well..

2) About performance: the fps is displayed in the top transparent rectangle (left number). The number of tris displayed in the scene is the number in brackets on the right end. I am pushing around 300k to 700k tris per second, but as i said, it's not really geometry limited so this number doesn't mean a lot.

3) Lens-flare: i cast a ray from the sun to the viewer to see it is occluded or not. Not very hard, i already had the ray-casting functions working before, when i implemented lightmapping ( not shown in the shots ). Ray-casting uses spatial subdivision ( octree ) and spatial coherence ( two rays that have similar directions likely hit the same object ), so it's pretty fast. I almost had real-time ( 5 fps ) lightmapping ( recalculating the lightmaps every time ) in a 2000 tris scene with this technic.

4) Shadows: use a per-vertex ray-casting technic ( yes, i use ray-casting everywhere :p ). They are cached to avoid to be recalculated when useless.

5) Grass.. seems to be very popular. Technically, it is just a very high number of alpha-blended objects. I use a standard "cross" (4 tris) object, but it doesn't look very good when seen from the top, so i'm opened to any idea..

Grass does receive shadows too. It is all the same texture and same color everywhere. The grass object is placed in concordance with the normal of the terrain; there is no grass on high slopes. The wind vector is calculated per terrain face. Grass objects all wave with some time difference to avoid repetitive patterns, though objects in the same area move the same way to make it more realistic.

The nice thing with grass (and the technic is not restricted to *only* grass -i'll extend it to rocks, plants, etc..-) is that it takes no memory at all and not even a single CPU instruction for grass that is "far". The distance is settable in the engine's config. To avoid any popping artifact, grass slowly becomes transparent when it goes far away. The major bottleneck is not the calculations or the rendering, but simply the distance sort (though i use qsort).

6) About clouds: no, they don't cast shadows to the ground. Actually i had it in en old version, but it was a fillrate eater. I'll probably put it back later for top-end systems.

What a long reply :)

F. Brebion

Mark Friedenbach

May 18, 2001, 09:40 PM

'very slow' is causing a pipeline stall, ruining parallelism

There is no parallelism going on!

At this point in the cycle the entire scene has been rendered, with the exception of some post-processing effects such as this. The 3d card isn't doing anything.


May 18, 2001, 09:51 PM

It's not too uncommon to have the 3d card lagging behind your game engine, the drivers will keep buffers so that it's possible to be rendering a frame or two ahead of what the card's drawing. That way the card gives you a bit of extra CPU time for whatever else you might need it for. If you force a flush by reading the z-buffer(or reading anything), you kill that render-ahead stuff, slowing down the application.


Eric Undersander

May 18, 2001, 10:41 PM

With D3D, there is a way to get (from hw) the count of the number of pixels that have been rendered over a specified period. To determine if your lens flare is visible, you could render a tiny polygon at your sun's screen position (of course you don't want this "test" polygon to display; either have color write disabled, or render between the frame flip and the frame clear).

Note: This feature was in the DirectX SDK for XBox (a.k.a. XDK). I don't have the XDK at hand just now, and for the life of me I can't remember the function names... anyway, it may be that the feature isn't available for DirectX 8 PC.


May 18, 2001, 11:01 PM

Sigh. When you send a command to the API, it is put in a queue. This queue then sends commands to the graphics card.

The only commands that cannot be queued are those that need to read data back from the card(like a zbuffer read). These require a queue to flush all commands, it has to wait for the card to finish performing those commands, so the cpu and card are in sync.

Every other command is queued, including swapbuffers/present. Its not uncommon for the driver to buffer several frames.

And you're right, the 3d card isn't doing anything, when you've killed parallelism! If you hadn't read from that zbuffer, it could be working on the next frame that's in the queue.

Mark Friedenbach

May 18, 2001, 11:50 PM

Do you have any idea how big a buffer would have to be queue an entire frame, let alone three or four? Sorry to burst your bubble, but drivers don't really do that. They usually only store at max maybe 15-20 commands at a time (and these 15-20 commands are then done in parallel [if possible]).

Mark Friedenbach

May 19, 2001, 12:07 AM

That way the card gives you a bit of extra CPU time for whatever else you might need it for.

Nope. Think about what you just said. If a command is buffered, that just means that it has been put on hold to be processed at a later point in time. The time it takes to process commands given to the driver does not just magically disappear once they're put in buffers.

Lots of commands in the buffer means more CPU time will eventually to be eaten up by the driver.


May 19, 2001, 04:46 AM

Could someone please test this so we don't start a flame war? Thanks.

If cards, drivers and API's are that slow, then we better all start writing software engines again. I mean, how can you develop new HSD algortihms if you can't even read fast from the z-buffer? I believe this is one of the many reasons why software engines aren't dead yet...

How can you possibly compute a few frames ahead? This would create very unnatural movement since everyting is rendered much too late. Even if you compute 1 frame ahead, the GPU always has to follow the CPU at the same speed, so somehow they have to be syncronised.




May 19, 2001, 05:26 AM

Hey! ultima 9 was very professional it used all the power it could(and more), not all engines do that.

Kasper Fauerby

May 19, 2001, 06:36 AM

Here is another way of doing real-time grass that one of the artists on my team brought to my attention. It's actually quite simple and can produce quite good results - but in this case ONLY when seen from above (or at least from some height).

Before I explain it, take a look at this small test we put together:

(and before you ask - that black thing is the legs of an emu standing in the grass ;)

The whole grass patch is something like 100 triangles in total!

The idea is to place a bunch of parallel planes - in this case I think there are 50 planes - and texture each plane with a texture consisting of green dots where you want a straw. To animate the grass you simply move the planes relative to each other. This means you can easily make the grass move after a given wind-vector if you want. The downside is that all straws in a patch move at the same time, but I actually think this is also the case if you looked at some high grass in the RealWorld(tm).

This test is fairly bad looking because of two thing.
1) It uses the same texture for all planes. This is because the texture was made by hand. Instead they should be auto-generated and each plane would have a different texture where the size and color of the dots varies to make the straw thinner and darker near the top. In the higher layers certain dots can be left out to make some variation in the height of the straws.
2) The animation is linear and boring.

Hope this helps someone ;)

Keep on codin'
Kasper Fauerby (aka. Telemachos)


May 19, 2001, 08:13 AM

Hey, cool engine you've got there. You say you're using alpha blending and a qsort for the grass, have you thought about disabling alpha blending and using alpha testing instead? The results probably won't look quite as good, but it might be a lot faster. To render the trees in my engine, I use:

glAlphaFunc(GL_GREATER, 0.5f);


Alexander Stockinger

May 19, 2001, 08:43 AM

Maybe I'm just stupid, but how do you read from a z-buffer on a Kyro?


May 19, 2001, 08:54 AM

what exactly does LOD mean?


May 19, 2001, 08:58 AM

Heheh. yeah, I'm going to buy a 2Ghz machine with 768 Mb ram and a R400 then see if it will run on that. Somehow, I almost doubt it - the engine is that powerful (at bringing thing to their knees).


May 19, 2001, 09:05 AM

Hmm. You can go slightly more flexible there (if I understood correctly what you said...) perhaps if with the grass you took 2 splines like I described above, then linked them with polygons depending on the distance and the curvature. If you put in some wind dynamics (perhaps some sort of noise function changing over time?) you should have grass that's viewable from any angle... with the polygon budgets possible today you could probably make it very pretty and convincing. I wouldn't go out and try and render a field of wheat unless you absolutely had to, but it might work.

Tobias Franke

May 19, 2001, 09:14 AM

LOD is for 'Level Of Detail'. LOD's are used to chop down poly's that don't really contribute visually to the final scene (i.e. mosaic window of a chruch 500m away).

The Wolf

May 19, 2001, 09:24 AM

I love the grass, top quality work, which LOD scheme are you planning to use?


May 19, 2001, 09:27 AM

The frame rate in the lower screen shot says 11 fps. But whether that's an average...

Lars Birkemose

May 19, 2001, 10:36 AM

I was wondering..
If your CPU limited, how will LOD improve FPS ?
My understanding is that LOD will _increase_ CPU load (In theory not including DX8 PMeshes).


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