Horde3D

Hi! I'm new with Horde3d: it sounds like a very good designed 3d graphics engine.

I want to make some questions about its structure:

1. Horde3D is a "next gen" graphics engine, but is it possible to use the fixed pipeline too?

2. Horde3D is "only" a renderer, with (graphics) resource managment. Suppose i want to make a high-level engine which uses Horde3D for graphics (and, for example, OpenAL for audio, Bullet Physics for physics calculation, etc.): i think the best design should have separated and interconnected "managers" for a clearer component structure, so what do you think about to divide "resource management" from "scene objects management and rendering" in two different branches of Horde3D project? In this scenery it would be possible to create an high-level engine which uses “Horde3D Renderer and Scene Management” like one (or two separated) component(s) and extends “Horde3D Resource Management” (with Collada support) to import audio, video and game logic resources.



I think that an high-level all-in-one engine based on Horde3D might be very attractive and powerful!

What is your opinion?

Bye!

Emanuele “Zuck” Bertoldi

Answers:

1) Yes. Horde's pipeline is flexible. The Chicago example's pipeline "pipeline_chicago.xml" contains both deferred and forward shading. By default the deferred shading is commented out but you can easily edit the pipeline to use it instead of forward shading.

2) You can go about it anyway you like. Though I'd read about Horde's node attachments of its integration support in the Horde Manual
http://www.nextgen-engine.net/docs/_usageguide.html#Integration

Opinions)



Yes I agree with that (mostly) or I wouldn't be a quarter way through toolset development.

I disagree with your approach to design. Design from the a lower perspective first and you'll find out just how much engineering you really need.

Yes, but in that page there are only a few rows about this argument. The attachment data approach sounds interesting!



Can you explain more this point, please?

Explaining more:
There's nothing inherently wrong with your approach, I'm actually making several assumptions about your design which may be false.

Think about when you're actually binding all these different things into a final object like an entity, special effect, weapon, sound emitter, etc. Figure out how all that should work before you start even thinking about systems.

Look over what you wrote for a high-level engine. Doesn't it look more like a wrapper than anything else?

Right off the bat it looks more like you've been thinking about the "How" of nothing instead of the "How" of "what."

There's Doom, Unreal, CryTek, Source, and etc engines for reasons aside from, "Well we'd like to code it ourselves and maybe save some money too while making money licensing it out." They have their own needs.

I'm willing to bet that no one on any of those teams is one of the true top 100 programmers in the world. All of the super-elite most likely go unnoticed working a 'normal' programming job.

Yet all those engines outperform the generalized Yake engine. Yake is even opensource, so why isn't Torvaldes' law of bugs helping it become of faster? There's nothing wrong with Yake, but it's built as a "How" to a vague generality and not to specific needs, so it does general well, but general doesn't mean that it performs well across the board.

Moral of the Story
If you have your specific needs and know how your lower level stuff will work then your higher level stuff will all fall into place.

This is why I only "mostly" agreed with:


An engine built with Horde3D that knows what it wants to do and does it, will be attractive and powerful.
An engine built with Horde3D that says "I want my hand in every cookie jar." will either suffer the woes of generality or never be completed.

-----------------------------------------------

You can't be a bodybuilding, fashionable, brilliant, conoisseur of: alcohol-jewels-drugs-history-math-psychology-philosophy, backpacking, surfboarding, jetskiing, daredevil motorcycling, skydiver who's an expert on all subjects yet unlisted (unless you're James Bond).

You can however be a Conoisseur of alcohol who is pretty good at math, intimate with the philosophical classics, is in decent shape, and has a modest collection of D&G belts and but still mostly wears Express.

-----------------------------------------------

It applies to programs, think low and you save yourself a lot.

Hi Zuck,

1) I guess you mean if Horde could use the fixed function pipeline for old hardware without shader support? That's practically not possible since most features are based on shaders. Of course it is easily possible to get some simple rendering on fixed function (in fact the wireframe debug mode (F7 key) is fixed function) but nothing really useful.

2) What you propose would make Horde ultimately a game engine. As AcidFaucet indicates generic game engines are hard to make since every game has its very own needs (some have destructible environments, others enormous landscapes and some might play in small dungeons but have hundreds of characters). For each of these requirements you need a specific design approach to make things efficient. Futhermore for a game engine you need many more things which Horde currently doesn't have like events, a messaging system, threading, io routines and so on.

I probably wouldn't try to share the Horde resource manager for a game engine. It is perfect for Horde but your game probably needs more specific features like loading of resources from archives, threaded background loading or similar. I would suggest that you write a separate resource manager for your game engine which does what you need and just forwards graphics related data to the Horde manager. The advantage of this approach is that it is much safer since you don't have to touch the graphics code and it can't happen that the rendering suddenly breaks because of some changes in the Horde managers. In general I would consider Horde as a closed component, a component only responsible for displaying your data.

An example: In a game engine your world could consist of a list of entities and some can have a graphical representation. These objects that have a graphics component could just store a handle to the corresponding scene graph node which gets updated when the object is moved. Of course this is just one idea to realize an object model for a game engine, there are many more all with their pros and cons.

Hi Marciano

1) Ok, no fixed pipeline. Thanks

2) First: i don't want to invite you to make Horde3D a complete game engine, ok?

My previous post is only a question about a possible (quite small) change of Horde structure for simplify the life of user programmers who want to use Horde3D as the rendering component in their high-level game engines (obviously this is my wish too ).

This is my idea: Horde3D would be a indipendent component of a high-level engine, like in the block schema of the previous post. Nothing of game engine details should be entered in the Horde code but viceversa.

I don't ask you to code an engine, i ask you if is it possible to lightly modify the horde structure (if you consider it a good solution) to permit third-part programmers to make complete game engines based on your Horde work (because Graphics, Scene Management and the major part of Resource Management are already implemented)

- Current:

Link

- Proposed:

Link

This is only a design possible idea

I'd suggest you do a few demos just in Horde before you decide to wrap parts up in two new namespaces/objects (w/e you've chosen the package as a substitute for). You may want to refresh on O-O design a bit. Wrappers are not good solutions to most problems.

Might want to think about why you're binding outside stuff with Horde's resource manager. Odds are that you shouldn't.

I'm currently working on a "Game-engine" which uses Horde3D as the rendering module, and I'm quite happy with the level of integration provided by the current resource manager implementation.

Horde's resource manager doesn't actually do any loading of data, it leaves that up to the application. This means that my engine's resource manager can easily wrap-up horde resources already (without having to modify Horde at all), in order to provide an interface that is consistent with the rest of my engine.

Hi DarkAngel! So, your implementation is similar to the first image?

Repeat: i don't want to change nothing in Horde, i only ask you the best solution to make a high-level game engine with Horde3D for graphics. I've proposed my solution but it's only a proposal: if there are other better solutions to make this (i hope), i'm listening to you

Yes, it's similar to your first image.

I've got a resource manager class which has lots of functions like LoadScene(char*filename), LoadAnimation(char*filename), LoadMaterial(char*filename), etc...

Then I've got a set of classes to represent each of these resources. All of my horde wrapper resource classes implement from CHordeResource, which contains a Horde3D ResHandle.

so my implementation of a Scene resource is something like:

ok, thanks!