[ODFAEG] (Open Source Development Framework Adapted for Every Game)

[Lolilolight]

I'm not a beginner with opengl but maybe I should check how 3D engines does for rendering effects. (Because I've never do this in 3D)

But otherwise I know opengl quite well, it's just that sometimes I don't know about which is the best technique to render different things. (Water, lighting, etc...)

There are many different way to render things with opengl. (FBO and shaders, 3D textures, cubemaps, multitexturing, PBO, etc...)

opengl is a very wide api.

But I'm pretty sure that modern api use shaders. (Except if they only need to modify vertices component, the using of VBO is certainly more appropriate)

But I'm not totally sure so it's why I need to see how a recent 3D engine proceed.

Is there a good 3D engin which is opensource like SFML

[Nexus]

Looking at existing 3D graphics engines is definitely a good idea.

There are several ones with an open-source philosophy:

• Irrlicht: Very user-friendly, you can quickly achieve a lot
• Ogre: A huge biest, quite flexible, but maybe not the best start
• CrystalSpace: I haven't used it yet, but looks interesting
• ...

[Grimshaw]

From your last post, its clearly noticeable you are a beginner with graphics in general. You might know the OpenGL API but you aren't aware of how the graphics pipeline really works as far as I can tell..

I second Nexus's suggestion, take a look in those engines, browse the internet for information... I am sure you will get it right eventually, but right now I can assure you your lack of understanding is crippling your entire framework's design.

Investigate on the GPU pipeline to better understand the process. Then you will see how using FBO or not, its all the same if done correctly, VBO or client-side arrays, its also all the same shader-wise.. Understand the pipeline and it will all make sense

[G.]

You're wrong Grimshaw, Lolilolight is one of the most experienced C++ developer in the world, it's safe to believe him when he says that he knows OpenGL quite well.

BTW Loli, did you say that your replacement for normal mapping was a displacement of vertices? If not, how does your engine do normal mapping?

[Lolilolight]

It's just an idea that I had : displacing vertices to cross semi-transparent textures between them but I have'nt tested yet.

Using vbo to do this seems to be a good idea.

But first I want to have a look at the source code of an existing 3D engine, it's not a bad thing, but, as you've said, I'm quite experienced so, I'm now able to invent my own techniques.

This is what I've always done until now. (exepts for more complicated things like cryptography because I want to be sure to have a framework which is very  securised.)

[Grimshaw]

Oh G. You are right, I bow to his superior intellect Especially with his latest post

[Lolilolight]

Lol I'm not so smart, if I use my own techniques it's because I don't understand many of existing 3D engine techniques. (So i found it smart to act like that)

Where I'm quite smart it's only in c++. (And to invent new and simpliest techniques also)

[lolz123]

But I'm pretty sure that modern api use shaders. (Except if they only need to modify vertices component, the using of VBO is certainly more appropriate)

VBO's and shaders are not replacements for one another. Like I said, I would first read a good modern OpenGL book it you really want to get into 3D engines.

Also, please turn down the arrogance a bit. Especially when so far the arrogance seems to be unfounded. Calling yourself "One of the most experienced C++ developers in the world" is pretty obnoxious. I myself have often been called arrogant, and rightfully so, but I hope that I have mended my ways.

[Tuffywub]

I don't really knows how vbo's work...

I'm not a beginner with opengl...

VBOs are an absolute MUST if you want to create a 3D engine with reasonable performance today...
Not knowing VBO's is to modern OpenGL what not knowing what objects are is to C++.

[Lolilolight]

Ok but anyway I work every day very hard to be the best.

Ok, ok, I'll check out about vbo, I've read a tutorial about vbo a long time ago but I wasn't expecting that they where so much important in a 3D engine.

All the tutorials that I've found until now was talking about shaders.

[Grimshaw]

VBO's aren't just important, they are the ONLY way to render in modern OpenGL. Either with client-side arrays or server-side arrays(VBO), its the same thing, as far as the shaders are concerned.

Also, I think you should forget that shaders vs non shaders thing. In modern OpenGL, you are forced to use shaders, its the ONLY way to do anything. That's the way to go. Plus, leaving the fixed pipeline behind will probably have no consequence for you. By the time you have a usable library, no computer or phone will not support shaders..

[Lolilolight]

Mmm..., ok I see!

I've looked in the sources of Irrlicht, and, Irrlicht uses vbo. ^^

This source code'll help me to render water, pixel per pixel lighting and shadow rendering. ^^

It'll become quite interesting. (this is pretty the only things which I've still to do to have a complete engine, with terrain generation and .obj file loading.)

[Grimshaw]

Nope, it is not the only list of things still left to do, you really have no clue xD

[Lolilolight]

Ok, if you think that. ^^

Anyway the next update'll be the final version of the ODFAEG rendering engine, which'll use vbo to update vertices object in the TileMap class, if vbo are not supported it's vertex array which'll be used.

The TileMap class'll be renamed as FrameRenderer. (Because it simply draw each faces of the current frame on the framebuffer and the depth texture)

The advantage with the odfaeg::framerenderer'll be that this rendering class'll be able to update or load each faces using the same primitive type and the same texture into a vector. (without carrying about the order on which entities'll be drawn if they have semi-alpha textures)

But your right transferring each vertices at every frame can be very heavy if I've a lot of vertices to draw, mmm..., but there is a last problem : I can't use the shader anymore because I can't draw VBO on a rendertexture!!!

No finally I think I can. ^^

So I'll combine vbo and shaders for more powerfullness. (It should optimize the trick)

Thank to you all, I'll try this.

[Lolilolight]

Ok, I've reviewed the design a bit.

-I'll add two classes :

Face (it'll contains information about vertices and textures)
Facegroup (it'll contains all vertices which use the same textures for a group of faces, because we can't bind the textures in vbo, I'll use one vbo per facegroup)
All shapes'll inherit from the face class.

FastRenderComponentManager : this class will contains usefull rendering informations like texture buffers and'll use pbo or shader to render efficiently semi-transparent objects by reading and writting on textures in a fast way.
it's also this class which'll draw all the render components.

RenderComponent : this class'll render all vertices of a facegroup object with vbo, render components can be a model, a 2D gui, a set of tiles using the same texture, etc....

EntityManager : entity manager'll know about  the render component manager and the main window, this si this class which'll regroup each faces in facegroups and which'll choose the best way to render everything on rendercomponents.

This is also this class which'll update the rendercomponents to get the current frame.

I think this design is good.

PS : I've added a function compute normals in the vertex array class.