New Release D3D9Client Development

[jarmonik]

I am not an expert, but could it be a CPU thread issue? Maybe the creation of tiles should be on a separate thread to the Orbiter core and D3D9Client. I use an Intel Core Duo processor at 2.1GHz.

That CPU should be very good to run the client. Could you give some more details about the Intel Graphics Chip you have ? And how much video and system memory the computer has ?

Would it be possible to add a "Tile Resolution Bias" control, as exists in DX7? Reducing the vertex count this way would improve basic frame rate for lesser computers, although it still might not fix the stutter.

Possible, yes, but not easy. I haven't had time to study the implementation Martin made and I was hoping to get some documentations for it. It's difficult to change it without fully understanding it in detail.

I might have found the fix. Switching the new atmosphere off seems to fix the stutter, and improves basic frame rate. It seems the problem is with my ancient computer.

I am a bit confused that how does the atmosphere produce the stutter. Could you give some numbers how much the atmospheric rendering is effecting into your frame rate ? Is the stuttering a skipped frames or a longer stalls ? There are some problems with the surface collision physics in the Orbiter. For an example my frame-rate can drop from 500fps down to 20fps when crashing a vessel onto a ground. So, could you keep the Orbiter paused and the camera in the exterior view when doing some testing. It's also a good idea to check the /Modules/D3D9Client/D3D9ClientLog.html if it contains an extensive amount of errors.

---------- Post added at 20:56 ---------- Previous post was at 20:46 ----------

Sorry again, I haven't found the fix. The stutter is still there even when switching the atmosphere off, although the basic frame rate is about 70% better.

Wow. That's a heavy impact.:facepalm: I get something like 5%. Is the computer running in software vertex processing ? There are a lot of users running the Orbiter with pretty old hardware so there should be a basic rendering for the atmosphere that would run in all computers. The problem is that the current one was supposed to be the basic renderer.

 

[Phoenix]

Sorry, I found out later that even switching the atmosphere off didn't fix the stuttering. Sorry.

I've attached an image showing the performance meter. Don't laugh too much at the poor frame rate I get.

You can see it is fairly steady when flying along straight and level, but when I roll, the frame rate changes even when the vessel is pointing in the same direction, and causes the stutter. From the meter it looks as if the frame rate improves, but visually there is a definite stutter.

My graphics chip is: Mobile Intel 4 Series Express Chipset. I am fairly certain it's running in hardware mode.

Thanks for your help.

 

[jarmonik]

Is the scattering related to the terrain? Cannot it be ported to "default" planets with atmospheres? I'd have loved to enter the Venusian atmosphere during a sunrise ...

Not in the 3D terrain. It depends about the tile format used in a surface textures. Of course, it can be ported for a default planets. I'll think about it when we have a reliable implementation at first. I suppose one possibility is to port the old surface textures into a new format.

 

[Phoenix]

Here's the log - there doesn't seem to be many errors in there.

 

[jarmonik]

Here's the log - there doesn't seem to be many errors in there.

Thanks, the log seems to be clean.

There are a few things that we can do to improve the performance:

- Reduce the surface mesh resolution like the inline engine allows.
- We can add an option in the setup panel to use the legacy sky model.
- We can simplify the surface haze model

---------- Post added at 21:47 ---------- Previous post was at 21:26 ----------

Does anyone else have information available regarding the efficiency of the atmospheric implementation ?

 

[Felix24]

On an old laptop I have, running The Himalayas scenario (in 2010 Edition->Earth Views), I get around 18 fps with the atmosphere, and about 30 fps with it off.

On the ground (DG-S ready for takeoff), I get 14 fps with the atmosphere, 30 fps with it off. While flying, I get 10 fps with it on, 19 fps with it off.

Lenovo Ideapad U350- Core 2 Solo, 1.4GHz, 4GB RAM, Windows 7 64-bit, Intel GMA 4500MHD graphics

 

[Phoenix]

Thanks, the log seems to be clean.

There are a few things that we can do to improve the performance:

- Reduce the surface mesh resolution like the inline engine allows.
- We can add an option in the setup panel to use the legacy sky model.
- We can simplify the surface haze model

---------- Post added at 21:47 ---------- Previous post was at 21:26 ----------

Does anyone else have information available regarding the efficiency of the atmospheric implementation ?

The basic frame rate I get, while low, is acceptable. I don't think I'll be switching the new atmosphere rendering model off to get an extra 10fps because it looks so much better than the old one. It's the frequent freeze-frame effect that's annoying, but I am beginning to think no amount of programming will fix it - the problem will be down to my obsolete computer.

I think a "Tile Resolution Bias" control might help to improve basic frame rate, though.

Thanks for your help.

 

[Felix24]

Try this in HorizonScatterFast(), it should fix the difference.

Thanks, that fixes it.

At sunrise, viewing the ground from some point above the clouds, the ground looks dark. But when zooming in to ground level, the ground becomes lighter.


I was playing around with the surface pixel shader. It seems that the atmosphere is not to blame for looking opaque when looking down on the terminator from space. Instead, the ground is too dark, so changing the frg.atten.rgb gave some better results. In SurfaceTechPS, try

    float3 color = (cTex.rgb + cSpe) * saturate(frg.atten.r * 2.0f ) + vAddBkg.rgb + frg.insca.rgb + cNgt;
//    float3 color = (cTex.rgb + cSpe) * frg.atten.rgb + vAddBkg.rgb + frg.insca.rgb + cNgt;

with these atmosphere settings


Unfortunately, all the color is now gone from the light that hits the ground, so sunsets make the mountains look gray instead of orange, and other issues appear. But you can now see the ground from space during sunset.

I think if the color curve of frg.atten.rgb is changed to include more white light toward the end of the day, and then become orange only right at the very end, it will make it look better, both for the ground and for the clouds.

Also, the "horizon ring" seems to go around too far into the night side.


---------- Post added at 10:57 PM ---------- Previous post was at 10:25 PM ----------

Here are some photos of earth showing the terminator:

http://www.stp.isas.jaxa.jp/nozomi/MIC/fullEarth.jpg
http://cdn2.vox-cdn.com/entry_photo_images/8711533/earth_large_verge_medium_landscape.jpg
https://www.flickr.com/photos/nasacommons/5052744618/in/set-72157625096855580/lightbox/
http://public.media.smithsonianmag.com/legacy_blog/day-night-terminator.jpg
http://chamorrobible.org/images/pho...inator-night-and-day-20010617-Earth-large.jpg
http://astrobob.areavoices.com/files/2012/01/ISS-day_night_terminator-1024x688.jpg
http://chamorrobible.org/images/pho...tor-day-Apollo-11-mission-July-1969-other.jpg

 

[jarmonik]

At sunrise, viewing the ground from some point above the clouds, the ground looks dark. But when zooming in to ground level, the ground becomes lighter.

Try this:

// Camara altitude dependency multiplier for ambient color of atmosphere
float fMult = 1.0; //saturate((fScaleHeight-fCameraAlt)*fInvScaleHeight);

I think if the color curve of frg.atten.rgb is changed to include more white light toward the end of the day, and then become orange only right at the very end, it will make it look better, both for the ground and for the clouds.

It's difficult to control the results like that in a model like this. There is an ambient light tweak that will lengthen the day by adding some white light. I suppose it might be possible to paint the colors into a texture and cast them to a surroundings. Not necessarily a bad idea to control ambient light. If there is a problem with a direct sunlight then it's likely an implementation error.

Also, the "horizon ring" seems to go around too far into the night side.

Yes, I agree. At least, it's too bright. It comes pretty far in this picture too. Also, there's not much color in a terminator in those photographs. The yellow/green dirt ring around the Earth is kinda ugly in the implementation. I'll try to improve the mie model to attenuate a light without a color shift to yellow.

http://public.media.smithsonianmag.com/legacy_blog/day-night-terminator.jpg

BTW, An atmosphere configuration settings are located in /Config/GC/Earth.atm.cfg It's easier to copy-paste than use a screen shots.

 

[Felix24]

Try this:

I tried it, and it did get rid of the difference in surface brightness. But then I tried "float fMult = 0.0;" instead of 1.0 and it seems to look better. If it is set to 1.0, the ground is lit up too far around into the night. In the screenshot, 1.0 is on the left, 0.0 on the right.


I think part of the issue with ground brightness near the terminator is how the level of detail is automatically adjusted in the elevation map when the camera moves beyond a certain distance/above a certain altitude. When the camera is near the mountains, the LOD is high, and the mountain peaks are sharp and tall and catch a lot of evening sunlight. But when the camera moves higher above the earth, the LOD is lowered, making the mountain peaks not as high and steep, therefore catching less evening sunlight and appearing darker.

Is there an algorithm in place that keeps mountain LODs higher than that of the plains as distance increases? Increasing the elevation LOD worldwide would be inefficient, but if it was selective and only did it to the mountains and not to the plains, that would be acceptable.

I suppose it might be possible to paint the colors into a texture and cast them to a surroundings.

I think that's how FS9, FSX, and P3D do all of their sky colors.

Thanks for the tip about the sky configuration file.

Red = 0.6517
Green = 0.6004
Blue = 0.4816
RWaveDep = 3.28
ScaleHeight = 8.449
OutScatter = 0.512
InScatter = 0.714
RayleighPhase = 0.6825
Balance = 1.14
DepthClamp = 24.667
SrfColor = 0.551
SrfIntensity = 1.0344
MiePower = 0.507
MiePhase = 0.990507
Exposure = 0.6362
Aux1 = 0
Aux2 = 0
Mode = 0
OverSaturation = TRUE

 

[jarmonik]

I tried it, and it did get rid of the difference in surface brightness. But then I tried "float fMult = 0.0;" instead of 1.0 and it seems to look better. If it is set to 1.0, the ground is lit up too far around into the night. In the screenshot, 1.0 is on the left, 0.0 on the right.

That is all true. And that's why I placed the fMult there. The problem is that when you are observing a sunset from a surface, the surface of the planet is still lit by the sky even after the sunset during twilight. There is enough light that you can see pretty well even-if the sun is below the horizon. If you zoom the camera into an orbit then I suppose the surface lightness is very dark compared to a surface that is still lit by the sun. So, does the fMult change from 1.0 to 0.0 too fast then ?

EDIT: Or should we try to control the light sensitivity of the camera. By increasing the exposure setting towards night ? It might produce problems with meshes in that case everything would need to go under the exposure control.

I think part of the issue with ground brightness near the terminator is how the level of detail is automatically adjusted in the elevation map when the camera moves beyond a certain distance/above a certain altitude. When the camera is near the mountains, the LOD is high, and the mountain peaks are sharp and tall and catch a lot of evening sunlight. But when the camera moves higher above the earth, the LOD is lowered, making the mountain peaks not as high and steep, therefore catching less evening sunlight and appearing darker.

I suppose that could happen in some rare cases. But you have a good point. The surface isn't a smooth, so, a typical diffuse light computation fDiff = vSunColor * dot(vSunDir, vNormal) may not work well enough.

---------- Post added at 16:22 ---------- Previous post was at 16:16 ----------

Is there an algorithm in place that keeps mountain LODs higher than that of the plains as distance increases?

No.

 

[jarmonik]

Beta 3 for Rev 8

Here is a new build for Orbiter Beta Rev 8.

- Surface clipping issue should be fixed.
- Cloud layer clipping issue should be fixed.
- Horizon ring issue should be fixed.

Mie scattering (i.e. Fog) has been enchanted a bit. Allowing a surface to catch some scattered light. Mie Power setting increases a grey fog and reduces transparency of the atmosphere. (Fog light level is temporarily controlled with Aux1 slider).

 

[Felix24]

I agree that with 0.0 the ground gets really dark after sunset, and that normally things look lighter in real life for a while after sunset.

So, does the fMult change from 1.0 to 0.0 too fast then ?

Yes, I think so. I see you've just released an update, but here's this anyway. This softened the effect by lessening it (down to 0.3, I think 1.0 is too bright) and by increasing the altitude at which the ground started to brighten, making it more gradual.
in SkyScatterFast,

float fMult = saturate((fScaleHeight-fCameraAlt)*fInvScaleHeight);

in SurfaceTechVS,

float fMult = saturate((fScaleHeight - fCameraAlt * 0.01f) * fInvScaleHeight) * 0.3f;

in CloudTechVS,

float fMult = saturate((fScaleHeight - fCameraAlt * 0.01f) * fInvScaleHeight) * 0.3f;

Or should we try to control the light sensitivity of the camera.

That might be a good idea to explore. It is probably the only real way to capture the difference between day and night.

Clouds can get pretty orange/red when the light is coming from below during sunset.

I like the idea of making the clouds lit from beneath for a short time around sunset.

Also, I think it would be cool if at night you could see the dim greenish glow from the aurora, like this:
http://spaceflight.nasa.gov/gallery/images/station/crew-29/hires/iss029e029257.jpg

 

[SolarLiner]

Dynamic Exposure (so some sort of fake HDR) ? Oh yeah, so much want!
D3D9 is going to be the most amazing graphics client in the solar system! Good job guys :tiphat:

 

[Interceptor]

Could there be any way to simulate earth thunderstorms from orbit like the flashing under clouds caused by lightning?

 

[Ripley]

Don't make the LEO experience too good, otherwise nobody will ever want to go interplanetary anymore!!




...just kidding of course!

 

[Weirdo Earthtorch]

Fantastic. Orbiter, and D3D9 client seem to me to do a better job at terrain rendering than the 'traditional' flight sims, although I haven't used one for a while. The LOD variance with height seems to work really well, and the Earth atmosphere looks great.

Performance on my i3 HD3000 laptop is 30-40fps after terrain generation (takes about 4-5s to do that). Older core 2 duo with Intel GMA965 graphics around 3-4fps in the same area, so not really recommended for terrain.

One small issue I noticed when using the Debug controls - if in Earth Atmosphere, using wheelfly/pan cam control (which is great) can cause some weird atmospheric effects.

Cheers

 

[jarmonik]

Yes, I think so. I see you've just released an update, but here's this anyway. This softened the effect by lessening it (down to 0.3, I think 1.0 is too bright) and by increasing the altitude at which the ground started to brighten, making it more gradual.

Thanks, I'll test that.

That might be a good idea to explore. It is probably the only real way to capture the difference between day and night.

I'll try to implement this in the next version along with a pre-computed sunlight in a texture. Let's see how it will work.

Also, I think it would be cool if at night you could see the dim greenish glow from the aurora, like this:

The atmospheric model can't do that and there are a lot of things in a schedule... But, let's see when the time comes.

---------- Post added at 21:13 ---------- Previous post was at 21:10 ----------

One small issue I noticed when using the Debug controls - if in Earth Atmosphere, using wheelfly/pan cam control (which is great) can cause some weird atmospheric effects.

I wasn't able to produce any atmospheric effects but I found a bug that will be fixed in a next version.

 

[SolarLiner]

Does the exhaust flames use BLEND_Alpha? Is there a way to set that in transparent meshes/groups/textures so that it blends more clearly?

 

[jroly]

I just tried the dx9 version, it looks alot better than the dx7 version, has better colors too. Performance was very smooth too.