Horde3D

Just wondering, does collada conv support animation of visibility properties from collada? I ask because I am trying to animate a muzzle flash and it doesnt appear to be visible ever during the update cycle, although the geometry is clearly within the scene.

Unfortunately there is no official support for such animated properties, as they are beyond the scope of a renderer.

You think? I'm not so sure about that. I mean in practical "I want to develop a game using horde" terms, it really isnt beyond the scope. As are things like triggering events during the animation timeline and such.

It doesnt bother me adding those kind of things myself, but I have to disagree that it isnt a function of the rendering engine. I'd have to think that anything to do with visual properties of objects is the render engines domain.

Hmm, I can see both sides

The 'active' (visibility) state of nodes is something that Horde does hold responsibility over, so such animations could well be implemented within Horde's animation format. Visibility-events are a specific case of the more general "time-line event" concept though.

On the other side of the fence, most animation systems that I've used provide a call-back to the user-code in the case of time-line events. In Horde's case that might mean that h3dSetModelAnimParams would return a pointer to any events that occurred between the previous and new frames, and letting the caller decide how to interpret them. If the animation layer is going to be implemented inside the Horde library, it probably should have some way to support animation events in some form (otherwise the user would have to modify the collada converter to export the animation-event data to a separate game-specific file, and implement another animation system running in sync with Horde's one).

This is a tricky topic. First I would differentiate between renderer and 3d engine. For me, a renderer abstracts the underlying graphics API, deals with state management/optimizations, provides a shader and effect system and implements the actual rendering algorithms (shadows, lighting, effects, etc.). The 3d engine is responsible for the scene management, including visibility management (culling). The core domain of Horde is clearly rendering but we also have a basic 3d engine (scene graph and culling) although we don't provide a full world/level representation as this can be very game type dependent. Horde also provides a low level animation system with blending and skinning but animation is certainly not the focus.

I would put animation of properties (including visibility) rather into the domain of a timeline system (as DarkAngel mentions) which would be used for cutscenes or scripted events. This system is a lot closer to game code than a rendering engine. However, I know that this clear separation of subsystems is pretty much Western AAA tech thinking and that for a "smaller" production/project you probably don't have the resources and motivation to create a fully featured timeline editor and similar. But of course the latter is the target group for Horde, so it is quite a challenge to find out where to draw the line between supported features and other systems' responsibilities

My opinion is that Horde should mainly focus on its core domain (rendering) and provide basic 3d engine and animation support as we do already to make it useful for a wide range of projects. However, everything else besides rendering should be orthogonal, that is easy to replace by another subsystem (e.g. using Havok for animation) or easily extensible in functionality.

I agree with Marciano and DarkAngel, Horde shouldn't have so much implicit functionality, but rather provide means of attaching functionality. So, I'd rather see some benefits of adding "custom channels" in the Collada animation (and supporting animation_clips btw). Not sure thhough, if/how it's possible to squeeze sth. into the Collada DAE, maybe using the "channels" and "extra" data, and how it might be supported by the animation package.
Adding sth. like "visibility on/off", "play particle effect" would be trivial then, if one attaches a "custom channel" handler which can react to animation "events", as DarkAngel pointed out.

In practical terms, it doesnt really matter WHO has the responsibility as long as its taken care of

If we're loading animation data and applying it to a model in horde, then logically to me the core of additional animation data should be within the same set of data and exposed by the same API. I'll experiment with some simple assets in max and see how the collada output looks for those specific tracks.

Mind you, I read somewhere recently that they were going to allow indie developer licenses of the full set of havok tools. Maybe that'll be an option.

Anyway, will see what happens.