Horde3D

Hey Folks,

I recently have discovered the Horde3D engine. I absolutely love this project. The API is totally my style, the source code is clean, and the entire design philosophy is in-line with everything I have been looking for in an OSS cross-platform 3D engine.

I have been working on a game off and on for a couple of years now (yes, I am a perpetual hobbyist like most programmers ). And I have resorted to writing my own graphics system due to the over-bloated offerings out there (Ogre3D, Irrlicht, CrystalSpace, are all yucky in one way or another.) Of course, being a lone programmer, my graphics engine is effective, but pretty simple as far as the functionality it offers. I would love to replace my old graphics engine with Horde3D, but I am not ready to commit yet given some uncertainties I have about it's capabilities.

My engine relies on a very large tiled world. Tiles being scene nodes (containing geometry, particles, etc.) which are instanced across a grid. I use a simple flood-fill style algorithm to render only the chunks currently visible to the camera. The end result is a very large world, made up of a limited collection of scene nodes. Similar tiling schemes are used in many games, for example:





I am wondering if it is possible to set up such a system with Horde3D "out of the box", or will it require modification of the engine (using the extension mechanism I suppose)?

Further, how complicated would such a system be to set up? I am really looking for as painless a transition as possible with out having to wade well into the guts of Horde3D and spend weeks hacking this out.

On another note...

I use Blender3D exclusively as my modeling environment. I have seen the export script, is it reliable? I have seen some complaints as to how useful it is? What is the current state of Blender3D support?

Thanks to everyone in advance! I am looking forward to using Horde3D in my project

That doesnt look like anything particularly tied to a given render engine. Any scenegraph API would render that scene (each tile would be a node essentially), but I doubt any of them would have an interface specifically for tiling.

Incidentally I'm considering a similar style for my own game. Mainly due to the AI.

Hey, thanks for the response!

Ya, I understand that idea, but the problem is if I have a tilemap of 80x80 tiles that makes 64000 SceneNodes. I think this would be inefficient memory wise not to mention that it would probably slow the crap outta the rendering.

What do you all think?

Thanks a lot, it's always great to hear that

Concering your question:
When you talked about a very large world, my first thought went to floating point precision issues and that you would require some shifting to cope with that. But apparently your world ist not that huge

Of course Horde has AABBs for models and does frustum culling, so only tiles that are visible will be rendered. The point is that we do not have a spatial partition scheme implementation at the moment. The infrastructure for that is already existing and the plan is to add culling volumes that are boxes which group other scene nodes. That should be easy to realize but so far it has just not been high enough on the TODO list.
64'000 nodes would be a bit much but luckily 80x80 is just 6'400 (or do you use 10 nodes per sector?). This could even work without additional optimization.

6400 nodes I accidentally added a zero.

Ya, my world ranges from between 64x64 at the smallest to 256x256 for really large maps.

But the average is around 80x80.

The game looks more akin to the first screenshot with the chocobo. It has a simple camera which looks down at the game world at a 45.0 angle and the world is made up of various tiles and 'chunks'. The fixed camera made it very easy to create huge maps in my engine (1000x1000) tiles, since I could do simple 2D calculations to estimate what tiles were visible and not take an fps hit.

I suppose I could just try it with horde3d and see if it chokes

My worry is that I will invest allot of time in trying to set it up, only to find that it is not optimized enough. Although, the quality of the engine is obviously far beyond what I could implement in any reasonable amount of time

So what do you think, should I give it a go?

I would suggest you to do a quick proof of concept. Take one of our samples, load a tile of average complexity and try to add 80x80 of them. That should not take much time and you see how the engine performs. If it is really too slow we will certainly do something to solve that. Just let us know about your results.

Yes, I suppose that is the only real test I was already setting up a project as you put up your post. I was also diging in the Horde3D source code checking out where the culling is done... but that's another mater...

I will post back with some results!

On the culling issue, I've been advised that a BVH is really the simplest most useful structure (bounding volume heirarchy that is) to implement and might be a good first stab. I didnt have time to pursue it with my old engine as I had other fish to fry, but it would make sense if there's no particular gross culling mechanism to implement that as a first pass. Apparently it shouldnt take more than a day to implement.

A small update.

I have so far ported my application framework over to Horde3D. Basically initializing the engine etc. During this process I made an error in my code which caused the camera node to be created and the camera viewport adjusted before Horde3D::init() was called. This lead to a total segmentation fault crash with perplexing error codes etc.

Is this intended? Shouldn't there be some sort of error checking and useful info generated in case of a dumb mistake like this? I noticed that manipulating other elements of the engine before calling Horde3D::init() did not cause this kind of crash.

But hey, I guess it's not the libraries job to hold the programmers hand.

In any case, I hope to actually begin porting over the actual graphical bits of my game engine so I can post some screenshots of my results.

EDIT: I am using Code::Blocks with MinGW to use Horde3D. I notice some other folks on the forums had issues with this IDE. Would some sort of tutorial be in order? Perhaps in the Wiki? I could create it if you think it would be useful.

We used to have an AABB tree. But since it operated directly on the scene graph, it was tied to the logical structure of the scene (the transformation hierarchie), not the spatial structure. This is ok for static objects but does not work well for dynamic ones: Imagine a room and a character. To make the character part of the room it is not enough to change its transformation but it needs to be attached to the scene node of the room to benefit from the BVH.
We have a better system now which seperates the logical and spatial structure: a scene tree (lightweight scene graph with just transformations) and a spatial graph. When the transformation is updated in the scene tree, the object gets rearranged in the spatial graph. The spatial graph is used to perform the culling and outputs a render queue which is handled by the renderer module.
At the moment the implementation of the spatial graph is trivial: a flat list. As a general purpose solution it could be an octree and/or a portal system. But octrees don't give much control to the user and portal systems require very strong tool support to be useful, so I would go for something like culling volumes (multibounds). They are manually placed AABBs. A designer can put them where he thinks they are appropriate, for example to group together objects of a room. The very nice thing is that these volumes can be used with our hardware occlusion culling.


I think that's acceptable behavior. Init needs to be the first call to the engine (stated in the docs and other libraries require that too), so we can avoid slowing down the functions by adding an additional check which is usually not required.


Thanks, that would be very appreciated!

99% of the time (or actually, 100% of the time in a correct program!) this check would only serve to hamper performance but perhaps this feature could be added in the Horde3D debug build only.

What about a kd-tree for the default implementation? It should be considerably sparser than the equivalent octree, and is cheaper to update as nodes move around.

_________________
Tristam MacDonald - [swiftcoding]

I haven't had the chance to work on my engine port again, but I was just thinking...

Would it be possible to implement some sort of spatial partitioning system (a sort of quad tree in my case) at the application level? I could use group nodes which contain the various map chunks, then using some sort of culling mechanism I activate/deactivate the appropriate chunks of the map.

Deactivating a node drops it (and it's children) out of the update/render loop completely, correct?

This will provide a way of dividing up my tilemap without having to modify the engine in its current state. Am I on the right track with this idea?

That's nearly true. It does not remove it from the scene graph, so if you are changing e.g. the transformation of a node within the deactivated node, it's transformation will be updated, even if the node is not active. That's important for animations that should be executed even if the nodes are not active at the moment. But concerning the rendering it's totally correct, that if the node activation is set to false, the node (and all of it's children) won't be put into the renderer queue anymore.

Yes, this is what I did in my racing game. I manually created "zones", and then created a "potentially visible set" of the zones that are visible from each other zone, and then used this set to enable/disable horde nodes.

What would be really cool though, is if Horde exposed the entire scene-traversal algorithm to the application via a call-back function.
A default implementation could be provided in Horde3DUtils, but this could be overriden by the application if a custom traversal algorithm is desired (e.g. the flood-fill that you talked about, or portal systems, or BSP, or KD-tree, etc....).
The traversal algorithm would be passed a node by horde, and be responsibe for passing a list of new nodes to traverse back to Horde. By default, this algorithm would pass back the child-nodes of the input node. However a user would be free to implement their own spacial partitioning structure instead.