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-06-2019, 07:50 PM   #4921
jarmonik
Beta Tester

Default New build is out

New builds are published for Orbiter 2016 and Beta. Available from additional downloads section due to "Beta" status.

- Dave's reflection issue should be fixed
- Donamy's local lights issue in GenericCameraMFD should be fixed
- An attempt is made to fix Clipper's planet issue. Feedback required.
- Kuddel's local lights on lunar surface issue should be fixed.
- Some animation related bugs have been fixed. (Related to a use of negative amin state)
- Some other lunar surface rendering issues have been fixed.
- Cloud shadow intensity over water has been increased.
- Nightlights intensity has been increased. (Plenty of nights visibility problems exists. Missing from certain tiles. Corrupted textures ???)

- SSU Over saturation issue remains. Proper fix is still unknown.

---------- Post added at 22:50 ---------- Previous post was at 22:47 ----------

Quote:
Originally Posted by GLS View Post
 Can't run D3D9 as it shuts down my PC....
I am sorry to hear that. We have invested a quite lot of efforts to keep the client available as many as possible.

Do you know why it doesn't run ? If not then could you post the logs ?
Attached Thumbnails
cupola.jpg  

Last edited by jarmonik; 04-10-2019 at 12:18 AM.
jarmonik is offline   Reply With Quote
Thanked by:
Old 04-06-2019, 08:30 PM   #4922
DaveS
Addon Developer
 
DaveS's Avatar


Default

I can confirm that the issues reported by me has been fixed except for the over saturation issue. Two issues still remain though, shadows not affecting diffuse particle streams and of course the atmosphere rendering.
DaveS is online now   Reply With Quote
Old 04-06-2019, 08:51 PM   #4923
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 - SSU Over saturation issue remains. Proper fix is still unknown.
Is it only SSU? If so, then we might be doing something wrong...



Quote:
Originally Posted by jarmonik View Post
  I am sorry to hear that. We have invested a quite lot of efforts to keep the client available as many as possible.

Do you know why it doesn't run ? If not then could you post the logs ?
I'm 99% certain it's hardware, probably not even the GPUs. It started to shut down the PC when I tried to run D3D9 in the NVIDIA, but it still worked in the Intel GPU. That was until a week or so ago, when it started to do the same in the Intel.
When I have time I'll try to debug this further, but you guys are almost certainly innocent.
GLS is online now   Reply With Quote
Old 04-08-2019, 02:48 AM   #4924
Donamy
Beta Tester


Default

Quote:
Originally Posted by jarmonik View Post
 New builds are published for Orbiter 2016 and Beta. Available from additional downloads section due to "Beta" status.

- Dave's reflection issue should be fixed
- Donamy's local lights issue in GenericCameraMFD should be fixed
- An attempt is made to fix Clipper's planet issue. Feedback required.
- Kuddel's local lights on lunar surface issue should be fixed.
- Some animation related bugs have been fixed. (Related to a use of negative amin state)
- Some other lunar surface rendering issues have been fixed.
- Cloud shadow intensity over water has been increased.
- Nightlights intensity has been increased. (Plenty of nights visibility problems exists. Missing from certain tiles. Corrupted textures ???)

- SSU Over saturation issue remains. Proper fix is still unknown.

---------- Post added at 22:50 ---------- Previous post was at 22:47 ----------


I am sorry to hear that. We have invested a quite lot of efforts to keep the client available as many as possible.

Do you know why it doesn't run ? If not then could you post the logs ?

Lighting issue in generic camera is fixed.
Donamy is offline   Reply With Quote
Old 04-08-2019, 03:46 PM   #4925
clipper
Orbinaut
Default

Quote:
Originally Posted by jarmonik View Post
 New builds are published for Orbiter 2016 and Beta. Available from additional downloads section due to "Beta" status.

- Dave's reflection issue should be fixed
- Donamy's local lights issue in GenericCameraMFD should be fixed
- An attempt is made to fix Clipper's planet issue. Feedback required.
- Kuddel's local lights on lunar surface issue should be fixed.
- Some animation related bugs have been fixed. (Related to a use of negative amin state)
- Some other lunar surface rendering issues have been fixed.
- Cloud shadow intensity over water has been increased.
- Nightlights intensity has been increased. (Plenty of nights visibility problems exists. Missing from certain tiles. Corrupted textures ???)

- SSU Over saturation issue remains. Proper fix is still unknown.

---------- Post added at 22:50 ---------- Previous post was at 22:47 ----------


I am sorry to hear that. We have invested a quite lot of efforts to keep the client available as many as possible.

Do you know why it doesn't run ? If not then could you post the logs ?
I haven't been able to test it on my main hardware as I'm away, but I tested it on a different hardware and it seems to work perfectly well, so thank you very much for the effort and implementation.

By the way, I'm not sure if this is an issue with D3D9 or not, but when running the sim in Window with Taskbar mode, the MFDs in the default glass cockpit appear rather blurry as compared to when running with the other two full screen modes. I managed to replicate this on two different systems and I also compared it to Orbiter 2010 Window with Taskbar mode and the MFDs appear exactly the same as in the other two modes, so this seems to be an Orbiter 2016-specific issue.

EDIT: So after some more tinkering, it seems that this issue only occurs when using a Generic MFD size of 3 or less (which I do on a regular basis), otherwise the MFDs appear just as they should. However, this still isn't the case in Orbiter 2010 where MFDs appear smooth regardless of the selected size.
Attached Thumbnails
Comparison.png  

Last edited by clipper; 04-08-2019 at 04:12 PM. Reason: added image
clipper is offline   Reply With Quote
Thanked by:
Old 04-11-2019, 05:13 PM   #4926
fred18
Addon Developer

Default

Hello guys,

so, following to this conversation https://www.orbiter-forum.com/showth...5&postcount=40

I am here asking if possible to implement the following function in a test version of D3D9.

given a set of values which is:
- center coordinates
- size
- altitude
- shape factor

a rectangular terrain area will be rendered simply flat with possibly its edges smoothly linked to the surrounding and this rectangle will have the following characteristics:
- center at center coordinates
- long side = 2*size
- short side = shape factor * long side
- altitude = constant altitude as per input value

This flat area should be rendered overriding the terrain elevation tiles, simply when it's time to be rendered it will be flat instead of following terrain tiles.

If the set of values is removed then the regular terrain shall be rendered

I gave a look at the code of the tile manager of D3D9 and I am available to participate actively also to the coding part, but I need at least help to get a grasp of what is going on in those functions before I could touch anything there.

Will someone be so kind to make this test or to help me through it?

thank you very much in advance for any attention

Fred

Last edited by fred18; 04-11-2019 at 05:16 PM.
fred18 is offline   Reply With Quote
Thanked by:
Old 04-12-2019, 04:48 AM   #4927
jarmonik
Beta Tester

Default

Quote:
Originally Posted by clipper View Post
 EDIT: So after some more tinkering, it seems that this issue only occurs when using a Generic MFD size of 3 or less (which I do on a regular basis), otherwise the MFDs appear just as they should. However, this still isn't the case in Orbiter 2010 where MFDs appear smooth regardless of the selected size.

I can reproduce the problem and I think I know what is causing it. Haven't had time to fix it.

---------- Post added at 07:48 ---------- Previous post was at 07:42 ----------

Quote:
Originally Posted by fred18 View Post
 so, following to this conversation https://www.orbiter-forum.com/showth...5&postcount=40

I am here asking if possible to implement the following function in a test version of D3D9.

This flat area should be rendered overriding the terrain elevation tiles, simply when it's time to be rendered it will be flat instead of following terrain tiles.

If the set of values is removed then the regular terrain shall be rendered

I gave a look at the code of the tile manager of D3D9 and I am available to participate actively also to the coding part, but I need at least help to get a grasp of what is going on in those functions before I could touch anything there.

If you want to flatten a terrain in D3D9 then the easiest way is to do it in a vertex shader especcially if you can settle down to a circle instead of a square as an shape. You could feed a reference point (i.e. a vector [x, y, z, radius]) to a shader and flatten the terrain within the reference radius and smoothed the edges with vertex blending. Even if relatively easy to implement it has one major flaw that the orbiter's surface collision logic wouldn't take the modified terrain in count.

So, it would be more practical to create somekind of patch utility to apply a terrain flattening described in a configuration file to elevation data on a harddrive. Which would work without any modifications to the Orbiter or to the Client.

Back when I was working with the surface micro-textures, I got an idea of micro-elevation which would require some kind of tile-server in order to be implementable. Right now the Client requests a tile elevation file with it's tile-number from a harddrive. If a tile-server would be in place then the request/number would be passed to the server which would then load the file and preprocess the elevation data using a pixel-shader before forwarding it to a terrain manager for rendering. This would allow us to do more extensive real-time processing with the elevetion data. This idea came to a halt due to fact that the Orbiter's surface collision logic wouldn't know about the modified terrain.

So, technically it would sound more practical approach if the Orbiter would request the surface elevation data from the Client directly instead of loading it from a data file. Client could easily return elevation and normal for a requested lng, lat.
jarmonik is offline   Reply With Quote
Thanked by:
Old 04-12-2019, 10:05 AM   #4928
fred18
Addon Developer

Default

Quote:
Originally Posted by jarmonik View Post
 If you want to flatten a terrain in D3D9 then the easiest way is to do it in a vertex shader especcially if you can settle down to a circle instead of a square as an shape. You could feed a reference point (i.e. a vector [x, y, z, radius]) to a shader and flatten the terrain within the reference radius and smoothed the edges with vertex blending. Even if relatively easy to implement it has one major flaw that the orbiter's surface collision logic wouldn't take the modified terrain in count.

So, it would be more practical to create somekind of patch utility to apply a terrain flattening described in a configuration file to elevation data on a harddrive. Which would work without any modifications to the Orbiter or to the Client.

Back when I was working with the surface micro-textures, I got an idea of micro-elevation which would require some kind of tile-server in order to be implementable. Right now the Client requests a tile elevation file with it's tile-number from a harddrive. If a tile-server would be in place then the request/number would be passed to the server which would then load the file and preprocess the elevation data using a pixel-shader before forwarding it to a terrain manager for rendering. This would allow us to do more extensive real-time processing with the elevetion data. This idea came to a halt due to fact that the Orbiter's surface collision logic wouldn't know about the modified terrain.

So, technically it would sound more practical approach if the Orbiter would request the surface elevation data from the Client directly instead of loading it from a data file. Client could easily return elevation and normal for a requested lng, lat.
I never done a shader in my life so I don't know where to start from

anyway you are surely right that having a client which stands in between Orbiter core and the planetary textures would be a very good organization. Actually the point would all be there: put something in the middle between the hard drive files and orbiter to override the terrain definition when (where) needed. I was thinking about creating temporary files that orbiter will then parse and acquire, but I don't know if that is feasible
fred18 is offline   Reply With Quote
Thanked by:
Old 04-12-2019, 05:34 PM   #4929
Donamy
Beta Tester


Default

Or in vain, if future changes in Orbiter break it.
Donamy is offline   Reply With Quote
Thanked by:
Old 04-12-2019, 05:52 PM   #4930
4throck
Enthusiast !
 
4throck's Avatar
Default

Quote:
Originally Posted by fred18 View Post
  put something in the middle between the hard drive files and orbiter to override the terrain definition

Elev_mod files.... they already exist.


Don't know it the graphic client could be used to generate them.
If it could, it would be great. Do it all from within Orbiter...
4throck is offline   Reply With Quote
Old 04-12-2019, 06:25 PM   #4931
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by fred18 View Post
 anyway you are surely right that having a client which stands in between Orbiter core and the planetary textures would be a very good organization. Actually the point would all be there: put something in the middle between the hard drive files and orbiter to override the terrain definition when (where) needed. I was thinking about creating temporary files that orbiter will then parse and acquire, but I don't know if that is feasible
If you put some area definitions into a text file, you can parse it and use the information at the end of "bool SurfTile::LoadElevationData ()" inside of Surfmgr2.cpp to manipulate the "elev" field in the tile, which is nothing but an 259x259 array of INT16. It is what the renderer will eventually put on screen.

So there you can iterate over all the shape definitions, check if they are relevant for the tile at hand (tile boundaries), then project the shape onto the tile and set the covered pixel to the altitude value you want.

It will not make the collision thing work, but it will demonstrate what the idea could accomplish in terms of developer experience. It will also demonstrate the impact on the frame-rate.
Face is offline   Reply With Quote
Thanked by:
Old 04-12-2019, 09:20 PM   #4932
fred18
Addon Developer

Default

Thank you, I will surely try this, I am very curious to see where it does end up. I have an issue anyway: I can't compile the D3D9 client, it seems that I don't have the right redistributables, but if I try to install them I get the error s1023 or something like that which means that I have a newer set. I use VS community 2019. Anyone knows a workaround?
fred18 is offline   Reply With Quote
Old 04-12-2019, 10:01 PM   #4933
kuddel
Donator
Default

To compile D3D9Client, the redistributables are not enough! You need the DirectX SDK.
See Orbitersdk\D3D9Client\README.txt for further details.

[*] ...some points in that document are not very up to date I must say , it was last updated May 2014!
Let's see if I can find the SDK Link for you...
This should be it:
https://www.microsoft.com/en-us/down...s.aspx?id=6812

Last edited by kuddel; 04-12-2019 at 10:13 PM.
kuddel is offline   Reply With Quote
Old 04-12-2019, 10:18 PM   #4934
fred18
Addon Developer

Default

Quote:
Originally Posted by kuddel View Post
 To compile D3D9Client, the redistributables are not enough! You need the DirectX SDK.
See Orbitersdk\D3D9Client\README.txt for further details.

[*] ...some points in that document are not very up to date I must say , it was last updated May 2014!
Let's see if I can find the SDK Link for you...
This should be it:
https://www.microsoft.com/en-us/down...s.aspx?id=6812
thank you very much but that is what I was talking about:

fred18 is offline   Reply With Quote
Old 04-12-2019, 10:31 PM   #4935
kuddel
Donator
Default

It's a known issue (nowadays):

https://support.microsoft.com/de-de/...-sdk-june-2010

https://walbourn.github.io/known-iss...e-s1023-error/

---------- Post added at 22:31 ---------- Previous post was at 22:27 ----------

It looks like I have to do a whole new chapter on "how to setup & build D3D9Client"
kuddel is offline   Reply With Quote
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 04:03 PM.

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.