Horde3D

The next version of Horde will have a new extension mechanism.

This makes it very easy to use additional scene node types in the engine and will hopefully encourage other developers to write some addons.

As a proof of concept we have realized our terrain node as extension. Everything is working fine so far

Excellent, that sounds very useful. Perhaps I will have time to integrate my planet renderer some time.

That's convenient (for both plugins and terrain).

You wouldn't happen to be willing to speak of this terrain node would you? Chunk? GeoMip? Qaud-tree? Icky Roam?

Does this currently only apply to scene nodes at the present? Or does it also include resources?

@swiftcoder: A planet renderer sounds great, but probably you need a custom scene manager for that?

@AcidFaucet: At the moment extensions are only working for scene nodes but it should also be easy to add a mechanism for resources.

About the terrain: It uses a simple but nice and effective algorithm that was described in Game Programming Gems 6. It is some sort of quadtree and reuses a single vertex array which is stretched to the size of the quadtree cells. This algorithm is very GPU-friendly since it requires little memory and could run completey in hardware by using vertex texture fetches (although we have disabled this in our implementation for compatibility and oddly enough also performance). I heard that Unreal Engine 3 is also using this algorithm (but not sure).

I think we will have a quite solid implementation but there are still many things which can be improved for a fully-featured landscape renderer. We will leave this to the community and concentrate more on the engine core, so if you or someone else is interested don't hesitate to improve it

Not so much, as long as we can manipulate scale in the plug-in.


I would need that feature though.


Funny world this, I think I described that very method a long time ago...
http://www.gamedev.net/community/forums/topic.asp?topic_id=312262

Yes, that seems to be exactly what we have implemented. Since your post is from 2005 and the article in Game Gems from 2006 it is quite obvious who deserves the credits
Although the idea is actually simple (and I love the elegance of simplicity) you have my respect that you came up with it yourself!

Good news, resource extensions are also working now. Took twenty minutes for a clean implementation

Nice work! How does the resource system integrate with current resources?I guess I am asking whether I can implement a new type of texture or mesh loader using this.

The resource and scene managers have a registry which maps the resource/node type ID to a few function pointers. Each resource for example has a static factory function that creates an instance of the resource. A pointer to that factory function is stored in the registry. Since extensions are initailized after the registration of the resource and node types they could overwrite the mapping. This should make it possible to replace e.g. the texture loader.

In the latest code, "Horde3D Utils" seems to have been moved to an extension, "ExtUtilLib." I updated the namespace in Bindings/C++/Horde3DUtils.h to match this change (otherwise you can't link against the library) but I'm not sure that it's right to keep it as an extension. Horde3D Utils contains some core functionality, like setting resource paths.

You don't have to link explicitly against an extension. Extensions are directly included in the Horde3D.dll, similar to the OpenGL extension mechanism. The namespace in the binding header file does not matter. Actually it is just there for convenience so that you can type Horde3DUtils:: and get a list of all functions from intellisense. Sorry, I had to undo the change because all samples and our projects would have to be updated too. But I have renamed the internal ExtUtilLib namespace to Horde3DUtils for consistency.

Horde3DUtils is included by default in the Horde3D library. But you could remove it if you want to do your own file handling, so it is not an integral part of the engine.

Okay, that makes sense. But did it really link in the Windows build despite the different namespace names? Anyway, as long as they still match up it should be fine, and Horde3DUtils is a nicer name for the util library

Ah, now I see why you had to change the namespace. In windows you explicitly tell the compiler which functions should be exported. In Horde they are exported as C-functions, so no namespaces are used and things work fine. In Linux everything is exported to a shared library, so you also need the namespaces to match.

I had a look at the code today in order to make that static build change, and found that you've moved the Terrain extension into a separate root directory. It looks like you have to do an overwrite-copy of the ExtTerrain directory into the Horde3D directory in order to use the extension. Is this right? I assume this is because you want ExtTerrain to be strictly optional, and not force everyone to build Horde3D with it.

However, having to copy things around before you can use them doesn't seem very user-friendly. It's also not very developer-friendly, since you can't easily use extensions straight out of SVN.

It then occurred to me that building all extensions statically into libHorde3D may not be the best thing to do, because it means that for every combination of extensions, you have to create a new special version of Horde3D, and manually keep it up to date. Wouldn't it be better to keep it all together, and have each extension in its own shared library, and let applications choose which combination of extensions to link with?

Sorry if I'm missing anything, or if this post is unclear. I have a cold, and my brain isn't 100% at the moment. Now I'm going back to bed!

Originally we planned to make a plugin system with DLLs. The problem is that you need to link against the engine from the extension. So all the engine classes need to be exposed in the Horde3D.dll. This is easy in Linux but in Windows it is much harder to export classes and especially templates. From what we have learnt it seems even nearly impossible for some STL containers. A DLL based plugin system would probably have required many ugly changes to the code. But I must admit that we are no experts here. If anyone knows a simple and clean way to do this I would be happy to hear about it.

So we decided to make the extension system. I think it is acceptable for users to build their special version of Horde, especially since an extenison is very easy to install (takes less than a minute). Usually you won't have so many extensions in your project so I think this is fine. But I must also admit that the separation in the svn is a bit annoying for our development. Might be we find a better organisational solution here.



Oh, I hope that you get well soon!