Difference between revisions of "Talk:World Simulator"

From SpaceElevatorWiki.com
Jump to navigationJump to search
(New page: 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...)
 
Line 1: Line 1:
 +
== Engine in C# (vs C/C++) ==
 +
 +
=== Good and bad points ===
 +
 +
* ++ It's C#
 +
* -- Overload of evaluating the track to be displayed (Many marshaling required).
 +
 +
=== Discussion ===
 +
 
To start, I guess for now I'll just make some minimal improvements in
 
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.
 
C++, it's a good way to make me comfortable with the code base.
Line 5: Line 14:
 
is often a module where performance should not be sacrificed and to
 
is often a module where performance should not be sacrificed and to
 
much "C# to C++" calls may hurt performances.
 
much "C# to C++" calls may hurt performances.
 +
 +
== Scene-Graph (vs Custom Renderer) ==
 +
 +
=== Good and bad points ===
 +
 +
* -- Outdoor scene like quad-trees / octrees ([http://www.google.com/search?q=octree+outdoor] and [http://www.gamedev.net/reference/programming/features/quadtrees/])
 +
* -- Good scene graphs are in C++, what about the completeness of wrappers?
 +
* -- It's fun to write a 3D renderer
 +
 +
=== Discussion ===
  
 
Concerning this and the scene graph, I don't think we need a complex
 
Concerning this and the scene graph, I don't think we need a complex
Line 20: Line 39:
 
see what says this guy: [http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D]
 
see what says this guy: [http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D]
  
I just discovered OpenTK, an OpenGL/AL wrapper as well as a toolkit
+
== Toolkits ==
providing math functions, etc.. [http://www.opentk.com/project]
 
This may be a good choice to. It has less dependencies than TAO
 
(since/however it provides less wrappers..).
 
  
Also, car informations already are in data files (see
+
* [http://www.opentk.com/project OpenTK], an OpenGL/AL wrapper as well as a toolkit providing math functions, etc.
data/cars/models/). An XML file describe the car. AC3D files for 3d
+
** This may be a good choice to. It has less dependencies than TAO (since/however it provides less wrappers..).
models. RGB textures. etc..
+
* TAO

Revision as of 16:56, 13 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).

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.

Scene-Graph (vs Custom Renderer)

Good and bad points

  • -- 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

Concerning this and the scene graph, 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. ([3] and [4])

Humm, if you want to understand my opinion about scene graph you can see what says this guy: [5]

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