Looks like I’m the first.
Let me just give a little background. I’m a Sr. Technical Systems Analyst which is a title that is only meaningful to my employer. What I do is design computer programs based on input from a business analyst. I have designed quite a few interface type programs to allow different systems to communicate with one another. As I am not a programmer my interest in your project is strictly from the perspective of how you are going to go about the separation of the core from the visual and the subsequent interfacing of external programs to the core.
I really have no clue what approach you have in mind but I’ll throw out a couple of conjectures. The first would be an API approach much like you are now doing but without any visualization code in the core. The second would be more of an interface that gets called as needed by any type of program. This would allow the core to run in the background and be entirely separate form any other effort. As I said the first approach is similar to what you are now doing but the second in more similar the Microsoft approach for their flight simulator.
It’s a bit difficult to offer any more or go further without more input as to direction. That is unless at this point you really have none and are looking for ideas. If that is the case then I’d lean more towards the interface approach as it offers the ability to be more easily used by other systems.
Well looks like I've finally made it in here. A little background about myself: I just graduated from college with a degree in Computer Science and a minor in Math, May 2005. I was helping with Orbiter since nearly the beginning in late 2001 or early 2002.
I've been job hopping the last few years falling down through the cracks of companies that don't look at my full potential. Now I've got a new job lead with a leading furniture designer in the New York City region. They are flying me out next week, and if they make an offer I will almost certainly accept it. I would be programming AutoCAD, Pro-Engineer, and 3D Studio MAX as well as their robotic production facilities. So naturaly I'm going to be rather busy in the future.
I've got a large amount of interest in Orbiter and it's future and some features that I would like to see come around that would best be implemented in the Graphics Engine. Here is a little list:
1. DX9 module
2. DX10 module
3. 64bit execution
4. Multiple Light Sources
5. Bump Mapping
6. Volumetrics (lights & fogs)
7. A Keyboard interface and registration system for MFD's
8. Optional Lenz effects
9. A better management system to handle planetary mapping, more specifically one that could integrate with a future ground collision and 3D Terrain. (Ground collision would of course need to be implemented in the physics engine before this could happen) So a good place to start is simply with a better tileing system, and adding support for 3D Terrain into the rendering engine.
We are the future of the graphics for Orbiter, so I am GLAD to be here and hope contribute as much as my time will alow me.
Opps, I forgot to mention the following:
10: Multi-threaded execution
11: Multiple Monitors
Well, I guess it's my turn
I'm Zatnikitelman (Zat for short) I have been using orbiter since 2004 and would like to help in any way I can. I don't know what I can bring to the project as I have no programming expierence (except Ti-83 calculators) except for HTML. I am eager however to be able to help as Orbiter is my favorite computer program of all time.
A couple of things I'd like to see in the next version are:
Better blending between tiles and textures
Dynamic rendering to keep loading time down
Like I said, I don't know what I can contribute, but I'll be happy to contribute whatever I can.
Ok, I want in too. I have no MSVC++ experience at all, other than following the wiki instruction and compiling a default module to invoke the default vessel. However, I am a FORTH professional at the FORTH Inc. (TM) level, with extensive experience with large complex FORTH applications, as well as at the FORTH nucleus level (fully self recompiling with cross compilation) for mission critical software, so I don't see any particular problems with participating, after I have gone through the usual full addon development process. Hopefully that will only take a few more months. I suppose I am about half way through the ordinary Orbiter learning process, and I've got a month of flying and two months of API study.
I don't think Orbiter has even begun to reach it's full potential, even with the extensive addon development community, so commenting on future approach and direction is fruitless for me right now, considering my newness. It's interesting to watch the evolution of it, though, so I'll just wait for Martin's next release, recompile any addons that I have hopefully created by then, and compare that release with the well established stable release out there now (2006P1), and then get back to you. I think Martin said maybe late this year or next.
Martin has specifically stated : Graphics and Physics, so I'll let the thread continue.
Log in to post a comment.