Irrlicht Engines Graphical limitations?

BlindSide · Post by **BlindSide** » Sun Jul 01, 2007 1:05 am

monkeycracks wrote:They're going to have shaders instead of food eventually.
-.-

Lol its ok monkey, Im sure you would've upgraded by then...

Spintz · Post by **Spintz** » Wed Jul 18, 2007 3:01 pm

GameDude · Post by **GameDude** » Thu Jul 19, 2007 5:02 pm

Do you think Irrlicht will allow for that in future updates? Since the Irrlicht is meant to be a graphic engine, wouldn't the developers try to increase its graphical capabilities? Those are just my thoughts, I don't know if they'll really do it.

hybrid · Post by **hybrid** » Thu Jul 19, 2007 7:27 pm

Yes, it will eventually do support GPU vertex buffers.

GameDude · Post by **GameDude** » Thu Jul 19, 2007 7:32 pm

That's cool.

hybrid · Post by **hybrid** » Thu Jul 19, 2007 7:37 pm

We always said we will add these features, it's basically a question of the API. I'd like to provide these features in an almost transparent way. No need to think about which mesh will go into a vertex buffer object.

zet.dp.ua · Post by **zet.dp.ua** » Fri Jul 20, 2007 5:14 am

are there any plans about implementing hardware buffers?
gpu buffers suppot is really needed at least for static objects.
we have chosen TGE for our 3d game because of perfomance issue.
as for me, irrlicht design is rather good for casual game development
if you need help in implementing i can help.

hybrid · Post by **hybrid** » Fri Jul 20, 2007 9:24 am

The question is how to hide the various implementations of hardware buffers together with their attributes behind a simple and intuitive API. I don't think that it is a good idea to make people call several functions such as 'useHardwareBuffer', 'updateVertexBuffer' etc. This brings too much implementation to the user level. If these functions are accessible by the user it's ok, but the basic feature should be almost transparent to the user.

zet.dp.ua · Post by **zet.dp.ua** » Fri Jul 20, 2007 11:51 am

How then were hidden various texture implementations?
I see no problem, everything is already hidden from user.

As for functions such as 'useHardwareBuffer', 'updateVertexBuffer':
it would be nice if device supports a flag "useHardwareBuffer",
anyway if user modify buffer data manually, he know that he's doing.
we can synchronize hardware buffers after call of func like "updateVertexBuffer"

e.g. we use lock unlock to modify texture data, it would be better if IMeshBuffer interface supports lockVertexBuffer(), unlockVertexBuffer and... to do any modifications; getVertices() updateVertices() pair can do the same.

Also it is possible to implement IMeshBuffer for drivers and do appropriate work in driver->drawMeshBuffer(mb);

CMeshSceneNode, CWaterSurfaceSceneNode, CQuake3ShaderSceneNode uses drawMeshBuffer for rendering, CTerrainSceneNode also can use drawMeshBuffer with minimal changes, COctTreeSceneNode needs some work.

BlindSide · Post by **BlindSide** » Fri Jul 20, 2007 11:57 am

hybrid wrote:The question is how to hide the various implementations of hardware buffers together with their attributes behind a simple and intuitive API. I don't think that it is a good idea to make people call several functions such as 'useHardwareBuffer', 'updateVertexBuffer' etc. This brings too much implementation to the user level. If these functions are accessible by the user it's ok, but the basic feature should be almost transparent to the user.

Omaremads' implementation of OpenGL display lists was done really well from an interface standpoint I think. You just grab the mesh buffer and do meshbuffer.DisplayList = true;.

omaremad · Post by **omaremad** » Fri Jul 20, 2007 7:27 pm

For abstraction irrlicht should add a static mesh type, that way the user tells irrlicht what is required of the mesh but has to know nothing about whats isnide the driver classes. We cant do evrything for the user, if a user is serious about performance im sure they dont mind decalring their meshes as say IStaticMesh rather than IMesh

zet.dp.ua · Post by **zet.dp.ua** » Sat Jul 21, 2007 5:58 am

Implementing hardware vertex/index buffers ideally should be done in the same way as device-depended textures are implemented, but this is a lot of work.

What about extending IMeshBuffer interface?
Device-depended IHVertexBuffer, IHIndexBuffer can be added
While doing drawMeshBuffer(mb) device can check if HBuffers present and do appropriate call
IMeshBuffer should have "uploadToDevice" function.

If user wants to modify any data, he should call lock/unlock pair, but IMeshBuffer has only lock func (getVert...).

Code: Select all

class IMeshBuffer ...
{
...
  IHVertexBuffer* getHVertexBuffer();
  IHIndexBuffer * getHIndexBuffer();
  bool uploadHBuffers(device);
...
}; 

CNullDriver::drawMeshBuffer(mb)
{
  if (mb->getHVertexBuffer() && mb->getHIndexBuffer())
 {
   drawHMeshBuffer(mb);
   return;
 }
drawVertexPrimitiveList(mb->getVertices(), mb->getVertexCount(), mb->getIndices(), mb->getIndexCount()/3, mb->getVertexType(), scene::EPT_TRIANGLES);
}

BlindSide · Post by **BlindSide** » Sat Jul 21, 2007 1:19 pm

omaremad wrote:For abstraction irrlicht should add a static mesh type, that way the user tells irrlicht what is required of the mesh but has to know nothing about whats isnide the driver classes. We cant do evrything for the user, if a user is serious about performance im sure they dont mind decalring their meshes as say IStaticMesh rather than IMesh

Thats a bit restricting. You see openGL has these VertexArrays right? and what you can do is you can ->lock(); them, and after the point they are locked u cannot modfy them and they are considered static. They are also cached for every frame after than until you unlock them.

This idea is less restricting then making a mesh permanently static because of its type. Instead, similar to the Irrlicht texture->lock/unlock methodology where you unlock textures in order to modify them, we should do the exact same for meshes.

Cheers

EDIT: Oh looks like zet.dp.ua beat me to it. Smart guy

(I hope this means its a good idea kuz like they say "Great minds think alike" hahaha)

omar shaaban · Post by **omar shaaban** » Sat Jul 21, 2007 3:59 pm

kburkhart84 wrote:I'm surprised that IrrSpintz hasn't mentioned this here, but he has got DX10 working in IrrSpintz, so it is definetly possible. It's just not too usable yet anyway since most people still don't have the hardware.

Direct x 10 is buggy and if u download it or get it with vista u will find that it will run so bad and with many errors and will take time untill it is fully compatible

zet.dp.ua · Post by **zet.dp.ua** » Sat Jul 21, 2007 4:46 pm

BlindSide wrote: This idea is less restricting then making a mesh permanently static because of its type. Instead, similar to the Irrlicht texture->lock/unlock methodology where you unlock textures in order to modify them, we should do the exact same for meshes.

Exactly, i also think so after reviewing rendering code blocks.
IMeshBuffer::getVertices()/getIndices() funcs give direct access to data.
"Unlock"-like function should be added to update HW buffers.

From my point of view (i'm newbee to Irrlicht),
only one way to implement HW buffers support without breaking semantic of getVertices()/getIndices() is adding some update function which should be called automatically by mesh loaders or by user after buffer was changed.

What are Irrlicht's developers thinking about it?