Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Visualization Project Orbiter external graphics development.

Reply
 
Thread Tools
Old 04-03-2016, 03:11 PM   #3646
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by Felix24 View Post
 I know very little at all about 3D rendering, but after some research, it seems the main benefit of deferred rendering would be inexpensive multiple light sources. I assume D3D9 currently uses a forward rendering approach.

It seems that ordinary deferred rendering has problems with multiple material types within a scene, whereas light-prepass rendering doesn't. Would this be a problem for scenes containing multiple vessels having parts with different material definitions?

Currently the only light sources in Orbiter I can think of are the sun, planet, and vessel lights. Could new visual effects be realized if a few hundred light sources were available?

Three major visual effects I'm hoping for in future versions are self-shadowing, realtime irradiance mapping (sunlight reflected off clouds, ocean sunglint, and land, also glow from planet night lights), and blurred reflections (a cross between mirror reflections and specular lighting, like reflections from smooth but not shiny metallic surfaces). Would using deferred or light-prepass architecture make any of these effects easier to realize?

A while back I found an article about realtime calculation of irradiance environment maps. I thought I linked to it in a D3D9 related thread, but I can't find it anymore. Here is the article: http://http.developer.nvidia.com/GPU...chapter10.html. It sounds similar to the realtime reflection maps already in the D3D9 client, except a special blurring algorithm is applied. This technique might hold some promise even if it is a bit computationally expensive, since the lighting environment changes relatively slowly compared to the reflection environment. The lighting environment could be recalculated at 1Hz or even slower, once every two or five seconds, whereas the reflection environment looks bad if the updates are not much slower than the frame rate.

If a realtime irradiance map can be calculated in near real-time, a blurred reflection map may also be possible using a similar (less) blurring algorithm, also recalculated at a slow rate.
I'm hoping for a improvement in the exhaust rendering myself. I'm thinking taking the step from the pseudo-3D (really 2D texture with billboard mapping) rendering we have now to actual 3D rendering. This should improve visuals a great deal.
DaveS is offline   Reply With Quote
Thanked by:
Old 04-03-2016, 03:59 PM   #3647
jarmonik
Beta Tester

Default

Quote:
Originally Posted by kuddel View Post
 @Jarmo: Could you take a look at issue found by Nikogori?
Scenario for easy check attached
Poles , Fixed.

Last edited by jarmonik; 04-03-2016 at 04:03 PM.
jarmonik is offline   Reply With Quote
Old 04-03-2016, 04:06 PM   #3648
kuddel
Donator
Default

Quote:
Originally Posted by jarmonik View Post
 Poles , Fixed.
Indeed you did! Thanks
kuddel is offline   Reply With Quote
Old 04-03-2016, 05:12 PM   #3649
Felix24
Orbinaut
Default

Quote:
Originally Posted by DaveS View Post
 I'm hoping for a improvement in the exhaust rendering myself. I'm thinking taking the step from the pseudo-3D (really 2D texture with billboard mapping) rendering we have now to actual 3D rendering. This should improve visuals a great deal.
Yes! I've been thinking about exhaust rendering too.
Felix24 is offline   Reply With Quote
Old 04-03-2016, 07:30 PM   #3650
jarmonik
Beta Tester

Default

Quote:
Originally Posted by Felix24 View Post
 It seems that ordinary deferred rendering has problems with multiple material types within a scene, whereas light-prepass rendering doesn't. Would this be a problem for scenes containing multiple vessels having parts with different material definitions?
Ordinary deferred renderer can have multiple materials. But the problem is the G-buffer that forwards information from geometry/scene rendering stage to screen space light processing stage. From the current material properties we could have pretty much everything else except specular color. Specular color could vary between two choices, white or diffuse color. Probably, a bigger concern would be a lack of MSAA (Multi-Sample AA) which would need to be replaced with heavier SSAA (Super-Sample AA).

I guess the G-buffer layout would be something like albedo.rgb, emission.rgb, specular power, specularity. In our case a reflection from a pixel would be added to emission color, which from a physics point of view would be accurate.

Quote:
Originally Posted by Felix24 View Post
 Currently the only light sources in Orbiter I can think of are the sun, planet, and vessel lights. Could new visual effects be realized if a few hundred light sources were available?
We are not talking about hundreds of light sources, merely implementing the current ones in a per-pixel basis instead of per-vertex basis. Currently local light sources (vertex lights) won't interact with normal maps properly.

The reason why a deferred pipeline is considered is mostly SSAO (Screen Space Ambient Occlusion) which is the only dynamic AO technique implementable to the client. Also, other screen space effects, like light bleeding (glowing) from sun-lit surfaces to near-by-pixels would come more efficiently and naturally in a deferred architecture.

Quote:
Originally Posted by Felix24 View Post
 Three major visual effects I'm hoping for in future versions are self-shadowing, realtime irradiance mapping (sunlight reflected off clouds, ocean sunglint, and land, also glow from planet night lights), and blurred reflections (a cross between mirror reflections and specular lighting, like reflections from smooth but not shiny metallic surfaces). Would using deferred or light-prepass architecture make any of these effects easier to realize?
No, deferred does not help there. Shadows are problematic, there are plenty of computer games using commercial renderers and yet still they have problems with shadows. Shadowing is what I might call an unstable effect, how well it works would depend on rendering conditions. If shadowing is limited to self-shadows only not to vessel-on-vessel shadows, then it might get simpler.

Irradiance mapping is a stable and implementable effect, I already had an experimental version of it when the reflection model was implemented but it never went out. SSAO and other screen space effects are also stable. So, the question would be how much the SSAO is worth ?

I am not sure if a deferred is a good idea and I have no need to push it so I can dump it overboard if need be. Every technique has good sides and the bad ones too.

Last edited by jarmonik; 04-03-2016 at 07:43 PM.
jarmonik is offline   Reply With Quote
Thanked by:
Old 04-04-2016, 01:46 AM   #3651
hutchison66
Donator
Default D3D9 spacecraft 3

I finally got this working in windows 8.1 and Nvidz card,

people keep saying make it your Addons D3D9 compliant well easier said than done you've all probably covered this all before but
I mainly use Spacecraft3 seems like it isn't compatible is there anything I can do to make them work
when I changed to spacecraft 4 it doesn't CTD anymore but no visuals
is there any tips anyone can give me for getting my addons working
I would have thought That spacecraft 3/4 is so important to orbiter I would have thought D3D9 would have made sure it works with it with little change

thanks
David
hutchison66 is offline   Reply With Quote
Old 04-04-2016, 05:26 AM   #3652
Cras
Spring of Life!
 
Cras's Avatar
Default

Just completed a shuttle fleet flight with R16.4, everything seemed to be working well, the only oddity was that there was a flicker in the mountains and buildings at Wideawake Int'l as seen through the VC windows.
Cras is offline   Reply With Quote
Old 04-04-2016, 08:56 AM   #3653
4throck
Enthusiast !
 
4throck's Avatar
Default

Quote:
Originally Posted by hutchison66 View Post
 would have thought D3D9 would have made sure it works with it with little change
There's no problem with D3D9 and spacecraft.dll and no changes are needed.

Did you click on "create symbolic links" on the "D3D9 client advanced setup" window?
You must do that in order to get it working.

Last edited by 4throck; 04-04-2016 at 08:58 AM.
4throck is offline   Reply With Quote
Old 04-04-2016, 10:58 AM   #3654
kuddel
Donator
Default

Is the "forgot to create symbolic links" problem happening too often?
In that case the D3D9Client could create that links *always* without any user-action required.
The downside of course is, that the user looses control of that process.
Some might not like to have symbolic links at all (Linux users might dislike this automatic "feature").
kuddel is offline   Reply With Quote
Old 04-04-2016, 11:09 AM   #3655
jarmonik
Beta Tester

Default

Doesn't the client display a warning on a splash screen if the links are not present ? Maybe that could be improved ? I'll leave it to you.
jarmonik is offline   Reply With Quote
Old 04-04-2016, 11:34 AM   #3656
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by kuddel View Post
 Is the "forgot to create symbolic links" problem happening too often?
In that case the D3D9Client could create that links *always* without any user-action required.
The downside of course is, that the user looses control of that process.
Some might not like to have symbolic links at all (Linux users might dislike this automatic "feature").
Here's hope this work-around is not needed anymore once SC5 (supposedly fully beta-compatible as well) is out. It's quite a crutch IMHO, anyway.
Face is offline   Reply With Quote
Thanked by:
Old 04-04-2016, 11:34 AM   #3657
kuddel
Donator
Default

Quote:
Originally Posted by jarmonik View Post
 Doesn't the client display a warning on a splash screen if the links are not present ?
Yes it does! ...but nobody reads messages

Quote:
Originally Posted by jarmonik View Post
 Maybe that could be improved ? I'll leave it to you.
I'll wait for any reaction from users ("easy spacecraft.dll" vs. "Linux" ).
kuddel is offline   Reply With Quote
Old 04-04-2016, 03:50 PM   #3658
4throck
Enthusiast !
 
4throck's Avatar
Default

Quote:
Originally Posted by kuddel View Post
 Yes it does! ...but nobody reads messages
Second that. Never noticed that message!

Back on topic, the current Client performs great on my machines.

The only complaint is the current specular reflection. Interesting if you want to create mirrors, but incorrect for other metallic surfaces. At least on my machine/config.

I suggest looking into Physical Based Rendering lighting model as the next step. We already have support for multiple textures (we would need diffuse, specular, gloss, normal), so it's very close.
It would benefit things like solar panels a lot!

For example, here's my Skylab B with PBR textures. It's the same model (and base textures) as in Orbiter.
https://sketchfab.com/models/eda477f...1eefea5da9bcee
4throck is offline   Reply With Quote
Thanked by:
Old 04-04-2016, 07:06 PM   #3659
jarmonik
Beta Tester

Default

Quote:
Originally Posted by 4throck View Post
 The only complaint is the current specular reflection. Interesting if you want to create mirrors, but incorrect for other metallic surfaces. At least on my machine/config.

I suggest looking into Physical Based Rendering lighting model as the next step. We already have support for multiple textures (we would need diffuse, specular, gloss, normal), so it's very close.
It would benefit things like solar panels a lot!

For example, here's my Skylab B with PBR textures. It's the same model (and base textures) as in Orbiter.
https://sketchfab.com/models/eda477f...1eefea5da9bcee
That model looks very nice. One problem in our end is that we have tried to match the current rendering with the Orbiter's DX7 inline engine. I suppose we could have different shaders for models build for the inline engine and models build for DX9+, but in that case those models wouldn't be backwards compatible with the inline engine.

Do there actually exists any standards for parameters used to define materials for 3D models ?
jarmonik is offline   Reply With Quote
Thanked by:
Old 04-04-2016, 09:37 PM   #3660
4throck
Enthusiast !
 
4throck's Avatar
Default

The model is the same as on OH and the textures are also quite similar! It's the shader that's different.


As far as I know, the material parameters are these:
http://www.marmoset.co/toolbag/learn/pbr-practice



From my tests with Sketchfab, textures are not incompatible.


The main difference is that the albedo texture has no backed shadows. So let's say the interior of a cockpit will be textured as bright as the outside. Shadows are calculated in realtime (ambient occlusion).
From my tests if you don't change the textures they only look darker (because you have textured shadows + computed ones). So we can use the current textures.


Normalmaps are unchanged, so the current ones can be used.


Specular map. This should have the reflection intensity + reflection color. We already have a specular texture, so nothing new here.


Roughness map. This controls reflection, from mirror like to something more diffuse. It's connected to the surface roughness. For a solar panel, you will have brighter (smother) parts over the solar cells, and darker parts over the metal structure, wires, etc.
This is the only new texture.


Of course, for 100% accurate results you need a new set of textures, but they will still look decent on the inline client.
The oposite is also true, the current texture will look OK on a PBR shader. Perhaps even better because of real-time ambient occlusion.
I don't see a problem there.

Last edited by 4throck; 04-04-2016 at 09:43 PM.
4throck is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project

Tags
d3d9client, graphicsclient


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 01:50 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.