OpenGL 3.x - Early preview stage avaiable

Nadro · Post by **Nadro** » Thu Sep 24, 2009 7:42 pm

Nox wrote:Every single vertex is allocated dynamically. I think this is not really practicable. By the way can this solution be used for the fixed function pipeline and how to set the vertex decl fo the driver?

And i dont get BlindSides idea. Why should a flexible vertex format similiar to the dx solution be bad?

Why You think, that it isn't practicable? I think that it's more safely solution (one vertex type per mesh buffer with const offset) and it offer all useful features for user.

BTW. What with IVertexBuffer and IIndexBuffer?

Nox · Post by **Nox** » Fri Sep 25, 2009 9:26 am

Well if i get you right a buffer for a 1000 vertices model would need at least 1000 calls of the new operator. Is that correct?

Dorth · Post by **Dorth** » Fri Sep 25, 2009 9:41 am

I think he meant one vertice model per mesh buffer, so that 1000 vertices might be split between 2-3 mesh buffer. And if not, guess we have new[]

Nadro · Post by **Nadro** » Fri Sep 25, 2009 1:02 pm

Nox wrote:Well if i get you right a buffer for a 1000 vertices model would need at least 1000 calls of the new operator. Is that correct?

Yes, but it isn't a problem, because it's done on the mesh loader step, in places where we now add new S3DVertex. But for this solution I don't see place for IVertexBuffer...

Nox · Post by **Nox** » Fri Sep 25, 2009 5:15 pm

Well loading time is a matter and you have to keep in mind that the OS save some hiden information for each new. This results in the fact that new int[1000] consums less memory than 1000 times new int. Its not that much but the disadvantages of many new calls sum up. By the way your MeshBuffer looks like a possible IVertexBuffer canditate to me

, doesnt it?

Nadro · Post by **Nadro** » Fri Sep 25, 2009 5:59 pm

Yes, thats true but it's still more memory friendly than vertex format with static allocated all atributes similar to S3DVertex structure. I'm also interesting dev team opinion about this solution, because existing vertex format is really crap

If it's bad solution someone other should put Your code here.

sio2 · Post by **sio2** » Fri Sep 25, 2009 6:49 pm

Nadro is getting closer, but I still don't like the implementation. It seems restrictive: I need halfs, DWORD weights 2d/3d/4d texcoords, etc - in other words I want control over the buffer I create. I want hardware skinning and hardware instancing which needs more control over buffer I believe.

We are also missing new draw calls and stream handling and code for things like the geometry creators. I also need it so I can easily code up support for my DX11 driver.

I have a Cal3D hardware skinning demo almost finished - it's just waiting for my new buffer code. I'll code this up ASAP and so how a generic buffer API would fit in with a real app.

Plus, as Nadro says, *anyone* here can have a go at writing this themself. At least Nadro is having a go!

Nadro · Post by **Nadro** » Fri Sep 25, 2009 7:37 pm

Thanks Sio for interesting this problem, Instancing and Hardware Skinning are very important. I don't know how will be role current IIndexBuffer and IVertexBuffer in dev team vision, but maybe we can use this classes as constructor parameters for simply mesh buffer? so what we can do?

a) IVertex->IVertexBuffer->IMeshBuffer
or
b) IVertexBuffer->IMeshBuffer (I preffer this option)

In my current code we have got only IMeshBuffer class, but we should speatare it on 2 classes (option 'b') or more (option 'a')

What should be size of simple vertex? static as in current Irrlicht solution or dynamic as in my solution.

What of attribure parameters we should make avaiable for user control. Type and Stream (as in my solution) or maybe also other eg: Size etc.

In solution 'a' we can use different vertex types in VertexBuffer, so it's potentially more dangerous solution than 'b' where we can use only one vertex type in Vertex Buffer, but in solution 'a' we can optionally add control vertex type mechanism for make this solution more safely. Where we will manage attributes (on vertex level or on Vertex Buffer level) is depend on which solution we will choice.

It will be good, when we will get more support for this problem from dev team, because now I think that this is important topic for me, Nox and Sio2 (but I hope that I'm wrong

)

hybrid · Post by **hybrid** » Mon Sep 28, 2009 7:47 pm

new[] discussion moved to http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=35244

MarcoTMP · Post by **MarcoTMP** » Mon Nov 30, 2009 6:07 am

Hi guys, are you still working on this?

Nadro · Post by **Nadro** » Mon Nov 30, 2009 3:12 pm

You mean about OpenGL 3.x Forward Compatible? Yes, it should will be avaiable in January 2010.

wowdevver24 · Post by **wowdevver24** » Thu Jan 07, 2010 10:37 am

any updates on this???

Nadro · Post by **Nadro** » Mon Apr 05, 2010 10:48 pm

Sorry for my delay, but in last 4 months I had many other work :/ When Buggy Race was released I can back for this project (now this is my primary project). I will release preview version as soon as it will be possible. Currently I rewrited some draw operations eg (drawMeshBuffer, draw2DImage), replaced gl.h with existing Irrlicht extension handler by gl3.h and new extension handler (OGL 3.2 core functions), rebuilded 2D and 3D rendering states and many others things, but now I have question for dev team. I think that we should create one standard material (optionally clone it for each EMT_* for some compatibility existing apps) and make this driver more programmable (my current driver version is working in this way) eg. for Alpha we need:

Code: Select all

ND->setMaterialType((E_MATERIAL_TYPE)MyMaterial); // basic material is EMT_ONETEXTURE_BLEND
ND->getMaterial(0).MaterialTypeParam = pack_texureBlendFunc(EBF_SRC_ALPHA, EBF_ONE_MINUS_SRC_ALPHA, EMFN_MODULATE_1X );

I think, that for smaller projects user can stay with GL ver < 3.0, and use new 3.x driver only for more advenced projects if it will be required, so we needn't prepare too much useless built-in stuff, which will be used only in Hello World apps... We need only inform (in documentation) user how to get access to lights data etc, but shader for lighting he/she should write manually.

Because GL3.x hardware = DX 10.0+ hardware, we needn't 'queryFeature' or '#ifdef' for GL 3.0, 3.1, 3.2, 3.3 etc... I think, that we should driver up to the latest OpenGL version (currently 3.2, because 3.3 isn't avaiable in official, stable NV/ATI drivers)

What do You think about this idea?

Here screenshot (Animated Mesh + draw2dImage) with current Irrlicht OGL 3.2 (Core Profile) driver on ATI Radeon 2600 Pro (AGP):

hybrid · Post by **hybrid** » Tue Apr 06, 2010 9:00 pm

I don't exactly understand what you mean. But even with OpenGL 3.3/4.0 you still have extensions and stuff. There's no way to avoid it.

Nadro · Post by **Nadro** » Tue Apr 06, 2010 9:40 pm

But we have also Core profile, so we needn'e check for each extension individually (only in extreme situations, eg tesselation in Radeons HD2xxx-HD4xxx) so we can request the latest OGL context and use core functions without check queryFeature for mostly functions.