New Release OGLAClient release 091011

EDIT:
Sure, but what relation to use?
Hmmm, in reality, how is the brightness of a rocket determined?

I would think it is essentially mass flow--the more mass you're throwing out the back, the brighter it would be.

I think, then, it would scale up with thrust and down with ISP...

Alternately, since realistic high-ISP engines would already have lower thrust, you could possibly just make it a factor of thrust. More thrust = brighter.
 
Hmmm, in reality, how is the brightness of a rocket determined?

I would think it is essentially mass flow--the more mass you're throwing out the back, the brighter it would be.

I think, then, it would scale up with thrust and down with ISP...

It would scale up with power (which scales with the product of thrust and ISP) and down with efficiency (if all your energy is going into the KE of the propellant and the spacecraft, with no losses, you won't see any light at all), and would also somewhat be influenced by the properties of the exhaust and the engine type. I understand that LH2-LOX rockets put out most of their light in the UV range and the flame is transparent. It will also depend on the properties of the local atmosphere: Even if the exhaust stream isn't hot to begin with (unlikely for most engines), if it's moving at any kind of speed it will get really hot really fast when it hits air.

But for a given set of properties, increasing either thrust or ISP will make the engine brighter. Increasing the total power will increase the amount of power lost as heat for a given efficiency. If you're using an engine that gets its thrust from the expansion of hot gasses, you're guaranteed to be losing a fair amount of energy as heat.
 
Update 3:
http://orbides.1gb.ru/orbf/oglaclient-091010_beta-090728.zip

Changes:
*Fixed multilight
*OGLA SDK and example for it
*DG with lights
-Usability fixes:
*Calibrated shaders lighting model
*Calibrated advanced graphics
*Fixed some advanced graphics instrumentation invisibility problems
*Fixed texture transparency problems on markings and HUD

The multilight works differently depending on the mode. In this release it is on by default, disabled by F7-2.
-In performance mode (right) the FPS should be largely independent of the amount of lights, but the lights themselves are computed by-vertex, that is the spotlight smaller than the launchpad will not light the launchpad.
-In advanced graphics mode (left) that is turned on by F7-u, the FPS is dependent of whether the lights are on, and the lights are computed by-pixel, so the spotlight will cast light between vertices. Due to performance hit, advanced graphics mode have a separate switch for terrain illumination, F7-8 (terrain enabled by 5), with it's on the FPS drops significantly.
ogla-091010-1.jpg

ogla-091010-2.jpg


Also included, OGLA SDK and DG code example with lights defined.
Defining lights is quite simple, for example oglcAddLight(vis,OGLA_LIGHT_SPOT,_V(0,-2,10),_V(0,-0.7071,0.7071),_V(1,1,0),45,10e6,400);
call registers a landing spotlight in the DG example.
You can then bind the light to thruster group using oglcBindLightThruster, or animation using oglcBindLightAnim. You can also toggle and tune the light manually.

Example DG have 3 lights defined - main engines, hover engines and landing spotlight. Latter is enabled when the gears are down.

Suggestions? Ideas?
What kind of functionality do you, add-on developer, expect from OGLA SDK?

Does this illuminate the contrail smoke as well?
Smoke is not implemented yet. I think it will.
Could you make the relation user definable?
possibly just make it a factor of thrust. More thrust = brighter.
Ok, then the add-on creator can define the power of the engine's light, and the brightness will scale with thrust. The feature is disabled by default and is enabled by the add-on maker.
 
Terrain texture resolution?
Even at Lv14 it will be quite blurred up-front.
Update one should have improved the sharpness of the Lv14+ rendering, i gather it's not good enough?
I don't know, maybe just the high resolution texture loading not good. So the textures changing to lower resolution too close to the camera. I don't know how they call it, but it's called LODing in 3d meshes

These need OpenGL 3.2, and i'm not sure there are graphic cards that support it yet (meaning, i don't have one). So, not yet.

There are graphics cards, since some years, all directx10 gpu-s support opengl 3.2 in HW, the problem is, the first 3.2 driver came out from nvidia 1 week ago, but ati still working on it. But ogl 1.1 also supports it, using EXT_geometry_shader4


And another problem. I loaded one of your scenarios shipped with ogla, called ogla_setscene, thats over habana about 2 km alt, in daylight, and the Moon looks like a black circle from there.
 
What about another big light source we have in LEO - Earth?
ogla-091010-9.jpg

ogla-091010-8.jpg

What does Earth shine look like?

I loaded one of your scenarios shipped with ogla, called ogla_setscene, thats over habana about 2 km alt, in daylight, and the Moon looks like a black circle from there.
Got it, fixing.
 
LOL now i watched both gpu, and cpu usage running orbiter with ogla.

over himalaya, advanced graphics, terrain, advanced athmosphere enabled every realism setting on, orbiter uses all remaining cpu time, on both cores (at least it's multithreaded now :D), and only 33% of gpu. So my fps is limited by the cpu... but it's strange that the orbiter limited by a dual core amd x2 4400+.
(It's the time to use gpu for orbiter physics?)
But when i start it with the plain orbiter exe, it uses just 1 core... hmm


And i saw another bug. From the dense atmosphere, the limit of visible athmosphere looks too sharp.
 
over himalaya, advanced graphics, terrain, advanced athmosphere enabled every realism setting on, orbiter uses all remaining cpu time, on both cores (at least it's multithreaded now :D), and only 33% of gpu. So my fps is limited by the cpu... but it's strange that the orbiter limited by a dual core amd x2 4400+.
(It's the time to use gpu for orbiter physics?)
I would think that most of that CPU time is spent calculating the terrain, which is still quite a power-hungry task. It is also the only significantly multithreaded part in Orbiter-OGLA pair that i know of.
 
Last edited:
I would think that most of that CPU time is spent calculating the terrain, which is still quite a power-hungry task. It is also the only significantly multithreaded part in Orbiter-OGLA pair that i know of.

You could compute terain on the gpu, its a bit of work but in the end the results are worth it.

Something like a 3870 has over half a TFLOP of computing power.
 
Last edited:
Ok, Hm. ISS wouldn't look much different, since there is no HDR.

What about Brighton Impact Crater?

OK, those images look better as far as the scale of the lit area, but I think part of it is that the color towards the center needs to be a bit whiter. The eye can't perceive differences in color well at high intensities (because there's so much light at all colors, so the dominant color channel hits its maximum value, and isn't perceived to get any brighter), so everything tends to look white or near white, and thus such a deep shade of blue/violet makes things look fairly dimly lit from the psychological standpoint. So it would look brighter if the light faded from pretty much pure white at locations close to the DG, to the same bluish color further away. If that's to complex, it would probably be good to make the light whiter all around. (Getting a computer monitor to display exactly what the eye would perceive can be tricky). .
 
You could compute terain on the gpu, its a bit of work but in the end the results are worth it.

Something like a 3870 has over half a TFLOP of computing power.

I've mentioned it, some replies ago (geometry shader).

But for that everone needs at least a geforce 8xxx or more, or a hd2xxx or more.
 
I don't dare to ask

Any chance there will be eclipses in orbiter?
 

On the moon... it's looks like this when i watch the moon surface this angle. Above or under it's good. Only comes out when the advanced graphics enabled.

And there is a problem with the cockpit views too. I used the dg in 2d virtual cockpit, but when i pressed F8 to change to other view, the picture "desintegrated" and the display driver restarted, and everthing started to lag, music too until i killed the orbiter process. I tried with another scenario where the default was the 2d cockpit without design elements (so just the hud, mfd), after an F8 happened the same. So i think the problem is with the 3d cockpit.
 
I don't dare to ask

Any chance there will be eclipses in orbiter?

Eclipses can already occur. I was privileged to spot a partial solar eclipse while I was building my space station. It was very cool.

However, I believe that you're asking for those eclipses to throw shadows on other planets, correct? I certainly hope that that comes about.

EDIT: I can't get OGLA to work. When I hit F7 in the launchpad or in game, nothing happens. Also, whenever I enable OGLA or enter the launchpad with it active, I get the following error:

"The procedure entry point ?clbkSetMeshProperty@GraphicsClient@oapi@@UAE_NPAHKK@Z could not be located in the dynamic link library Orbiter.exe."

Yes, I am using the latest version of the beta. I'm also trying to use the third update of OGLA.
 
Last edited:


And i still see and old bug: some object are visible through the celestial bodies. Fe i can see brighton beach from the opposite side of moon, and luna ob-1 too, and same happen with some bases on earth.
 
I don't dare to ask

Any chance there will be eclipses in orbiter?

Already there! Start a scenario on MJD 55031 and fly to the moon, keep watching the moon and you'll see the longest eclipse this century.
 
{IMG}
On the moon... it's looks like this when i watch the moon surface this angle. Above or under it's good. Only comes out when the advanced graphics enabled.
Hm. With advanced atmosphere on, right? No check for where to draw the haze, to be fixed.

And there is a problem with the cockpit views too. I used the dg in 2d virtual cockpit, but when i pressed F8 to change to other view, the picture "desintegrated" and the display driver restarted, and everthing started to lag, music too until i killed the orbiter process. I tried with another scenario where the default was the 2d cockpit without design elements (so just the hud, mfd), after an F8 happened the same. So i think the problem is with the 3d cockpit.
ATI card? I get a similar problem on Radeon 4670 - some settings and VC results in a total hang-up.
Since nothing but a reset cures that it's hellishly hard to debug or even figure out WTF, so i plugged Nvidia in for the moment.
To be eventually fixed.

Yes, I am using the latest version of the beta. I'm also trying to use the third update of OGLA.
Have you downloaded the 090728 patch?
Make sure there are no no-plug-in-the-wall kind of problems.
Are you sure you use Orbiter_ng.exe?

That is being worked on.
And i still see and old bug: some object are visible through the celestial bodies. Fe i can see brighton beach from the opposite side of moon, and luna ob-1 too, and same happen with some bases on earth.
Correct, for performance reasons the terrain is made solid only when the shadows are turned on.
Is that a bad idea?
 
Okay, it's working now. However, it only appears in a small window in the upper left corner of my screen regardless of the video settings. Very annoying.
 
Back
Top