Input wanted for hardware buffers design

[Luke]

I’m planning on working on hardware buffers for irrlicht, and I’m like some input with the design, features, interface, etc.

Design wise:

I think the hardest design problem is with IMeshBuffer, working out this nicest way to add hardware buffers, maybe deriving a class for buffers, IHardwareMeshBuffer?

Everything else should be pretty straight forward,
I’m thinking CNullDriver::drawMeshBuffer should check the meshbuffer for hardware buffers and call the correct function.

Interface:

Well I’m hoping to make the hardware buffers completely transparent to the user. The hardware buffer being automatic, and you wouldn't have to mange anything, or have to change any code to get the speed gain.

I’m thinking that all static meshes over x poly or just all (depending on what works best) would be uploaded. Animated meshes would just be ignored or just have index data uploaded (till hardware skinning)

Of course there will be an interface to have full control over the hardware buffers, and you can turn them off easily.


Let me know what you think, any problems you can see, good designs you got, features you want, how you think the interface should be, etc.

[Raedwulf]

I'm working on this too, perhaps we should work together? I'm quite busy these days but I'm sure I can help out

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=24215
http://www.jeeastwood.co.uk/irrlicht-vb-06-11-2007.zip

I like the idea of IHardwareMeshBuffer... hmmm can I contact via some sort of messenger? Check my profile and maybe add me/or if you use some other messenger just PM me yours.

[hybrid]

I don't think that a IHardwareBuffer would make sense. It would limit usage of the hardware acceleration because one would have to copy usual mesh buffers into hardware mesh buffers. Finally, anyone would have to use custom meshes to accomplish this.
I think that forcing the user to use a lock/unlock sequence for accessing the vertices and a flag to specify the access scheme to the vertices (such as dynamic, static, etc.). The flag should also be accessible on the mesh level to make usage easier.
Another important point (that Raedwulf already considered) is to make use of buffers transparent to the meshbuffer in that it won't store driver dependent information. So not storing VBO identifier in the meshbuffer, but hide them in the driver. The driver should recognize a meshbuffer somehow and use the proper hardware identifiers automatically. This will also allow usage of DisplayLists in OpenGL etc. A solution making implementations easier could be to add a driver information structure which every meshbuffer has to store, in case an easy mapping is not possible.

[omaremad]

The implementation should be exactly the same as ITexture and opengl texture directx texture etc...

We also need to consider some extra flags to tell the mesh if its update able or not (gives better performance for static meshes), however that would depend on what the node using the mesh is(octree or animated) also some trouble may arise if multiple nodes share the same mesh and some are static and some are not; in this case making multiple copies of the mesh could work but hiding that inside irrlicht may seem a bit dangerous.

I think in the constructor of Imesh we should allow the user to define if the mesh will be static or not since thats something irrlicht can`t predict but users want.

[Luke]

Raedwulf:

Thanks I’ll have a look at the code

And thanks for the link to that topic, I’ll have a read, would have been hard to find with a name like “SColor for OpenGL”

Hybrid:

It would limit usage of the hardware acceleration because one would have to copy usual mesh buffers into hardware mesh buffers. Finally, anyone would have to use custom meshes to accomplish this.

Well I cannot see much of a problem as IHardwareBuffer would hold a normal mesh as well, it would just invoke changing one name. But I also cannot see any problem putting it in IMeshBuffer as well.

I think that forcing the user to use a lock/unlock sequence for accessing the vertices and a flag to specify the access scheme to the vertices (such as dynamic, static, etc.). The flag should also be accessible on the mesh level to make usage easier.

Sounds fine

So not storing VBO identifier in the meshbuffer, but hide them in the driver.

That seems ok, but I don’t like idea of searching though a list, etc it would involve. Trying to think of nice way to do it, or another way to have multiple drivers sharing the same meshbuffer.

This will also allow usage of DisplayLists in OpenGL etc.

Well storing links to DisplayLists, etc should be fine with any method.


Omaremad:

also some trouble may arise if multiple nodes share the same mesh and some are static and some are not

not sure how that would be possible. (unless you just mean the user having animated meshes with animation but using them as static ones)

We also need to consider some extra flags to tell the mesh if its update able or not

Yeah, of course,

irrlicht should be able to set it up fairly well automatically with the plain loading meshes from file but.

I think in the constructor of Imesh we should allow the user to define if the mesh will be static or not since thats something irrlicht can`t predict but users want.

I don’t think you need it in the constructor (there would be nothing to upload anyway at that point), maybe just a function to set it? most of the normal use of meshes irrlicht should be able to predict by the way

[hybrid]

This will also allow usage of DisplayLists in OpenGL etc.

Well storing links to DisplayLists, etc should be fine with any method.

Not storing DisplayLists somewhere, but using DisplayLists as an alternative to VBOs. Hence not unleashing the full power of display lists, but making use of some similarities between display lists and VBOs.

[bitplane]

As discussed on IRC, I'm in favour of index and vertex list interfaces, so they can be shared, and forcing people to use them and lock/unlock even in non-hardware CMeshBuffers. Would mean changes to IMeshBuffer and breaking everyone's code, but it's worth it imo

[hybrid]

I think I understood the IHardwareMeshBuffer wrongly. Having it as a driver handle to meshbuffers (not forcing the user to put everything into IHWMB instead of IMeshBuffer in order to use VBOs) would be a good thing. Because we would get a way to reorganize meshbuffers for drivers (dx9 mesh optimization, changing from unsupported mesh primitives, tri-stripping buffers, ...)
Still, this does not solve the problems with hw meshbuffer sharing between different devices and proper destruction of the IHWMBs.

[Luke]

well with bitplanes index and vertex list interfaces idea.

I'm thinking:

http://img140.imageshack.us/img140/3725/vbo4kd1.png

-shouldn't break any code (expect custom meshbuffers, but I could set it up so it doesn't if wanted)

-this also would let you use 32 bit indices, and shared indices (for animated meshes)

-meshbuffers wouldn't have to be templated anymore, and all meshbuffers could change vertex types at runtime.

-when using a displayLists, the data would be stored in the vertexBuffer by the driver and the hardware type set.

-the VBO can only be used by one driver at a time, if using two drivers (of different types), one will be drawn without VBO, so you have to clone it if you want to both having VBOs.

you could do the same thing without the index and vertex list interfaces, the IHardwareBuffer way, just no index sharing.

[Luke]

little update:

http://img210.imageshack.us/img210/2548/vbo7ln6.png

starUML file if you want to make changes: http://www.fileden.com/files/2006/8/10/162152/VBO3.uml

[ferdekk]

ahh!! Finally someone starting programming official VBO's Things for Irrlicht!!!

Question: when? in Irrlicht1.5?? next-version?

[Luke]

yeah, but I really don't want to be forcing a design on people, I'd love some input.

yeah possibly 1.5, depends on how soon it is, and how well it goes.

[bitplane]

What's remove() for? Is this different to the destructor?

[Luke]

I don't need the remove() anymore, ignore it

[BlindSide]

not sure how that would be possible. (unless you just mean the user having animated meshes with animation but using them as static ones)

I think he means if someone was modifying a mesh at runtime or something. Water simulations maybe? (I know omaremad was doing one a while back.)