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 offline   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 offline   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
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 06:03 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.