Orulex 1.0 Alpha testing

[Redburne]

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?

As far as the absence of something can be reliably tested, yes, disabling multi-threading seems to fix the dislocated terrain.

Another issue (Lunar suicide): .992 has introduced a lot of flickering at the "active edge" of newly generated high-res tiles. It became apparent when I lowered LevLimit to 10 to get a wider area of static terrain under the vessel (but it is definitely also present at LevLimit=17). I noticed that at the forward edge of that area, a majority of patches flickers between lower and higher res before finally settling down to the higher resolution.
I switched back to .991 to confirm that the problem has not been present in that version.

Oh, and there shouldn't be any "ocean reflection" on Luna, but you're probably aware of that little glitch.

 

[Artlav]

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

As far as the absence of something can be reliably tested, yes, disabling multi-threading seems to fix the dislocated terrain.

Well, this answers the why, but the how remains...

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.

Hm. Sounds barely playable by my standards. Looks like any loss of performance will be barely visible in that case.
What about World Studio? What kind of performance you get in it (being a stand-alone Orulex)?

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.

You mean, in motion prediction? Right now it is 2 seconds ahead.
Putting it further may make the tiles nearby go bland.

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

There is a slow memory leak in Orulex .992, but i don't quite understand how it could possibly go over an Orbiter restart.
Any details please? Ways to reproduce?

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.

Well, you need to download the local textures. Everest and Grand Canyon is available a the start of this thread, along with Lv8 heightmaps for Earth Moon and Mars.
If you want hi-res textures in other locations, use world studio to download them.
Orbiter's Lv10 textures are used too.

If you don't see any terrain at all, then it's a problem.
If nothing above applies, please clarify your problem.

Another issue (Lunar suicide): .992 has introduced a lot of flickering at the "active edge" of newly generated high-res tiles. It became apparent when I lowered LevLimit to 10 to get a wider area of static terrain under the vessel (but it is definitely also present at LevLimit=17). I noticed that at the forward edge of that area, a majority of patches flickers between lower and higher res before finally settling down to the higher resolution.
I switched back to .991 to confirm that the problem has not been present in that version.

Is the camera moving relative to the planet? If yes, then it could be normal camera-dependent updates.
What exactly "flickering" means?

Oh, and there shouldn't be any "ocean reflection" on Luna, but you're probably aware of that little glitch.

Hm. Screwed up defaults. Fixed.

 

[MJR]

I first install the heightmaps for Earth, then what?

 

[Redburne]

Is the camera moving relative to the planet? If yes, then it could be normal camera-dependent updates.

Yes, the camera is moving. I'm using the normal Lunar suicide scenario, without any additional control input or camera moves. If you set LevLimit=10 in the config file and just run Lunar suicide and watch the landscape as it approaches the camera, the effect is quite obvious.
(LevLimit=10 emphasizes the problem, because at level 10, most landscape changes affect fairly large areas right in front of the vessel. If LevLimit gets higher, the flickering patches become smaller and are closer to the camera and are not that easily spotted)

It doubt that these are "normal" updates. They don't look right, and they did not happen in .991.

What exactly "flickering" means?

"Flickering" means a patch of landscape at, say, level 9 resolution approaches the camera. At a certain distance, it becomes subdivided and becomes a level 10 patch (or rather, multiple level 10 patches). Then, in the next frame, it is back to level 9 again, then 10 again, then 9, and so on. For maybe a fifth of a second, before it finally stays at level 10.

[Note: the flickering is very obvious at LevLimit=10. It has been introduced with .992, so it's very likely caused by the forward prediction, which - as you pointed out - is work in progress. You may have already fixed it without noticing it.]

 

[Artlav]

I first install the heightmaps for Earth, then what?

Well, for a start try installing everest_lv11.zip and grand_canyon_lv13.zip,
this will get the named areas hi-res fast way.
If you want a random location on Earth to get hi-res, run World studio program, use the map in it to select the area you want (explained in Help menu), and follow the button names in Download menu.
Beyond that, please be more specific in describing what you expect.

It doubt that these are "normal" updates. They don't look right, and they did not happen in .991.

"Flickering" means a patch of landscape at, say, level 9 resolution approaches the camera. At a certain distance, it becomes subdivided and becomes a level 10 patch (or rather, multiple level 10 patches). Then, in the next frame, it is back to level 9 again, then 10 again, then 9, and so on. For maybe a fifth of a second, before it finally stays at level 10.

[Note: the flickering is very obvious at LevLimit=10. It has been introduced with .992, so it's very likely caused by the forward prediction, which - as you pointed out - is work in progress. You may have already fixed it without noticing it.]

It seems that was fixed along with planetary resets, or it is something machine-specific.
Can anyone else confirm the problem?

 

[jedidia]

There is a slow memory leak in Orulex .992, but i don't quite understand how it could possibly go over an Orbiter restart.
Any details please? Ways to reproduce?

I revoke my theory. Problem is, the memory leak isn't so "slow", at least not when you have only 512 Megs of ram. I tried this some times on Mars now, Memory overruns allways at about the same time, that is flown distance. so when I fly fast and punch in time compression, the overflow comes very fast when measured in minutes (which is why I thought there might be stuff left ocupying the memory). It happened allways at about the same point on the way however. I tried it in several directions, same result: when I have flown a certain distance, Memory runs out.

 

[Redburne]

I first install the heightmaps for Earth, then what?

Did you activate the "Orulex-core" module on the "Modules" page in Orbiter?

 

[MJR]

Did you activate the "Orulex-core" module on the "Modules" page in Orbiter?

Yes, I did that. Well I think I installed something out of order or downloaded something wrong. This is only a little bit of the bad part of the error report. I first installed the alpha version, next I installed the Earth heightmaps, then Everst and the Grand Canyon.
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]
ERROR: DDraw error DDERR_INVALIDPARAMS
[C:\Source\Orbiter\Texture.cpp / 224]
ERROR: TextureManager::LoadTexture|ReadDDSSurface (code: -2147024809)
>>> ERROR: Missing texture: orulex\orulex.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]

 

[jedidia]

ok, here come the shots...

here you see the allmost perfect microtexturing from a certain altitude, but it gets very boxy at the outside.







this is from a lower altitude. You see the microtextures getting boxy, plus there is not much texturing up ahead.



I was able to recreate the ctd on switching vessels. It happens when you switch to a vessel on another planet while Orulex still is loading the terrain for the current planet.

 

[Artlav]

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

As i said above in this thread, 1200 of these in the log is normal.
Missing textures report in orulex.log is normal too.

What are your system specs (CPU, RAM)?
What happens when you run Orbiter with Orulex?
Is there any other error, except the ones in the log? CTD?
Is there any kind of non-flat terrain?
What is being shown when you run the included Everest or Grand canyon scenarios?

 

[MJR]

I cannot even start the mission because it crashes to desktop. I can't tell whether the terrain is flat or not because it CTDs. Also, how do I find out my computer's specs?

 

[Artlav]

I cannot even start the mission because it crashes to desktop. I can't tell whether the terrain is flat or not because it CTDs. Also, how do I find out my computer's specs?

Now, that's a good description of the problem...
Try deleting orulex.log file.
Press windows key (the one with windows logo between Ctrl and Alt) and pause/break (normally around right-top side) key at once to open system properties window, it will have the CPU and RAM info.

 

[MJR]

My RAM is 0.99 GB.
Dell Dimension DM061 Intel(R) Pentium(R) D CPU 2.80GHz 2.79GHz. Is that it?
Does the orulux log contain something like this? 3/21/2008-12:40:40 PM:[getheihmap]:Error: File "Heightmaps\earth-lv11-425-97-5-4.hei" not found or not loadable.
3/21/2008-12:40:40 PM:[getheihmap]:Error: File

 

[Artlav]

My RAM is 0.99 GB.
Dell Dimension DM061 Intel(R) Pentium(R) D CPU 2.80GHz 2.79GHz. Is that it?

Yes. Seems quite sufficient.
Any result from deleting orulex.log file?

So, with Orulex on, any scenario, on Earth or other planet, crashes to desktop on start?

 

[MJR]

I updated that post above the one you just posted.

 

[Artlav]

I updated that post above the one you just posted.

As i just said, "Missing textures report in orulex.log is normal too."

 

[MJR]

What I mean is, is that the orelux log?

 

[Artlav]

What I mean is, is that the orelux log?

Sorry, yes, it is. orulex.log file.

 

[Artlav]

For the purpose of comparison, here is a video of Orulex in normal action:
China, flying in Gregburch's Swift1.

http://orbides.1gb.ru/orbf/oru-flight-080321-x264.avi (x264, 21Mb)
http://orbides.1gb.ru/orbf/oru-flight-080321-xvid.avi (xVid, 31Mb)

 

[MJR]

Sorry, yes, it is. orulex.log file.

I deleted it and got no CTDs. My only problem is flat-terrain.