Difference between revisions of "Talk:World Simulator"

From SpaceElevatorWiki.com
Jump to navigationJump to search
Line 32: Line 32:
  
 
I don't think we need a complex scene graph. In every project I made, the use of a specific scene graph quickly became a limitation. Taken this into account, I prefer we write a tiny 3D engine completely in C#, just containing the flat list of 3D objects in the world, it's easy and probably faster: no wrapper, we're free to make application-specific optimizations, etc. For example we can then switch to a quad-tree (or octree) for storing objects, which is really better than a scene graph in an outdoor scene. ([http://www.google.com/search?q=octree+outdoor] and [http://www.gamedev.net/reference/programming/features/quadtrees/])
 
I don't think we need a complex scene graph. In every project I made, the use of a specific scene graph quickly became a limitation. Taken this into account, I prefer we write a tiny 3D engine completely in C#, just containing the flat list of 3D objects in the world, it's easy and probably faster: no wrapper, we're free to make application-specific optimizations, etc. For example we can then switch to a quad-tree (or octree) for storing objects, which is really better than a scene graph in an outdoor scene. ([http://www.google.com/search?q=octree+outdoor] and [http://www.gamedev.net/reference/programming/features/quadtrees/])
 +
 +
: Here are some links to check out
 +
: http://sourceforge.net/projects/odedotnet
 +
: http://axiomengine.sourceforge.net/wiki/index.php/Main_Page
 +
: http://www.nuclex.org/weblinks/Programming/Math
  
 
== Toolkits ==
 
== Toolkits ==

Revision as of 08:28, 15 June 2008

Engine in C# (vs C/C++)

Good and bad points

  • +++ It's C#
  • -- Overload of evaluating the track to be displayed (Many marshaling required).
  • - Require to write a

Discussion

To start, I guess for now I'll just make some minimal improvements in C++, it's a good way to make me comfortable with the code base. Probably when enough things will start to be ported to C# we'll consider making the 3D engine working completely in C#. Although this is often a module where performance should not be sacrificed and to much "C# to C++" calls may hurt performances.

I think this is not a good idea to invest in the C++ codebase for anything more than fixing a bug. If we want to do more to a component, we should port it first. Let's not worry about interop performance. It will eventually go away ;-) Keithcu 04:08, 15 June 2008 (EDT)

Scene-Graph (vs Custom Renderer)

Good and bad points

  • +++ PLib's SSG renderer already written.
  • --- Outdoor scene like quad-trees / octrees ([1] and [2])
  • - Good scene graphs are in C++, what about the completeness of wrappers?
  • -- It's fun to write a 3D renderer

Discussion

If you want to understand my opinion about scene graph you can see what says this guy: [3]

I don't think we need a complex scene graph. In every project I made, the use of a specific scene graph quickly became a limitation. Taken this into account, I prefer we write a tiny 3D engine completely in C#, just containing the flat list of 3D objects in the world, it's easy and probably faster: no wrapper, we're free to make application-specific optimizations, etc. For example we can then switch to a quad-tree (or octree) for storing objects, which is really better than a scene graph in an outdoor scene. ([4] and [5])

Here are some links to check out
http://sourceforge.net/projects/odedotnet
http://axiomengine.sourceforge.net/wiki/index.php/Main_Page
http://www.nuclex.org/weblinks/Programming/Math

Toolkits

  • OpenTK, an OpenGL/AL wrapper as well as a toolkit providing math functions, etc.
    • This may be a good choice to. It has less dependencies than TAO (since/however it provides less wrappers..).
  • TAO