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-01-2020, 02:39 PM   #5101
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 Of course, they shouldn't be rendered but it is very very difficult to detect (efficiently) if an object is obscured by on other one. Especially if texture transparency is taken in account. There would need to be some kind of low-poly mesh to help with visibility detection. This is unlikely going to happen. Too complex, too little benefits.
Thanks!
A couple a things I found in file gcConst.h:
line 495: nameless structs containing variables with same name
line 578: missing return
GLS is offline   Reply With Quote
Old 04-01-2020, 03:12 PM   #5102
llarian
Orbinaut
 
llarian's Avatar
Default Mouse unavailable after loading ...

When I am setting up a session in orbiter-ng my mouse works fine. When I launch the mouse will respond to movement but mouse click on any selection is not recognized. Any idea what I did and how to get it back? Oh, yes in the parameters focus follows mouse is set.
llarian is offline   Reply With Quote
Old 04-01-2020, 03:28 PM   #5103
4throck
Enthusiast !
 
4throck's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 Implementing shadows for local lights isn't that difficult from source code point of view. But it's kinda performance heavy.
Since performance will depend on unknowns (number of lights, mesh complexity and CPU power) the only answer it to let the user decide. But it should be implemented for all lights of course.
So a "Compute local light shadows ON/Off" switch would do.
4throck is offline   Reply With Quote
Old 04-01-2020, 04:04 PM   #5104
Trekkie
Starfleet Head of Ship Design
 
Trekkie's Avatar

Default

I was Testing my system in the D3d9Client, and i have Meshes that Play as Planets.. but in the D3D9 client they are not showing up.. anyone any Idea how to fix this?
Trekkie is offline   Reply With Quote
Old 04-01-2020, 04:43 PM   #5105
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by jarmonik View Post
 The local lights sources do have two different modes (Partial, Full) the "Partial" lights won't cast specular reflections, this is sort of a low weight mode for laptops. The "Full" mode should cast specular reflections. If they don't then it might be related to "No specular reflectins in PBR mode" you reported later on. Is there a pre-build binary package for the SSU that could be used for debugging the specular issue ?


Implementing shadows for local lights isn't that difficult from source code point of view. But it's kinda performance heavy. So, let's say that shadow casing is limited to 2 or 4 local light sources (depending on settings) then which one ? How should the client know which lights should cast shadow ? Finding a solid answer to that question would make the case half solved.

---------- Post added at 14:17 ---------- Previous post was at 14:10 ----------




Of course, they shouldn't be rendered but it is very very difficult to detect (efficiently) if an object is obscured by on other one. Especially if texture transparency is taken in account. There would need to be some kind of low-poly mesh to help with visibility detection. This is unlikely going to happen. Too complex, too little benefits.
Quote:
Originally Posted by 4throck View Post
 Since performance will depend on unknowns (number of lights, mesh complexity and CPU power) the only answer it to let the user decide. But it should be implemented for all lights of course.
So a "Compute local light shadows ON/Off" switch would do.
I agree with this option as it is an option seeing in many modern AAA games. Another shadow related bug is that what shadows are seen depends on what vessel is in focus. This is an old bug that I have reported earlier: https://www.orbiter-forum.com/showth...postcount=4566
DaveS is offline   Reply With Quote
Old 04-01-2020, 09:29 PM   #5106
kuddel
Donator
Default

Quote:
Originally Posted by GLS View Post
 Thanks!
A couple a things I found in file gcConst.h:
line 495: nameless structs containing variables with same name
line 578: missing return
a) That's the 'a' float used both in {R,B,G,A} and {{RGB},A} "union". they should be O.K. from a memory layout. I haven't found a good way to work around that (yet).
b) Right! Good catch. Will be fixed!
kuddel is offline   Reply With Quote
Thanked by:
Old 04-01-2020, 09:42 PM   #5107
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by kuddel View Post
 a) That's the 'a' float used both in {R,B,G,A} and {{RGB},A} "union". they should be O.K. from a memory layout. I haven't found a good way to work around that (yet).
b) Right! Good catch. Will be fixed!
and the 'w'
GLS is offline   Reply With Quote
Thanked by:
Old 04-01-2020, 10:09 PM   #5108
kuddel
Donator
Default

Changing the FVECTOR4 from
PHP Code:
typedef union FVECTOR4 
{
    
// ...
    
float data[4];
    
struct {
        
float xyzw;
    };
    
struct {
        
float rgba;
    };
    
struct {
        
FVECTOR3 rgb;
        
float a;
    };
    
struct {
        
FVECTOR3 xyz;
        
float w;
    };
FVECTOR4
...to...
PHP Code:
typedef union FVECTOR4 
{
    
// ...
    
float data[4];
    
struct {
        
float xyzw;
    };
    
struct {
        
struct {
            
float rgb;
        };
        
struct {
            
FVECTOR3 rgb;
        };
        
float a;
    };
    
struct {
        
FVECTOR3 xyz;
        
float w;
    };
FVECTOR4
...should do the trick.

But it greatly reduces readability

I might have to add some comments ?!

By the way here's a nicer summary of that.

---------- Post added at 00:03 ---------- Previous post was at 00:02 ----------

Quote:
Originally Posted by GLS View Post
 and the 'w'
Oh, 'w' has also to be moved. Thanks!

---------- Post added at 00:09 ---------- Previous post was at 00:03 ----------

So this should be it, right?
PHP Code:
typedef union FVECTOR4 
{
    
// ... 
    
float data[4];
    
struct // {x,y,z,w} or {xyz,w}
        
struct {
            
float xyz;
        };
        
struct {
            
FVECTOR3 xyz;
        };
        
float w;
    };
    
struct // {r,g,b,a} or {rgb,a}
        
struct {
            
float rgb;
        };
        
struct {
            
FVECTOR3 rgb;
        };
        
float a;
    };
FVECTOR4
kuddel is offline   Reply With Quote
Thanked by:
Old 04-01-2020, 10:53 PM   #5109
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by kuddel View Post
 So this should be it, right?
PHP Code:
typedef union FVECTOR4 
{
    
// ... 
    
float data[4];
    
struct // {x,y,z,w} or {xyz,w}
        
struct {
            
float xyz;
        };
        
struct {
            
FVECTOR3 xyz;
        };
        
float w;
    };
    
struct // {r,g,b,a} or {rgb,a}
        
struct {
            
float rgb;
        };
        
struct {
            
FVECTOR3 rgb;
        };
        
float a;
    };
FVECTOR4
It seems ok now.
GLS is offline   Reply With Quote
Old 04-02-2020, 03:11 PM   #5110
jarmonik
Beta Tester

Default

Quote:
Originally Posted by DaveS View Post

Ok, Thanks. I had some trouble getting it to work, it seems to crash in a cockpit view but I was able to make the necessary test.


Here's a slightly modified shader and textures. Some of the textures were pretty badly out of reasonable range. Even if we have a "roughness map" it is in-fact a smoothness map so 255 is mirror smooth and 0 is very rough. This article speaks of a "Microsurface" https://marmoset.co/posts/physically...d-you-can-too/


The textures should be remade the ones in the package have been modified-compressed-modified-compressed... so the quality have deteriorated.


Could you test these textures and the modified shader to see if there are any fundamental issues remaining. I wasn't able to test the local lights due to no access in cockpit.
Attached Files
File Type: zip PBR.zip (4.98 MB, 1 views)
jarmonik is offline   Reply With Quote
Old 04-02-2020, 03:13 PM   #5111
jarmonik
Beta Tester

Default

Quote:
Originally Posted by kuddel View Post
 But it greatly reduces readability

It's readable well enough

---------- Post added at 18:13 ---------- Previous post was at 18:12 ----------

Quote:
Originally Posted by 4throck View Post
 Since performance will depend on unknowns (number of lights, mesh complexity and CPU power) the only answer it to let the user decide. But it should be implemented for all lights of course.
So a "Compute local light shadows ON/Off" switch would do.

Ok, Agreed.
jarmonik is offline   Reply With Quote
Thanked by:
Old 04-02-2020, 03:22 PM   #5112
4throck
Enthusiast !
 
4throck's Avatar
Default

A quick remark about transparency:
Perhaps mesh groups could be excluded from shadow computations, based on material properties. Simply exclude if opacity is different from 1.

(For texture alpha, there's no solution, the mesh must be updated)

Last edited by 4throck; 04-02-2020 at 03:24 PM.
4throck is offline   Reply With Quote
Old 04-02-2020, 03:22 PM   #5113
jarmonik
Beta Tester

Default

Quote:
Originally Posted by DaveS View Post
 I agree with this option as it is an option seeing in many modern AAA games. Another shadow related bug is that what shadows are seen depends on what vessel is in focus. This is an old bug that I have reported earlier: https://www.orbiter-forum.com/showth...postcount=4566

I made some testing and I saw that shadow quality can wary depending on vessel in focus like in this screen shot (SRB on shuttle wing) but they shouldn't completely disappear. It shouldn't be difficult to apply better shadows on all small vessels like the shuttle.
Attached Thumbnails
shot.jpg  
jarmonik is offline   Reply With Quote
Old 04-02-2020, 04:37 PM   #5114
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by jarmonik View Post
 Ok, Thanks. I had some trouble getting it to work, it seems to crash in a cockpit view but I was able to make the necessary test.


Here's a slightly modified shader and textures. Some of the textures were pretty badly out of reasonable range. Even if we have a "roughness map" it is in-fact a smoothness map so 255 is mirror smooth and 0 is very rough. This article speaks of a "Microsurface" https://marmoset.co/posts/physically...d-you-can-too/


The textures should be remade the ones in the package have been modified-compressed-modified-compressed... so the quality have deteriorated.


Could you test these textures and the modified shader to see if there are any fundamental issues remaining. I wasn't able to test the local lights due to no access in cockpit.
I did forget to mention that the modules were built for the latest Orbiter 2016 beta revision (90). Things do look better now though, thanks. Final confirmation will have to come once proper reflections have been implemented.
DaveS is offline   Reply With Quote
Old 04-02-2020, 08:05 PM   #5115
kuddel
Donator
Default

Side note for developers compiling D3D9Client from source:
- 'trunk' is currently not the main development branch of Jarmo. He currently mainly develops on branch '2016'.
- I'll merge all the changes back to 'trunk' when it makes sense (@Jarmo: drop me a note when you think it's worth it )
kuddel 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 07:47 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.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.