Horde3D

Why are Euler angles used all over the place with conversions? Why not quaternions and matrices as needed? And degrees instead of radians?!

It's making me throw up in my mouth a little bit...

Seriously... any plans for changing this?

I like having Euler angles in degrees available at a high-level (because they're very human-usable), but yeah, both Euler-angles and degrees don't really belong at a low-level.

High-level would be the app using Horde in this case I would imagine... not Horde itself.

You can set the transform matrices directly - as I do in StarFall.
OpenGL has always used degrees.

_________________
Tristam MacDonald - [swiftcoding]

What do you mean with all over the place? I think it's only in getNodeTransform and setNodeTransform. Internally only matrices and quaternions are used. And you can also use getNodeTransformMatrices and setNodeTransformMatrix if you want to use matrices.

I think there's still a point. It's a pain interfacing existing code that trusts in the availability of all kinds of mathematical concepts. Such as "rotate node". Someone should spend some time writing utility functions like that, at least corresponding to the basic functions available in, say, openGL. ("lookAt", etc.)

For example to make a rotation, the quickest thing with the engine (if you don't have a matrix cached yourself) is to getTransform with 9 parameters (scale, rotate, translate), and push them back with setTransform, with one of them transformed. Getting a matrix doesn't work the same way, because it's an internal matrix which means you would have to copy the whole 4x4 matrix and push it back just to make a single modification.

Not to mention 9 parameters is a *lot* IMO.

It is more of a design issue in your App than anything else. There is no good reason to for your App to store data in a scene node. Instead, your app should store the position and rotation (probably as a vector and a quaternion, respectively), and set the scene node transform when necessary.

_________________
Tristam MacDonald - [swiftcoding]

My app is lightweight in the sense that the properties scene nodes have are enough. I don't want to mirror the whole scene graph because it would be essentially wrapping it with features it already has. I'm not storing intermediate calculations but final data. Not to mention caching this kind of stuff uselessly is very error prone. I think Horde has a pretty generic model of a 3D scene.

There are many cases where I just would like to incrementally e.g. rotate a node, without having to read its state to my internal representation in between, simply because I don't care to ever read it. Now this requires at the minimum two function calls after a thorough inspection of the API for different possibilities of accessing the data, to notice that it's not possible in any easier way.

Yes, I like the idea of being able to keep my own record (though when I do, I don't like Horde caching stuff for me) but from what I've read, many people would like to quickly prototype applications with Horde using e.g. some scripting language. For ease of use and perhaps even popularity of the engine, I can't see why utility functions like this would hurt.

It's already possible to use the scene nodes directly for many applications and there are not bad consequences other than the usability of the API for simple things, are there? I understand that it's just lacking utility functions because no one has implemented them.

This is where I think the engine looks very "low level", when I've read that it should be high level. I think it's also part of being "simple", "lightweight" and "uncomplicated".

You can always feel free to do that!

BTW: I really like it if someone is interested in the project and gives us feedback and proposals to make the engine better. But apart of the fact that some of the proposals may not find wide support in the development team, you also have to think about the fact that currently 'marciano' and myself have fulltime jobs, that may not allow us to continue the development that fast as it was while Nicolas was still a student. So don't hesitate to post patches. This way good contributions may be integrated faster and contributions we don't like that much can still be used by others.