DeleD Community Edition

Starnick · DeleD PRO user Joined: 28 Jul 2007 Posts: 611

Well in regards to Mesh and MeshParts, that resembles my engine's scene graph which has the following hierarchy:

Spatial is the root (analogous to your SceneObject) everything in the scene inherits from this. Spatial holds everything common to every scene object, such as a parent, local/world transformations, world renderstate info, world bounding information, etc.

Internal scene nodes are simply the class Node that can have any number of children and support operations to access/update those kids.

Leaves of the scene graph are visible geometry, represented by the base class Mesh. Meshes contain a MeshData, material information, local bounding information, and local render state information. They also contain the actual calls to the renderer to draw geometry.

The idea between local/world information is when the scene graph gets updated, information is propogated up and down the tree, that way you can set a single renderstate (or bounding volume) to an entire branch of the tree or have the world bounding volume of a node with children updated to fully contain the volumes of its children.

And finally arriving at the point of this explanation...the MeshData class contains the actual geometry. This separation allows for geometry to be shared and loaded only once, but be logically different. So you can have two tanks that share the same data, but can have different bounding or transform data associated with it. Of course, if you're interested in repeating geometry in different locations then something like hardware instancing will be faster since regardless of the shared data, you're still going to have two draw calls.

The general structure was inspired by David Eberly's design in his 3D Game Engine Architecture book.

Now in regards to a real time 3D editor, the idea to separate geometry may not be as beneficial since there are few cases for sharing data (since you're creating it!).

AWM Mars · Posted: Sat Oct 02, 2010 12:26 pm Post subject:

Isn't this another way of describing Layers?
_________________
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 · Posted: Sat Oct 02, 2010 3:06 pm Post subject:

AWM Mars · Posted: Sat Oct 02, 2010 4:35 pm Post subject:

Starnick · DeleD PRO user Joined: 28 Jul 2007 Posts: 611

chronozphere · Posted: Sun Oct 03, 2010 9:09 am Post subject:

Ewout · Member Joined: 15 Sep 2010 Posts: 45

The scene layer with treeview idea is nice. You can also make an easy drag-drop interface around it. People can build own components to hang in the tree. I think it's a good idea. I can't think about some disadvantages.

Anyway, i found a chapter about 3D Game Engine Architecture by David H. Eberly on GameDev.net. Going to read that one, because I don't know the complete principle Starnick talked about in his previous posts.

AWM Mars · Posted: Sun Oct 03, 2010 7:23 pm Post subject:

chronozphere · Posted: Sun Oct 03, 2010 7:47 pm Post subject:

AWM Mars · Posted: Mon Oct 04, 2010 9:04 am Post subject:

I have seen it implemented in other platforms. The most intuitive was based visually on a PC filing system that you see in Explorer. Root directories, that include child directories. Graphically, in the viewports, each layer could have its own colour, and all objects in a layer, would adopt its colour in the bounding/selection box.

Having 'top root commands' for each layer, such as Hide, Show, Lock, Unlock etc would be useful as a Right Click menu, as these are more than likely to be used more than other commands.

Being able to drag an entry to a element, to a different layer, would be a good work-flow. As would be preselecting a layer, then adding a object to a scene, that would appear in that layer.

Selecting a object in the scene, would display its layer information, say in the status bar, so it can be found easier. This would also show properties in the correct menu window (assuming its open and displayed).

One very useful tool I used in Atmosphere, was the ability to select a script, hold down the left button and drag a 'pointer' to a single, or multiple objects, that would link the instance. Any edits to the single script would apply to all the linked objects. This was known as a whip in Atmosphere builder. It would also be useful to have procedural script linking, for us non programmers.
_________________
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

Ewout · Member Joined: 15 Sep 2010 Posts: 45

I think using layers or treeview is both layer based. Alltough this is more a GUI decision instead of an technical decision. The GUI comment of ATM Mars (latest one) sounds like the easiest one for artists to understand.

I've also read the chapter and I think we absolutely could use some of that architecture (especially the Spatial part).

oliebol · Member Joined: 30 Dec 2009 Posts: 8 Location: Eindhoven

Personally I think:

- the advantages of C# is more that more people use it in the daily occupation. People instinctively try to use the same stuff they do in their daily occupation, but often don't see that the daily, fulltime practice changes faster than you can afford in an open source project.

- I think the safety and ease aspect of VM languages is more for trial and error and small apps programming, and shouldn't be overrated (to the user it doesn't matter if a program crashes from a nil pointer exception or an access violation).

- the VM languages have slow starting times which are fine for server work, but suck for clients.

- Even if you buy into the productivity aspect, you need to stick to it for quite a long time with the choices you make (language, GUI/framework version) to earn back a major migration of a non trivial codebase. For progress it is often more worthwhile to stick with a true and tested version.

- Be very careful with simplistic arguments about portability of specially Mono. On paper it works, and it works for trivial stuff, but it might not be that easy in practice for non trivial stuff.

- I assume the C# version would have a OpenGL GUI, but otherwise Winforms vs WPF would be a major battle. OTOH, the recent deprecation of silverlight might meanthat the focus of Microsoft for major development swings back to WinForms.

That said, the other side has problems too:

- Delphi, while far from dead, no longer has a free version
- Lazarus/FPC is a bit rough, and while i think it is doable technically, if minds are already divided, I doubt such a project will reach the finish line.
- The influx of new members will have decreasing Delphi (and even native) abilities and affinity.

On the other hand, that goes for every choice that has a major change in direction, and betting on large external hordes of people that will join is always dangerous.
(the C# and Java hordes might stick to projects that have already started in C# instead of trying to port native codebases to it)

This because for a major rewrite in C# you might need vastly more manpower than for even a major rearrangement in Delphi.
_________________
Marco V

Daaark · Posted: Tue Feb 15, 2011 12:02 am Post subject:

The language comparisons here are hilarious, and look like they were written by people who've never built an app that does anything. C# is no 'vm' language, it compiles JIT to native code.

Also, they are not slow, or insuitable for clients. Even high speed games running on limited platforms use these type of languages to execute 99% of their logic with C++ simply acting as the main hub. Even Unreal Script used to be interpreted in real time back in the 1990s.

Most content editors these days have all their commands and interface implemented as python or mono type languages scripts anyways.The C++ hub just starts the program and runs the appropriate scripts...

C# / SlimDX / WinForms seems like the smartest and easiest route to go. C# is perfect for this kind of app.

There is lots of talk of advanced features here. IMO, you should focus on producing a basic, vertical slice and build up from there.

A lot of stuff described here (like layers) is already implemented and working well in Blender. Just grab a copy of Blender 2.5 and use it to compare notes.
_________________

zarfius · DeleD PRO user Joined: 06 Nov 2008 Posts: 7

I totally agree with Daaark when it comes to choosing a language such as C#. I've been programming for 20 years and I've used a whole bunch of languages from C++ to java to C# and a heap of things in between.

C# is by far the most productive languages I've ever used for most application development. While I agree there are good reasons to use other languages when your developing performance critical bits of code or cross platform stuff you really can't just say one language is better than another without carefully considering what your about to implement. Sometimes, it's even a good idea to have a mix of languages.

So please, before you go and say VM's are slow or dependencies are huge please do some research of your own first. In many cases it's simply not an issue.