yup, another terrain renderer, but this time with (basic) geomipmapping ! - controls: up, down, left, right, home, end, pageup, pagedown, shift (faster forward motion), w (toggle wireframe mode) - no collision detection yet ... - the code is totally unoptimized and quite frankly very ugly if you stay in windowed mode, you can see the fps in the titlebar (the rest is irrelevant). If anyone could give me some numbers (ie the fps at the beginning) I would be very happy. click here Viva la Révoluçion !

Nice !

Config :
Athlon 1G2 (256Mo Ram)
Geforce 2 Ti 64Mo

FPS = 60 at startup window
FPS = 36 if windowed to 1280x960

Nice work, ran well under Linix with Wine!
Lowest about fps 40 and 60-80 very common on GF2MX400 AMD Tbird 1GHz
edit: 53fps in the beginning.

-----------
RacingTreme - for fun multiplayer racing:
http://users.utu.fi/stkibr
Coming soon...

[edited by - stefu on September 6, 2002 11:17:47 AM]

I got about 150-200 fps on my AMD XP 1800+ with Radeon 8500. Good work, looks great and runs smooth on my machine.

quite impressive.
the tirangle/sec rate is pretty nice.

you can boost it further if you optimize for the vertex cache (I got around 40% boost from doing this to a terrain renderer - so don''t underestimate it).

is that using multitexturing, because it almost feels like it''s using multi-pass.... but ohh well


<-- smile

quote:

---

Original post by RipTorn
quite impressive.
the tirangle/sec rate is pretty nice.
you can boost it further if you optimize for the vertex cache (I got around 40% boost from doing this to a terrain renderer - so don''t underestimate it).

---

Please excuse for this kinda''an offtopic question but ...vertex cache ? What is this ? where can i find something about this ?

moromete

quote:

---

Original post by RipTorn
quite impressive.
the tirangle/sec rate is pretty nice.

you can boost it further if you optimize for the vertex cache (I got around 40% boost from doing this to a terrain renderer - so don''t underestimate it).

is that using multitexturing, because it almost feels like it''s using multi-pass.... but ohh well


<-- smile

---

Thanks for the compliments everyone .

The triangle/sec count isn''t accurate, it''s without taking account of the LOD.

It is using multitexture, although I get a sort of graininess/distortion of the textures when I go too close to the terrain, and I don''t know why (I haven''t seen it in other terrain engines or at least not as bad).

What exactly do you mean with "optimizing for the vertex cache"?

Viva la Révoluçion !

Well, very good job! I liked very much your engine!
It needs collision detection and 3d movement, not just front back.Also needs mouse interaction.

Looks sweet! What did you use to make the skin and texture for the terrain?

pretty much all good T&L video cards have a vertex cache. My geforce 1 has a cache of 16 verticies, but apparently is only effective to 10.
It means as a vertex is indexed when rendering, it''s position on screen, colour, etc, is cached. Since this cache is 10 verticies long, if that vertex is indexed again within the next 10, you get a massive boost, as it pretty much will bypass the t&l unit, and just go straight to the cached data.
A simple way to optimize for this, for example, is if you have one huge uniform mesh... eg, 256x256 verticies...
Now, you would likly render it by making 256, 512 vertex long, triangle strips that go right across the mesh. (using drawElements of course), BUT, if you were to draw them in the opposite direction in blocks of 10 verticies (6 triangles) you will make full use of the vertex cache, and the next strip (which is across one, not up) will only have to calculate 5 of the 10 verticies. And again for the next. Overall, on the entire mesh, you reduce the number of verticies you transform by just marginally below 40%. Which, I found, equated to around 35% faster frame rate.
In on of my recent terrain renderers, I did this, Combined with VertexArrayRange, I managed to push 9.5 million tris/sec. Where with straigh strips, without VAR, I was getting around 2.5. over 3x the performance. (there was also some state change reduction in there too, but that wasn''t as significant)
The point is, basically, you do more to do less.

<-- smile :-)