Talk:World Simulator: Difference between revisions
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...) |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| 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). | |||
* - Require to write a | |||
=== 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 6: | Line 16: | ||
much "C# to C++" calls may hurt performances. | 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 ;-) [[User:Keithcu|Keithcu]] 04:08, 15 June 2008 (EDT) | |||
scene graph. In every project I made, the use of a specific scene | |||
graph quickly became a limitation. Taken this into account, I prefer | == Scene-Graph (vs Custom Renderer) == | ||
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 | === Good and bad points === | ||
wrapper, we're free to make application-specific optimizations, etc. | |||
For example we can then switch to a quad-tree (or octree) for storing | * +++ PLib's SSG renderer already written. | ||
objects, which is really better than a scene graph in an outdoor | * --- Outdoor scene like quad-trees / octrees ([http://www.google.com/search?q=octree+outdoor] and [http://www.gamedev.net/reference/programming/features/quadtrees/]) | ||
scene. ([http://www.google.com/search?q=octree+outdoor] and | * - Good scene graphs are in C++, what about the completeness of wrappers? | ||
[http://www.gamedev.net/reference/programming/features/quadtrees/]) | * -- 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: [http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D] | |||
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 have found many codebases that support Octrees: [[Codebase_Analysis]] | |||
== Toolkits == | |||
* [http://www.opentk.com/project 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 | |||
Latest revision as of 09:42, 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])
- I have found many codebases that support Octrees: Codebase_Analysis
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
