Project Orbiter Addon IDE - automatic C++ code generator

[chpeller]

Hi There,

As i wanted to create beautiful addons for Obiter, i am limited by total lack of C++ knowledge.
I have found a lot of tools made by several developpers but nothing very usefull by a rookie like me. Spacecraft3 is very good but also very limited in options and lauching capacities (10 vessels max).
I think it should be possible to create an integrated and graphical 3D IDE to automaticaly generate the C++ code.
The functions could be :
1 - import Orbiter mesh and texture and render
2 - manipulate and insert directly on 3d object renderd, Orbiter parameters and functions by clicking on icones. (an smart helper cand be add to explaine the users wat they are supposed to do, and to suggest some parameters). Must be compliant with UCGO, UMMU and Orb Sound of course.
3 - As the user validate the result checked graphicaly and logicaly by the IDE, the C++ code is automaticaly generated and stored in a VC++ like repository.
4 - An SDK could be added to enable anyone to create new modules for the IDE to add new functions or options.

My will is that anyone can create addons with absolutly no C++ knowledge.
The interface must be very user friendly and must have all the necessary tools to create vessels, planets, VCs or MFD, with using all the Orbiter API powerness.

I can manage the project, specify somme functions and make some testings, but i need a motivated developpers team to make this possible.
I think it could be a very enthousiastic project not only for the users but also for the builders.

I am sorry for my bad english writing, but i hope you will understand wat i mean.

Here-under in French for those who understand this langage.

Thank to give me your thinking about this.

Regards.

---------------------------------------------French version---------------------------------------------------------------
Je me dis qu'il serait sans doute possible de créer un IDE qui permette d'exploiter toutes les fonctionnalités à disposition dans le SDK d'Orbiter pour créer de super vaisseaux, planetes, VC et MFD, très facilement. (Enfin facilement pour les utilisateurs parce que le truc il faudra le développer quand même). Je ne pense pas que ce soit surhumain à développer compte tenu de toutes les compétences à la fois en C++ et sur Obiter qui participent à ce forum.
Le principe de base serait le suivant :
1) Un interface très intutif et totalement grahique permettant de manipuler à partir d'icones les objets d'Orbiter.
2) A l'ouverture on importe en 3d le mesh et les textures au format Orbiter.
3) A partir d'icones on applique directement sur la 3d les objets et animations d'Orbiter et on en précise les paramètres, (exhaust, lights, parties animées, masse, quantité et poids du fuel, age du capitaine, tour de poitrine, etc ...). Bien entendu on le rend compatible UCGO, UMMU et OrbierSound... Une asssitance debrayable ludique et intructive guiderait l'utilisateur.
4) Le soft permet de donner un rendu unitaire des créations (visualiser les objets sur le mesh ou le template)
5) une fois le rendu validé par l'utilisateur, le code C++ est généré au format VC++, avec des sections documentées proprement.
6) Il pourrait y avoir des modules pour faire des vaisseaux, des planetes, des VC, des MFD.
7) La limite est qu'il faut avoir une base de départ qui soit un mesh convenablement conçu au format Orbiter ou des templates pour les MFD.
8) Un standard est établi de façon à ce que les passionés puissent y ajouter leurs propres outils ou templates au fur et à mesure qu'ils constatent un besoin au cours de leurs projets.

Bien entendu je propose de piloter le projet, de le spécifier et le tester, mais j'ai besoin d'une équipe de dev motivée par l'aventure.
Je pense qu'au dela de premettre à tout un chacun de faire voler sa lessiveuse avec toutes les options qui vont bien dans Orbiter, ce serait également un formidable outil didactique et de vulgarisation, à la fois sur le C++, mais également sur les bases de la physique et des mathématiques spaciales. Cet outil permettrait de rendre concret des concepts souvent difficiles à aprehender pour le vulgus pecum dans mon genre.

Qu'en pensez-vous ?

 

[Artlav]

Something like this?
http://www.orbiter-forum.com/showthread.php?t=10383
Or that?
http://www.orbiter-forum.com/showthread.php?t=8987

A project like this is easy to start, but nearly impossible to finish.
First 80% is an all-nighter of enthusiasm, the last 20% are months of puting things together occasionally.
And it won't work usably without these last 20%.

A blast from the past...

 

[Urwumpe]

I thought lately about making a Domain Specific Language for describing Orbiter add-ons and turn this "meta-programming language" into C++ source files. Would still require some sort of visual editor for easier defining animations and reference positions.

 

[BruceJohnJennerLawso]

Something like this?
http://www.orbiter-forum.com/showthread.php?t=10383
Or that?
http://www.orbiter-forum.com/showthread.php?t=8987

A project like this is easy to start, but nearly impossible to finish.
First 80% is an all-nighter of enthusiasm, the last 20% are months of puting things together occasionally.
And it won't work usably without these last 20%.

A blast from the past...

Painfully true, but like most of your add-ons Artlav, it wasn't that far away. Maybe if a new project were open-source, it might finally get done; Orbitershipyards source might be hard for anyone but Artlav to understand.

I must admit I have come full circle on this issue though, I would rather teach new developers how to code their own vessel modules in VC++ (2010), rather than create some sort of little factory program. Even if the program is properly finished, it still has to be updated for new UMMU/UCGO/Orbitersound/Orbiter updates, somebody might want a new feature that not everyone supports...

Its a lot of work for little gain, IMO.

 

[PhantomCruiser]

I'd like to learn C++, but I've got time and schedule problems. I'd relish the idea of taking a mesh (that I've nearly worked 18 month on, give or take), and having Artlav's shipyard make the functionality of it work.

I have taken a look at the Orbiter API, and some of the examples, but I just don't have the time to sit down and go for hours at a time coding. What few projects I've done, I've used SC3, then used the SC3 to DLL tool. There are some limitations of course.

If something like this were available, and stable, I'd used the crap out of it.

 

[N_Molson]

Looks promising ! :thumbup:

 

[chpeller]

Many Thanks to you all to feed the thinking.

Artlav i agree with your vision, but i notice like BruceJohnJennerLawso that all the ambitious projects i saw on Orbiter are closed source and made by one or very few people.
My goal is to make an open-source project to welcome abord a maximum of people and insure the sustainability of the project. I want to create a growing snowball and not a bullet. Do you understand what i mean ?. I think it should be a very exciting project for developpers to show their knowhow and quality capacities and for the users to enable them to take benefits of this marvellous software "Orbiter", and make flying easily all their prefered washing machines with all API options. All will be able to give ideas, and to acitvely participate if they want or just use with a very user friendly experience.
The softwares you show in your response are right in the mind but need to become very more user firendly but the experience of their developpers could be very usefull in this kind of project. They are a perfect kind of proof of concept.
At this thinking level all contributions to identify the goals and difficulties are welcome and i thank you again for your responses. I am sure there is a real need for most of Orbiter users actually frustrated because of C++.
Plase talk about this to your Orbiter contact and help me to make this project growing, i dream about this and i want a maximum of people to dream with me.

 

[Urwumpe]

There are already many factors that we currently lack - for example too few class libraries for C++ to simplify development. We have started creating a common code base for the Ultra add-ons with the libUltra subproject, but it is not yet something to use easily.

 

[chpeller]

Do you have a shareable inventory and roadmap for this project ?
I think it's possible to start without this, by specifying software at user level interface design and needed functions. It could help you to precise some aspects of your working.
Are you in touch with Orbiter developpers on this issues ? I think they could be interessed to participate or at least give a help.

 

[Urwumpe]

Do you have a shareable inventory and roadmap for this project ?
I think it's possible to start without this, by specifying software at user level interface design and needed functions. It could help you to precise some aspects of your working.
Are you in touch with Orbiter developpers on this issues ? I think they could be interessed to participate or at least give a help.

SSU is open-source there is no reason for others to not contribute or fork from our code.

The main problem is: It is a 0.x version, currently, without any useful public API yet. It is just finding stuff in SSU, that is generic or find generic super models of a subsystem, that could be moved into it for forming a common code base. It is very detailled and component oriented, what is not always good for add-on development.

But: There is no reason to not develop a framework, that permits building a full vessel by specifying only the capabilities and behavior of it and which automatically fills the Orbiter callbacks with the needed life. Even without the code from libUltra, a lot of the good and bad experiences of SSU can be helpful for this.

 

[Face]

I don't think that what is missing for an easy access to Orbiter modelling is a DLL "generator" of sorts. I think what we miss is a visual designer. Whether this designer creates a DLL, C++ source code, SC3 INI or whatever DSL there might be, is secondary to the user experience IMHO.

In essence, I understand this to be a "bring KSP editor to Orbiter" approach: create and test your "add-on" visually inside Orbiter (or another renderer), then save and deploy it.

As I don't see a full blown editor from scratch being developed on a free basis (like KSP was able to do with its commercial approach), I'd suggest a more pragmatical and incremental roadmap:
1. Take an already available framework. The best candidate is SC3, even if it is limited currently.
2. Do the editing in Orbiter, as it is the obvious renderer at hand.
3. Start without big UI, but make it interactive. I.e. don't do fancy dialogs and snap-in features right from start, concentrate on the ability to create content fast.
4. Add dialogs to get away from text-based definitions.

Number 3 could be achieved by means of a reload function to SC3, i.e. the possibility to edit the INI while running the simulation, then reload the configuration to see what it changes. Number 4 would then build upon this first working state by means of e.g. adding a positioning mode via mouse, a mesh selection dialog, pasting template definitions (typical thruster setups, panel folding animations) etc.

If you find SC3 too limiting, I'd like to invite you to contribute to the genericvessel project.

regards,
Face

 

[Urwumpe]

I think finding a good visual language for describing an orbiter vessel will be hard. How would you describe all capabilities of a Stock Delta-Glider in Dialogs and visual parameters?

 

[chpeller]

I am very pleased to see your reactions, are you interessed by such a project ? are you ready to be part of the projetc hard core ?

If yes, i suggest you to begin to organise a little bit the project.
First i suggest you to separate the user wanted functions by section to identifie the best way to do it and eventually the existing code we could use, (with developpers permision obviously).

Here is what i think to initiate this global vision :
**** Input ****
- The software must be open-source
- The interface must be multi-langage capable
- The user project must begin by importing at least an orbiter mesh, but if possible the textures. This projet don't be a 3d modeler this already exist. It will only be a 3d Orbiter compliant renderer. (exept for MFD wich can begin by a standard tamplate provided by the software).
- The position of the interface components must be as same as possible for every kind of project. (vessel, planets, VCs, or MFD).

*** Output ***
- The generated code (output) must be natively full compliant with Orbiter, (ideally C++, but wy not in a first step using SC3 as output generator. If Vinka agree of course. It would be so great to invite Vinka to participate with us !
- The final output must be a full working package with a readme.txt to precise the mandatory requested addons.
- It must be able to use UCGO, UMMU and Orb Sound as functions to insert in the project.
- All the function must be added graphicaly and testable in the interface
- At any time it will be possible, the software must be as smart as possible, suggest the best parameters and calculate automaticaly the requested calculable parameters. (if necessary it can ask the user some questions to do this, but allways in end user mind).
- A standard to integrate news functions must be created to enable any developper to increase or imporve the software functions.
- At first we can work only on vessels interface, but at the end i hope we will have also Vcs, planets and MFD interfaces in the same mind.

*** developping environnement***
- I have actually no idea about Framework or language to use, but i suggest the most open as possible, like "Eclipse" and Java for example. I hope we will add time after time usefull developping tools to this framework.

- For the repository we can use Sourforge or something like to be acessible to anyone who contribute at any time.
- For the communication we can use Wiki and this forum.

I suggest you also to tell us what part of the project mostly interessed you and eventually if you want to manage the related works.
If you agree i propose to take the main lead to coordonate the entire project obviously with an helpfull backup to manage plannings, road maps, codes produced, communications to developpers teams and end users, documents and so on. To have an efficient organisation for the best confort of all contributors and users.

What do you think about this ? have you a better ideas ? do you think it is possible ?

 

[Urwumpe]

Here is what i think to initiate this global vision :
**** Input ****
- The software must be open-source
- The interface must be multi-langage capable
- The user project must begin by importing at least an orbiter mesh, but if possible the textures. This projet don't be a 3d modeler this already exist. It will only be a 3d Orbiter compliant renderer. (exept for MFD wich can begin by a standard tamplate provided by the software).

*** Output ***
- The generated code (output) must be natively full compliant with Orbiter, (ideally C++, but wy not in a first step using SC3 as output generator. If Vinka agree of course. It would be so great to invite Vinka to participate with us !

*SNIP*

What do you think about this ? have you a better ideas ? do you think it is possible ?

I think this is important for now, all the other stuff is currently three or four steps too far into the future.

I like Faces idea of using Orbiter as core of such an editor. This means, we are going Visual C++ and possibly Lua for such an editor.

One interesting subproject there, that I would suggest: Could it be possible to create a Lua API for Orbiter to define dialogs?

 

[chpeller]

When you write "I like Faces idea of using Orbiter as core of such an editor" you mean use the Orbiter code ?
I don't think is a good idea to have to launch the entire Orbiter to test the result. My idea is to have something totaly inetgrated.
Regarding Lua where could be the problem to create this kind of API ?

 

[Urwumpe]

When you write "I like Faces idea of using Orbiter as core of such an editor" you mean use the Orbiter code ?
I don't think is a good idea to have to launch the entire Orbiter to test the result. My idea is to have something totaly inetgrated.
Regarding Lua where could be the problem to create this kind of API ?

Why? Orbiter isn't that massive and it would show the vessel right where it is supposed to be rendered later.

And I have no idea how easy or how difficult such a API would be. Would need to try it.

 

[4throck]

Just my 0.2€

A visual companion to SC3 / multistage is the way to go. It can be done in almost any language, the only "problem" being mesh display.
Integration into Orbiter is nice, but what would happen when the next version comes out? Better use a standalone solution.

Nevertheless, to be really useful, it would need to be integrated with some sort of data repository. I remember a discussion about a rocket engine database sometime ago.
I'm thinking about something where you could choose something like Rocket » Atlas; Payload » Mercury and get that assembled into some sort of workflow that you could manipulate.

What I don't see working is making this work with individual meshes, unless they are uploaded to the "system" with some data associated (mass, internal camera position, animations, etc). So we are talking free meshes and data here (or at least Orbiter licenced ;-) )

 

[Artlav]

Concerning the renderer - the graphics are separate, so making an Orbiter-compatible separate renderer is not going to be too hard - i.e. Orbiter Shipyard is OGLAClient at it's core.

Doing the editing from inside the Orbiter proper is ripe for problems, from GUI and camera controls to resource allocation exhaustion and OVP compatibility. I was at one time thinking of making a KSP-like editor for Velcro rockets from inside Orbiter, and there were too many problems even to get to a proof-of-concept.


Concerning the code generator.
We already have the genericvessel project, which is an open-source SC3 replacement (Vinka is out of business for now, and he gave us free use of his format) - http://bitbucket.org/face/genericvessel
That thing is a descendant of the Orbiter Shipyard, along with a C++ code and DLL generators.
That would form an already-existing backplane for the project - the vessel is compiled into the xves data structure, which can then be exported into a DLL, SC3 code, or C++ code - whatever the user wants.
Panel/VC instrumentation can be made with generic classes (see DG code).


Concerning the editor.
There are two approaches.
First is to load meshes, and define functionality.
Orbiter Shipyard is still functional, you can download it by the two links here http://www.orbiter-forum.com/showthread.php?t=10383
This is the example of the first kind of editor.
You load meshes, then you define animations, place engines, locate camera, and so on.

The second kind is KSP-like editor.
You can take a look at the still-functional [ame="http://www.orbithangar.com/searchid.php?ID=4075"]Station Shipyard 090701[/ame] for an Orbiter example.
In that case, you put a vessel together from pre-defined modules.
Each module have it's own animations, docking ports, engines and so on - the features are not explicitly defined.

Which kind would be more useful?
Full editor is more flexible, but in the modular one you don't need to line up the engines and do all the math.

Combining the two kinds (think Forth - each design can be either a full spacecraft, or a part of a bigger spacecraft, bigger spacecraft can be parts as well, and so on) is also conceivable, but can be on the wrong side of the implementable complexity horizon.

The back-end of both the Orbiter Shipyard and the Station Shipyard is the same genericvessel ancestor, so the kind of editor don't really affect the code generation part.

- I have actually no idea about Framework or language to use, but i suggest the most open as possible, like "Eclipse" and Java for example. I hope we will add time after time usefull developping tools to this framework.

Bad idea.
The reason why few of my projects can be made open-source is that i use custom tools in the community that uses standard ones.

Orbiter API is in C++, most of the developers we can count on are Orbiter add-on developers, familiar with that API and the C++.
Making the project in Java or something else would just cut an already small developer pool down, at no real gain.

 

[chpeller]

Thank you Artlav,

- As i can see you have already thought a lot about such a software and even produce a lot of code.
- I like your combined approach for the editor, is it so hard to make ?

Would you like to help me to initiate this project ? with your experience you could be a major wining contributor.

regarding your writing about custom tools, the problem is that we need to work with a team of contributors and i think it is much better if they, (i am not developper unfortunatly), use the same tools for the same job.
How do you think we could do this ?

I agree with you about C++ as the best language candidate. And have you an idea about the graphical framework for the interface ?

 

[Urwumpe]

I agree with you about C++ as the best language candidate. And have you an idea about the graphical framework for the interface ?

There are many choices. I personally currently would select Qt, because it has a great tool chain and we could also use PyQt for defining the user interface and limit the C++ code to the parts of the program that need to be fast or memory-efficient.