Delgine 3D Tools & Content DeleD Community Edition
Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

DeleD (re)design discussions
Goto page Previous  1, 2
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    DeleD Community Edition Forum Index -> DeleD Development
View previous topic :: View next topic  
Author Message
Starnick
DeleD PRO user


Joined: 28 Jul 2007
Posts: 611

PostPosted: Fri Oct 01, 2010 9:21 pm    Post subject: Reply with quote

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!).
Back to top
View user's profile Send private message Visit poster's website AIM Address
AWM Mars
Member


Joined: 06 Jan 2010
Posts: 1195
Location: Wilts England

PostPosted: Sat Oct 02, 2010 12:26 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
chronozphere
DeleD PRO user


Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands

PostPosted: Sat Oct 02, 2010 3:06 pm    Post subject: Reply with quote

Quote:

Isn't this another way of describing Layers?


You mean photoshop layers? Nah, this is quite different. Wink

Quote:

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


I have that book. It's very good and we could certainly use ideas for our design. But, as you mentioned, not every idea in the book is applicable to 3d editors.
Back to top
View user's profile Send private message
AWM Mars
Member


Joined: 06 Jan 2010
Posts: 1195
Location: Wilts England

PostPosted: Sat Oct 02, 2010 4:35 pm    Post subject: Reply with quote

chronozphere wrote:
Quote:

Isn't this another way of describing Layers?


You mean photoshop layers? Nah, this is quite different. Wink

No silly, I mean Component Layers. You create a Layer in the Scene Tree, you can place objects, scripts, virtually anything, including child elements. Then you can control those layers, turning them on and off (hide/show), apply things/functions etc to them.. etc
_________________
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
Back to top
View user's profile Send private message Visit poster's website
Starnick
DeleD PRO user


Joined: 28 Jul 2007
Posts: 611

PostPosted: Sun Oct 03, 2010 3:17 am    Post subject: Reply with quote

AWM Mars wrote:
chronozphere wrote:
Quote:

Isn't this another way of describing Layers?


You mean photoshop layers? Nah, this is quite different. Wink

No silly, I mean Component Layers. You create a Layer in the Scene Tree, you can place objects, scripts, virtually anything, including child elements. Then you can control those layers, turning them on and off (hide/show), apply things/functions etc to them.. etc


That would be possible...I've seen something like that in regards to game states that can be its own independent hierarchy or decorate the actual scene graph. Not sure about scripts and such though (maybe give an example?)

Such a thing also reminds me of how I did lights and textures in my first graphics engine attempt with Spark (based on Eberly's design, and the jMonkey Engine). Lighting and textures were defined under the render state system. So you could just add a light inside a lightstate to the root node, it gets propagated down the tree and each geometry then sorts the nearest 8 or so lights (or how many your system supports).

In this sense I wouldn't exactly call them layers though, but probably more of an attribute.
Back to top
View user's profile Send private message Visit poster's website AIM Address
chronozphere
DeleD PRO user


Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands

PostPosted: Sun Oct 03, 2010 9:09 am    Post subject: Reply with quote

Quote:

No silly, I mean Component Layers. You create a Layer in the Scene Tree, you can place objects, scripts, virtually anything, including child elements. Then you can control those layers, turning them on and off (hide/show), apply things/functions etc to them.. etc


Lol, indeed a silly assumption. But you didn't explain yourself in the first place. Razz

We are initially just making a single hierarchy. Not sure if we want multiple at the same time, forming layers. It would make things more complex. I rather keep the program as simple as possible. Smile

We do need a good system for lighting and renderstates. I think eberly's approach would be a good start.
Back to top
View user's profile Send private message
Ewout
Member


Joined: 15 Sep 2010
Posts: 45

PostPosted: Sun Oct 03, 2010 5:34 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
AWM Mars
Member


Joined: 06 Jan 2010
Posts: 1195
Location: Wilts England

PostPosted: Sun Oct 03, 2010 7:23 pm    Post subject: Reply with quote

Starnick wrote:
AWM Mars wrote:
chronozphere wrote:
Quote:

Isn't this another way of describing Layers?


You mean photoshop layers? Nah, this is quite different. Wink

No silly, I mean Component Layers. You create a Layer in the Scene Tree, you can place objects, scripts, virtually anything, including child elements. Then you can control those layers, turning them on and off (hide/show), apply things/functions etc to them.. etc


That would be possible...I've seen something like that in regards to game states that can be its own independent hierarchy or decorate the actual scene graph. Not sure about scripts and such though (maybe give an example?)

Such a thing also reminds me of how I did lights and textures in my first graphics engine attempt with Spark (based on Eberly's design, and the jMonkey Engine). Lighting and textures were defined under the render state system. So you could just add a light inside a lightstate to the root node, it gets propagated down the tree and each geometry then sorts the nearest 8 or so lights (or how many your system supports).

In this sense I wouldn't exactly call them layers though, but probably more of an attribute.

I suppose they are more of a graphical way of showing bindings between objects and elements. The ability to drag say a light into a particular layer, so when you turn off the layer, it will hide that light, or terrain, tree, building etc etc. Apply a script to a layered element, would also be effected by the functions applied to the layer. This could be say a particle, or animation script, physical 'move to' behaviour, shader etc. Layers could also be used by the designer for creating levels. Being able to add functionality to each layer, could be very useful.

In looking at what you intend to develop with this programme, you need to assess its usefulness in being able to 'publish' a working rendered scene, complete with network, collaboration, physics, scripting and rendering additions.
As I said before, not worth reinventing the wheel, all these modules are already available. Making the whole platform work with plug-ins, is a very worthwhile and excellent choice in my opinion.

Grab a look at how Vast Park http://www.vastpark.com works, thats a prime example.
_________________
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
Back to top
View user's profile Send private message Visit poster's website
chronozphere
DeleD PRO user


Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands

PostPosted: Sun Oct 03, 2010 7:47 pm    Post subject: Reply with quote

AWM Mars wrote:

I suppose they are more of a graphical way of showing bindings between objects and elements. The ability to drag say a light into a particular layer, so when you turn off the layer, it will hide that light, or terrain, tree, building etc etc. Apply a script to a layered element, would also be effected by the functions applied to the layer. This could be say a particle, or animation script, physical 'move to' behaviour, shader etc. Layers could also be used by the designer for creating levels. Being able to add functionality to each layer, could be very useful.

In looking at what you intend to develop with this programme, you need to assess its usefulness in being able to 'publish' a working rendered scene, complete with network, collaboration, physics, scripting and rendering additions.
As I said before, not worth reinventing the wheel, all these modules are already available. Making the whole platform work with plug-ins, is a very worthwhile and excellent choice in my opinion.

Grab a look at how Vast Park http://www.vastpark.com works, thats a prime example.


Ok, The layering principle itsself seems usefull. My first guess is that its not that hard to implement. It might be harder to make a good userinterface for it that is easy to learn for new artists. Smile

About the second part of your post: I will probably not be the guy who will implement all the features you want. My goal is to design and help implement a simple extendable core that supports quality modelling/texturing tools and has nice shaders/materials. Everything beyond that has a low priority for me.
Back to top
View user's profile Send private message
AWM Mars
Member


Joined: 06 Jan 2010
Posts: 1195
Location: Wilts England

PostPosted: Mon Oct 04, 2010 9:04 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
Ewout
Member


Joined: 15 Sep 2010
Posts: 45

PostPosted: Mon Oct 04, 2010 4:49 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
oliebol
Member


Joined: 30 Dec 2009
Posts: 8
Location: Eindhoven

PostPosted: Sun Nov 07, 2010 12:42 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
Daaark
DeleD PRO user


Joined: 01 Sep 2004
Posts: 2696
Location: Ottawa, Canada

PostPosted: Tue Feb 15, 2011 12:02 am    Post subject: Reply with quote

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.
_________________
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
zarfius
DeleD PRO user


Joined: 06 Nov 2008
Posts: 7

PostPosted: Mon Jul 09, 2012 7:30 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    DeleD Community Edition Forum Index -> DeleD Development All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum