Horde3D

Hi

Hello. I've just come across Horde3D and I have a few questions to ask. I have the latest community SVN code compiling and the examples running. I've also managed to get a textured model through the Collada converter and into the knight demo. First post, so forgive my ignorance, on to my questions:

1. With regard to the C-style binding, if I wanted to just write an application in C++ I can go straight into the class structure, or is that bad?

2. My export scene XML file contains a collection of mesh nodes, does this file actually consistute the scene graph? For example, is it possible to map it to Maya's Hypergraph and then access objects, like all the floor objects? (I haven't checked out the GameEngine code yet so the answer might be in there)

3. Finally my main reason for looking at Horde3D... I noticed there's an ES_Test branch in the community SVN. Please can you tell me the status of this, does it work, what needs doing? It looks like it's using the ImgTec OGLES emulator while I've not tried to build it yet, I'm keen to get this going, possible by making a separate egRenderer class.

cheers

There is no public object oriented interface for C++ and you should not directly access the engine implementation details. The C-style bindings are easy to use from C and C++ (and many other languages). Is there a special reason why you want an OO interface besides it being OO?

I tried setting up a test case for ES, but don't have much time for it. It is currently not up to date since several fixed function calls not available under ES are already removed in the trunk. So it is probably not that usefull for you at the moment, apart maybe from the initialization code from the sample (and I tried the AMD and the PowerVR emulators, shouldn't make too much difference, since the headers are the official ones from khronos).

Basically yes, although the scene graph is very lightweight (it will quite certainly not provide all features that Hypergraph has). Each scene file can be merged into the application scene graph - that you build with the horde API - as a subtree. But I would not recommend to have your world structure driven by the horde scene graph, as it is actually intended for single assets (a character, a rock, etc.). There are also considerations to completely remove it in the future in favor of a more efficient model format.

Thanks for your replies!

Codepoet: I'm fine with the C-style binding, it was more OO for OO sake.

Volker: Thanks for the info. I'll dig into the startup code. I also noticed that the GLSL has been modified which is great. If I can get the ES working, the scene graph is ok and the Bullet physics extension is ok, I can port my game across, hopefully.

Marciano: Lightweight is good. I really only need the scene graph as a means to get levels or maps out of the art package. I want to be able to find object as doors, walls, spawn points, or some other tagged item, i.e the game level is all laid out and I won't need a separate file to say what goes where. I thought coupled with the frustum culling that would be good. The game level is largely static, so I'd then tag these meshes with collision data and game specific parameters. That's interesting that you're thinking of removing it. Do you think it is unsuitable for what I would like to use it for?

You may want to have a look at the discussion about why marciano thinks about removing it.

@zibba: The horde models are actually not meant to represent an entire scene but just (atomic) building blocks of a scene. Ideally you would have a world editor (like the horde scene editor) in which you place the models (or rather entities) after having imported them. In that world editor you would also set other game specific properties which are not necessarily related to rendering. However, creating such tool costs time and I understand that it would be too much effort for a lot of projects. This is a bit of a dilemma that all pure rendering engines have. Actually they are not responsible for the game world representation but as they are so close to 3d packages, you somehow still expect that they support you with creating the world.

What we would need is a separate tool that can interpret a collada file as a scene and split it into several models and entities, based on naming and hierarchy conventions. But this would be a side project and certainly not part of the horde core package. Other from that, I think it is perfectly acceptable to represent the static environment as a single model. If you want to extract interactive objects (entities) from that horde model based on some naming conventions, things get quite hacky, although no one stops you from doing this if you want to.

If anyone has a good suggestion how to better handle scene creation, I would be eager to hear it.