Horde3D

Hello,

This is my first message on this forum so.. 'Hi' to everyone ))

I'm relatively new to Horde 3d but I've recently decided to build our renderer ( for a machinima framework project called 'Raafal' ) on top of it because of its clean api ( and C ), and its great flexibility ( especialy regarding the pipeline ). So a big thanks to the author(s) for this wonderfull "piece of art" ( really :-] ).

Of course, nothing is perfect in this world, and the ( only ) issue I have with Horde 3d is regarding its fixed vertex attributes paradigm.

For us to be able to build our renderer on top of Horde 3d, several customs vertex attributes are needed such as, velocity vectors ( for object - including deformation - motion blur ) and several others related to subdivion surfaces ( we are implementing mesh refinement from Matthias Holländer and Tamy Boubekeur : "Synthesizing Subdivision Meshes using Real Time Tessellation" )

I'm then posting this message to request advises about wich would be the best way to add these custom vertex attributes without the need to corrupt the core Horde 3d sources.

For instance there is an extension mechanism and by looking at the terrain extension, I've seen that this extension registers its own 'vertex layout' and the associated commands to allow for this entity to be created proceduraly.

I have the feeling that this may be the right way to implement our needs, by creating a custom node type allowing subdivision surface and motion blur through additional vertex attributes, but I would be glad to hear from you if it is, or if there is perhaps another clever way for achieving this, or if we have to modify the core Horde 3D sources anyway ( wich I would rather not ).

What are you thoughts, advises or suggestions on this ?

Thanks a lot in advance.
Kind Regards,
Guy.

Hmm.. anyone ? anything ?

Btw, is there a documentation somewhere about the extension mechanism ?

Guy.

Hi grabiller,

Indeed you can make an extension however you'd need to make your own node type separate from the Model system currently in place so you'd need to do a lot of work here or duplicate the code into your extension and name it your own node type. The .geo format is quite flexible and allows an arbitrary number of vertex layouts so you can make it use the same resource in this new node(generating it the way you want will need collada converter modifications to extract the right data and setup the geo format the way you want). You're right the code is currently set to have a fixed layout which is a bit inflexible, I think I remember reading that marciano was going to change this but don't quote me on that.

_________________
-Alex
Website

Hi MistaED,

Thanks for your reply.


It would be interresting to have a word on this from Mr marciano.

Perhaps I should wait a bit, it would be stupid for me to start coding a custom node if a change is planned in a near future.

Or may be not, if the change is not planned before a long time.

I would be glad to hear from Mr marciano.

Thanks,
Guy.

Usually the motion vector is computed from a previous and the current transformation matrix (often also for hardware skinning), otherwise you would need a vertex buffer for each object instance which is expensive memory- and bandwidth-wise. So I guess you need the motion vector attribute/previous position only for a few objects which deform in a special way? Depending on how you compute your deformation, it might also work to store the data in some kind of displacement texture as a workaround.

If you really just need additional vertex attributes, I would not recommend to create a new node type because you end up with a lot of code duplication. As MistaED mentions, there is the idea to make the geo format more flexible, so that you could specify a vertex layout and depending on that a flexible number of streams. But still that data needs to be filled with something useful, if it comes from the asset either by ColladaConv or if it is dynamic by the application directly or an extension.

I need previous position vertex attribute, yes, because I need to create a motion vector field in the GBuffer for 2.5D motion blur post process. Having transformation matrix only is not enough to take into account deformation motion blur ( whenever vertices are animated independently from the node ).


This would be ideal yes. Is this something in the way ? Or should I start trying to customize the vertex layout myself ? If so can you give me some advises or pointers regarding the source code modifications ?


Clearly the previous vertex position attributes I'm talking about above don't need to be saved in the geo file, it's dynamicaly computed on the fly and sent to the shader, but there must be a way to do so.

I also need persistent vertex attributes that should be saved in a geo file. As told in my first message I'm in the process of implementing subdivision surface with the help of a clever virtual tesselator from the author of the mentioned paper. For this to be usefull I need to save the crease value of each vertex in the geo file so that a subdivision surface could be rendered faithfully in case the artist setted "hard" vertices or edges and with wich factors.

So far I have a need for all the current available attributes ( including tangents/bitangents and the 2 UVs channels ) + previous position + crease values, the last one being saved in the geo file.

( Those informations will be created directly from Softimage|XSI through a proprietary exporter, I'm not using the collada converter ).

I had an idea for motion blur the other day without blowing out the uniform vector limit by 2xing the amount of joints sent over, seeing as through motion blur would only be noticed by the object itself and the limbs (if you assume a typical humanoid figure), duplicating the limb joints, and using the previous frame's joint location applied to these secondary joints would give enough info for the screen space motion vector render... Or even rendering a second pass with lower res approximation of the mesh with just 2x the primary limb/body joints and just have animation outputted from a package with the current and previous joints might work....

Regarding the tessellation, currently Horde doesn't support the tessellation units found in modern GPUs/OpenGL 4, from a glance that paper you're referring to does rely on it?

_________________
-Alex
Website

But what about morph targets ? I also need motion blur in the context of morph targets ( wich can be fast and high in some case ).

In fact I'm targetting offline rendering similar quality of 2.5D motion blur ( wich is not even satisfaying in some case, but.. ), and at the same time, I'm trying to have a unified approach. I'm counting on the regular horsepower improvement of the graphic cards for having this additional vertex attrribute layer not beeing an issue, utlimately.

Remember I'm working on a machinima application, not a game, and by 'machinima' I'm not talking about toy like software such as iClone and such, but a professional framework able to produce pictures for movies and tv series. So motion blur is very important ( a game can run at 60 or more fps, where motion blur is less and less important, but when you run at 24 or 25 or even 30 fps, quality motion blur is mandatory for professional results, as antialiasing is ).


No, it doesn't rely on tesselation units, that's the beauty of this paper ( actualy the first paper, from 2005, called "Generic Mesh Refinement on GPU" and use a clever method of instance drawing of refinement patterns ( pre-subdivided triangles stored on the GPU once and for all ). With this technic, tesselation and fine displacement mapping was available long before tesselation units and even geometry shaders, but surprisingly, very few people use it. You can produce millions of triangle on the fly without even storing them on the GPU nor transfering them from the CPU. There is no limit in the triangles count you can "generate" this way, aside the raw horsepower of the graphic card and the targetted FPS of course.

It is then a futur-proof method for tesselation yet even run on old graphic card.

I'm also thinking to use it for the terrain extension, to add fine adaptive displacement mapping on top on the already existing lod algorythm.

Ah very cool grabiller! Ok now I'm thinking that more and more that it might just be easier to make your own Model node as an extension even though you'd be duplicating a bit of code (maybe with the enum SNT_AwesomeModel, hehehe), just for the fact that I assume that this relies on the GL_EXT_draw_instanced extension to use instanceID from the shader? For the drawing you'd need the right opengl instancing draw call, similar to how the terrain extension does a direct call to opengl for its own rendering (unless that's changed now and it uses a call that Rendering Device Interface wraps, haven't checked in awhile).

Ok yeah you're right morph targets would need this data for motion blur vectors.

_________________
-Alex
Website

@grabiller Quite unrelated, but if you're interested in GPU based mesh processing you might take a look at geomtry images, a technique that (wrongly) has not found much appreciation yet.

Yes, exactly, this relies on the GL_EXT_draw_instanced, albeit in some of their exemples they have implementation not using it, they send the coarse polygons one by one ( as uniform ). But it make more sense to use instances, albeit it's a bit more tricky for the adaptive method, as you have to sort the refinement pattern levels in order to group the instances call.

Regarding the model node extension, actualy I'm thinking that, in my case, it may be wiser to modify the core rendering process so every object would be drawn this way. If an object does not need subdivision then the level 0 refinement pattern is choosen without noticable impact on performances.

The advantage of this, at least for me, is that it makes the all implementation uniform, simple and straight forward. Every object would be treated the same way, with the same vertex shader, with just a refinement level parameter computed automaticaly according to some distance to camera metric plus a user biais.

This sounds generic and simple, it may even be transparent. I think I'll investigate this way. This is a major and mandatory feature for my project, so better be it well integrated at the core I think.


AFAIK instancing draw calls are not exposed through the RDI, nor bindable buffer objects. I think it's no big deal to add those to the RDI, especialy if I decide to modify the core rendering for this tesselation technic.

Plus this would help to modify the Terrain extension.

This seems, indeed, an interresting technic albeit the last time I'v checked there seemd to be an issue with texture coordinates. But I don't have enough knowledge of this technic to get a more precise idea.

Ultimately, it's more a way to store object data than a data amplification technic, wich is what I'm interrested in currently, through subdivision and displacement.

I'm trying to implement a way to get as much as details as possible to be as close as possible to what's possible in offline rendering, but in real time ( lighting will be another subject )

The technic I'm working one based on those papers can, conceptualy, achive this result. It's only a question of raw power of the graphic card, not even memory quantity, wich means ones the implementation will work, I wont have to change anything to achieve this result when the graphic cards will be powerfull enough. Even today, I think we are quite close with the latest cards, at least to have awesome results allready.

This is really exiting, and I have to make it work :-]