No, loading logic is the same: engine loads only nodes which are visible to the camera, and close enough to be split into children nodes. If disable detail textures and texture compression, loading is much faster than in 0.980. But new 10 levels of detail textures (0.990 feature) makes loading time even larger that 0.980 (but terrain resolution is 1000 times better).

How does travel movement effect the loading speed?  is this fundamental to the engine or is it more a limitation on PC resources?  example. too busy handling movement and then loading is bottle necked?

I noticed in aircraft mode the velocity and loading don't really happen at the same time, it seems to swap between the tasks rapidly. If terrain is loads detail the velocity slows or momentary stops and then resumes when that section finishes loading.  So the velocity counter is jumping around rapidly and the aircraft feels jerky. The FPS is not effected by this.

Movement is just change of coordinates, it does not produce any load on CPU. But terrain produces texture generation tasks then position changed, according to split/culling logic (new tiles became visible or need to be split). Texture generation of course makes some load on CPU and GPU, resulting in FPS drop or microstuttering. This may affect perceived movement speed or smoothness.

Will 0.990 have support for nvidia's real-time ray tracing feature in RTX cards, and if not are you planning on it in future updates?

In the upcoming release, will there be more customization for clouds? As in, specifying cloud coverage per latitude? Say, from the pole to 30 degree, coverage 90%, and tropics 10%? Or would that be in a future release (perhaps avoided entirely by accurate climate approximation?)

Secondly, you stated earlier in the thread that real-time texture updates for planet surfaces would be impossible, yet the planet editor seems to do such. Is it that there is no possible transitions? Would it be possible to allow some of the textures used in sampling, be grey scale, and have their colors applied real-time in-game allowing for such transitions?

Sorry if this sounds more like a suggestion, but since there have been a lot of features added to the new release, I honostly don’t know if something like this is already in there xD

SpaceEngineer wrote:

Movement is just change of coordinates, it does not produce any load on CPU. But terrain produces texture generation tasks then position changed, according to split/culling logic (new tiles became visible or need to be split). Texture generation of course makes some load on CPU and GPU, resulting in FPS drop or microstuttering. This may affect perceived movement speed or smoothness.

Thanks for the reply.

Yes it does seem to stutter in movement with aircraft mode but the terrain loading is pretty much realtime.

But in free mode the movement is smooth but seems to stop most of the loading until I no longer move.

So it is as if aircraft mode the loading is the priority and in free mode the movement is the priority.

This video shows what I mean, You can see how quick the loading is as long as I stop the travel (looking has no effect and loads at full speed)

This behavior is what I was hoping 0.990 would improve if it isn't a hardware limitation that is causing it.   I suspect CPU bottleneck looking at the overlay but I am not sure it is as it still does it in low settings.

You'll need to watch in full screen to really see it but it's very obvious.

vlad01 wrote:

Source of the post This video shows what I mean,

I envy your machine  .

no need too, it's a potato FX based system. Can't wait to upgrade as soon as I can get a 1080ti or equiv for half the asking price they are atm. ie around 600 AUD and I would buy one.

SpaceEngineer, I'm glad to hear about the equatorial ridge feature in 0.990, but if we really wanted to recreate the appearance of Iapetus, can we control the color of drivenDarkening and how sharply bounded it is?

Will there be a moon lunar eclipse? color red?

Rigel wrote:

Source of the post Will there be a moon lunar eclipse? color red?

No, but it's in the TODO list

Julian wrote:

SpaceEngineer, I'm glad to hear about the equatorial ridge feature in 0.990, but if we really wanted to recreate the appearance of Iapetus, can we control the color of drivenDarkening and how sharply bounded it is?

drivenDarkening replicates the darkening of a surface due to radiation (charged particles) being driven into the trailing hemispheres of moons by the rotating magnetic field of the parent planet. The dual-tone appearance of Iapetus is caused by a different process and doesn't look very similar.

Are the rings generated pseudo-randomly or is there a check to whether there exists valid orbits around a planet for rings to form, and they do. Since all large planets have rings that we have had the opportunity to check, right?

And do the new equatorial ridges on ringlets happen 100% of the time or is it also pseudo-random? Or a different mechanism?

Terran wrote:

Are the rings generated pseudo-randomly or is there a check to whether there exists valid orbits around a planet for rings to form, and they do. Since all large planets have rings that we have had the opportunity to check, right?

And do the new equatorial ridges on ringlets happen 100% of the time or is it also pseudo-random? Or a different mechanism?

The equatorial ridges on ringlets from what I have seen, are psuedo-random

Will Space Engine support crossfire in the next version?