Horde3D

Support for dynamic geometry (e.g. for soft bodies) is still an open issue. It would be trivial to enable uploading of vertex position data but getting things "right" is a lot more complicated. We needd a solution that is efficient and does not waste (too much) memory. Furthermore, there are several dependencies to other parts of the engine, e.g. ray collision queries and software skinning.

My current idea is to use 3 vertex streams that can be mapped by users: position, tangent frame and static data (tex coords and skin indices/weights). Why 3 streams? We certainly need a distinction between dynamic (positions, TBN) and static (tex coords, weights, joint indices) data for skinning and morphers, so that the least amount of data is uploaded to the GPU and that the chance of pipeline stalls due to vertex arrays that are still in use is reduced. Furthermore, to save memory, models using software skinning don't need to clone the whole geometry resource but just need a private buffer for the dynamic data. Having a separate stream for the positions makes sense in order to keep the ray collision feature which is useful for things like picking. For the ray queries we just need the positions and indices and not the tangent space basis.

The streams can have different formats. If a model has no skinning, the static stream could just be GEO_TC2F while a skinned model would have GEO_TC2F_JI4F_JW4F. This helps to save memory. Another benefit is that we could support more efficient data types like half float. At the moment, everything is float which is a bit wasteful for things like normals and tex coords. On the other hand, OGL support for half float via extensions is probably not available on all machines, so I don't know if we can make this a requirement (what about the Mac side?). Having support for both makes things more complicated for users since they need to support different formats when mapping a stream. Maybe we should just accept that this is a PC engine and that memory is not the biggest issue on this platform.

A final issue are AABBs. Horde can't update them automatically in an efficient way (vertices could be in VMem that can't be accessed), so the user needs to provide them when updating geometry. Doing this for every model/mesh is tedious so they should rather be stored with the geometry. I was thinking about introducing triangle groups in the geometry resource that store basic data like the local AABB and the min/max vertex range. A Mesh node would just reference such tri group then instead of having attributes like batchStart and batchCount.

Any thoughts about the mentioned things?

The separation vertex data into seperate streams is a good idea for optimizing the cost of updates.

You can save some memory using half float. Some time ago I've tested this with NVPerfHud(d3d9) and it seemed a little bit slower (1-2% if I remember correctly), but that's not a big issue. Maybe you can convert float to float16 under the hood for immutable buffers. For TBN maybe 10bit components format could be used too. For dynamic buffers I don't think it worth it.

The triangle groups in the geometry resource seems to be a good idea. The setting of local AABB by the user is good too. The user could have much more info about the AABB (from physics engine), or maybe he can preprocess a maximum AABB and skip recomputation.

If this is implemented, it needs to be configurable - often you can't afford the kind of precision loss caused by half float.

_________________
Tristam MacDonald - [swiftcoding]

Thanks for the feedback.

Correct me if I'm wrong but I think there is no widely supported 10bit format for vertex data. So half float would be the best choice. Regarding precision, float16 should be safe for normals, texcoords and colors. Since mesh positions are mostly in local space, they could use float16 as well but for supporting huge meshes it is probably better to use float32 for them. However, the half float extension does not seem to be available on all systems. Furthermore, it is more difficult to use since it is not a native data type.

I've checked the cardcaps in d3d9. 10bit is ATI/AMD only (from 9800). There are also 16bit integer formats which are widely supported (Intel G35 or better, AMD 9800 -, Nvidia FX -). Float16 support: (Intel G35 or better, AMD X700-, Nvidia FX - ).

Probably these cards has similar support in OpenGL. Hope this helps.

TexCoords could have precision problems with float16 (for example a terrain with a big/tiled texture - but uv's could be "normalized" with the cost of adding extra vertices), so this should be configurable too.

Thanks. Unfortunately it is always a different story with OGL. The latest ATI and NVidia drivers for Windows and Linux seem to support ARB_half_float_vertex but according to this table there is no OSX support. Can someone confirm this?

Latest ATI drivers for Vista don't have half float support on my 4870 HD. Anyway, support for half float will need to be optional, because a lot of older cards won't ever support it.

_________________
Tristam MacDonald - [swiftcoding]

Hmm, according to this database even the old ATI 9800 has half float vertex support, provided that the GL version is at least 2.1:
http://www.myogl.org/?target=database

My 8800 GTS has GL_ARB_half_float_pixel but not ARB_half_float_vertex, on MacOS X 10.5.7