Orulex 1.0 Alpha testing

[FordPrefect]

New Orulex version posted above tested:

Lunar orbit scenario, I get a CTD as soon as the scene is rendered and Orulex tries loading. I've discovered this in the new config\terrain\moon.cfg

//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

Do I need to download these Lvl12 tiles from somewhere first?

As a sidenote, testing the previous version I had no recognizable FPS loss (maybe 1FPS less) on my system (Pentium III 900 MHz, 1 GB SDRAM, 128 MB Nvidia Graphics FX5200, Windows XP Home) which is pretty cool, Artlav!
One thing I noted was that a few terrain patches were loading at a slightly offset location, protruding into an adjacent patch and then suddenly located properly, at the same time another patch in the vicinity was dislocated for a few seconds then relocated, then another one a.s.o. It seemed its always only one terrain patch that was dislocated at a time.

 

[Artlav]

New Orulex version posted above tested:

Lunar orbit scenario, I get a CTD as soon as the scene is rendered and Orulex tries loading. I've discovered this in the new config\terrain\moon.cfg

Do I need to download these Lvl12 tiles from somewhere first?

No, you don't need to download them, they should be silently ignored.
If it CTD's with I/O error 32 then try deleting the orulex.log, otherwise, is there any certain way to reproduce it?

One thing I noted was that a few terrain patches were loading at a slightly offset location, protruding into an adjacent patch and then suddenly located properly, at the same time another patch in the vicinity was dislocated for a few seconds then relocated, then another one a.s.o. It seemed its always only one terrain patch that was dislocated at a time.

Now that is severe. Are you sure this bug is present in current or yesterday's version?

 

[FordPrefect]

I simply installed your today's version over the previous. I had two scenarios which had run fine with the yesterday's Orulex version, one scenario starts with focus on vessel sitting on the lunar surface, the other with focus on vessel in lunar orbit.

I was going to test if the dislocated-terrain-patch phenomenon still exists in the Orulex version of today, though I could not yet due to the CTDs. The orulex log lists a lot of missing planetary texture files, the Orbiter log contains a few hundred error reports similar to this example:

ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>>        [C:\Source\Orbiter\Texture.cpp / 781]

 

[Artlav]

ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>>        [C:\Source\Orbiter\Texture.cpp / 781]

Yes, 1200 of these are to be expected, no problem there.

I assume deleting orulex.log file did not stop the CTD's?

Can it be reproduced with one of the default scenarios?
Is there any CTD on other planets?
Do you have MeshLand_2 disabled?

 

[FordPrefect]

Thanks Artlav. Success! After deleting the orulex log file, no more CTD! It loads normally. Some details: In the scenario starting at the lunar surface, Orulex Pre-Computation takes about 135 seconds, at that time the Orulex Mem = 139 Mb, which is slowly but steadily increasing thereafter. Is that nominal?

Do you want me to post some screenshots showing the dislocated terrain patch problem? I've taken some screen grabs of this phenomenon.

One other thing is, as you know I increased the terrain rendering altitudes in the terrain moon config to 300 and 270 kilometers altitude, if camera gets closer than ~ 300 kilometers to the focused vessel in lunar orbit, the sun texture is no longer rendered.

Otherwise, it looks really amazing Artlav, I hope so much that in a few years, when LRO collected enough elevation data, a global moon elevation map with the same resolution level as it exists for Mars, will be publicly available. That would be fantastic.

 

[Artlav]

In the scenario starting at the lunar surface, Orulex Pre-Computation takes about 135 seconds, at that time the Orulex Mem = 139 Mb, which is slowly but steadily increasing thereafter. Is that nominal?

By no means, pre-computation takes about 2-3 seconds over here...
How long does it take for a normal-looking mesh to form if you switch from one place on the Moon to another one on it far away?
Is there any normal terrain if you are flying fast and low over it?
Is there any difference in performance if you turn multithreading off (Multithread=0 in cfg, or configurator program)?

Do you want me to post some screenshots showing the dislocated terrain patch problem? I've taken some screen grabs of this phenomenon.

No, i think i found it. "Lunar suicide" scenario makes one quite fast...
To be fixed, i hope.

One other thing is, as you know I increased the terrain rendering altitudes in the terrain moon config to 300 and 270 kilometers altitude, if camera gets closer than ~ 300 kilometers to the focused vessel in lunar orbit, the sun texture is no longer rendered.

Yes, a knows Orbiter bug due to blending, it should reappear once you are out of transition zone.
I hope you didn't set it like

altlimit=300000
blendlimit=270000

, unless the 30-300Km transition is what you wanted?

 

[jedidia]

Ok, had some more fun with the new version. No more ctds when switching to another planet. I had them every time with version 0.990.

the new texturing method enhances the looks a great deal, nothing more to complain about "texturing-radius". Just that tile-thingy on close distances is still there. I looked at it some more, it could actually be due to lighting, but not all of it. I see tiles that don't fit to the neighbouring tile on a regular basis...

however, something seemed to have come up since 0.991. The rendering drops out in intervals (i'd guess about 10 minutes or so, but I'm not sure if it's regular) to come back about 5 to 10 seconds later. I had my shuttle-A parked in Olympus crater and waited 'til it happened, and the shuttle did not drop, so it's only the rendering that drops out. Meshland obviously still "sees" it.

one thought I had: When pausing the game, Orulex pauses loading. can this be changed?

oh yes, another thing I noticed: Orulex takes longer to load when there are high-res planetary textures. Note, I'm not talking about Orbiter (that one takes longer too of course), but about orulex itself. I don't know how the two interact, so this might be completely normal.

 

[Artlav]

Ok, had some more fun with the new version. No more ctds when switching to another planet. I had them every time with version 0.990.

That is good to hear.

Just that tile-thingy on close distances is still there. I looked at it some more, it could actually be due to lighting, but not all of it. I see tiles that don't fit to the neighbouring tile on a regular basis....

Known problem - absence of normal smoothing. I guess, unless it's something entirelly different. A screenshot would be good to see.

however, something seemed to have come up since 0.991. The rendering drops out in intervals (i'd guess about 10 minutes or so, but I'm not sure if it's regular) to come back about 5 to 10 seconds later. I had my shuttle-A parked in Olympus crater and waited 'til it happened, and the shuttle did not drop, so it's only the rendering that drops out. Meshland obviously still "sees" it.

Hm. Drops out like what?
Planet disappears, then reappears? Updates ceasing? Something else?

one thought I had: When pausing the game, Orulex pauses loading. can this be changed?

No way. When Orbiter is paused, it stops sending timer events. No timer events - no mesh updates, and using an independent timer makes a CTD firework.

oh yes, another thing I noticed: Orulex takes longer to load when there are high-res planetary textures. Note, I'm not talking about Orbiter (that one takes longer too of course), but about orulex itself. I don't know how the two interact, so this might be completely normal.

Simply, they don't. There is no way to get a planet texture out of Orbiter at run-time, so it just parses and loads them all over again.
Lv9-11 textures should not take much extra time as they are loaded in small chunks, so the loading times are not proportional.

 

[Tholin]

Ok. A couple of quick notes about the latest version:

1. The Windows Vista CTD bug raised its ugly head once again. It is the same problem that's been lurking in different Orulex versions for a long time. However the first alpha version you posted in the beginning of this thread worked for sure, Artlav.

2. I can confirm the Orulex mesh disappearing. With me it happens regularly every 20 seconds or so when my ship is not moving. As soon as I take off and gain even a little speed, the problem vanishes.

3. I also noticed that the Orulex memory usage does indeed rise continuously.

I hope this is of some help to you. All the above happened with a fresh Orbiter install and with the default Orulex settings.

 

[FordPrefect]

By no means, pre-computation takes about 2-3 seconds over here...
How long does it take for a normal-looking mesh to form if you switch from one place on the Moon to another one on it far away?
Is there any normal terrain if you are flying fast and low over it?
Is there any difference in performance if you turn multithreading off (Multithread=0 in cfg, or configurator program)?

Artlav, wow, turning off multithreading makes a big difference! Loading times are much shorter, Pre-Computation is finished after 3 seconds and when switching to different locations on the moon, loading times are equally short. With multithreading active it took much longer.

Yes, a knows Orbiter bug due to blending, it should reappear once you are out of transition zone.
I hope you didn't set it like

altlimit=300000
blendlimit=270000

, unless the 30-300Km transition is what you wanted?

I have to admit, I inadvertently set it like you suspected. :fool: I corrected that so that the transition altitude is only 30 km high, now I do see the sun texture again most of the time.

One glitch I noted in the version of today and I believe in the previous too, is that from time to time, every few minutes I see vertices in the shape of a thin band "flash" vertically out of the planetary terrain into deep space. It appears only for a fraction of a second, not sure what that could be.

As previously stated, I still can see the Orulex: Mem slowly increasing. It starts at around 139 Mb and after 6600 second simulation time it increased to 346 Mb.

 

[Redburne]

Great stuff, Artlav!
I just gave .992 a spin and was very impressed.

Aside from the dislocated terrain problem, I encountered two issues.

First, the "forward prediction" does not take into account that the directions of camera movement vector and camera view vector might differ siginificantly.
If you look at the nose of your vessel (i.e. the camera flies backwards), you get a "backward prediction" - the predicted spot lies well behind the ship.
If you look from port or starboard, you get a "sideways prediction", instead.

The second issue is somewhat harder to reproduce and may be machine and/or memory dependent (though I doubt it's lack of power or mem, I've got plenty of both).
Steps to reproduce (clean Orbiter + stock hires textures + Orbitersound + Orulex):
- Lunar suicide scenario
- prograde
- raise apoapsis to about 10 M
- coast to apoapsis and back again (careful with time acelleration at 3.475 M)
- once Orulex rendering kicks in, the textures are all messed up (colorful, random data)

I can provide a screenshot, if you need it.

System: Intel Core2Duo 6700; Nvidia GeForce 8800 GTX (at 1920 x 1200); 2 GB RAM; WinXP SP2

One glitch I noted in the version of today and I believe in the previous too, is that from time to time, every few minutes I see vertices in the shape of a thin band "flash" vertically out of the planetary terrain into deep space. It appears only for a fraction of a second, not sure what that could be.

From virtual cockpit view? I get those, as well, and they have been present for a long time in the betas. IIRC, Artlav suspects Orbiters rendering mechanism.

Edit: I can also confirm the "drop outs". Easy to reproduce in the IO scenario (no further action necessary). Landscape builds up, and after about 7 seconds realtime - independent of time acceleration - starts again (polycount drops and rises again):

20.03.2008-23:48:01:[Debug     ]:T=6.5789 Threads: 2
20.03.2008-23:48:01:[Debug     ]:Orulex: Mem=17.5440Mb Blk=990 PolyCnt=94848 FrmT=5822 SplT=33712 FncT=2191 CFncT=9691 (t in us)
20.03.2008-23:48:01:[Debug     ]: 
20.03.2008-23:48:02:[Debug     ]:T=7.0889 Threads: 2
20.03.2008-23:48:02:[Debug     ]:Orulex: Mem=17.8165Mb Blk=988 PolyCnt=94848 FrmT=5966 SplT=33676 FncT=2090 CFncT=8927 (t in us)
20.03.2008-23:48:02:[Debug     ]: 
20.03.2008-23:48:02:[Debug     ]:T=7.5899 Threads: 2
20.03.2008-23:48:02:[Debug     ]:Orulex: Mem=12.8347Mb Blk=46 PolyCnt=3840 FrmT=5421 SplT=31130 FncT=3230 CFncT=6155 (t in us)
20.03.2008-23:48:02:[Debug     ]: 
20.03.2008-23:48:03:[Debug     ]:T=8.0969 Threads: 2
20.03.2008-23:48:03:[Debug     ]:Orulex: Mem=14.1540Mb Blk=186 PolyCnt=17280 FrmT=5793 SplT=58749 FncT=3878 CFncT=6902 (t in us)
20.03.2008-23:48:03:[Debug     ]: 
20.03.2008-23:48:03:[Debug     ]:T=8.6029 Threads: 2
20.03.2008-23:48:03:[Debug     ]:Orulex: Mem=14.9695Mb Blk=272 PolyCnt=25728 FrmT=5661 SplT=76728 FncT=4197 CFncT=7463 (t in us)

Once the ship moves, the problem is gone.

 

[jedidia]

A screenshot would be good to see.

No webspace here, but I can send you one...

Hm. Drops out like what?
Planet disappears, then reappears? Updates ceasing? Something else?

Orulex landscape disapears completely and comes back a few seconds later. The planet beneath it still is there. It's kinda strage sitting in Olympus Mons' Caldera and having the whole mountain disapear beneath you, seeing the ship float 19 km above the surface... :blink:

I definitaly have them when moving too, but the intervals are pretty long compared to what others have posted...

No way. When Orbiter is paused, it stops sending timer events. No timer events - no mesh updates, and using an independent timer makes a CTD firework.

ah no, we can't have that... too bad.

Simply, they don't. There is no way to get a planet texture out of Orbiter at run-time, so it just parses and loads them all over again.

so it's completely normal that it takes longer. ok.

 

[Artlav]

1. The Windows Vista CTD bug raised its ugly head once again. It is the same problem that's been lurking in different Orulex versions for a long time. However the first alpha version you posted in the beginning of this thread worked for sure, Artlav.

Right on queue, taking even versions only.
I don't think i would be able to fix it unless i get Vista, and iam not getting it without a new PC...

2. I can confirm the Orulex mesh disappearing. With me it happens regularly every 20 seconds or so when my ship is not moving. As soon as I take off and gain even a little speed, the problem vanishes.

I can also confirm the "drop outs". Easy to reproduce in the IO scenario (no further action necessary). Landscape builds up, and after about 7 seconds realtime - independent of time acceleration - starts again (polycount drops and rises again):
Once the ship moves, the problem is gone.

That one reproduced and looks fixed.

Artlav, wow, turning off multithreading makes a big difference! Loading times are much shorter, Pre-Computation is finished after 3 seconds and when switching to different locations on the moon, loading times are equally short. With multithreading active it took much longer.

Good to hear. So, the guide line seems to be - if you got a multi-core CPU, keep multithread mode on, if you got single-core CPU and pre-computation takes longer than 10-15 seconds, try turning it off.

I hope frame rates stayed on acceptable level?

One glitch I noted in the version of today and I believe in the previous too, is that from time to time, every few minutes I see vertices in the shape of a thin band "flash" vertically out of the planetary terrain into deep space. It appears only for a fraction of a second, not sure what that could be.

If that is what i think it is, it's an Orbiter bug.
If you get a chance, a screenshot may help.

As previously stated, I still can see the Orulex: Mem slowly increasing. It starts at around 139 Mb and after 6600 second simulation time it increased to 346 Mb.

3. I also noticed that the Orulex memory usage does indeed rise continuously.

A memory leak, actually a gaping hole with a torrent rushing thru it!
Strange that i didn't noticed it before.
Fixed.

First, the "forward prediction" does not take into account that the directions of camera movement vector and camera view vector might differ siginificantly.
If you look at the nose of your vessel (i.e. the camera flies backwards), you get a "backward prediction" - the predicted spot lies well behind the ship.
If you look from port or starboard, you get a "sideways prediction", instead.

Well, it's more a lack of implementation than a bug. Being worked on now.

The second issue is somewhat harder to reproduce and may be machine and/or memory dependent (though I doubt it's lack of power or mem, I've got plenty of both).
Steps to reproduce (clean Orbiter + stock hires textures + Orbitersound + Orulex):
- Lunar suicide scenario
- prograde
- raise apoapsis to about 10 M
- coast to apoapsis and back again (careful with time acelleration at 3.475 M)
- once Orulex rendering kicks in, the textures are all messed up (colorful, random data)

I'm not exactly sure where it is coming from exactly. I get that kind of result when alt-tabbing from full-screen mode.
Looks like a DirectX texture invalidation, maybe reinitializing the planet on re-entering it's active radius will help.

One thing I noted was that a few terrain patches were loading at a slightly offset location, protruding into an adjacent patch and then suddenly located properly, at the same time another patch in the vicinity was dislocated for a few seconds then relocated, then another one a.s.o. It seemed its always only one terrain patch that was dislocated at a time.

Aside from the dislocated terrain problem,

Looks like i found a reason for this one, if iam right, it should only appear when multithreading mode is on.
Could anyone confirm that?

 

[DaveS]

No webspace here, but I can send you one...

Or you can use a free image host such as www.imageshack.us.

 

[FordPrefect]

I can confirm, with multithreading disabled, this phenomenon no longer exists!

With multithreading disabled, I have a small loss on FPS, around 20%, from previously around 13, 12 to 10 Fps in my Apollo scenario I use for testing.

Artlav, is it possible to increase the (hi-res) terrain rendering radius around the camera/focused vessel so that the terrain and hi-resolution textures are loaded a little further than the visible horizon from the camera/vessel position? I suspect this would go hand in hand with performance loss, still it would be interesting to test if possible.

 

[jedidia]

I definitaly have them when moving too

I have to correct this... it indeed only apears when moving at slow speeds, I don't think i encountered it at anything above 50 m/s.

as for screenshots... erm... I'm slightly embarassed to say that I couldn't figure out how to take them... I looked through pretty much the whole manual. Of course there's allways printscreen, but Alt-Tabing doesn't work for Orbiter on my machine (it used to until I launched Orulex for the first time, then it didn't work anymore... even on clean versions. I don't think that there's a relation.)

Plus, something I am now fairly certain about: when launchig and quiting Orbiter with Orulex on numerous times, I run out of memory...

 

[Notebook]

For screenshots, this could be what you need:-

[ame="http://www.orbithangar.com/searchid.php?ID=3279"]Screen capture[/ame]

N.

 

[FordPrefect]

...but Alt-Tabing doesn't work for Orbiter on my machine...

Plus, something I am now fairly certain about: when launchig and quiting Orbiter with Orulex on numerous times, I run out of memory...

That's why I sometimes simply run Orbiter in windowed mode - no alt-tabbing required

 

[jedidia]

Plus, something I am now fairly certain about: when launchig and quiting Orbiter with Orulex on numerous times, I run out of memory...

I can definitaly confirm this one. It just happened right now during play that windows had to expand virtual memory after runing Orulex for some time. I think it's also possible that it doesn't properly free used memory, since this can happen allready a few minutes after startup when I allready ran it a few times before that.

@others: thanks for the tips.

 

[MJR]

I have a problem with orulex period. Everytime I download it, I never have any of those beautiful textures. It is the same, plain old Earth like it was.