New Release OGLAClient release 091011

[Artlav]

OGLAClient status release 091007:
orbides.1gb.ru/orbf/oglaclient-091007_beta-090728.zip
orbides.1gb.ru/orbf/oglaclien...90728-fix1.zip
orbides.1gb.ru/orbf/oglaclient-091008_beta-090728.zip
orbides.1gb.ru/orbf/oglaclient-091010_beta-090728.zip
Latest:Beta 091025, info in thread http://www.orbiter-forum.com/showthread.php?t=10728 .
Install over beta 090728( latest 090722 + patch http://download.orbit.m6.net/betaTB24S/orbiter090729beta_base.zip ).

Public beta mirror: http://orbides.1gb.ru/orbiter_public_beta.php

This is yet another "it's still alive" status release.

Changes:
*Beta 090728 compatibility
*2D graphics debugging and straightening out
*Fixed vessel creation and deletion related bugs
*VC textures support
*Dynamic textures and skins support
*Better Sun rendering
*Surface shadows

The main point of this release is playability and usability.
Nice effects aside, this is after all a game (or a simulator), that should be played. So, feedback on what is preventing you from playing it like nothing broken is welcome.
The default setup is with all FPS-hungry features off, if you want some, you should activate them manually in the F7 menu. Some may be broken, some are very slow.

Installation:
Copy Beta 090331 (http://orbitervis.wiki.sourceforge.net/OrbiterPublicBeta) into a folder, copy latest Orbiter beta 090722+090728 over it, copy OGLAClient over it, optionally, copy heightmaps in.

Pre-composed heightmaps:
http://orbides.1gb.ru/orbf/earth-hmap-lv8.zip (84Mb) Very recommended. Terrain is a bad joke without it.
http://orbides.1gb.ru/orbf/mars-hmap-lv8.zip (82Mb)
http://orbides.1gb.ru/orbf/moon-hmap-lv8.zip (81Mb)
Also, the updated World Studio is included for better heightmaps and Lv12-Lv17 texture acquisition.

Current:

Performance:
Atlantis, terrain, shadows, advanced graphics, 25 FPS:

Atlantis, terrain, shadows, 43 FPS:

Atlantis, shadows, 60 FPS:

Atlantis, nothing, 200 FPS:

Skins and dynamic plates support:

VC elements support:

---------- Post added at 08:45 PM ---------- Previous post was at 05:55 PM ----------

Update 1:
http://orbides.1gb.ru/orbf/oglaclient-091007_beta-090728-fix1.zip
Install over beta 090728( latest 090722 + patch http://download.orbit.m6.net/betaTB24S/orbiter090729beta_base.zip ).

Changes:
*Fixed Atlantis tanks
*Straighterned fonts a little
*Fixed a bunch of various bugs
*Improved performance here and there


One thing i wonder about - is it me not remembering, or does the terrain rendering work significantly faster and smoother than before?
Both from orbit, and from nearby. Heightmaps recommended.

Terrain (F7-5 to enable, F7-6, F7-u to improve sky):

 

[Linguofreak]

So, feedback on what is preventing you from playing it like nothing broken is welcome.

I left my joystick in the States and the Orbiter core doesn't run well under Wine are the two biggest reasons.

 

[Jarvitä]

I left my joystick in the States and the Orbiter core doesn't run well under Wine are the two biggest reasons.

But does it run under wine at all?

 

[Linguofreak]

But does it run under wine at all?

Yes. I've done it, and I think I've even done it with an Orbiter 2006 install (and thus without OGLAclient).

But it doesn't run very well.

 

[Disconnect]

I've tried this version. But for me, the stars arent appear. I can see all planets, but no stars, but i don't remember for the last version... is this a bug, or it isn't implemented yet?
The FPS isn't bad, but nor too good. The graphics isn't so complicated as many other games, but FPS isn't higher too. There will be problems with higher resolution models.
But the graphics now more better than the d3d7 client, exept ofc the terrain texture resolution
BTW Artlav, did you think about using geometry shaders? I think it would be good for terrain rendering.

 

[Artlav]

But for me, the stars arent appear. I can see all planets, but no stars, but i don't remember for the last version... is this a bug, or it isn't implemented yet?

A mix of both - older stars code went obsolete, but since i usually run Orbiter with stars turned off, i never noticed.
To be fixed.

exept ofc the terrain texture resolution

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?

did you think about using geometry shaders? I think it would be good for terrain rendering.

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.

 

[Arrowstar]

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?

Out of curiosity, what sort of resolution does Microsoft Flight Simulator use for it's ground terrain? I ask simply because it looks better than Orbiter's, and I'm curious to know if there's any sort of technical limitation that would prevent anyone from generating a ultra-high resolution Earth texture or some such thing.

 

[n72.75]

Works good, performance is acceptable.

 

[Linguofreak]

Out of curiosity, what sort of resolution does Microsoft Flight Simulator use for it's ground terrain? I ask simply because it looks better than Orbiter's, and I'm curious to know if there's any sort of technical limitation that would prevent anyone from generating a ultra-high resolution Earth texture or some such thing.

Well, there are a number of limitations that I can see from a purely layman's standpoint, and there may be a few more from the perspective of those with technical knowledge.

The first is that Orbiter has no native support for "bumpy" terrain. Artlav has developed Orulex for that, and I think OGLAclient uses that or a similar system. So most screenshots you see of Orbiter will have flat terrain.

The second is the typical altitude the camera is at in Orbiter: The camera is usually so high that you don't really notice the low terrain resolution.

The third is that of time, the higher resolution you use, the more time a developer needs to spend waiting as his computer chews on processing it, the more time he needs to spend checking it to make sure it all got put together right, and there might also be problems for the developers of the program itself in getting it to support high resolution, and such problems are going to take time to solve. Since Orbiter is freeware, the developers aren't getting paid for their time, and sometimes real life gets in the way.

The final one is that of size: More resolution requires bigger files. With a commercial product that one buys at a store, you can just have a DVD or two full of terrain data. With a freeware product that one downloads off the Internet, uploading takes a lot of connection time for the developer, and downloading can be equally burdensome for the user.

 

[Artlav]

Out of curiosity, what sort of resolution does Microsoft Flight Simulator use for it's ground terrain? I ask simply because it looks better than Orbiter's, and I'm curious to know if there's any sort of technical limitation that would prevent anyone from generating a ultra-high resolution Earth texture or some such thing.

More resolution requires bigger files.

For what i know, they generate terrain in a distinctly different way - by mixing a terrain type-specific high resolution textures, making a surface that looks like what the place should look like - a map of terrain types and a set of terrain type textures to be mixed.
Orbiter, on the other hand, uses orbital photography-derived global surface textures, precisely describing what is there.
FSX system works great near the ground, Orbiter system works great from orbit.

Then, data for FSX, or X-plane, comes on multiple DVD's, amounting to 60Gb or something, while all Orbiter have is 0.5 Gb of global textures.

Combining the two systems is tricky, the Mk2 Orulex used in OGLA can apply a mix of overlay textures to the global textures map, giving an order of magnitude higher surface resolution up-close like in FSX, but getting something to apply is a different story - so far it's a couple of cratered surface textures for the Moon:

Getting it to the FSX level will need much more work and a lot more data to download. And it is, after all, a space flight simulator.

The second is the typical altitude the camera is at in Orbiter: The camera is usually so high that you don't really notice the low terrain resolution.

Ultimately, depends on what you're looking at, so the higher - the better.

---------- Post added at 06:47 PM ---------- Previous post was at 03:18 PM ----------


Update 2:
http://orbides.1gb.ru/orbf/oglaclient-091008_beta-090728.zip
Install over beta 090728( latest 090722 + patch http://download.orbit.m6.net/betaTB24S/orbiter090729beta_base.zip ).

Changes:
*Fixed DG HUD
*Slightly improved VC performance
*Fixed Moon terrain microtextures
*Several random fixes

Moon microtex scenario (F7-5 to enable terrain, F7-u to enable microtextures, F7-7 three times to make mountain non-transparent (and turn shadows on)):

DG HUD:

 

[Arthur Dent]

The moon microtexture has blurry edges. It makes it looking like a checkerboard pattern, unfortunately. But it's nothing that couldn't be fixed when you're done with the more important things.

The only thing that keeps me from using it, is the incompatibility with multistage.dll, but this is not the OGLAClients fault.

 

[Bluefinger]

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.

The new HD5870 cards from ATI come with OpenGL 3.2 support (along with DirectX 11), so the newer stuff is coming out now. Since it is new, the prices will still be at a premium, but nonetheless, it is starting to come through. I guess it is Nvidia that needs to follow up next.

Anyway, keep up the good work.

 

[Artlav]

Ok, since playability is impaired beyond my reach for now, let's move to something more exciting.

What can you say about lights?

Specifically, about light emitted by a DeltaGlider's engine?
How bright should the light from DG engine be?
Or, which one of the images below looks better.
Also, what about color?

Launchpad, 1:

Launchpad, 10:

Launchpad, 100:

ISS, 100:

ISS, 10:

ISS, 1:

On the topic of usability - i decided to make a separate OGLA SDK for vessel add-ons to link to. It allows the add-ons to define and use various features of the graphics engine, like lights, bump mapping, custom shaders(?), etc.

 

[Arthur Dent]

Awesome!

IMHO the Launcpad 10/ISS 10 light is the best.

 

[jinglesassy]

awesome, and i agree 10 is best

 

[Linguofreak]

The DG Engines need to be much, much, much, brighter. They have an ISP of 40 km/s and put out around a gee of acceleration. Unless they have very, very, very good efficiency, such that only a very small fraction of the power they put out is wasted as heat and most of it goes into the kinetic energy of the exhaust stream and the vehicle, they are going to be very bright. And in atmosphere, with a 40 km/s exhaust stream hitting air, they're going to be bright no matter how efficient they are.

The ISS in those screenies should be at least as well lit as if it were in sunlight...

Please...

 

[Arrowstar]

I agree, rocket engine lighting should be far far brighter than it is now. But otherwise, looks great! I love the multi-color ISS.

 

[RisingFury]

Man! Good job. I love the Space-Disco ISS!

Imo, the DG engines should be at least as bright as 100.

 

[Hielor]

From an artistic standpoint, I think 10 looks the best, but realistically 100 is probably closer. Any brighter though I think would start to lose artisticness and look odd.

Can you make the brightness depend on the engine parameters (ISP/thrust/etc)?

 

[Artlav]

The DG Engines need to be much, much, much, brighter.
...
Please...

I agree, rocket engine lighting should be far far brighter than it is now.

Ok, Hm. ISS wouldn't look much different, since there is no HDR.

What about Brighton Impact Crater?

Not much to see from far away...

Maybe, boost DG exhaust size?

Then, at least you can see something as it rises over the night:

EDIT:

Can you make the brightness depend on the engine parameters (ISP/thrust/etc)?

Sure, but what relation to use?