DeleD Community Edition

[Starnick]

Note: Made a new forum topic since the old one was really for this engine's predecessor.

As you may recall I have my own 3D project, a graphics engine written in C# (.NET 4.0). It's designed to be portable between different graphics API's. Currently it supports a Direct3D10 and XNA 4.0 renderer. Sometime in the future I intend to have OpenGL support.

Well I've recently released it (finally) as open source. And I updated the site with a complete feature list:

Engine Features

Google Code Page

Ohloh Page

One of the prettier examples of it in action is that planetary shader I showed off in another thread.

I use DeleD as my primary modeler, so at the moment only the DXS file format is supported as far as model formats go. But one of my interests that I've focused on is making things easy for artists.

One such example is that the engine has a material script feature. Material scripts are text files that define how a material is to be assembled: what shader to use, render states (per-pass), parameters, engine-defined values. An artist can author a shader, create a new material with it, define colors/textures, etc. Or they can override an existing one, replacing which colors/textures, etc to be used.

This means an artist can author content, and have it rendered without needing to write any C# code (or very minimal, to setup a scene). It's also convenient because you can change materials without having to recompile the source code or digging into it. Eventually I plan to have tools to further promote this (editors and such).

[chronozphere]

Amazing.. It has a pretty solid list of features.

I see you've chosen to use a "classic" scene graph approach. Why did you do that? I wanted to use the same approach for my own engine, but It seemed that this structure wasn't all that nice. Have a look at this thread:

http://www.gamedev.net/topic/464464-anti-scenegraphism-a-tale-of-tom-forsyths-scene-graphs-just-say-no/

I feel that stuffing most of your game actors/objects into one hierarchy seems like a nice abstraction but isn't all that comfortable to work with. You are using Dave Eberly's approach, isn't it? It is one of the nicer scene graphs, but still I try to avoid them alltogether.

But really.. great job. Would love to see what you (or others) can do with this engine.

[Starnick]

Yep, it's heavily influenced by Eberly's descriptions in his engine book, and that of jMonkey/Ardor3D java engines that I've had a lot of experience working with years ago (so that should answer the why).

However, it's not really, really a traditional scene graph. I know there's a lot of hate against them (I've seen that post on Tom's blog) and I think that's because they're often poorly defined and abused, being a structure where everything's dumped in.

Tesla's scene graph is really nothing more than a transform hierarchy / BVH / light hierarchy (with sorting). It's more of a stripped down version of some of the things Eberly described (e.g. Render states are really independent of the scene graph, moving to a shader-based renderer made render state inheritance rather awkward). The lighting is included in the scene graph mostly because that can be closely tied to the Spatial structure of a scene, and having it tied to game elements would be odd since...the engine doesn't have any.

I should point out that Tesla is a -graphics engine-, not a game engine. I wouldn't recommend using the scene graph to represent game entities (I've had failings at trying to do that in the past, one of the biggest problems I always had was how entities communicate with one another, which the scene graph only made harder, not easier). I really like scene graphs, but only in context to organizing a scene - not a game.

Note: If you noticed, there are still controllers that can be attached to the scene graph (very Eberly), but in my opinion they're small potatoes and should not contain a scrap of game logic.

Instead, I prefer having an entity database. An entity references its model in the scene graph, e.g. mostly to get at its transform, but keeps its logic separate. Of course this means the user has to implement all of this themselves. But if I were to do it, I'd have to go all the way in providing a package that facilitates game development (which is bit of a herculean effort for a single developer), since I'm telling the developer how they have to organize their game, according to how I've put together those systems. So there's pro's and cons to having this absent from Tesla.

And as a final note, the scene graph could be extended (e.g. quad/oct trees) or ignored. You can either override the existing Mesh/Node classes or roll your own scene structure completely. The graphics system and Renderer really do not require the scene graph to be used, and can still be beneficial even if you don't. The same thing pretty much goes for all the engine objects outside of the Tesla.Scene namespace.

[Starnick]

Just looking at some of the links from that thread you posted:

http://www.gamedev.net/topic/110342-terrain-and-scene-graphs/

From the first reply of the poster Yann, ultimately describing a scene graph:

"It's a high level, standarized representation of your scene"

That's something I agree with. It's an easy way to organize your scene, not necessarily your game. It's all related data, but there should be multiple "views" for different contexts. And in a scenario where an enemy ship is firing a laser to blow your ship up, that can be viewed different ways. One would be how its represented in the scenegraph, the other would be that entity map* I mentioned with how the ships and the lasers communicate with one another.

At least that's my opinion. As I said I like scene graphs, but everything has its advantages and disadvantages.

*Heh that's actually a game I'm working on right now. My entity database is big on using event delegates where entities will subscribe to various event handlers for notification on the more important details (getting hit, blowing up, etc).

[Starnick]

I've also had some minor experience/exposure to Valve's source engine (mostly in server-side modding for TF2 though), but I've gotten to know a bit about how their entities are managed. I believe its only a global entity list and nothing more, but what's important is each entity can have a set of inputs and outputs (like a black box) where outputs of an entity will trigger the inputs of another entity, causing it to change.

I really like an event/trigger based entity communication system. But that really would sit ontop of what's in Tesla atm, and not be a core feature.

[Jeroen]

@starnick: I'm impressed by the way you are able to explain things - you have a way with words.

About scene graphs: I was thinking about their usefulness in an editor like DeleD. Without having read much on the topic, it seems that scene graphs are most useful in a rendering context: as in, it being a tool to be able to quickly render scenes. Is that correct?

In a 3D editor, objects are (obviously) moved around a lot. Seems to me that this means you'd to rebuild the scene graph constantly, right? Which would have an impact on the usefulness of the scene graph in 3d editors in general.

In DeleD, the scene simply has a list of primitives which are all rendered. A scene graph, however, usually exists in the form of a tree (be it an octree or whatever tree). I can see trees being useful for grouping functionality, where primitives have children. So... suppose we refactor DeleD so its primitives are stored in a tree, would that tree be called a scene graph?
_________________
Check out Figuro, our online 3D app! More powerful 3D tools for free.

[Starnick]

Some would say a scene graph would be inappropriate for a rendering context, and all you really need a scenegraph for would be to represent a transformation hierarchy. Where in actually rendering the scene you just dump everything into a list, cull objects that don't belong, sort the list, and render.

Technically when you invoke the Draw() and OnDraw() (which performs the actually culling) methods in Tesla's scene graph, when a leaf node (Mesh) is found it gets added to the Render queue and not actually drawn. Rendering takes place after the scene graph has been traversed by a separate call to the renderer, which then all the buckets in the render queue are sorted and rendered in order.

Rather than having to assign your model to the scene graph, and then assign each Mesh to some sort of uber list of IRenderable (in the engine meshes inherit from IRenderable, which is how the renderer is decoupled from the Tesla.Scene objects). Using the model in one place, by attaching it to the scene graph, and letting the engine automate the rest is a lot less tedious and error prone.

For DeleD, a scene graph would be useful in logically organizing the scene. Although like you say, objects get moved around - so the scene graph may no longer be spatial-coherent. This could be a problem in my scene graph also, since I incorporate the BVH - two objects grouped to a node, that are so far apart that the subtree would never get culled because the objects are always in view since the volume that encapsulates them is always so large. But sometimes you want this - e.g. the root node (which is purely logical).

Of course you could have a structure that will constantly rebuild the scene graph and ensure close together objects are grouped (ala oct-tree or other spatial indexing structures). But then that kind of defeats the idea of being able to logically place nodes and group objects since that grouping may change.

I would think a tree of primitives would fall under the scene graph category, it is a vague term after all. But I don't know the benefits, since each primitive (and we're talking triangle here right? Not an entire object with a triangle list?) wouldn't normally have its own transform. But you do have structures like that (BSP for instance). I would think a tree of primitives is more useful though in the context of collision detection for triangle-accurate tests. I've seen collision trees where the primitives are organized in a balanced red-black tree structure.

[chronozphere]

Wow, long replies.

I agree, it makes much more sense when you are managing scenes which are more or less static. In games, things move around and the many different relationships objects have, make things even more difficult. For my current project, I have the following in mind:

I separate the engine into subsystems. Each subsystem controls one aspect, like physics, graphics, audio, input etc.. And then there are actors which tie everything together. Each actor may own multiple entities from different subsystems). So there are for example, MeshRenderEntity, FontRenderEntity, AudioSourceEntity, RaceCarInputEntity, RigidBodyEntity etc.. Actors can instantiate these entities and implement underlying logic to make them do usefull things. All elements in the game will be Actors, but there will also be UI-Actors, or actors that act merely as controllers or even entire game-states.

So, Infact I have dropped the idea of having a tree of objects that each have a generic set of data-fields such as BoundingSphere or Transform. Such trees can be implemented by individual subsystems to optimize performance. If I need it, I will introduce a Spatial subsystem that may support spatial queries and occlusion testing, but I think I can do simple and effective culling in game-code (for my current project) rather than designing a generic spatial engine.

Does this sound like a good design to you?

Just curious.

[Starnick]

Well, the tree is for dynamic objects too. I never liked the idea of separating the two out (e.g. a lot of people have an IMoveableObject interface). Technically everything's "moving" when you transform a scene to the screen, and really a movable object interface is more of a precursor to physics (and even then not everything that moves may need physics). Everything should at least have some sort of position, otherwise it wouldn't be rendered, so separating static vs dynamic to me is pointless.

I think a big problem we've been discussing here relates to coupling issues, and you don't have to be a tree structure to have those. Good design, proper interface usage (e.g. the whole idea of different "views" of the same data), regardless of the application should mitigate these sorts of issues.

I can't really comment on your entity layout because I guess I would have to see it in action. But to me, if you have everything derive from some sort of entity, and your basic entity has children which are called MeshRenderEntity, RigidBodyEntity, etc that's still bit of a tree hierarchy. And coupling issues still can arise if each of those child entities are managed by independent systems that may not talk to one another. Unless if you have the entity that owns the child be in charge of its creation/destruction. But then that goes back to my first point heh.