DeleD Community Edition

[Starnick]

I've been talking about an engine I've been working on every now and then, and I've recently been making some videos showing it off (for a presentation about it), so I thought I'd post about it!

Material & Lighting Systems
http://www.youtube.com/watch?v=vOxVtG8zfaw

Frustum Culling
http://www.youtube.com/watch?v=9wtThxQgiu4

Spark is a scene-graph based graphics engine built ontop of the XNA Framework (so its implemented in C#). Currently, it's just intended for windows, although an Xbox 360 port is something I do one day intend (during development, I do try to keep it 360 friendly).

Technically it's open source, but its still somewhat "unreleased". Since it is a school project, it may undergo a name change and become launched as a new project.

Unlike a lot of "xna engines" out there, I do intend this to be fully featured. It's heavily based on concepts featured in David Eberly's "3D Game Engine Design" book (which jMonkey, the engine I previously used extensively was rooted in) with its scene-graph design. Current features include:

• Extensible Material & Lighting system
  
• Integrated Shader Library (basic + advanced materials)
  
• "Smart Renderer" that does the following:
  -Spatial sorting (transparent objects back to front, opaque state sorting)
  -Render State Caching (keeps track of last state used, to reduce redundancy)
  
• DXS Support (DeleD and Maya are currently our top two modeling tools, as XNA has default support for .fbx)
  
• Integrated Bounding Volume Hierarchy (BVH) in scene graph
  
• Scene-graph handles all updates automatically, and keeps track of when data is changed, so it doesn't do redundant updates if data hasn't changed
  
• Collision (and picking) testing and response
  
• Easy to use and extensible input system
  
• Simple skeletal animation system
  
• Much more like a shape library, spatial controllers, game screens for UI layering, and so on
  

There is also the beginnings of a game library (world objects, user-defined collision volumes, entity system, etc) is also in development for a project utilizing the engine. Eventually I'd like to put the "game" in "game engine", and eventually branch out to tools such as a world editor. This would make the engine, game library, and tools essentially be its own little framework.

However, the engine is designed to be easily extensible (especially where shaders & lighting is concerned). For instance, the scene graph is fairly "dumb", there's no spatial partitioning like a quad tree or oct-tree, but users can easily make their own implementation, and extend the scene graph to use it.

This is actually a bit of a problem I've seen with a lot of XNA-related engines out there, and one of the reasons why I started this project.

About 8 months ago I started this project for an Honors Thesis/Senior Design project (the design project used the engine to create a small game last semester, and a little puzzle game this semester). Originally for my thesis, I intended to do primarily shader & effects work, but I found myself doing more and more engine-like tasks for our design project (such as the scene graph). I wanted to have more convenience, like I had with jMonkey, in making scene objects...and now 8 months later I have Spark Engine v.6 heh.

Edit: Shoot just realized I didn't include light mapping in the effects video. A bit ago I implemented light mapping (from DeleD), here's a picture:

[trucker2000]

Now that's really cool. Your choice of music fit perfectly. I especially like the environmental mapping demo. Really cool.
_________________
Some day I will grow up and be a real modeler.
"Never give up! Never surrender!!"
Sys specs:
asus
8 gigs ram
Invidia gtx560 video card
Windows 8 (worst op sys Ever)

[Starnick]

[Paul-Jan]

Awesome video! I'm currently implementing a "basic" 3D engine for the day-job (with some application-specific sugar coating on top), and this was very inspiring. As it turns out, it can be a bit difficult to discuss feature planning and minimal requirements with an audience that is unfamiliar with these 3D graphics concepts (but otherwise very knowledgable), and your video does a great job explaining and showcasing stuff.

Questions:
- mind if I use your video as a showcase for the basic lighting / material concepts? It won't be promoting your engine, but it will help me a great deal in communication .
- although it's somewhat "unreleased", I'd really to browse the source... I'm especially interested in the exposed interface to the user (developer). My own target audience consists of seasoned developers with very little knowledge of graphics, which can be a though combination at times.

[Starnick]

[Starnick]

Also, I'm taking any and all suggestions for a better engine name. For the life of me I couldn't think of a better name than "Spark" since I started this, and the name kinda sounds puny now considering a lot of the performance gains I've made with the engine lately (I've been thinking of maybe "Tesla" to continue the electrical motif).

You'd think it would be an easy thing working with it almost daily and being its creator, but I haven't thought of anything snazzy yet so spark kinda stuck!

[Paul-Jan]

Hah, I now see I can scratch "look into XNA again to see if it has improved" from my todolist. Yours looks lots better. Oh, and thanks for letting me show your movie, I'm sure it will help a great deal explaining stuff.

Love the rotation controller. I did take a more classic approach to the scene graph in my engine: meshes and other dynamic objects are explicitly attached to nodes, but aren't themselves "nodes".

If the application builder doesn't like this setup, and wants to transform the "mesh" directly, they can simply abstract this away by using a wrapper object around both the mesh and the node (I actually do this in the target application).

My engine setup is generic, but currently I'm only implementing the DirectX (9, 'cause I'm in Win32 land here) backend.

Thanks for the heads-up on the shaders, I was wondering how tesselated those models were to make those lights look as high-res as they do . My engine is still fully fixed function, but I'm soon hitting the point where I have to mix in shader code. Something I've never implemented in an engine before, and I've yet to find a third party engine that handle this stuff to my liking. Oh well...

As a side-node, the OpenGL (and co) attenuation function is totally non-practical for most artists. Yes, I´m saying the choice we (me) made in the DeleD lightmapper is wrong. And yet I´ve implemented a similar setup in my engine as well, but at least this time I've made a note on the todo-list to get rid of it.

Regarding the name, I actually like spark, so perhaps something in the same line but stronger? Names like
- Brilliance (or Brilliance 3D, etc)
- Gleam
- Luster
- Beam
- Blaze

I like Tesla as well, but to me the word Tesla is associated with "very strong but old-fashioned", or even "retro".

But I'm just mind-wandering here, so I'll shutup now.

[AWM Mars]

what about:

Radiance

Radiate

Rayzor
_________________
Politeness is priceless when received, cost nothing to own or give, yet some cannot afford.

Checkout:
http://www.awm.mars.yourinside.com/
http://www.bccservices.co.uk
http://www.localtradecheck.co.uk

[Starnick]

[Starnick]

Also a note about RenderStates:

There's Global and Data type states, the global are your traditional (BlendState for alpha blending, CullState for changing the polygon cull mode, FillState for changing if polygons should be wireframe, solid...ZBufferState for changing depth buffer values). Where as we have three data type states (mentioned as TextureState, MaterialState, and LightState). While the renderer applies the global states directly to the device, these three get set to the object's shader during the definition updates (as mentioned above).

Now the cool thing (and this is still a TODO feature, but its something seen in engines that mine is based off of), is you can have a LightState attached to your root node (and only that node).

When you attach it, it propagates a dirty mark (bit flag) down to its children, so when they go and update their world render states the root node's light state would be passed down. This light state can be combined with other light states in the tree by a mesh, and it'll pick up the closest lights up to the maximum.

So even though a lightstate may have dozens of lights (or multiple light states exist for parents of a mesh), the mesh will only pick the 8 (or more, or less if you change the max) closest lights to be sent to the shader.

Same can be done with combining texture states also, although I'd imagine its more useful for lightstates.

As I said this is only a planned feature, at the moment setting of renderstates (and materials) is a rather dumb process heh.

[Starnick]

Some more comments (this is good, because I'm taking bits of this from my thesis Im writing...good to try out my explanations out on people hehe):

Mesh-Node-Spatial relationship

The three main scene objects have this special hierarchy primarily to make it easy to create a scene graph. For some stuff, it doesn't matter what it is as long as its a spatial, so you don't have to worry about is it a mesh or is it a node as long as you care about the common properties shared by both.

With that said, from Eberly's book (and in jMonkey), the mesh side of things are a bit obfuscated. They dont have a "Mesh" but a "TriMesh" that's only a triangle mesh, and it extends from a "Geometry" class that extends from Spatial directly. This is reasonable to a degree, but it adds some unneeded redundancy.

In Spark, the concept of a mesh is a lot simpler and a bit more elegant. The actual mesh data is abstracted out of mesh in the form of a "MeshData" object. This is the object that contains the vertex and index buffers (indices optional too), and primitive data doesn't have to be triangles either. MeshData fully supports point lists, line lists, triangle lists, and triangle fans (pretty much all the primitive types XNA supports).

Also doing it this way, MeshData can be shared between multiple meshes. The geometric data doesn't change at all regardless of how you transform it (that's the job of the world matrix after all). That's the Mesh object's role.

This also makes it painfully easy to extend the MeshData class too. E.g. by default it supports for each vertex (or index): position/normal/tangent/binormal/color. What about skinning when you have bone weights and bone indices? The animation system I developed simply adds a SkinnedMeshData object with those two extra lists, and creates the appropiate vertex buffer during reconstruction. There's no reason to change the Mesh class!

There is one nasty thing at the moment with MeshData unfortunately, and its with vertex declarations. For the moment, I have all the vertex formats hardcoded that I use, and the MeshData basically goes through all the permutations when it reconstructs the vertex/index buffers. Really really ugly, and it doesn't lend itself to be easily used with custom vertex formats unless if you extend it. It's been an issue that I haven't thought of an adequate solution to yet.

[Starnick]

Man almost an entire month passed by. Just got my thesis finished and approved today, all about Spark Engine and its development (as well as mine)!

Now I'm free to return back to work on all of this

[AWM Mars]

Please keep us posted.. sounds very interesting.

You may want to consider having a MP4 exporter.
_________________
Politeness is priceless when received, cost nothing to own or give, yet some cannot afford.

Checkout:
http://www.awm.mars.yourinside.com/
http://www.bccservices.co.uk
http://www.localtradecheck.co.uk

[chronozphere]

This is looking really cool. I'm also making a game-engine with Pascal at the moment. It should have the following features:

> Windows and Linux support
> OpenGL 2.1 graphics (fully shader driven)
> Forward compatibility with OpenGL 3.2 (to make a migration easier)
> Support for rendertargets, fonts and particlesystems
> Easy-to-use render state management using stacks
> OpenAL 1.1 3D sound (multiple movable sources) and OGG music
> SDL keyboard, mouse and joystick input
> Really simple & to-the-point scene management

Hope to get it working ASAP. It will be supporting my game project for the IGF.

Have to take some time to read through these posts. I may have some questions about your engine.

[Starnick]