OpenGL tips

[DJ]

I get impressive results...

[targon]

OK, if you guys really want to bother with own 3D engine I may show you list of things I'm as artist expecting from you code to do (at least, eventualy, but not _virtualy_, please!):
1) Portability.
2) Really good FPS for complex scenes.
3) HW T&L native support (in fact, it's second item), so forget about glBegin/glEnd and display lists, stick to arrays.
4) For even more complex scenes (I've seen "3000 units" somewhere), impositors or other rendering caching techniques.
5) Multitexturing support, including, but not limited to
6) Environmental cubic mapping,
7) Bump mapping,
8) Vertex/fragment shader support (for platforms really supporting it, that means any modern 3D accelerator).
9) Particle systems, with some basic "particle physics" like wind etc.
10) Some simple animation support. No need to bones, IK and other advanced features, but feel free to add some anim sequence/script/whatever you mean.
Are you ready?

[Kurilka]

Phiew...
I'm not
My thoughts:
- looks cool but:
- i don't think that we could implement (of course we can but the question of time...) such a complex engine, so if we want All these features then we should use somthing like OSG;
- what is HW T&L (i'm already getting mad from all these abbreviations)?
- do you think that all these features will be really used by designers?

[targon]

This features are't something pure eye-candy. Items 1..4 are vital for 3D strategy game (large landscapes/space scenes, lots of units etc.). 5..7 are in fact somewhat obsolete variants of 8th, but the later still is't widespread (legacy 3D cards). All bunch 5..8 is for any not-ordinary looking surface any nowdays gamer expects, why StP must be worse than commercial ones? 9th is obvious choise for dust/smoke/explosions/stars etc. 10th is nessesary even for simple mechanical units unless you want table toke look for them.
No way, you need't all these once from the beginning; but this stuff will surely very helpful in future (do you expect this game has some future?).

[Kurilka]

What is HW T&L?

[targon]

HardWare Texturing and Lighting (though someone may call it HardWare Transformation and Lighting). This is that all modern 3D cards do unless you disturb them with obsolete rendering pipeline (ab)use (like glBegin/glEnd).

[DJ]

you can still get good results if you use glBegin/glEnd, if you cull right..., although my engine does ultilize vertex arrays because that's the best way to go i think :-D

Here's the difference:

If i render, say 5,000 verts with glBegin/glEnd, on my GeForce 2 | 1.2 MHz Athlon my computer will begin slowing down at a VERY noticable speed.

If i render about 60,000 verts with vertex arrays I experience no lag at all... Big difference eh?

I tested this idea actually on my 3D Terrain Engine when implementing quadtrees.

[targon]

With arrays, 3D card (and its drivers ) may actualy upload vertex data into on-board memory (if you utilize it in clever way) and never bother about it (at lest on per-frame basis).
Vertex/fragment shaders are cool because all neat effects like refraction, grass, skinning, motion blur etc. may be disjointed from the mesh, so 3D card may stay in its rendering loop uninterupted. This is exactly the way of work all modern 3D chips were designed for. Vertex arrays (AKA "vertex buffers" in evil place far from here) plus vertex/fragment programs.

[Blake]

Well as far as I know, there is no-one on the team who has the skills to write such an engine. As such we are probably reliant on the work of other opensource projects for a decent 3D engine. Openscenegraph looks promising for sure.

The best strategy is probably to have it so the rendering can easily be changed, so initially we can use a quick 'n nasty 2D interface for testing stuff (prehaps written in straight SDL) and later change to a full featured 3D engine.

[DJ]

Yea, all models in my engine (.3ds and .md3 models), are rendered with Vertex Arrays to provide the best performance. Unfortunantely my terrain isn't optimized yet, but it runs fine and i'm not sure if i'm gonna deal with it....

[Vultur]

Originally posted by Blake
The best strategy is probably to have it so the rendering can easily be changed, so initially we can use a quick 'n nasty 2D interface for testing stuff (prehaps written in straight SDL) and later change to a full featured 3D engine.

I've tried to inizialize the screen surface with SDL_OPENGL flag, and won't accept normal blitting with SDL
The things don't fit together...

[Blake]

Yes... it says that in the documentation.

Try, instead of "SDL_OPENGL" use "SDL_OPENGLBLIT"


However the best way to do blits for small sprites (faster and better flexibility with stuff like coloring and rotation) is to convert the surface to a OpenGL texture then use it as a texture on a GL Quad.

[Vultur]

SDL_OPENGLBLIT works fine...
But I've the impression that the program cannot blit together both a SDL surface, both a GL triangle...
Maybe I've forgot to write something, but I don't know what...
I think there is a simplier way...
Thanks for the suggestions

[targon]

Originally posted by Blake
Well as far as I know, there is no-one on the team who has the skills to write such an engine.

Right. Common horror story is the Boson.