Horde3D

It will probably still take at least two releases until Horde will get to the 1.x level but nevertheless I'm doing step by step some changes to improve the API (this already began for 0.14). I will list a few points from my TODO list so you can give feedback if something should be done in another way.

• Modify resource loading: I have finished that a few minutes ago. Querying and loading of resources will be done using handles and no more names. Furthermore the resource search path (from setResourcePath) is no longer included in the resource name. This makes things more convenient for dynamic resources.
  
• Use safe handles: Currently handles are just indices to arrays. The problem is that if you delete e.g. a scene node but forget to invalidate the handles you have stored for that node you get "dangling handles". One simple trick to avoid this (or at least output a warning) is to encode some sort of magic number in the handle.
  
• Use global get/set functions for node parameters: Currently each node type hast its own get/set function which is returning/taking a float value. The problem is that floats can only represent integer values up to 2^23 which was until now no problem but would become one if the handles contain the magic number and get really huge. So one would need get/set functions for float and for int params. To reduce the number of functions I want to replace the specific functions (e.g. setMeshParam) by global ones (e.g. setNodeParamf). With a few tiny tricks this shouldn't have any disadvantages.
  
• Replace all usinged ints by ints in API functions: I'm really not sure about that. The issue is that .NET doesn't know the unsigned int type. So having just (signed) ints would make the interface easier to port.
  
• Drop the NodeAttachment class: The node attachments are nice but I think they could cause problems in multithreaded apps and of course they are completely inconsistent with the rest of the API, which uses just functons. So I want to replace them by a polling mechanism which can basically do the same,
  
• Make all node attributes mutable: I'm also not quite sure here. The question is whether it should always be possible to modify all attributes of nodes (e.g. the batch count for meshes) or some only at creation time (when addMeshNode is called). The problem is that a node could become invalid due to wrong data (e.g. if batch count is negative). But since a node could also become invalid by other events (e.g. when a geometry resource is reloaded and suddenly has less vertices than before) some mechanism is necessary anyway.

Swift pointed out that "The scene-graph/renderer should not be the container for an applications entity data", which will usually be the case, but some users may want to attach extra data to the scene-graph nonetheless.
I believe the simplest way to allow this is to give the user access to an opaque pointer-sized variable simply called "userData".
This would require another set/get function though for use with pointers, e.g. setNodeParamv that takes a 'void*'.

The reason why we introduced the attachment thing a few month ago, was that we didn't want to store the whole scene graph again in some other type of data format. In case of e.g. physics data, which may depend on the Mesh Data, I really like to store this data at the scene graph file, which makes the creation of physics nodes for example using Bullet quite easy. Since Horde3D does not use the attachment data and only forwards it to the registered callback I think it should be Ok, if we have this attachment mechanism.

Dropping the attachment class itself should not be such a great problem, since e.g. the PhysicsEngine does already know which nodes contain attachments and can ask Horde, if the node's transformation changed. The only thing I really want to see integrated is the callback thing for attachment data.

I am trying to use Horde3D with C in Linux. First I though that would just work because of the feature description Simple and intuitive C-style DLL interface for easy integration with virtually any programming language.
Beside the fact that was already mentioned - the C++ class in Horde3D.h - there are some other difficulties to use Horde3D from C. I won't describe them now as I don't know if it should be usable from C directly. But I think it should be as there is define DLL extern "C" __declspec( dllimport ) in Horde3D.h.
I would be keen on making Horde3D usable from C in Linux directly. But maybe it is already and I just missed something.

The main use case for the engine is certainly C++ but of course it would be nice if it could be used from C too.

The class has been removed now and functionality replaced by some C-API functions. What other problems (except the namespace of course which can easily be removed) do you see that keep the interface from being used in pure C?

EDIT: Ok, of course there are bools which are not supported by C but should be easy to convert to ints.

There are several enum definitions with the same name. E.g. enum List appears several times in different structs. But gcc only allows one definition for enum List.
I am not very comfortable with this kind of C++ stuff, but it seams that C++ allows it, because it appears in another context.

Edit: Made it understandable and correct.

It would be good to remove these anyway, as some compilers (in particular Metrowork's) seem to have funny ideas about how many bytes a bool is, even in C++.

I think there is no simple, compatible solution for that. I was playing around with it, but I think it is unavoidable to use #ifdef.

I started to use Horde3D via C. I would be willing to help with this tralslation, but I am not sure if you want the Horde interface to be like this.
As the C++ enums in structure are not usable from C, change to The functions must be changed as well:
would become
With those changes everything stays unchanged except for some calls, such as EngineOptions::SceneGraph -> EngineOptions.SceneGraph.
The solution is straight forward. I was looking for something to allow calls of this kind EngineOptions::SceneGraph, but found nothing.
What do you think?

Just made a quick test: In Visual Studio C++ EngineOptions.SceneGraph didn't work but EngineOptionsList::SceneGraph is fine although the compiler gives a non-standard warning.

About the bool to int conversion. Actually I like bools since they have some additional semantic compared to ints. In general I think it should be ok to have separate bindings for C++ and C. Doing the conversion is trivial and in the future after 1.0 the API should stay more stable and not change so often.

EngineOptions.SceneGraph is not legal C, so it shouldn't work. You should just be able to use the enum label directly in both C and C++ though, i.e. just SceneGraph - which indicates that the label name should probably be EngineOptions_SceneGraph or some such.


For an integrated workaround for C, this snippet at the beginning of the headers should fix things nicely:

Eek! Aside from the point that bool won't be recognised by that #ifndef to start with, redefining language keywords is about as horrible as it gets. Imagine what will happen to the poor programmer who innocently includes a header that does this in their project.

The best approach would probably be to define a H3DBOOL type or similar.

Edit: Okay, the __cplusplus check would probably avert disaster. But I still think it's a bad idea on principle

Oh my god. Of course, you are right. I tried different ideas in one header - one used a struct, that's why there is a "." - and somehow mixed two different ways in my post. Sorry, I should not waste the time of others just because I was not enough concentrated on that topic.

A callback for the addition of an application specific draw process, such as debug drawing of physics primitives would be nice in a future version.