Gemini Golden Jubilee Upgrade

[Urwumpe]

Nice indeed. Interesting if someone wants to do systems simulation.

:crystalball:

I have OBC emulation, embedded assembler and a library handling DC circuits spanning over multiple vessels...

I just don't know how far I will get, this was the result of some boring days between Christmas and New Year, as well as some frustration with the Project Gemini add-on and multistage2.dll :facepalm: Now its exam time until February.

 

[4throck]

Indeed, that's the problem. To go further than the generic sc3/multistage implementation takes a lot of time.
Once I tried to redo a vessel in LUA, only to find that it took a lot of time for little gain compared to SC3. Better to load LUA on top of it.

Based on that, I'd suggest doing system implementation using a MFD and not the spacecraft itself.
That way you could target any Gemini version and not to worry about what you already have working.

 

[Urwumpe]

Based on that, I'd suggest doing system implementation using a MFD and not the spacecraft itself.

Problem: You can't talk to a MFD by a reliable way. You can only indicate things and trigger events, but the MFD is hard to be influenced by external factors.

And Gemini is really a flexible vehicle, what is much of the fun of it. You can really "pimp your ride" with it.

I currently made every part of Gemini a separate vessel with a separate DLL. Since all vessels are based on the same shared static library, this is much easier than it initially sounds.

So, the structure during prelaunch is currently like that, held together by attachments (italic entries are currently missing):

|LC 19| | |
|First Stage| | |
|Second Stage| | |
|Reentry Module| | |
Retro Section|R&R section| Horizon Scanner | Ejection seat | Docking bar
Equipment Section|Nose fairing| Scanner Fairing | Astronaut |

If you want to launch with a different adapter section, you only need to modify the scenario entries for retro section and equipment section - not sure if I can modify the sections after loading the scenario or if I will need a new configuration file there.

But thats something for another thread... once I really have something cute to show, because currently you need to appreciate HUD painting and debug strings to really notice the changes.

 

[4throck]

Indeed. My small experience with the LUA driven Agena control MFD has shown me that.
Yet if you weight work x time x results it's a good way to get things done fast, and better than the pure SC3 approach.

Anyway, do keep an eye on the tread about the Gemini resources and repack.
On my machine I have a custom Orbiter install for it, and I have all the addons working together. Looks really good, a shame it can't be released.

If your developments could at least reuse the same meshes, that would be great. I really don't want to have another copy of the Gemini seat mesh in my install!

 

[Urwumpe]

Added a link to the Gemini Press Reference book, from there you can also find more Gemini documents from bobandreponts collection.

Indeed. My small experience with the LUA driven Agena control MFD has shown me that.
Yet if you weight work x time x results it's a good way to get things done fast, and better than the pure SC3 approach.

Well yes - but running the Gemini Mathflow from the VirtualAGC page would be a pretty nuissance with Lua. :lol: And that became the first big fun for an old IT guy.

If your developments could at least reuse the same meshes, that would be great. I really don't want to have another copy of the Gemini seat mesh in my install!

Well, I hope that I could one day get corrected and more detailled meshes for it. For example, the equipment section lacks the honeycomp blast shield towards the retro section, that gets important during a mode I-II abort. Or the many antennas on the adapter section. The many different payloads in the equipment section.

Especially a VC would be great (but no simple job for the mesher, because of the many variable parts). Also, the instrumentation packages for the unmanned missions would be interesting to add as replacement for the ejection seats. Or a mission control for keeping the unmanned missions (or the unmanned parts of it) a challenge. With slide rules please. :lol:


But this time, its coding first. Still work on the EPS framework to group multiple relays (about 20 per panel) into one subsystem for keeping the code tidy. Invisible to the player (relays are already working as subsystems of their own), large effect for the developer, huge refactoring. :facepalm:

Luckily, the milestone is currently only Gemini-Titan 1.

 

[4throck]

100% agree. I looked into the panel variations when doing textures and most of them are documented, but there are no usable photo references.
Specially photos of the preflight cockpits. Showing them aged, as they are now, would be a mistake.

I think that your approach is correct:
- code first, then try to connect that to mesh / panel animations.

Until then, you can simply dump the information into a status "table" drawn on screen, by pressing "tab" for example. Just a suggestion

 

[Urwumpe]

Until then, you can simply dump the information into a status "table" drawn on screen, by pressing "tab" for example. Just a suggestion

Actually, I just dump it either into the HUD or into orbiter.log, if it is about full deep debugging. :lol:

The real advantage of coding first and meshes later is also, that you focus automatically much more on a bottom-up approach, which I currently experience as very good process. it initially is slow and there is little to see, but then things gather momentum and get done really quickly.

 

[4throck]

That's what I had in mind!

Works great as a panel.
Just make it on/off using TAB or something.

You can use the same approach to switches. Simply use 2 keys for next/previous switch, and another to flip it. Don't worry about graphics, those colored boxes will do. In fact, it is a 2D panel you have there :thumbup:


3D VCs are cool but hard to read. As you have it, it's the best of both worlds.

 

[Urwumpe]

3D VCs are cool but hard to read.

I disagree there - especially for something like Gemini, where you are much closer to the instrument panel and where you have only few small indicators.

You could maybe not read the check list tape on the center console, but especially the radar indicator would be easy to read (You don't need to tell the EXACT distance - what really matters is making sure the range rate pointer is always counter clockwise of the range pointer)

What I like of 3D VCs is, that if they are properly designed (like a real spacecraft), you can get a very good overview and the elements are really ergonomically placed, so you don't need to seek long to find a switch again.

In NASSP for example, even when I know what I am seeking, I need hours to switch to the right panel and scroll until I can manipulate the switch.

In a VC, it would be a single movement with mouse and mouse wheel, if needed.

I am a VC guy, I admit it.

Its like in DCS:Warthog, I would need to zoom in to read the labels there, but once you know how the C&W lights are sorted, you can already know by the position of the blinking light to tell what went wrong.

 

[4throck]

Your point valid, but only works if you have a large monitor.
Try reading VC instruments on laptop screen at 1366x768.... you can zoom in yes, but the you lose the immersive feel. Dont' forget that a lot of people have setups like that.

That's why I like your approach! You have both the overall VC feel, and a quick HUD that gives you all readings. Even if I had a full working VC, the schematic buttons would be a useful option.

Anyway, to animate a VC you need to implement the type of code you are working on right now. So you are making progress towards it.

You "only" need to mary group animations to your button states. Tedious but doable.

 

[Urwumpe]

Ok, I use 1920 x 1080 now on a 15.6" notebook. :hmm:

Well, the big plan is to develop a core library that assists developing historic spacecraft and that works equally well with generic cockpit view, Panel2D and VC mode. But thats currently just a concept for designing the respective interfaces in the library, nothing that already works out.

For example, a switch exists in multiple ways in the concept:

first as simulation entity in the backend of the vessel. It is simulated, changes its electrical properties during the timestep if needed and can be manipulated by AI crew members.

Then, you have user interface classes connecting mouse and display to the simulation entity.

As final layer, you have visualization details, which do the actual painting and which must not be hard coded in the DLL, but can be defined as external file (for example XML)

To do the rendering of the lights in the VC, I would for example just use one large texture for all lights, and shift the V coordinates of the light mesh group depending on light state. Even with a AGP bus, this is still much faster than the currently preferred Bitblit.

 

[Zachstar]

Does this mean your work will allow me to have a Lunar Gemini on top of a Saturn V/N1 Frankenstein Velcro rocket?

Okay I'll stop.

The AI crew members part sounds very interesting to me. A way to add "life" to Orbiter missions in my opinion.

 

[Urwumpe]

The AI crew members part sounds very interesting to me. A way to add "life" to Orbiter missions in my opinion.

Actually, it is just a kind of a cheat to keep the work load for the player low. :lol:

 

[4throck]

O
As final layer, you have visualization details, which do the actual painting and which must not be hard coded in the DLL, but can be defined as external file (for example XML)
....
To do the rendering of the lights in the VC, I would for example just use one large texture for all lights, and shift the V coordinates of the light mesh group depending on light state. Even with a AGP bus, this is still much faster than the currently preferred Bitblit.

Go for XML to indicate mesh animations (group, translation, scale, direction, center, etc, same as SC3). That way other developers can make the VC using standard tools, add the proper animations and test them one by one.

Don't go for texture coordinates for animations, that will complicate export from 3d modeling software. Go for mesh group translations/rotations.

For example:
If you need lighted buttons, simply have 2 versions of the button and animate them going up and down toward the pilot as needed. Quite simple :thumbup:.
(tested that on the OK-GLI VC mesh, it works)

This can simulate both analog cockpits with gauges and switches and digital readouts. Of course, for digital you need to have a mesh group for each character (thinking about he Apollo DSKY display for example), but still doable.

---------- Post added at 09:08 ---------- Previous post was at 09:01 ----------

Does this mean your work will allow me to have a Lunar Gemini on top of a Saturn V/N1 Frankenstein Velcro rocket?

You can do that using Velcro. Setting up the necessary config files is tedious, but anyone can do it. No programing needed.
There's even an old Lunar Gemini add-on that can give some direction on how to set things up.

 

[Urwumpe]

Go for XML to indicate mesh animations. Use same syntax as sc3. That way other developers can make the VC, add the proper animations and test them one by one.

Exactly thats the idea - bypass the need to use meshwizard or AC3D as developer again to understand what the mesher intended, get the data in a standard format and allow quick and easy manipulation of the animation during testing.

But it is not going to be a generic DLL at all. Thats simply too complicated to realize such metaprogramming. while a lot of the work could get defined by files, like the electrical connections, it is not always an improvement.

Don't go for texture coordinates for animations, that will complicate export from 3d modeling software. Go for mesh group translations/rotations.

For example:
If you need lighted buttons, simply have 2 versions of the button and animate them going up and down toward the pilot as needed. Quite simple :thumbup:.
(tested that on the OK-GLI VC mesh, it works)

As other game engines do that very successfully, I doubt that 3d modelling software is the limit. In the worst of all cases, the part just needs to use the right material and the texture coordinates are defined by XML completely.

Also, going up and down is not needed. It is much simpler for a DLL to simply disable a meshgroup for rendering. But then the people coding the graphics clients will complain about me wasting performance again.

 

[4throck]

As other game engines do that very successfully, I doubt that 3d modelling software is the limit. In the worst of all cases, the part just needs to use the right material and the texture coordinates are defined by XML completely.

Also, going up and down is not needed. It is much simpler for a DLL to simply disable a meshgroup for rendering. But then the people coding the graphics clients will complain about me wasting performance again.

Whatever works. My suggestion works well in real time powered by LUA.
And using the basic sc3 animations allows more people to help and participate, unless you want to do the meshes yourself.
Nothing wrong with it just lots of work

 

[Urwumpe]

Nothing wrong with it just lots of work

Well, I am coder not a mesher. Give me enough pain and I will code a command line compiler to define VCs by XML and compile a mesh and render the indicator textures. :lol: (Yes, thats a joke - Only because it can be described by an algorithm, this does not mean that it is a better way to make meshes)

 

[4throck]

Go for it! That would be a universal VC maker. FlightSim does something like that for 2D panels, where you define different the positions of the default gauges for different aircraft.

What you suggest is realistic if you use pre-existing meshes for each VC component. I think the community could put together a generic mesh library relatively fast.

It is a great idea!

 

[Urwumpe]

Go for it! That would be a universal VC maker. FlightSim does something like that for 2D panels, where you define different the positions of the default gauges for different aircraft.

What you suggest is realistic if you use pre-existing meshes for each VC component. I think the community could put together a generic mesh library relatively fast.

It is a great idea!

The problem is: A CAD tool for making VCs would be the better choice to realize this (using a visual editor for assembling it all, but without the generic mesh editing perspective). Making a tool for creating instrument meshes and textures would be a relatively small task, but putting it all together and make it look good is harder. Maybe it would be better to just create instruments in a format, that can be included in 3D studio or else.

But that is no job for me. :lol: Mostly because I will be quite busy making sure the Titan II does lift off properly in April.

 

[4throck]

You may be complicating things. Look at Velco or Multistage. They have no mesh editing or viewing options and they work.

But yes, don't get side tracked with that, work on the Titan :thumbup: