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 1, 2  Next
 
Post new topic   Reply to topic    DeleD Community Edition Forum Index -> DeleD Development
View previous topic :: View next topic  
Author Message
Jeroen
Site Admin


Joined: 07 Aug 2004
Posts: 5316
Location: The Netherlands

PostPosted: Thu Sep 30, 2010 7:19 am    Post subject: DeleD (re)design discussions Reply with quote

This topic continues the topic on DeleD (re)design found here. Please feel free to join the discussion! Smile
_________________
Check out the gallery, our DeleD Wiki and Youtube videos!
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Starnick
DeleD PRO user


Joined: 28 Jul 2007
Posts: 611

PostPosted: Thu Sep 30, 2010 7:33 am    Post subject: Re: DeleD (re)design discussions Reply with quote

From the previous post:

Jeroen wrote:
Check out unit_types in the code. Summarized it comes down to this: a primitive has lists of vertices, edges and polygons. A vertex has a list of edges by which that vertex is used. An edge has a list of polygons by which that edge is used. A polygon has lists of vertices and edges from which it is build.

Using that structure, there are a number of topology methods that allows the programmer to come up with additional info about geometry in the primitive, especially focusing on adjacency questions (which polygons are adjacent to what vertex etc). This is important, because in an editor, you want to be able to quickly determine what geometry is affected if you're working on some part of your model. Ewout has adopted this way of doing things in his design too.


Thanks so something more sophisticated Wink, I was starting to look through the source code a bit and I was interested if you guys did account for looking up adjacency information real quick, and indeed you have.

Jeroen wrote:
A question on a different matter comes to mind: how would this application be named? As it is derived from DeleD and heavily influenced by it, it seems the name should have DeleD in it as well. Perhaps DeleD.Net if things go the C# route. The sooner this app has a name, the sooner it becomes "alive" for both developers and users, so to speak, so it's important to come up with something soon.


Eh I never was sold on just adding .NET to names. It wouldn't make sense if Mono was used either. Of course this coming from a guy who got a .net domain for a .NET application Laughing
Back to top
View user's profile Send private message Visit poster's website AIM Address
Starnick
DeleD PRO user


Joined: 28 Jul 2007
Posts: 611

PostPosted: Thu Sep 30, 2010 7:46 am    Post subject: Reply with quote

Also, on the topic of Cg:

Cg is a high level shading language much like GLSL and HLSL and Nvidia has runtimes that can be used with both OpenGL and DirectX, so it's a write-once deal. That is of course if your target application supports Cg shaders.

It's almost exactly identical to HLSL syntax wise (at least up to DX9, there's changes for DX10/11 but its more or less the same), and minor differences with standard library functions. This shouldn't be a surprise since Nvidia developed it in collaboration with Microsoft.

A nice feature of using Cg is using CgFX files (which are exactly like .fx files for HLSL). Effect files allow you to bundle the vertex/fragment shaders in a single file and define them in a set of techniques and passes, as well as specify what render states should be active for the pass.

The file format also has an annotation feature, where you annotate a shader variable for use by an editing tool. E.g. a variable may have a string identifier, a min, and max value that is used by a GUI. HLSL effect files also have the same feature.

I learned shader programming using Cg, and I personally prefer Cg/HLSL over GLSL Smile
Back to top
View user's profile Send private message Visit poster's website AIM Address
Jeroen
Site Admin


Joined: 07 Aug 2004
Posts: 5316
Location: The Netherlands

PostPosted: Thu Sep 30, 2010 9:17 am    Post subject: Reply with quote

Starnick wrote:

I learned shader programming using Cg, and I personally prefer Cg/HLSL over GLSL Smile


Well, to me it really seems Cg is a serious candidate here. Smile

Another thing comes to mind: I think it's safe to conclude that functionality like animation and raytracing in DeleD is being used much less than things like the 3D editing tools, UV mapping and various import/export plugins. Therefor, I would suggest putting the most effort in the latter, when designing a new app. It would be nice to have the ability to add animation and raytracing later, of course, and if individual plugins could be written for that kind of functionality, it would be for the better. But, if we want this new app to evolve into some kind of scene manager, animation and raytracing seem less important for now.
_________________
Check out the gallery, our DeleD Wiki and Youtube videos!
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Ewout
Member


Joined: 15 Sep 2010
Posts: 45

PostPosted: Thu Sep 30, 2010 9:33 am    Post subject: Reply with quote

Sounds like CG is quite cool. I personally program shaders in HLSL, because it was compatible with XNA. Alltough, CG seems better in this case to use.

I also checked yesterday SlimDX and for this case, I think it's indeed better to use that instead of XNA.

Anyway, I am going to install the mIRC client ^^ Didn't knew this forum had a irc channel Smile
Back to top
View user's profile Send private message
chronozphere
DeleD PRO user


Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands

PostPosted: Thu Sep 30, 2010 9:37 am    Post subject: Reply with quote

Ok, I'll give my opinion on some of the issues that have been discussed. Smile

The C# language

I'm not a huge fan of C#, but you guys are giving good arguments so I believe its the way to goo. Alot of people around me said that C# was quite bloated because of the huge .NET framework dependancies people have to install in order to use the software. I'm curious about how you think about this? Is there a way to minimize dependancies for C# programs?

Graphics API's

I think plain OpenGL is the way to go. However, we absolutely need some kind of abstraction layer. It's main purpose is not to hide possible DirectX functionality, but to organize the render resources like textures, states etc...
It'd be great if we could quickly tell the renderer what to do through a high-level interface, instead of messing around with opengl states all over the place. Smile

OpenGL also allows us to make DeleD cross-platform through MONO. I think having DeleD on linux would be very interesting (allthough it's a low priority thing).

Shaders


Personally, I'd prefer GLSL since we are using OpenGL. I haven't looked much into Cg so I don't know how good/fast it acutally is. If Cg tools allow us to make code conversions to HLSL/GLSL quickly, it would probably be a very good option. Smile

Design

I'd opt for enough abstraction here. The current deled design is based around "Scenes being lists of meshes" (TBaseMesh class I believe it was). Everything in the scene is a mesh, even a light-source. This seems wrong to me, so I suggest we should introduce a very abstract SceneObject class from which we can derive Meshes, Lights, Gizmo's, Spline-paths, Animation-controllers and whatever we may need in the future. We should make a nice class diagram that includes all our scene objects and allows us to add new things in the future.

Also we should think about some of the core classes that we will use during complex geometry-operations. DeleD now uses a lot of List classes to store vertices, polygons and such. I think having a "Set" class would be good, since the order of elements in the container is often irrelevant. I'm pretty sure there are more usefull core classes to add.

DeleD has always used "Edit-modes". Each element of the scene could be changed by selecting the right mode. It would be good to anticipate on any future edit-modes we may need. Adding new types of objects to DeleD require new toolsets to be included aswell. Re-using edit modes for these new object-types will quickly become a maintainance nightmare.

What kind of plugins do we want in the future? Definitely import/export plugins, but also new tools having their own panel, or even new scene-objects like camera's, splines etc... It might be that a new plugin may also introduce a new viewport (like a texturing tool).

I'm a bit unsure what MeshParts is in your diagram. Do we need it? We may benefit from separating the actual geometry data from the Mesh-object, but don't know any good reasons now.

Name of DeleD

A new name is needed. I don't have any suggestions. We could just call it DeleD.Net. However, I think that DeleD originally came from the fact that the program was created using Delphi. If we rewrite it in C#, it would probably deserve a totally new name. Smile

Programming-wise we should keep our focus narrow to make our goals realistic. However, design wise, we should think big and consider what DeleD may be able to do in the future.
Back to top
View user's profile Send private message
Jeroen
Site Admin


Joined: 07 Aug 2004
Posts: 5316
Location: The Netherlands

PostPosted: Thu Sep 30, 2010 11:14 am    Post subject: Reply with quote

About API's and Shaders: is a combination of OpenTK and Cg even possible?

chronozphere wrote:

I'd opt for enough abstraction here. The current deled design is based around "Scenes being lists of meshes" (TBaseMesh class I believe it was). Everything in the scene is a mesh, even a light-source. This seems wrong to me, so I suggest we should introduce a very abstract SceneObject class from which we can derive Meshes, Lights, Gizmo's, Spline-paths, Animation-controllers and whatever we may need in the future. We should make a nice class diagram that includes all our scene objects and allows us to add new things in the future.


Scenes in DeleD have a list of primitives. Lightsources are primitives too, because they need to be rendered in the views too. Although inheriting was the easiest way of handling things at the time, there are other ways to solve that, of course.

The main thing here is: meshes, lights, gizmo's etc etc are all very different things yet almost all of them need to be rendered in 3D. The design should be able to handle that. For example, we could inherit all from some Mesh class (which is what I did in DeleD), or add a Mesh as a property or... you tell me! Smile
_________________
Check out the gallery, our DeleD Wiki and Youtube videos!
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Ewout
Member


Joined: 15 Sep 2010
Posts: 45

PostPosted: Thu Sep 30, 2010 11:36 am    Post subject: Reply with quote

Well there are different ways to think: The light contains a position, color and contains a structure (the mesh in this case), but in some cases you can also say that it's a part of the scene, and then is inheritance handier I think.

Anyway, i will be on mIRC tonight Smile
Back to top
View user's profile Send private message
chronozphere
DeleD PRO user


Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands

PostPosted: Thu Sep 30, 2010 12:55 pm    Post subject: Reply with quote

Jeroen wrote:
About API's and Shaders: is a combination of OpenTK and Cg even possible?


I'm not familiar with OpenTK, but my guess would be that it is some kind of widget set. In that case, it has nothing to do with Cg. Totally different things. Smile

Jeroen wrote:

Scenes in DeleD have a list of primitives. Lightsources are primitives too, because they need to be rendered in the views too. Although inheriting was the easiest way of handling things at the time, there are other ways to solve that, of course.

The main thing here is: meshes, lights, gizmo's etc etc are all very different things yet almost all of them need to be rendered in 3D. The design should be able to handle that. For example, we could inherit all from some Mesh class (which is what I did in DeleD), or add a Mesh as a property or... you tell me! Smile


You're making a good point there. Smile Each scene object needs geometry to make it visible. I'd rather see a "Has a" relationship between a lightsource and it's mesh than an "Is a". Light sources do need a mesh, but they don't need all the geometry operations that the DeleD mesh class has. Smile

I'd make a distinction between two kinds of meshes.

> Mesh: This one is used to render geometry. It contains a few OpenGL buffers to store the vertices, texture coordinates etc.. Do note that this object does not keep it's data in RAM, but in Video RAM instead.

> Geometry: This is a mesh-representation that can be easily manipulated by the tools. When we need to render, we quickly upload the contents of the geometry object to the corresponding Mesh object.

So every "visible" SceneObject needs a Mesh object. If the object needs to be editable, we add a Geometry object and tell the tools to use that. Smile

I say we need to set up some kind of wiki, to gather all the idea's. Wink
We could also use the old one and add a few new pages.
Back to top
View user's profile Send private message
AWM Mars
Member


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

PostPosted: Thu Sep 30, 2010 2:18 pm    Post subject: Reply with quote

I knew it, as soon as you guys got onto the IRC channels, you go off and all talk tech naughty stuff Twisted Evil

Spare a thought for 'userability'. A good tool is a good as the way in which it interfaces with a user. My several comments about how DeleD had given me a good workflow, is true, not because it provided more or better tools, but just in the way it made them useable.
If I want more tools, I can load up Blender or some other programme... but, I get superior workflow with DeleD.. don't loose this, it is very very important. Smile

I also see that there is a potential that DeleD is about to br rewritten. Not to make it different to the user pa sa, but under the hood. I would like you to consider annexing/branching a new addition to 'DeleD 3D Editor', and develop 'DeleD 3D Scene Manager' as a companion programme.

It has been said already, rewritting DeleD as it stands, using a different language, would only result in DeleD being at this point now in its evolution, some 5 years down the road, making it akin to a better working version of DOS.

You have had my 5 cents worth.
_________________
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: Thu Sep 30, 2010 3:16 pm    Post subject: Reply with quote

Quote:

Spare a thought for 'userability'. A good tool is a good as the way in which it interfaces with a user. My several comments about how DeleD had given me a good workflow, is true, not because it provided more or better tools, but just in the way it made them useable.
If I want more tools, I can load up Blender or some other programme... but, I get superior workflow with DeleD.. don't loose this, it is very very important.


I know what you're saying. I'd like the new program to have a very similar user interface. There will probably be some inevitable changes, but nothing too spectacular. Allthough I'm not really a modeller, I have used DeleD to create stuff, so I know what makes a tool easy to use. We'll certainly give it some thought because usability is the core strength of DeleD. Smile
Back to top
View user's profile Send private message
Starnick
DeleD PRO user


Joined: 28 Jul 2007
Posts: 611

PostPosted: Thu Sep 30, 2010 8:20 pm    Post subject: Reply with quote

chronozphere wrote:
Ok, I'll give my opinion on some of the issues that have been discussed. Smile

The C# language

I'm not a huge fan of C#, but you guys are giving good arguments so I believe its the way to goo. Alot of people around me said that C# was quite bloated because of the huge .NET framework dependancies people have to install in order to use the software. I'm curious about how you think about this? Is there a way to minimize dependancies for C# programs?


I wouldn't totally buy into that, although the argument can be made (as I know has been made about Java). I think the folks who like to make a case for how bloated any managed program is won't ever buy into writing managed code anyways. Managed code won't be quite nearly as fast as native code and there is overhead since you do have a virtual machine/CLR. For small programs, the runtime probably will take up the the largest part of the program's memory footprint, but for large programs I think its significance is rather diminished.

But writing managed code is often more productive and faster than unmanaged and less error prone, and some heavily optimization for mission-critical code the difference can be very small.


Last edited by Starnick on Thu Sep 30, 2010 8:34 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website AIM Address
Starnick
DeleD PRO user


Joined: 28 Jul 2007
Posts: 611

PostPosted: Thu Sep 30, 2010 8:31 pm    Post subject: Reply with quote

chronozphere wrote:


Graphics API's

I think plain OpenGL is the way to go. However, we absolutely need some kind of abstraction layer. It's main purpose is not to hide possible DirectX functionality, but to organize the render resources like textures, states etc...
It'd be great if we could quickly tell the renderer what to do through a high-level interface, instead of messing around with opengl states all over the place. Smile

OpenGL also allows us to make DeleD cross-platform through MONO. I think having DeleD on linux would be very interesting (allthough it's a low priority thing).


By abstraction layer I meant a graphics API independent level, of course I'm sure you'd want to write something more high level to interface and manage OGL rather than using the raw API. The big difference is you write something that's targeting OGL calls, states, etc and may not translate directly into DX calls.

But you can also get around this by using third party technology for your rendering needs and bypass having to work at the low level (or at least for long). Axiom3D, a fork of Ogre3D is written in C# and has OGL/XNA/DX9 support.

Truth to be told, I would love to contribute my graphics engine work to serve as the rendering base. However, I do not support Mono or an OGL binding yet (just DX10, soon XNA for DX9), although its planned. Consequently you'd also get full support of a BVH-based scene graph (though Axiom I'm sure has something similar). Just throwing it out there.

chronozphere wrote:

Shaders

Personally, I'd prefer GLSL since we are using OpenGL. I haven't looked much into Cg so I don't know how good/fast it acutally is. If Cg tools allow us to make code conversions to HLSL/GLSL quickly, it would probably be a very good option. Smile


Cg code basically gets compiled down to HLSL/GLSL code so it doesn't quite matter. And I find it more readable than GLSL, but that's just me since I was raised on it.

Also another point I saw Jeroen raise, I did think about if Cg bindings are even available for C# right after I made the Cg post (heh). I honestly do not know, but the Tao framework seems to have them...not sure about OpenTK. It's something to look into.
Back to top
View user's profile Send private message Visit poster's website AIM Address
Ewout
Member


Joined: 15 Sep 2010
Posts: 45

PostPosted: Fri Oct 01, 2010 12:31 pm    Post subject: Reply with quote

chronozphere wrote:

Design

I'd opt for enough abstraction here. The current deled design is based around "Scenes being lists of meshes" (TBaseMesh class I believe it was). Everything in the scene is a mesh, even a light-source. This seems wrong to me, so I suggest we should introduce a very abstract SceneObject class from which we can derive Meshes, Lights, Gizmo's, Spline-paths, Animation-controllers and whatever we may need in the future. We should make a nice class diagram that includes all our scene objects and allows us to add new things in the future.

Also we should think about some of the core classes that we will use during complex geometry-operations. DeleD now uses a lot of List classes to store vertices, polygons and such. I think having a "Set" class would be good, since the order of elements in the container is often irrelevant. I'm pretty sure there are more usefull core classes to add.

DeleD has always used "Edit-modes". Each element of the scene could be changed by selecting the right mode. It would be good to anticipate on any future edit-modes we may need. Adding new types of objects to DeleD require new toolsets to be included aswell. Re-using edit modes for these new object-types will quickly become a maintainance nightmare.



I'm a bit unsure what MeshParts is in your diagram. Do we need it? We may benefit from separating the actual geometry data from the Mesh-object, but don't know any good reasons now.


The MeshPart is a class when you seperate mesh in groups. For example, if you have an human and you want to split it in different objects like arm, hand etc. Alltough I see it's also possible to remove that one and just use "sceneobject". So arm etc become sceneobjects.

chronozphere wrote:
I think having a "Set" class would be good

What do you mean by "Set" class? You mean a HashSet?

chronozphere wrote:
What kind of plugins do we want in the future? Definitely import/export plugins, but also new tools having their own panel, or even new scene-objects like camera's, splines etc... It might be that a new plugin may also introduce a new viewport (like a texturing tool).

Yeah and i am not sure how to do this. I can imagine that every tool should have its own space (like the dockpanel left, so options will appear). Alltough i can also imagine that some of those tools could receive more properties, so spaces aren't large enough.

I was also thinking, every tool should get its own set of variables (some needs a mouse position to do an edit, some need a few matrices etc). How should we handle this? We can use an array of parameters with a name, but then you can get enormous list of parameters. Any ideas about this? I want to avoid that we pass all available parameters to every plugins.
Back to top
View user's profile Send private message
chronozphere
DeleD PRO user


Joined: 20 Jun 2006
Posts: 1010
Location: Netherlands

PostPosted: Fri Oct 01, 2010 3:35 pm    Post subject: Reply with quote

Quote:

The MeshPart is a class when you seperate mesh in groups. For example, if you have an human and you want to split it in different objects like arm, hand etc. Alltough I see it's also possible to remove that one and just use "sceneobject". So arm etc become sceneobjects.


I agree. I rather use SceneObjects. We should maintain a hierarchy of these to support spatial parent-child relationships (like human > arm -> hand).

Quote:

What do you mean by "Set" class? You mean a HashSet?


A set would be an unordered collection of elements. I haven't used hashsets before, but I guess that would be an efficient implementation of this datatype. Smile

When I was working with DeleD, I often recognized "set operations" in the geometry algorithms. For example, take the intersection of polygon-sets A and B and iterate through it's polygons... etc. The code would be easy to read if we actually used generic classes that support these operations.

About the plugin architecture: This is one of our biggest challenges design-wise. We need an interface that is flexible but also easy to use. The more things we can write plugins for, the more extendable the program becomes. But it's important that we keep things simple. This system must be easy to understand by future plugin developers. I'll give this some thought.

I highly suggest we set up some kind of wiki for this. It will be very hard to organize all the information and design decisions in this thread. Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    DeleD Community Edition Forum Index -> DeleD Development All times are GMT
Goto page 1, 2  Next
Page 1 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