Ogre or Horde3D

[Funcracker]

Also I have just seen that there is interest from the big guys in this engine. They have the choice between CryEngine 2.0, Gamebyro (Oblivion engine) and Offset and are currently seriously consindering using Horde3D.

http://www.nextgen-engine.net/forums/viewtopic.php?t=93

So this engine can't be that bad!

Well, Frantic Games is a relatively new Indie developer, that worked on a(or maybe multiple) BF2 mod before starting to work on this project.
They already checked Ogre in 2004 btw, among with several other engines, but because they couldn't find an engine that suited their needs, they started working on a mod/total conversion variant first.

So big guys would be kind of an overstatement I guess, especially as the projectleader seems to be the sole employee of this company and he still has his day job to pay for all external libraries he acquired for this game.

Please note that there is nothing wrong with this (far from it, as it seems his project is actually well-planned and and all), but it's not really that interesting to note that they are looking into using Horde3D.

After re-reading my post I realise I might sound as an Ogre-fan or something, but I just want to set things straight so you don't get the wrong idea here

I wish you guys the best of luck with your Horde3D game and I hope everything works out for you guys!

p.s. Most of my info was from this topic. I really don't know these guys, but googled them and based this post on the stuff I found on the web.

[beaugard]

Actually, one of the biggest reasons I am interested in Ogre3d is that it already has been used successfully in several commercial projects. This, and the ease with with you can write your own Scene Managers (actually, I should probably say "the well implemented modular design" or something, but I only ever worked with customizing SceneManagers)

Horde 3d looks fine, but spontaneously I see two problems:
1. Occlusion culling is a "planned feature"!
2. Like everyone else here, advertising shaders such as "parallax mapping" as a feature sends nasty shivers down my spine. This is biz talk, nothing else.

However, Collada support sounds good. And more importantly, it seems from your post that the most experienced programmer on the team wants to use Horde3d - so keep him happy and go with it.

[yeahdixon]

im farely new to the 3d engine world so take my comment with a grain of salt , but one thing that has baffled me is how to smoothly get animations into render/game engines. With so many competing companies, and now opensource projects, it seems that the best file format is an independent one. Even if you do find an exporter its likely that that exporter has some quirk because it was not updated or the original software has changed making that exporter marginally functional or worthless. This is why collada makes sense. One format single format instead of trying to create every combination of import/exporter for 3d modeler to every game/render engine. Therefore when i tried pulling a converted collada file into horde3d and saw my mesh appear animating with such simplicity, i realized that this was all i ever wanted. A collada converter came along with the download. I definitely do agree, horde is immature so it may not be wise for many people to seriously get involved, but I hope that either horde matures or orge gets a bad ass importer for collada with animation support.

[jacmoe]

We are on it! ->
http://www.ogre3d.org/forums/viewtopic. ... 91#p322491

[nikki]

2. Like everyone else here, advertising shaders such as "parallax mapping" as a feature sends nasty shivers down my spine. This is biz talk, nothing else.

Hah! That's like saying, "Windows! Comes with Notepad.".

[nullsquared]

2. Like everyone else here, advertising shaders such as "parallax mapping" as a feature sends nasty shivers down my spine. This is biz talk, nothing else.

Hah! That's like saying, "Windows! Comes with Notepad.".

More like "Windows, comes with support for running applications as well as Internet Explorer!"

[nikki]

2. Like everyone else here, advertising shaders such as "parallax mapping" as a feature sends nasty shivers down my spine. This is biz talk, nothing else.

Hah! That's like saying, "Windows! Comes with Notepad.".

More like "Windows, comes with support for running applications as well as Internet Explorer!"

[DDd]

Horde3D has been coming along nicely. Many of the planned features are now implemented

From the get go Horde3D states itself as a shader-based engine, so the lack of support for older hardware is a given. If you are targeting an old market then Horde3D is not your engine. If you are targetting next-gen and current-gen hardware then the simplicity and flexibility of Horde3D saves you time, and makes you more productive. (it's like buying a Ferrari and complaining about the gas milage, or buying a Fiat panda and blaming that it can't go 250mph, it's the nature of the beast!)

Horde3D now uses the CMake build system, so it supports all major OSs. GLFW is used for platform portability.

Horde3D community is growing, and there are a few people that are productive members of both communities (Horde3D and Ogre3D). Personally i think there is much to learn and knowledge/experience is a good thing to share. For instance i notice that both engines are struggling a bit to get dx10/opengles2x and shader based material systems in place. Ogre3d community has many years of experience and trialed solutions to share with the horde3d community.

Horde3D has a nice scene editor, and supports some nice features in terms of asset management and animation.

Horde3D API interfaces are much more unstable than Ogre3D (what i mean is that the feature set and naming is not set in stone in horde3d and from one beta release to the other your code will break). So maturity and good design development is certainly a big Ogre3D plus for anyone that wants a production ready gfx engine. Horde3D is more "cutting edge" in that sense.

Personally i like the fact that i can read the full code in half a day there is more to build on top of, but the thin layer that it provides is solid and comprehensible. Lately there are talks of defining an abstraction layer so that it can support other APIs with more ease, so expect a few more twists and turns from the Horde3D devs until it reaches the same level of maturity of Ogre3D.

[KungFooMasta]

I needed to kill some time at work last week, and checked out the Horde3D webpage/forum. Comparing it to Ogre, from a somewhat limited perspective, the biggest problem I see with Horde3D is its lack of showcase. I checked available screenshots as well as user projects from the forums, and the amount and quality of the screens I saw were not remotely comparable to the number of amazing screenshots Ogre has. Hopefully that doesn't sound too negative, basically I'm saying that Horde3D doesn't really show off anything fancy, so its not very likely to pull in people that are already using Ogre3D, unless there are some functional limitations of Ogre that Horde3D provides.

[DDd]

I needed to kill some time at work last week, and checked out the Horde3D webpage/forum. Comparing it to Ogre, from a somewhat limited perspective, the biggest problem I see with Horde3D is its lack of showcase. I checked available screenshots as well as user projects from the forums, and the amount and quality of the screens I saw were not remotely comparable to the number of amazing screenshots Ogre has. Hopefully that doesn't sound too negative, basically I'm saying that Horde3D doesn't really show off anything fancy, so its not very likely to pull in people that are already using Ogre3D, unless there are some functional limitations of Ogre that Horde3D provides.

It's true that there is not as much eye candy. However, take into consideration that the engine is young and so is the community. There are some interesting screens on the wiki: http://horde3d.org/wiki/index.php5?title=Main_Page
and a nice video of using Horde3D animation system:
http://mm-werkstatt.informatik.uni-augs ... p/showcase
there are a few more videos on youtube from projects done by people at the Augsburg uni. and others. Two nice games are Sheep Me Up! and Plight Of The Weedunks
http://www.youtube.com/watch?v=qbCyp2UC ... r_embedded

If i was to make a case for Horde3D i would have to say that it's size and simplicity. the shader only and configurable pipelines are a big plus to simplify the wrkflow. The animation system and the Collada asset pipeline are some of the main "selling" points.

Ogre3D has a bigger community, it's mature, supports more APIs and hardware platforms (though Horde3D will soon support D3D also, using an abstraction layer), has more features, more projects under it's belt, and a full time dedicated developer , availability of commercial consulting services associated with it, etc... However it is also more complex.

For any newcomers: I would say if you want to do a prototype Horde3D is simpler to pick up and get things done, the official editor is a great productivity tool. For production it would require heavier evaluation depending on the project at hand.

Personally i think they are both great gfx engines with their strong points and their shortcomings.

[Kojack]

The animation system and the Collada asset pipeline are some of the main "selling" points.

From the Horde3D website's feature list:
Animation
* Unified low-level animation system working directly on scene graph
* Keyframe animation for joints and meshes
* Skeletal animation with up to 4 weights per vertex for articulated models
* Layered animation blending and mixing using masks and additive channels
* Inter-frame interpolation for smooth animations
* Access to joint data for dynamic animations and ragdoll physics
* Morph targets for facial animation and lip synchronization

All of those are in Ogre.

The api is C based, which makes it very scripting language and alternative language (like D) friendly, but it also makes it very C++ unfriendly.
For example to make a light (taken from the latest sdk example code):

Code: Select all

NodeHandle light = Horde3D::addLightNode( RootNode, "Light1", 0, "LIGHTING", "SHADOWMAP" );
Horde3D::setNodeTransform( light, 0, 15, 10, -60, 0, 0, 1, 1, 1 );
Horde3D::setNodeParamf( light, LightNodeParams::Col_R, 1.0f );
Horde3D::setNodeParamf( light, LightNodeParams::Col_G, 0.8f );
Horde3D::setNodeParamf( light, LightNodeParams::Col_B, 0.7f );

That transform line looks rather painful. I'm guessing it's pos (0,15,10), euler angles (-60,0,0) then scale (1,1,1), but it's still freaky.
Having to set each colour channel of a light separately?

But the more the merrier. Having choice is always a good thing.

[DDd]

lol are you seriously nitpicking with setting lighting attributes?

it's open source, you can overload the function and set the parameters any way you want

[jacmoe]

Dude: You are writing this in the Ogre Forum. Don't expect us to be non-partial.

[DDd]

Dude: You are writing this in the Ogre Forum. Don't expect us to be non-partial.

Yeah! but there are so many features that Ogre3D has that Horde3D does not, it just me laugh that Kojack decided to nitpicking at details. It's such a typical programmer response. I do it all the time too .

For full disclosure purposes i would probably pick Ogre3D for a production project, due to it's maturity. Though i find Horde3D easier to use, due to the C-style API usage, coming from an OpenGL background i am just more familiar with this style. Though as pointed out Horde3D is a full OOD/OOP C++ implementation.

[Kojack]

The colour setting of a light was an example of what the api looks like. It's reasonable to assume that if the api is consistent, then it makes users set other things one value at a time. The sample code doesn't do much, but if lights are any indication then the api looks overly verbose and annoying, requiring many lines of code to do simple things.

Then again, looking at the api doc shows that while most of it is single parameter based, there's also functions like this one:

Code: Select all

DLL void showOverlay(	float 	x_tl,
	float 	y_tl,
	float 	u_tl,
	float 	v_tl,
	float 	x_bl,
	float 	y_bl,
	float 	u_bl,
	float 	v_bl,
	float 	x_br,
	float 	y_br,
	float 	u_br,
	float 	v_br,
	float 	x_tr,
	float 	y_tr,
	float 	u_tr,
	float 	v_tr,
	float 	colR,
	float 	colG,
	float 	colB,
	float 	colA,
	ResHandle 	materialRes,
	int 	layer	)

It also seems annoying that you can only get/set the transformation of a node either 9 (pos, euler, scale) or 16 (4x4 matrix) values at a time. You can't just modify the position without setting the scale and rotation again.

I'm sure some people like it, but the api just doesn't seem that friendly.

[DDd]

That is why there are many changes to the API from beta to beta, as people complain just like you do

I find that having single step parameter settings is good for debugging.
Actually i think there are a few new function to setup just part of nodes, anyway these are issues best discussed in the Horde3D forums.
Then again if you have functions just to set every major part that bloats the API.

That showOverlay function clearly need to be deprecated/changed. I would never use it for nothing more than put a logo or something like that.

[eugen]

clearly C has its advantages but in complex API's C++ should be the language of choice for readability and ease of use
If you think about it is also not quite performance friendly if you have to call methods for each component of a light for example or if you keep pushing alot of parameters on the stack all the time when you could easily do that in one call and one parameter.
Is not about people here dont like Horde3d but is about the reasons people choose one engine over another. It might take you a bit longer to familiarize with Ogre but you will get that time back when actually working with the library and the code.
Otherwise i have no complaint with Horde3d, looks very nice having also the editor worked out along with the engine

[DDd]

That's why you can do that (do changes with only one call) also on Horde3D

setparamf is an accessor method. that lets you set a parameter of a node... i really don't see why the fuss. It's a simple general method, you can create other methods that do any particular set of operations. Extend the system in whatever way you see fit. Anyway i didn't design the API, so i don't know all the reasons behind the design decisions.

[nullsquared]

Though as pointed out Horde3D is a full OOD/OOP C++ implementation.

Just because something uses classes doesn't mean it's object orientated.

[eugen]

That's why you can do that (do changes with only one call) also on Horde3D

SetParamf is an accessor method. that lets you set a parameter of a node... i really don't see why the fuss. It's a simple general method, you can create other methods that do any particular set of operations. Extend the system in whatever way you see fit. Anyway i didn't design the API, so i don't know all the reasons behind the design decisions.

SetNodeParamf is taking the id of the parameter to set as param to the function meaning internally has to make a switch case operation to find out what to set, not too performance friendly also.
I want to point out that i have no problem with the code phylosophy of Horde3d, if you want to get something done quickly you most likely parametrize everything into a function call and deal with it internally, that doesnt mean calling one method to set 100 parameters is more readable or easy to spot into a thousand lines of code file (it would be if programming means writing the code only once and never have to deal with it again). If simplicity means you criptically group sets of parameters under one function call then i have to give up but im pretty sure thats not what it means.
On the other hand, working with methods which are impersonal for each call (you need to learn which method to call by thinking how many params you will pass - as opengl does it) is helping you construct automatisms in the wrong direction. You are not learning about the API and the feature of the code you're using, you're just learning to differenciate function call by number of parameters. In the end you'll end up knowing what method to call but knowing nothing of the specifics of each call and what is their porpose into the general overview of the application.

[DDd]

That's why you can do that (do changes with only one call) also on Horde3D

SetParamf is an accessor method. that lets you set a parameter of a node... i really don't see why the fuss. It's a simple general method, you can create other methods that do any particular set of operations. Extend the system in whatever way you see fit. Anyway i didn't design the API, so i don't know all the reasons behind the design decisions.

SetNodeParamf is taking the id of the parameter to set as param to the function meaning internally has to make a switch case operation to find out what to set, not too performance friendly also.
I want to point out that i have no problem with the code phylosophy of Horde3d, if you want to get something done quickly you most likely parametrize everything into a function call and deal with it internally, that doesnt mean calling one method to set 100 parameters is more readable or easy to spot into a thousand lines of code file (it would be if programming means writing the code only once and never have to deal with it again). If simplicity means you criptically group sets of parameters under one function call then i have to give up but im pretty sure thats not what it means.

I may be missing your point. What to set is given in the function call: Horde3D::setNodeParamf( light, LightNodeParams::Col_R, 1.0f );

Anyway, what i wanted to point out in the previous post is that it's possible to set the transform by using setNodeTransform(...), setNodeTransformMatrix(...). These functions give you a single call access to the most used operations on objects (change translation, rotation and scale). What i understood from previous posts is that some people would like to have separate functions just to set each of the subset values: setNodeTranslation(), setNodeRotation(), setNodeScale() to me this does not make sense, i prefer to have just the setNodeTransform function.

But i guess what you are trying to point out is that there should be a method similar to

Code: Select all

virtual void Ogre::StringInterface::setParameterList  	(  	const NameValuePairList &   	 paramList  	 )   	 [virtual]

Anyway my definition of simplicity is having a compact framework that you can quickly pick up. Reading the Horde3D API takes 30 min at most reading the Ogre3D API takes a bit longer And as stated on Ogre3D API doc:

This is the complete API reference for OGRE; contained within are the specifications for each class and the methods on those classes which you can refer to when writing code which uses OGRE.
It's so BIG!
Yes, yes it is (and thank you for noticing).

[eugen]

I may be missing your point. What to set is given in the function call: Horde3D::setNodeParamf( light, LightNodeParams::Col_R, 1.0f );

For example if you have a 10.000 line of code c file and you want to see exactly where you set the LightNodeParams::Col_R parameter you cannot quickly find it out. Because the same param id is used in getting function calls or other operations. There is no way to imediatelly find out exactly where are the places where you are only setting that. Also is very hard to quick look over code and find out what is the phylosophy since you use the exact same method name to do all sorts of stuff which are not logically related from the application point of view (they are related to an object type but not logically related into the application logical flow)

Anyway, what i wanted to point out in the previous post is that it's possible to set the transform by using setNodeTransform(...), setNodeTransformMatrix(...). These functions give you a single call access to the most used operations on objects (change translation, rotation and scale). What i understood from previous posts is that some people would like to have separate functions just to set each of the subset values: setNodeTranslation(), setNodeRotation(), setNodeScale() to me this does not make sense, i prefer to have just the setNodeTransform function.

It seems it makes alot of sense for other people. I have to agree that having separate methods is better since you only have to deal with logic related to a few parameters which you are interested in setting/getting. If you dont want to deal with multiple problems at once, why forced to. From the application logical point of view, you want to keep things as simple as possible why set the rotation if you only want to set the position. In the case you presented above, if you only have to set the position you need to get the rotation and scale parameters from somewhere to supply that to the method call and that means more code for nothing.
Your argument, that it takes 30 minutes to read through the Horde3d API doesnt realy mean anything when starting to code. Of course you can gasp the initial concept easier than Ogre's (im not even sure of that) but thats not all about making a game/application. The hard work only comes later when you have thousands or houndread of thousands lines of code which you need to understand and maintain.
That said, if you only want to use Horde3d for a few months then initally might seem easier, otherwise is not.

Code: Select all

virtual void Ogre::StringInterface::setParameterList     (     const NameValuePairList &       paramList      )       [virtual]

Ogre uses this approach only in a few places, all method calls in Ogre are explicit to the logical application flow. Normally this construction might seem ok but from my point of view you cannot relay in passing params in this manner; meaning in order to pass params this way for common operations (like setting positions) is too time consuming and bloates the code. Imagine that you need to declare and initialize a struct of params each time you want to set a position, thats just a waste of time and processing power (thats why current good designed engines/application work with natural application structures passed as pointers or references)

My suggestion is this, if the original poster wants to make a good decision of what is easy to use and simple just take a look on what is currently on the market, how other engines are organized and what is the coding design phylosophy. Im pretty sure that over 90% of them are using OOP intefaces and OOP design as their API (just ask yourself why are all doing this and not what Horde does, im sure there are thousands of man hours put in each of the design decision of each engine)

[nullsquared]

setNodeTranslation(), setNodeRotation(), setNodeScale() to me this does not make sense, i prefer to have just the setNodeTransform function.

This violates encapsulation.

BTW: setNodeTranslation() doesn't make sense to me, either. Node::setTranslation() does

[DDd]

For example if you have a 10.000 line of code c file and you want to see exactly where you set the LightNodeParams::Col_R parameter you cannot quickly find it out. Because the same param id is used in getting function calls or other operations. There is no way to imediatelly find out exactly where are the places where you are only setting that. Also is very hard to quick look over code and find out what is the phylosophy since you use the exact same method name to do all sorts of stuff which are not logically related from the application point of view (they are related to an object type but not logically related into the application logical flow)

If i want to find out all the set operations on light1 i simply do a search with "setNode* light1"

Anyway, what i wanted to point out in the previous post is that it's possible to set the transform by using setNodeTransform(...), setNodeTransformMatrix(...). These functions give you a single call access to the most used operations on objects (change translation, rotation and scale). What i understood from previous posts is that some people would like to have separate functions just to set each of the subset values: setNodeTranslation(), setNodeRotation(), setNodeScale() to me this does not make sense, i prefer to have just the setNodeTransform function.

It seems it makes alot of sense for other people. I have to agree that having separate methods is better since you only have to deal with logic related to a few parameters which you are interested in setting/getting. If you dont want to deal with multiple problems at once, why forced to. From the application logical point of view, you want to keep things as simple as possible why set the rotation if you only want to set the position. In the case you presented above, if you only have to set the position you need to get the rotation and scale parameters from somewhere to supply that to the method call and that means more code for nothing.
Your argument, that it takes 30 minutes to read through the Horde3d API doesnt realy mean anything when starting to code. Of course you can gasp the initial concept easier than Ogre's (im not even sure of that) but thats not all about making a game/application. The hard work only comes later when you have thousands or houndread of thousands lines of code which you need to understand and maintain.
That said, if you only want to use Horde3d for a few months then initally might seem easier, otherwise is not.

You have options: 1) Set them all at the same time. 2) Set options one by one. 3) Extend the system by creating a new function.

Code: Select all

virtual void Ogre::StringInterface::setParameterList     (     const NameValuePairList &       paramList      )       [virtual]

Ogre uses this approach only in a few places, all method calls in Ogre are explicit to the logical application flow. Normally this construction might seem ok but from my point of view you cannot relay in passing params in this manner; meaning in order to pass params this way for common operations (like setting positions) is too time consuming and bloates the code. Imagine that you need to declare and initialize a struct of params each time you want to set a position, thats just a waste of time and processing power (thats why current good designed engines/application work with natural application structures passed as pointers or references)

My suggestion is this, if the original poster wants to make a good decision of what is easy to use and simple just take a look on what is currently on the market, how other engines are organized and what is the coding design phylosophy. Im pretty sure that over 90% of them are using OOP intefaces and OOP design as their API (just ask yourself why are all doing this and not what Horde does, im sure there are thousands of man hours put in each of the design decision of each engine)

The reasons are stated on the features page. Easier to use, and easier to bind to other languages.

[nikki]

The api is C based, which makes it very scripting language and alternative language (like D) friendly, but it also makes it very C++ unfriendly.
For example to make a light (taken from the latest sdk example code):

Code: Select all

NodeHandle light = Horde3D::addLightNode( RootNode, "Light1", 0, "LIGHTING", "SHADOWMAP" );
Horde3D::setNodeTransform( light, 0, 15, 10, -60, 0, 0, 1, 1, 1 );
Horde3D::setNodeParamf( light, LightNodeParams::Col_R, 1.0f );
Horde3D::setNodeParamf( light, LightNodeParams::Col_G, 0.8f );
Horde3D::setNodeParamf( light, LightNodeParams::Col_B, 0.7f );

Hmm, that's pretty... Dirty.

But I guess I'm just spoiled by OO ideas. Hardcore C guys would love this.