Wow, that looks absolutely amazing. Hopefully one day I will understand OpenGL enough to create something so pretty.
Peter, I saw your image on the IOTD. I don’t have to mention how good it looks or how I am impressed, don’t I ;)?
You mentioned that
... In this test there are over a thousand of each tree, plant and grassy clump. (over 3,000 foliage objects)
The cost of drawing all the foliage (in terms of frames per second) is really minimal...
- What are numbers (fps) and on what machine?
- I presume that you have some nice LOD system and that you write only sprites for distant trees, grass, plants etc?
- Also, in your world there are 3000 foliage objects, but you certainly have frustum culling so you draw some 500 of them each frame? Multyplied by some 30 polys for each tree, 2-3 for plant is around 20,000 polys without LOD, and I dont know, maybe 4-5,000 with LOD?
- Am I right or you have some other magical rendering tricks?
Thanks for your comments Hvor!
I checked out your Monstrumo site (as both our efforts are of the ‘first-person hack/slash’ variety) and it looks like you’re strides ahead at the moment in terms of NPCs (models and anims) and general gameplay. I’ve been focussed on the terrain for a good while now and although I’ve got physics and AI in the works, it’s not all rolled together yet.
So, to the questions:
There are a number of different techniques in use here and I’m working on pushing the terrain through at even faster speeds right now. On a 2.4Ghz PC with a Radeon 9550 (256Mb) it was running about 20fps for the screenie.
I’m using a semi-developed CLOD system (chunked LOD I believe) and the far plane is pushed way out for that screen shot.
Doing some tests, sending all the verts to the card for the whole terrain one by one at every frame drops the rate to about 2 fps (to be expected) wrapping the entire terrain with no LOD in a single display list draws about 20fps (no foliage) which is equally shocking.
I’ve done some tests (screenshots soon) using a mixture of quadtree-type implementation with CLOD and the terrain alone draws at around 100 fps.
Well I haven’t sat and done the maths yet but yes the foliage objects are removed using frustum culling and on average about 10% of the total foliage in the map is drawn at any one time. I should really sit and calculate this stuff soon but my first goal was get it running at a ‘kind-of-playable’ speed and then worry about performance later.
As I’ve hinted above, you’re nearly there but there are some funky tricks in the works that I’ll be boasting about soon!
Oh and all the foliage ? Currently loading one of each model onto the graphics card in a display list and then calling the display list multiple times for each bit that needs drawn. You lose a tiny bit doing all those translates, but gain a HUGE amount by having the calls preloaded on the card.
Yes, it seems that you efforts in terrain rendering are on good path. As you noticed, after I implemented simple terrain rendering, I went to draw and animate models, to round up all aspects of game into some gameplay, to add sounds and so on… So my terrain is basics, really. Currently foliage is rendered with display lists (grass) or glDrawArrays (trees). On my machine (2.0Ghz Radeon 7500) it runs with ~30 FPS, without terrain ~50 FPS.
Terrain is triangle strips, and it is 128 x 128 vertices. Every 2 vertices i test to frustum culling and to distance from camera. It is still less costly with all that calculations then to draw whole terrain (drops to ~18 FPS). I intend to do larger terrains, so I am seriously inversigating methods of LOD for terrain rendering.
I’ve done some tests (screenshots soon) using a mixture of quadtree-type implementation with CLOD and the terrain alone draws at around 100 fps.
That sounds great!
So you are doing display lists, too? I will soon try to render distant trees like sprites (1 polly), with 2-3 distance based LOD models each tree (10 - 50 - 500 polys) and see what is performance boost…
Cheers!
Seeing as how there’s some interest in the terrain and foliage in this game, I’ve posted a few new screenshots and a movie here:
http://vault101.co.uk/screenshots/
Hvor, framerate is now up to 60fps with over 9,200 foliage objects in the world (avg 400 drawn per frame)
Pete
Nice screenies and movies It’s looking very good. When do we get to play it?
Thanks! I’m hoping to get a huge test going at the start of January amongst friends : LAN + pizza + multiplayer test.
After that all going well there’ll be some kind of simple ‘hack-em-up’ level available for download. No promises though. Like most on this forum (from what I can tell) I code this when I have time.
It looks very promising! I really want to try it.
You build your trees in your code or made them in some modeling tool (which format?) By the look of them, they are code- made. When I make some models in milkshape3d and load them into game, all over graphics impression was much much better.
And I am impressed with sun effect.
So your terrain is made of chunks, how many and what size are they?
—> Like most on this forum (from what I can tell) I code this when I have time.
You are right about that 
Good luck, keep us posted, and yes, your web page look great too!
The trees were thrown together at very high speed in Milkshape 3D, and I’m using the ms3d format at the moment. The number of terrain chunks in a level is completely customisable and a lot of pre-processing work takes place as the level is being loaded. In these shots there are 256 chunks each 32x32 tiles in size. So that’s 16x16 chunks covering a 512x512 tile area.
I’m trying to find out what works best - lots of small chunks or a fair number of medium sized ones.
Well that is the answer I want to know, too. I hope that you will write your conclusion here…
I’m curious… Do you load your height data (for terrain) in some sort of heightmap? That is, 512x512 texture divided in 16x16 pieces? That is my idea how to start to handle that part of my engine…
Any (2^n +1) x (2^n +1) heightmap will do - the ‘chunking’ is all done automatically. It’s +1 to each dimension so that I still have 2^n x 2^n tiles.
I use chunks of 33x33 for a 513x513 heightmap with geomipmapping - meaning five detail levels (33x33, 17x17, 9x9, 5x5, 3x3), but the problem is, that the chunk size heavily depends on the type and scale of terrain you want to model (soft hills vs. rocky mountains). I fear such settings need to be “hand-tuned” for each location of a game.
That’s exactly what I’m running with just now - 32x32 tiles in each chunk made up of 33x33 verts. Only I’ve got 3 details levels at the moment, not 5.
I am planning to rise the number of detail-levels even more by providing detail meshes per quad node, this way I get more flexibility regarding the terrain type and chunk-size.
If I understand you correctly isn’t that going to take up a LOT more memory?
No not really, since a lower detail level only needs a 4th of vertices than the next higher level. The way I plan to do it needs the double amount of vertices than the original vertex data at maximum.
I fear that memory consuming will be heavier then you predict. And you are right, I think that some locations in game will have to be “hand-tuned”.
Cylab’s right. Example: 16x16 = 256 verts for the full detail mesh, plus 128+64+32+16+8+4+2+1 = 255 verts for the detail levels.
That gives 511 vertices for the full detail mesh plus all the detail levels. Nice one!
Ahh… :-[
Seriously, nice approach!
It’s even better ;D
16x16=256 full detail, 8x8=64(!) half detail, so you end up
256+64+16+4+1= 341 vertices for all levels (including full detail)
To be correct it has to be 17x17 + 9x9 etc., but powers of 2 are easier to think of
Also you will need some extra vetices for gap filling and such…