considering using irrlicht, and game/engine design.
Posted: Mon May 26, 2008 11:30 am
Hello
I'm new to the forum and to Irrlicht engine, for quite some time I've been considering dropping my own 3D engine, which I don't have tine to keep up to date anymore, adopt a 3rd party 3d engine and focus on what I really want: make games and not 3D engines.
For some time, I've been evaluating several 3D engines around, and I had to discard all of them for one reason or another.
It happens that I have one game which is half finished... one of the design requirements I choose was to not be tied to any rendering engine; that means that I can run the game logic without even linking to a 3D engine, but also means the game implements its own scene graph and its own internal gui system, actually, everything it needs to run the logic. The rendering is done using some abstract interfaces that the 3d engine should implement.
In other words, I use a "game centric" approach, in which the engine should adapt itself to the game, as opposed to the classic "engine centric" approach in which the game had to adapt to the 3d engine.
And now lies the problem of most 3D engines... which are "engine centric", and provide their own scene graphs and gui systems and everything, and there's no way to use them other than to adapt the game to their scenegraphs and guis, and everything... tying to life of the game, to the life of that particular 3d engine.
This weekend I gave Irrlicht (1.4) a try and these are the initial conclusions I got (please, take them as my personal opinion)
The first impression was very good: the whole codebase is very clean and very well structured, and it was nice to see that it has abstract interfaces at many levels, to make custom implementations. I definitely liked the fact that it is very easy to add custom mesh loaders.
I liked even more the fact that the video driver is readily accessible, not like other 3D engines which hide it deep into the structures. At this point, Irrlicht looked very promising, because since my game code already implements a scenegraph, I only need a low level interface to do the rendering.
About this, I have a request to all 3d engine designers worldwide: It is good to provide a scenegraph as an extra feature, but a few of us want driver level access!!
But as I browsed the source code, and reached the actual implementation, I found that the drivers were using the DrawPrimitiveUp rendering DX functions, which are very easy to use, but horribly slow. At exactly that point I understood why irrlicht is so clean... it comes at the cost of speed, and I decided to drop irrlicht as a candidate.
Today, I decided to take a last look before moving forward, and found some posts saying that for irrlicht 1.5, changes are being done to actually support vertex buffers and true hardware rendering, and my hopes for irrlicht have been renewed.
Now, I did not have the chance to see version 1.5, and I don't know at which stage it is, so I'm a bit blind here, but from my own experience with my engine, and seeing how irrlicht is designed, I see a big conflict here: irrlicht meshes can be easily changed, while a true hardware mesh buffer needs not to be changed to be fast.
If I had the responsibility of updating the drivers of irrlicht, this is what I would do:
leave all the "drawVertexIndex_" calls in the driver, but, instead of calling drawindexedprimitiveUp, use dynamic hardware buffers; Dynamic buffers have two advantages over normal buffers: if the video card is currently rendering the dynamic buffer, and you unlock it to refill it with new vertices, it automatically creates a hidden copy, and that's what you fill while the hardware is still rendering the other one. And for data transfer to GPU, it tries to use things like AGP memory if they exist, so sometimes, the GPU can use the buffers directly, without having to do any data transfer, so they're way faster than UP calls, but still not as fast as a true static buffer in the GPU.
And, for static meshes, I would create a driver level mesh class, only for static objects (maybe also for skinned objects), that could only be rendered with a call like DrawStaticMesh( ... ) , this driver hardware mesh should be so abstract that the people using it should not even know of what it is composed of: vertex/index buffers, voxels, startrek like quantum particles... the implementation is up to the driver, and the user should expect that updating it would be very costly, and only done at startup time.
I have not decided yet whether to use irrlicht or not, but I'll be looking forward for the development of this issue...
cheers
I'm new to the forum and to Irrlicht engine, for quite some time I've been considering dropping my own 3D engine, which I don't have tine to keep up to date anymore, adopt a 3rd party 3d engine and focus on what I really want: make games and not 3D engines.
For some time, I've been evaluating several 3D engines around, and I had to discard all of them for one reason or another.
It happens that I have one game which is half finished... one of the design requirements I choose was to not be tied to any rendering engine; that means that I can run the game logic without even linking to a 3D engine, but also means the game implements its own scene graph and its own internal gui system, actually, everything it needs to run the logic. The rendering is done using some abstract interfaces that the 3d engine should implement.
In other words, I use a "game centric" approach, in which the engine should adapt itself to the game, as opposed to the classic "engine centric" approach in which the game had to adapt to the 3d engine.
And now lies the problem of most 3D engines... which are "engine centric", and provide their own scene graphs and gui systems and everything, and there's no way to use them other than to adapt the game to their scenegraphs and guis, and everything... tying to life of the game, to the life of that particular 3d engine.
This weekend I gave Irrlicht (1.4) a try and these are the initial conclusions I got (please, take them as my personal opinion)
The first impression was very good: the whole codebase is very clean and very well structured, and it was nice to see that it has abstract interfaces at many levels, to make custom implementations. I definitely liked the fact that it is very easy to add custom mesh loaders.
I liked even more the fact that the video driver is readily accessible, not like other 3D engines which hide it deep into the structures. At this point, Irrlicht looked very promising, because since my game code already implements a scenegraph, I only need a low level interface to do the rendering.
About this, I have a request to all 3d engine designers worldwide: It is good to provide a scenegraph as an extra feature, but a few of us want driver level access!!
But as I browsed the source code, and reached the actual implementation, I found that the drivers were using the DrawPrimitiveUp rendering DX functions, which are very easy to use, but horribly slow. At exactly that point I understood why irrlicht is so clean... it comes at the cost of speed, and I decided to drop irrlicht as a candidate.
Today, I decided to take a last look before moving forward, and found some posts saying that for irrlicht 1.5, changes are being done to actually support vertex buffers and true hardware rendering, and my hopes for irrlicht have been renewed.
Now, I did not have the chance to see version 1.5, and I don't know at which stage it is, so I'm a bit blind here, but from my own experience with my engine, and seeing how irrlicht is designed, I see a big conflict here: irrlicht meshes can be easily changed, while a true hardware mesh buffer needs not to be changed to be fast.
If I had the responsibility of updating the drivers of irrlicht, this is what I would do:
leave all the "drawVertexIndex_" calls in the driver, but, instead of calling drawindexedprimitiveUp, use dynamic hardware buffers; Dynamic buffers have two advantages over normal buffers: if the video card is currently rendering the dynamic buffer, and you unlock it to refill it with new vertices, it automatically creates a hidden copy, and that's what you fill while the hardware is still rendering the other one. And for data transfer to GPU, it tries to use things like AGP memory if they exist, so sometimes, the GPU can use the buffers directly, without having to do any data transfer, so they're way faster than UP calls, but still not as fast as a true static buffer in the GPU.
And, for static meshes, I would create a driver level mesh class, only for static objects (maybe also for skinned objects), that could only be rendered with a call like DrawStaticMesh( ... ) , this driver hardware mesh should be so abstract that the people using it should not even know of what it is composed of: vertex/index buffers, voxels, startrek like quantum particles... the implementation is up to the driver, and the user should expect that updating it would be very costly, and only done at startup time.
I have not decided yet whether to use irrlicht or not, but I'll be looking forward for the development of this issue...
cheers