Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Space Shuttle Ultra Support & development threads for Space Shuttle Ultra addon.

Reply
 
Thread Tools
Old 01-11-2018, 01:56 PM   #1306
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 Also, this isn't subsampling, AFAIR. We tested subsampling once in the past and it did not really solve all problems we had. The three steps are introduced for making sure, the subsystems work on the correct state data. The alternative would have been having a memento class for storing the subsystem states of all subsystems and create a copy of the old state before calculating the new state... which was much more evil to code. That is why the orbiter life-cycle was including in a smaller version inside SSU: Pre, Propagate, Post.
Yes, we have those 3, but there are also 3 more:
Code:
		while(t0 < fSimT + fDeltaT) {
		double dt = min(SUBSAMPLING_DELTAT, fSimT + fDeltaT - t0);
		for(i = 0; i<subsystems.size(); i++)
		{	
			subsystems[i]->OnSubPreStep(t0, dt, fMJD);
		}
		//if(BusManager() != NULL)
			//BusManager()->clbkPropagate(t0, dt);
		for(i = 0; i<subsystems.size(); i++)
		{
			//
			subsystems[i]->OnSubPropagate(t0, dt, fMJD);
		}


		for(i = 0; i<subsystems.size(); i++)
		{	
			subsystems[i]->OnSubPostStep(t0, dt, fMJD);
		}
		t0 += SUBSAMPLING_DELTAT;
		lSubCount ++;
	}
Like I said, I don't know is this, or something similar is going to be needed for the new DPS, but currently it is not used and creates a slide show at 100x or higher.

---------- Post added at 01:56 PM ---------- Previous post was at 01:50 PM ----------

Quote:
Originally Posted by GLS View Post
 There's something on an Orbiter manual about a binary mesh format that would be faster to load... anyone know anything about it?
It seams this isn't an alternative...
Quote:
Originally Posted by 3DModel.pdf
 ORBITER uses a proprietary mesh file format. Mesh files are ASCII text files. (A binary format may be introduced in the future).
(...)
meshc: mesh compiler. Eventually this may be extended to convert mesh files from text to a binary format (for more compact storage and faster loading)

Last edited by GLS; 01-11-2018 at 02:02 PM.
GLS is offline   Reply With Quote
Old 01-11-2018, 04:26 PM   #1307
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by GLS View Post
 On an 14s load, I got a 2s decrease with loading just one small texture.
I also found about 3s for loading the aero data, which I currently know nothing about, so I still have to look at it to see if something can be done.

I'd like to replace all the mesh groups with a smaller version to see the effect of a smaller mesh file, but that would take all day...
There's something on an Orbiter manual about a binary mesh format that would be faster to load... anyone know anything about it?

---------- Post added at 12:57 PM ---------- Previous post was at 12:48 PM ----------



Yes it is, because if you have no code, then no mesh or texture will ever be loaded. They are connected. One can say that creating the RCS textures and particle streams is "code" while the another can say that is "graphics". Most of the times it's hard, if not impossible, to separate things.
There is code behind the *.cfg files. In fact they're the original code for add-on vessels. *.dll modules for vessels only came along much much later along with novelties such as animations and particle streams.

Even the default Atlantis loads in the same 4 seconds as the Carina tests. The only thing I can't test, is how much of an impact our VC has. I'd like to see a log of when each element is loaded. This way it could be definitely established what takes the longest to load.
DaveS is online now   Reply With Quote
Old 01-11-2018, 05:31 PM   #1308
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 There is code behind the *.cfg files. In fact they're the original code for add-on vessels. *.dll modules for vessels only came along much much later along with novelties such as animations and particle streams.

Even the default Atlantis loads in the same 4 seconds as the Carina tests. The only thing I can't test, is how much of an impact our VC has. I'd like to see a log of when each element is loaded. This way it could be definitely established what takes the longest to load.
The subsystems, mesh and texture loading, plus setup of pretty much everything takes about ~3.5s. If we don't load the meshes (Orbiter, Cockpit, VC, MidDeck, Ku_band_DA and SSU_entry), those 3.5s go down go to peanuts. (This means I'll really do something I've been considering for a while which is moving the Ku antenna mesh stuff out of the Atlantis class, as like the RMS, ODS, ExtAl, CISS, EDO, etc, it isn't mandatory, so it should only get loaded when it is needed. This won't gain much and it will only be when not using the antenna, but it makes total sense.)

Scenario loading, mission file loading, vc panel loading (now with panel meshes/textures) and a few more subsystems takes another ~2.5s. Loading a "huge" scenario vs nothing doesn't seem to change anything.

The aero data could be hardcoded as I don't see the need for it to be "configurable" as it is. IMO this is the only part where we might gain something on the code side... any volunteers for understanding all that aero stuff and 4D tables?
GLS is offline   Reply With Quote
Old 01-11-2018, 05:44 PM   #1309
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by GLS View Post
 The subsystems, mesh and texture loading, plus setup of pretty much everything takes about ~3.5s. If we don't load the meshes (Orbiter, Cockpit, VC, MidDeck, Ku_band_DA and SSU_entry), those 3.5s go down go to peanuts. (This means I'll really do something I've been considering for a while which is moving the Ku antenna mesh stuff out of the Atlantis class, as like the RMS, ODS, ExtAl, CISS, EDO, etc, it isn't mandatory, so it should only get loaded when it is needed. This won't gain much and it will only be when not using the antenna, but it makes total sense.)

Scenario loading, mission file loading, vc panel loading (now with panel meshes/textures) and a few more subsystems takes another ~2.5s. Loading a "huge" scenario vs nothing doesn't seem to change anything.

The aero data could be hardcoded as I don't see the need for it to be "configurable" as it is. IMO this is the only part where we might gain something on the code side... any volunteers for understanding all that aero stuff and 4D tables?
That still doesn't add up to 17 seconds. 3.5+2.5=6.0! This is from when the SpaceShuttleUltra vessel shows up on the load screen until scenario start (it's the last thing to be loaded). Even loading all the planetary stuff is rocket fast. Something is eating up CPU cycles. Is it systems initialization that takes so long? That's something only we do. That I could understand.

Moving on: How are we handling verniers currently? I think that they might be a bit too powerful as the orbiter is very sensitive when translating (doing prox ops).

Last edited by DaveS; 01-11-2018 at 05:47 PM.
DaveS is online now   Reply With Quote
Old 01-11-2018, 06:05 PM   #1310
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 That still doesn't add up to 17 seconds. 3.5+2.5=6.0!
The STS-1 orbit scenario I was loading took ~12-15s.
It's actually 3.5 (constructor) + 2.5 (state load) + 4.0 (module init, mostly the aero data) = 10s. I measured a few more but it's all in the tens or hundreds of a millisecond range.


Quote:
Originally Posted by DaveS View Post
 Something is eating up CPU cycles. Is it systems initialization that takes so long? That's something only we do.
I took the mesh loading out of the equation and the constructor, where several duzens of systems are created + the all current GPC software, went down from 3.5s to tens of milliseconds.

---------- Post added at 06:05 PM ---------- Previous post was at 06:00 PM ----------

Quote:
Originally Posted by DaveS View Post
 Moving on: How are we handling verniers currently? I think that they might be a bit too powerful as the orbiter is very sensitive when translating (doing prox ops).
Probably by firing the current RCS thruster setup at 10% or something...
Our RCS is IMO very rudimentary. Making all the thrusters correctly and having all the visuals is easy, the big problem is creating the "RCS table" in the GPCs so when the vehicle wants to rotate in a certain direction, the correct thrusters are commanded for the correct duration...
GLS is offline   Reply With Quote
Thanked by:
Old 01-11-2018, 08:27 PM   #1311
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 Like I said, I don't know is this, or something similar is going to be needed for the new DPS, but currently it is not used and creates a slide show at 100x or higher.
Should work without, the only kind of "subsampling" like behavior might be counting the IO operations to tell when a timestep is over. Luckily, the IOP already is a single CPU running multiple parallel I/O operations in a round-robin fashion.
Urwumpe is offline   Reply With Quote
Old 01-24-2018, 01:41 AM   #1312
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quick q: Where is the shuttle-to-MLP attachment point located WRT to the SRBs? I'm trying align the stack with the HDPs on the new MLP and there seems to be some sort of offset. I have verified the position of the HDP attachment point in the MLP code, it is spot on.
DaveS is online now   Reply With Quote
Old 01-24-2018, 11:47 AM   #1313
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 Quick q: Where is the shuttle-to-MLP attachment point located WRT to the SRBs? I'm trying align the stack with the HDPs on the new MLP and there seems to be some sort of offset. I have verified the position of the HDP attachment point in the MLP code, it is spot on.
Too tired at the moment to dive into that now... I'll look at it in the morning.

---------- Post added at 11:47 AM ---------- Previous post was at 02:08 AM ----------

Quote:
Originally Posted by DaveS View Post
 Quick q: Where is the shuttle-to-MLP attachment point located WRT to the SRBs? I'm trying align the stack with the HDPs on the new MLP and there seems to be some sort of offset. I have verified the position of the HDP attachment point in the MLP code, it is spot on.
Should be this:
Code:
const VECTOR3 POS_HDP = _V(0.0, -10.25, -19.6);
Atlantis_defs.h:109
GLS is offline   Reply With Quote
Thanked by:
Old 01-24-2018, 05:09 PM   #1314
DaveS
Addon Developer
 
DaveS's Avatar


Default

Anyone have any objections to me correcting HDP_POS to actually be at the bottom of the SRB aft skirts where they meet the HDPs on the MLP?
DaveS is online now   Reply With Quote
Old 01-24-2018, 05:14 PM   #1315
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by DaveS View Post
 Anyone have any objections to me correcting HDP_POS to actually be at the bottom of the SRB aft skirts where they meet the HDPs on the MLP?
No. I would I just say we should make sure its not the "bottom of the SRB aft skirts" but precisely "Z axis coordinate is the interface plane between SRB and MLP"
Urwumpe is offline   Reply With Quote
Old 01-24-2018, 05:25 PM   #1316
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by Urwumpe View Post
 No. I would I just say we should make sure its not the "bottom of the SRB aft skirts" but precisely "Z axis coordinate is the interface plane between SRB and MLP"
Which is the one and the same: https://www.dropbox.com/s/btmxwkmwtf...Skirt.jpg?dl=0

The only protrusions are the thermal curtain, nozzle and the HPU exhaust duct.
DaveS is online now   Reply With Quote
Old 01-24-2018, 10:11 PM   #1317
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by DaveS View Post
 Which is the one and the same: https://www.dropbox.com/s/btmxwkmwtf...Skirt.jpg?dl=0

The only protrusions are the thermal curtain, nozzle and the HPU exhaust duct.
Yes - but if we are not describing it as explicitly as possible (source code comment should be enough), we might easily break it in the future.

---------- Post added at 23:11 ---------- Previous post was at 19:30 ----------

After digging for hours through the documentation on my HDD, I finally found the answer I was looking for:

A Listen Command over the Shuttle Bus is a command word with a interface unit address of 01000B (8).

(This was hidden in a document explaining how the redundant set synchronization works)

Inside the command data word is a 8 bit index, which is defined as an even number from 0 to 254 (Yes, that actually means 7 bit).

This command is mentioned a lot in the I/O processor flow charts. It operates together with the WIX (wait for index instruction). When a listening BCE is in WIX state and receives a "listen" message, it will take the index of that message for looking into a table (The WIX table) in the FCOS CSECT which contains the addresses of BCE programs that will process the incoming data words.

This mechanism is especially important for the ICC busses and the DK busses.

Yeah... now still to research the question: How often do BCE programs change? If they are mostly constant except large configuration changes and even payload I/O not requiring new BCE programs, it would be better to define the functions in C++ and just configure which programs are available for a mission (For example automatically if a certain hardware component is installed). The FCOS programs for example did not change much since ALT.

Also interesting: There is a self-test BCE (#25) in the AP-101S, which is missing in the AP-101B...
Urwumpe is offline   Reply With Quote
Old 02-14-2018, 08:48 PM   #1318
DaveS
Addon Developer
 
DaveS's Avatar


Default

Here's a question: Should we migrate over to dbeachy1's XRSound package given all the problems that OrbiterSound has with Orbiter 2016? For me SSU plays nicely with XRSound even though it isn't tied into it. No CTDs or other weird oddities.
DaveS is online now   Reply With Quote
Old 02-14-2018, 08:56 PM   #1319
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 Here's a question: Should we migrate over to dbeachy1's XRSound package given all the problems that OrbiterSound has with Orbiter 2016? For me SSU plays nicely with XRSound even though it isn't tied into it. No CTDs or other weird oddities.
For example...
GLS is offline   Reply With Quote
Old 02-14-2018, 09:14 PM   #1320
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by GLS View Post
 For example...
Could you explain this further? Do you mean with OrbiterSound or with XRSound?
DaveS is online now   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 08:06 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.