Orulex 1.0 Alpha testing

[Coolhand]

That's not really what i meant. What i meant was the whole mesh dynamically changing brightness as you ascend, giving a simple effect of atmospheric haze. The landscape looks dark at from outside the atmosphere. Is this possible? (Nebo is buggy)

I think the effect would work better if the landscape colour was linked to it's distance from the camera, rather than it's altitude... to simulate the effect of looking through more air at the object. Thats basically what i meant in my earlier post where i was talking about - a 'distance fog' effect - a bit like some early 3d games like magic carpet where the distant objects and terrain faded to white/grey.

 

[McWgogs]

I think the effect would work better if the landscape colour was linked to it's distance from the camera, rather than it's altitude... to simulate the effect of looking through more air at the object. Thats basically what i meant in my earlier post where i was talking about - a 'distance fog' effect - a bit like some early 3d games like magic carpet where the distant objects and terrain faded to white/grey.

The whole landscape is a single object so that would be quite hard in the hardcode limits of orbiter.
Putting a transparent mesh, like a 2D Nebo over the landscape would be one way.
Hell, Nebo needs to be worked on, it's way behind and has lots of possibilities.

 

[Tholin]

microtex_lev in planet cfg file should do it nicely.
What values have you tried?

Well I have tried several values with different planets/moons. The differences are clearly visible in world studio, but not at all inside Orbiter itself. Maybe a bug relating to Vista?

For example this extreme value of microtex_lev=999999999 had no effect what so ever inside the simulator.

 

[Artlav]

Suppose we have a heightmap with 1 pixel per meter.
if the resolution is two times larger we get 4 different pixels per meter.
A large 8bit image can hold enough information to create a smaller 16 bit image. You just need to use error diffusion when converting a 16 bit image into a larger 8 bit image, so the information isn't lost.

I don't think any kind of error diffusion will help.
Best optimized 8 bit heightmap will have a vertical resolution of 35 meters, while 16 bit map have about 0.13 meters.
Even if you tenfold the resolution you will get significant degradation, especially on the hi-res maps that is all about finer details.
And altitude maps are not pictures, you can't use Floyd-Steinberg or Bayer dithering to make 4bit one appear visually close to 32bit one.

A more visual argument of how i understand this:

If above is not what you meant, please clarify what you wanted to say.

That's not really what i meant. What i meant was the whole mesh dynamically changing brightness as you ascend, giving a simple effect of atmospheric haze. The landscape looks dark at from outside the atmosphere. Is this possible?

I think the effect would work better if the landscape colour was linked to it's distance from the camera, rather than it's altitude... to simulate the effect of looking through more air at the object. Thats basically what i meant in my earlier post where i was talking about - a 'distance fog' effect - a bit like some early 3d games like magic carpet where the distant objects and terrain faded to white/grey.

No, it is only as bright as 1 1 1 in material settings makes it, making it brighter involves color function, and color function have no concept of camera distance.

The major difference between Orulex and the games of old like magic carpet is that Orulex is bound to the Orbiter rendering system, while the named games had their very own one.
World Studio and OGLAClient on the other hand can define whatever real-time renderable way to make haze that fits the scene, probably even reasonably physically accurate scattering, if you have a good GPU.

None of that is possible in Orbiter-Orulex link, which in itself is a major hack that should not work at all.

 

[Artlav]

The differences are clearly visible in world studio, but not at all inside Orbiter itself. Maybe a bug relating to Vista?

No, it's a bug related to typo, so Orulex-Orbiter cfg loader just ignored the value.
Fixed.

 

[computerex]

None of that is possible in Orbiter-Orulex link, which in itself is a major hack that should not work at all.

Everything you do is a hack. This has come a long way Artlav, great job. However every time I run this my computer tries to kill itself, I really need to get more RAM.

 

[jedidia]

Well, the crater radius is the same as defined in base config, so technically they are already adjustable.
Will put it separately.

Oh, looky here. In that case Computerex was a bit lazy and didn't define the correct radiuses for his "bases of the solar system". Probably thought they where no use anyways. (the radiuses, not the bases) That would be allright then.

@Computerex: I'm running on 512 Megs too, I don't really have a problem anymore since .993...

 

[Artlav]

Update - Alpha version from 080326:
http://orbides.1gb.ru/orbf/orulex-0.9.994-080326.zip (650 Kb)
21:30 MST: re-uploaded the pack due to missing file, please re-download.

Changes:
*Configurable data acquisition system
*Data download speed-up
*Several new data servers and datasets
*New LandSat server and data
*Fixed microtexture level bug
*Threadsafed the downloads
*Fixed crater ridge discontinuity
*Added crater config options
*Added base config tool
*Potential fix for white map on some GPU's

Known bugs:
-Dislocated patches when flying, multithreaded mode on offset
-Absence of normal smoothing (tile edges visible)
-Windows Vista random CTD
-Textures getting colorfully random on some machines (probably Orbiter/DirectX bug)

Server list:
Earth:
+SRTM global Earth terrain
+NASA derived global 30 meters per pixel satellite image mosaic
+NASA derived global 15 meters per pixel satellite image mosaic, donated and processed by I-Cubed using equipment from Isilon Systems.
?USGS Digital Ortho
+USGS Urban Area Ortho
+Pseudo color 15m Landsat mosaic provided by MDA Federal, scenes comprised from early 2000s
Moon:
+Clementine global Moon terrain
?Clementine 40xx
+Clementine 30xx
Mars:
+MOLA global Mars terrain
?Mars THEMIS Color
Venus:
+Magellan Imaging Radar (Color)
+Magellan Imaging Radar (Grey)


Focus of today's update is mostly on the bugs related to World Studio new data download system and different servers now supported.

Also, many small Orulex bug was fixed, confirming which is welcome.

Crater types:
Interface:

Smooth hole:

Flat crater:

Default crater:

 

[Artlav]

I think the effect would work better if the landscape colour was linked to it's distance from the camera, rather than it's altitude... to simulate the effect of looking through more air at the object. Thats basically what i meant in my earlier post where i was talking about - a 'distance fog' effect - a bit like some early 3d games like magic carpet where the distant objects and terrain faded to white/grey.

Speaking about distance-dependent fog, below is how it could look like in Orulex.
The picture is made using Orulex static renderer, so it's not a real-time effect in the Orulex-Orbiter system.
Real-time performance can be achieved if the haze is done as post-processing, and that requires OGLAClient or World Studio.

 

[amalahama]

How can I activate the download manager?? It's looks like not work anymore. (the word "download" appear in grey, and pressing the D key haven't any action).

And the hi-res textures SRTM of old Orulex builds aren't recognized by World Studio... I don't know if this is normal

Good work Artlav!!

Regards!!

 

[Artlav]

How can I activate the download manager?? It's looks like not work anymore. (the word "download" appear in grey, and pressing the D key haven't any action).

Forgot the "test on the clean install" stage, missing file in the pack.
Re-uploaded, please download again.

And the hi-res textures SRTM of old Orulex builds aren't recognized by World Studio... I don't know if this is normal

Hm. Every new install overwrites the config\terrain\earth.cfg file, so all the settings are lost.
The buffers are no longer compatible, so everything in heightmaps\*buf could be safely deleted.

 

[MJR]

Well, the crater radius is the same as defined in base config, so technically they are already adjustable.
Will put it separately.

Don't exactly understand what do you mean there, and what resolution have to do with bit depth?

Initially 8bit image can be easily transformed to 16-32bit one, but initially 16-32bit one will be severely degraded if it was transformed to 8bit and back.
...

I have pressed "8" already. I have Intel GPU.

 

[amalahama]

Forgot the "test on the clean install" stage, missing file in the pack.
Re-uploaded, please download again.


Hm. Every new install overwrites the config\terrain\earth.cfg file, so all the settings are lost.
The buffers are no longer compatible, so everything in heightmaps\*buf could be safely deleted.

Artlav, sorry, more problems in world-studio. When you download a zone SRTM map, all the zone's elevation data are deleted. When I press "terrain" in the viewer, the selection is black (the rest have the typical lvl-8 heightmap)

Regards!!

 

[Coolhand]

Speaking about distance-dependent fog, below is how it could look like in Orulex.
The picture is made using Orulex static renderer, so it's not a real-time effect in the Orulex-Orbiter system.
Real-time performance can be achieved if the haze is done as post-processing, and that requires OGLAClient or World Studio.

That looks really nice, it looked like that with your nebo fog, but it's performance was not so hot - running alongside orulex i got about 4fps with the default orulex settings, reduced from over 30fps with orulex only. It's a shame that the technical limits imposed by the orbiter code are so tight, I'm sure one day we'll have the lovely new rendering engines to play with and by the sounds of it, something like orulex is far more than it was ever supposed to do anyway.

Thanks for answering my dumb questions, keep up the great work!

btw, actually i have another...

//Moon config file
seed =3856 //Microtexture and microterrain noise seed
sbcrater =300 //Surface base craters ridge height
microtexture=2 //Microtexturing
microtex_lev=200000 //Microtexture level
belowsphere =0 //Below sphere terrain
altlimit =40000 //Meters to cutoff
blendlimit =20000 //Meters from altlim to cutoff start
glhmaplevel =8 //Max global heightmap level
glhmapop =0 //Global heightmap operator
glhmapflag =0 //Global heightmap flag
speccol =0 0 0 //Surface reflection color
specpow =1000 //Surface reflection power
ospeccol =0 0 0 //Water reflection color
ospecpow =0 //Water reflection power
function=6250 1 1 1 5 50000 perlin* 0.9-- sealevel 600 1 1 1 9 5000 perlin*+ 0.9-- sealevel
//O-operator, 0=add, 1=multiply, 2=replace, 3=add&truncate ocean; F-flag, 1=truncate <0; U=use flag, 1=use
//heightmap =--------------file name-----------------|lower lat|upper lat|west lon|east lon| scale |O|F|U
heightmaphei=moon-lv12-1038-301-3-3 |-000000005|-0004.0625|+0324.3750|+0325.3125|00032768|2|0|1
heightmaphei=moon-lv12-1038-301-3-3 |-000000005|-0004.0625|+0324.3750|+0325.3125|00032768|2|0|1
heightmaphei=moon-lv12-1038-301-3-3 |-000000005|-0004.0625|+0324.3750|+0325.3125|00032768|2|0|1
//Flat spaces: flat=lower lat,upper lat,west lon,east lon
//SURFTILE's list
BEGIN_SURFTILELIST
END_SURFTILELIST

I altered and saved the file (from config/terrain folder) to increase the microtex_lev to 200000 as you demonstrated a couple of pages ago, but i haven't actually seen it make any difference in the moons surface when flying the sim. Am i editing the wrong file or something? I tried even higher values but it still didn't make a difference.

 

[Artlav]

Minor Update - Alpha version from 080327:
http://orbides.1gb.ru/orbf/orulex-0.9.995-080327.zip (650 Kb)

*Fixed unzip bug - SRTM tiles should work now.
*Fixed the packaging.
*Fixed download limiter
*Fixed Cancel download
*Interface fixes

Artlav, sorry, more problems in world-studio. When you download a zone SRTM map, all the zone's elevation data are deleted. When I press "terrain" in the viewer, the selection is black (the rest have the typical lvl-8 heightmap)

Hm. Uninitialized flags variable in unzip. It's a miracle it worked all the way since 0.9.0!
Fixed.

I altered and saved the file (from config/terrain folder) to increase the microtex_lev to 200000 as you demonstrated a couple of pages ago, but i haven't actually seen it make any difference in the moons surface when flying the sim. Am i editing the wrong file or something? I tried even higher values but it still didn't make a difference.

Are you sure you tried the 994 version? Earlier ones had a bug that made this parameter ignored.
Also, please re-try with today's bug-fix.

 

[aldarion]

Will Meshland be compatible with the new version of Orulex?

Great job BTW :speakcool:

 

[Artlav]

Will Meshland be compatible with the new version of Orulex?

It still is, i just don't pack it together to prevent bugs from one to screw up the testing of the other.
You can get a compatible meshland version here:
http://orbides.1gb.ru/orbf/MLVS-WIP-080327.zip

 

[Coolhand]

Thanks artlav, it was the older version causing the bug.

 

[amalahama]

Oh my GOD!! The news level 16 terrain textures are simply SUPERB!!



Good work Artlav!!

(Some day, we could fly over a whole level 16 earth...)

 

[Artlav]

The news level 16 terrain textures are simply SUPERB!!
{IMG}

Canary Islands?