Project Project Rexus - Addon development 101

[smarly]

Hey everyone,

I have been a long-time Orbiter user, but up to now I have absolutely no idea what it takes to develop an add-on for Orbiter. Inspired by a recent thread on the forum, I decided it’s about time I had a closer look at the whole add-on-development business so I would one day be able to give something back to the community. I have had this idea for years, but always thought it impossible for a guy like me to get into something as complicated as developing an add-on. After all, it takes skills in C++ programming, 3D modeling, texturing and so on… all things of which I know nothing about. So, what? … you only fail of you don’t try.

I am starting this new thread to document my first add-on project, the Project Rexus, in the course of which I will develop a small sounding rocket for Orbiter. The project should be seen as an experiment to demonstrate whether it’s possible to learn about add-on development in a reasonable time-frame (days to a few weeks), using an autodidactic approach. Over the next days and weeks, I will share my progress and experience in this thread in hopes that others might benefit from it. My goal is to show that add-on development is a manageable challenge even if you have no previous experience with this sort of thing.
I might fail, but even then others will hopefully learn from the mistakes I made.
However, if I should succeed, it is my hope that others will be inspired and start experimenting with their own add-ons.
There are plenty of ideas out there of things that would be nice to have in Orbiter, it just takes someone to do it.

Please let me know if you are interested in the progress of this project. Thanks!

P.S.: I know there are other ways to develop an add-on, e.g. using the famous spacecraft3.dll. However, for the sake of learning, I have decided to go the hard way and build my add-on using the "standard" Orbiter API functions in C++.

 

[Hurricane]

Looking forward to it, nice going man!
Can you post some diagrams/artworks so we could see your vision?

I am currently in the process of designing my own add-on. However I have a lot of things on my head right now so I develop it as a secondary project with emphasis on the infrastructure for the development itself.
I will surely be watching your progress, and I will contribute to you from my modelling knowledge.

~Take care and never let go of it until you're satisfied!
Oz.

 

[NovaSilisko]

I find spacecraft3 is excellent for prototyping, while C++ is good for final development.

 

[smarly]

As requested, a few details about the project. Thanks for your interest and support!

As you know, every add-on starts with an idea of what to develop. I picked a sounding rocket, since my research shows that there aren’t too many available in Orbiter. (In case you think sounding rockets are boring: I have a few ideas in the back of my mind to make them more interesting to play with, but for the moment a “simple” sounding rocket seems a good start for my purpose.) I decided on the Rexus rocket, which is usually launched in the course of a student campaign in Kiruna, Northern Sweden.

The Rexus rocket is a small sounding rocket: 5.6m long, 0.365m diameter, propellant mass 290 kg, total mass 515 kg. See attachment for an artists concept.

It’s divided into 3 sections:
- The solid rocket motor with a bi-phase thrust level (84.5 kN for the first 4 seconds of the flight, 13.3 kN afterwards).
- The experiment module, which houses the scientific payload as well as a parachute for a smooth landing.
- The nosecone, which covers the scientific payload during ascend and increases aerodynamic capabilities.

The rocket is launched from a dedicated rocket launcher and is spin-stabilized during ascend. At an altitude of ~ 60 km, the rocket is de-spun by a dedicated yo-yo system, nosecone and solid rocket motor are separated and the experiments are performed in micro-gravity. About 9 minutes into the flight, the experiment module re-enters earth’s atmosphere, the parachute is deployed and the experiment module returns safely to earth. Nosecone and solid rocket motor crash back to earth. (To be precise, the nosecone in reality has its own parachute, but this will not be modeled in Orbiter). More information can be found here.

As you can see, even though it is “just a sounding rocket”, this one is rather complex and has a lot of different features that need to be implemented in Orbiter: Thrusters, spin-stabilization, multi-module staging and separation, animations, parachutes, etc. And of course, a dedicated rocket launcher needs to be developed which can point the rocket in any given launch azimuth and altitude. The real launcher is displayed in the attachment. It will require animations, handling of user input and output, inter-module communication, etc. Oh, and before I forget, I need to build the 3D models for all these things, too.

I will tackle this problem in three steps:
First, find out what I need to do to develop an add-on in Orbiter.
Second, build the rocket.
Third, build the rocket launcher.
Sounds easy enough …

So, let’s start with the first step straight away. I will begin by reading the documentation provided with the OrbiterSDK. Looks like its going to be a loooong night … ::lol:

 

[smarly]

Day 2: Planning out the details

I spent most of this morning reading. Definitely recommend the “Api_Guide.pdf” and the “3D Model.pdf” in the OrbiterSDK\doc\ folder. It looks like I need to do 3 - 4 different things to create my add-on:

1) Build the physical model, either as a config file or a .dll
2) Build the visual model
....2a) 3D model
....2b) Add textures and material properties
3) Build a scenario file.

Obviously, I need a variety of different development tools for my add-on. I spent most of this afternoon researching the different options. There is a comprehensive list of resources available in the tutorial section of the OF. After some thought I decided on the following tools:

Visual Model:
Use Blender for 3D modeling and texturing. With the help of this clever plugin (see this tread for details) one can easily convert models to Orbiter mesh format. Blender is open source and a very powerful tool which can be used for a lot of other stuff, even rendering movies. I figured, if I have to learn a new software, I might as well learn a software which I can use for other things, too. Also, there are a lot of good (video) tutorials on the net to help you get started with Blender.

Physics model:
I will start with a simple config file, and later progress toward a .dll file. I will use MS Visual Studio Express C++ for the development of the .dll file. It’s free and very popular, meaning there are a lot of tutorials etc. available.

Scenario:
I will be using the scenario editor that ships with Orbiter to create the necessary scenarios.

I finished the day by downloading and installing Blender and the plugin for Orbiter meshes. That’s it for today. Tomorrow I will try to create my first object within Orbiter….

 

[smarly]

Day 3: It’s alive!!!... well, close enough.

I didn’t really have time to do much today, so I just created a very simple 3D model in Blender … yes, it is just a simple cube.

I exported it to an Orbiter mesh via the Blender-Orbiter plugin, added a config and scenario file… et voila, there is the first object I ever created within Orbiter!

I can’t believe it actually worked, and I can’t believe how easy that was!!!

Granted, the thing doesn’t really look very fancy, and it doesn’t do anything at all. It just sits there. Still, I am lacking the words to describe how proud and happy I am feeling right now. There it is, my first own “add-on” for Orbiter.

(Don’t panic, I won’t upload it on Orbithangar, I promise … :lol

 

[Hurricane]

Do upload it on April fool's day! :lol:

Now, about Blender. You should know that the learning curve in this software is very sharp, you'll find it hard to learn at first until you get the hang of the tools available to you.
Then, you should start developing your own techniques for modelling, and if that fails, then you should ask an expert how he does that and try to master his technique, of course changing it to suite your needs.

~Best of luck, Oz. :tiphat:

 

[smarly]

Thanks for the encouragement, Oz, it’s appreciated

Day 4: Re-shaping the cube

Actually, I found it rather easy to get started with Blender. There’s a number of great video tutorials on blendtuts.com:
Interface, Create objects, Edit objects.

First I re-modeled the cube into something that looks a little more like a rocket (but still a crappy enough one)


Than I added some material properties and added a rocket engine via the config file. When you hit “+” key, the rocket starts to move along the floor.


Ok, there’s definitely something wrong with the rocket axis. Blender is using a right-hand coordinate system, while Orbiter uses a left hand system…. That’s really giving me a headache. (I wonder why Martin in all his wisdom decided on that option…?!?Well, he probably had good reasons, he usually knows what he is doing )

After a few cups of coffee, I finally figured it out:


So, it’s something that almost does look like a (still very crappy) rocket, and when you press the “+”, it launches into the air.


Nice.
I think it’s about time I moved on to C++ and implementing the rocket as a dll file, so that I can add all the fancy stuff like exhaust particles, etc.

 

[Pipcard]

You can add particles in spacecraft3.

 

[MaverickSawyer]

you can also use Velcro to perform mesh tests, and to fine tune your dV and ISP settings.

 

[smarly]

Hey guys,

thanks for the tips. I had a look at spacecraft3 and Velcro today, that is some pretty good stuff. :thumbup: Definitely will use that for my next add-on (if I should ever attempt one after this), but as I said in my first posting, for the sake of learning I will try to use C++ and the native Orbiter API functions for now. This said, it's time for ...


... Day 5: Getting serious ... going C++

Today I installed the MS Visual Studio 2010 Express IDE. Afterwards, I spent most of my day reading C++ tutorials.

[FYI: My past experience with writing code is quite limited. Back in high school ( ~ 10 years ago) I did some programming in Visual Basic and a very simple piece of code in Java . Oh, and I did read the first 7 chapters of “Visual C++ for Dummies” while I was on holidays with my girlfriend 2 years ago. :lol: That's it.]

This afternoon I finally tried my first Orbiter module written in C++. Actually, setting up the compiler and project environment seems by far the most confusing part of it all. Thankfully, there's a really good video tutorial on that by computerex. Thanks, you saved me there!


Well, that's it for today, it's friday night and my favorite bar is calling. Will be back tomorrow

 

[Hurricane]

Was I smelling sarcasm? (;
Glad you've gotten the hang of it, and good luck!

~Oz.

 

[vlad32768]

Blender is using a right-hand coordinate system, while Orbiter uses a left hand system…. That’s really giving me a headache. (I wonder why Martin in all his wisdom decided on that option…?!?Well, he probably had good reasons, he usually knows what he is doing )

AFAIK, left-handed coordinate system is an OpenGL and DirectX standard, and right-handed one is a "special feature" of Blender, so I had to do coordinate conversion in my script.
I don't know why Blender developers decided to use right-handed system though.

 

[smarly]

Ah… thanks for shedding some light on that. As an engineer, I am quite used to the right hand coordinate system being the standard, so that’s probably why I had so much trouble with the left hand system.
Going a bit off-topic here: Great script of yours! :thumbup: Are you planning to continuously update it for future Blender versions, e.g. 2.61 and the new Cycle rendering engine?


Back to topic:


Day 6: Contrails and other fundamental stuff

Today I started hacking into the Orbiter API. If you stick to the API_Guide and the API_Reference, and maybe take a look at some of the examples provided with the SDK and on the forum, it’s actually pretty straight-forward. Martin did an amazing job of making it easy for beginners. Once again, I am deeply impressed by his work.

The result of today doesn’t really look that much different from what I have had before, but now the rocket’s physical parameters (mass, size, etc.) are fully implemented in a dll. I also added a propellant tank, main engine and exhaust contrails. Oh, and I did modify the control command of the rocket: The user does no longer need to continuously press the “+” (default main engine firing command) to fire the thruster. Instead, after the user presses the “l” key, the solid rocket motor is ignited and keeps burning until it runs out of fuel at an altitude of ~ 28 km. The rocket keeps climbing until it reaches the apogee at ~82 km, than falls back to earth.


Tomorrow I am going to add all the fancy details, like stage separation, parachutes, etc. And hopefully I will be able to present some new pictures by then.

 

[vlad32768]

Going a bit off-topic here: Great script of yours! :thumbup: Are you planning to continuously update it for future Blender versions, e.g. 2.61 and the new Cycle rendering engine?

Thanks
The add-on works with the latest Blender 2.6 trunk, tested with 2.61.4 R43873. It seems that the developers don't change the Python API. Did you try the latest version?
And yes, I'll update the add-on when I have free time. Now I'm waiting for Bmesh merging. After that the API may be changed, and I'll have to rewrite some functions. Also I'll add c++ header file generator.

I didn't think about Cycles materials yet. There are some difficulties with them. Old Blender internal materials are similar to Orbiter (DirectX) materials. They use Ambient, Diffuse, Specular, Alpha etc.; you can set up materials in Blender and export them into Orbiter, and they will be very similar to each other. The same thing is with materials imported from .msh. However, Cycles materials pretend to be physically based, you can not tune ambient-diffuse-specular-alpha components, and you can not simulate Cycles render result in Orbiter. A modeler should see how the model will look in Orbiter, so I think that Cycles materials aren't very useful for modeling for Orbiter.

 

[smarly]

Hi vlad, that’s good to hear, thanks a lot! I really came to like Blender, and would hate to not be able to use it for addon development in the future.
I haven’t found the time yet to test new Blender 2.61 with your script, but hopefully I will find some time for that sometimes next week. I'll let you know how it goes.
Well it’s been a busy sunday...


Day 7: To space and back again… launchers, staging, separation and parachutes

So, I implemented a lot of nice stuff today. First, I separated the rocket into 3 different vessels: Nosecone, Payload Module, Motor. I used attachment points and docking ports to create a nice little stack. Only problem is, Orbiter doesn’t support docked vehicles on ground. I really hope Martin will fix this in the future, because it would make a lot of things a whole lot easier. Doesn’t matter for now, I found a work-around and here is the complete stack:


As you can see, I also started working on the rocket launcher (that weird-looking green/blue tube to which the rocket is attached).
For the moment it doesn’t do much, it only provides an attachment point to which the rocket is fixed. If the user presses “L” while the rocket launcher is the active vessel, the solid rocket motor of the rocket is ignited, the focus is switched to the Rexus payload module and the rocket kicks off into space.


26 seconds into the flight the solid rocket motor burns out



~ 70 seconds after lift-off, the nosecone is jettisoned.


4 seconds later the solid rocket motor is also jettisoned.


The payload module keeps climbing up to ~ 86 km before it starts falling back to earth.


At an altitude of 3 km the parachute is deployed and the payload module returns safely back to earth.


Granted, I really need to re-work the models. I’ll do this over the next couple of days, but tomorrow I am going to pimp the rocket launcher a little and hopefully make it moveable around multiple axis so that I can point the rocket in any given direction.

 

[N_Molson]

You seem on the right track :yes:

Detailed models can usually wait that the core C++ code of your addon is written, unless you plan lots of animations (I wouldn't recommend it for a first try).

Nice to see you are not afraid by coding :thumbup:

 

[smarly]

.... written, unless you plan lots of animations (I wouldn't recommend it for a first try).

Thanks for the heads-up. Unfortunately, there was no way around animations in order to get the rocket launcher to work properly.... :facepalm:

Day 8: Making the rocket launcher turnable

Today, I fixed the rocket launcher so that it can point the rocket in any given direction. The user can press the "V" button and a window will pop up where the user can enter the target altitude and target azimuth. Once the user presses "ENTER", the rocket will start turning towards the targeted coordinates.



As I mentioned above, I had to use animations for that, which was rather challenging. When I started with animations, the topic seemed quite complicated and confusing. It took me a couple of hours and a lot of try-and-error before I got the hang of it, but after I figured it out, it's actually not too bad.
Same goes for prompting the user for input via a dialog box. Confusing at first, but once you understand the underlying principle it becomes easy.

After today the core functions and properties are integrated into the dll. Tomorrow I will start re-working the models.

 

[smarly]

Day 9: Pimping the model

Re-worked the 3D models of the rocket and the rocket launcher. Started to add some textures to the rocket, but textures are really a pain in the *****. :beathead:


Well, enjoy!

 

[smarly]

Day 10 - Final touches

Day 10 - Final touches

Sorry for the long wait, but real life eventually did catch up with me, so had to take a break from the Rexus project. Well, I am back now, and I added the final touches to the rocket launcher. It was mostly texturing, which I found the most complicated and time-consuming part.

Here are some pics.


I still have to work out a few minor bugs in the code. Hopefully, the project should by complete by the end of the upcoming week-end.