- Joined
- Mar 28, 2008
- Messages
- 2,670
- Reaction score
- 799
- Points
- 128
Here's my current API cleanup plan:
Removal of the DirectX7 based renderer and DX7 compatibility requirements.
Those very awkward mesh configuration/override files in /Config/GC/ would be discontinued. (no support after Orbiter 2024)
Mesh Visibility Mode
There are known issues with mesh visibility flags and clipping distance. Documentation regarding the flags should be reviewed and solutions searched for the clipping. It would be possible to render the exterior mesh of the focus vessel using interior clipping distance, but if the focus vessel is docked to a station then the entire station should be rendered using interior clipping otherwise z-ordering/depth-buffer would fail to render the docking port correctly. If the clip distance is too short Z-fighting would occur. I guess this should be tested in a test configuration to see how short the distance can be until problems arise. There's an issue raised about this on GitHub https://github.com/orbitersim/orbiter/issues/363
New Mesh File Format
New mesh file format 'MSHX2' would be added to address several issues. The overall layout of the format would be identical to 'MSHX1' format which, of course, will remain supported.
Right now there is no way to explicitly identify Virtual Cockpit mesh from the rest which is required for rendering VC shadows and other interior effects. New entry is required to tell what the mesh actually is. Also the shader that's required for rendering the mesh need to be identified in a mesh file.
Mesh materials will depend on shader being used, so, material entries would be identified with "DIFFUSE", "SPECULAR", "SMOOTHNESS", etc, keywords to avoid mix-ups and to do sanity checks. Right now there's just an array of values with no ID what they mean.
Mesh flags entry would be added for a flags that applies to entire mesh not just a single group.
Mesh groups would be categorized either as 'static const' or 'dynamic'. oapiEditMeshGroup() can be used only in a 'dynamic' group, using it for a 'static' group would do nothing. Of course, 'static' mesh groups can be animated and manipulated via matrices, since these operations do not require altering vertex data in a buffer.
In a 'MSHX1' format all mesh groups are 'dynamic' as they have always been and the mesh would be rendered with DirectX7 compatibility shader by default with normal map support, self shadows, dynamic ambient light (i.e. Earth Glow). PBR shaders could be supported (unofficially) for a backwards compatibility if PBR textures are provided, but due to lack of PBR material definitions, mesh groups without texture would render with default material.
In a 'MSHX2' format all mesh groups are 'static' by default and must be flagged as 'dynamic' to gain access via oapiEditMeshGroup() if needed. All shaders supported. Build in mesh debugger will be able to convert and save 'MSHX1' meshes in 'MSHX2' format as well as manage and configure all mesh properties.
Animations
Incremental animations will be removed. There's been problems with drift, when animation state is frequently incremented from a previous state it will slowly lose it's position over time (sometimes in a few minutes). Also if animation state is altered in a wrong callback it could contribute in a drift. "Absolute animations" are always updated from a default state for every frame (no drift). But backwards compatibility is less than 100%.
Stock Vessels
There is a pull request for BakedVC and VC Lighting update. It contains a lot of changes those are not so well tested, therefore, it might be better not to merge it to main before the release of Orbiter 2024. There are no vessels using those features anyhow. After the release it would be great idea to give a graphics update for the stock vessels (DeltaGlider, Atlantis). Especially textures and meshes would need some work.
Graphics Options
Current graphics options are somewhat disorganized since some graphics settings are in the Options tab and other ones under the "Advanced" button. So, maybe moving all graphics options in the advanced panel would be good idea and then making that panel to open from the "Options" button.
Old Planetary Textures
If we can make a tool to convert old planetary textures into a new format (TileFormat 2) then we could cleanup the source code by discontinuing the support for old *.tex files.
Math Cleanup
Math routines are messy and need some cleaning up and standardization. As an preparation step for Vulkan translation plan is to decouple DirectX math libraries from the D3D9Client by using FVECTOR data types instead of D3DXVECTOR data types.
Other Things
virtual void clbkDestroyRenderWindow (bool fastclose) needs cleaning up, remove fastclose. clbkDestroyRenderWindow is called multiple times with different 'fastclose'
Module::clbkShutdown() callback is required for releasing resources, surfaces, fonts, etc...
Removal of the DirectX7 based renderer and DX7 compatibility requirements.
Those very awkward mesh configuration/override files in /Config/GC/ would be discontinued. (no support after Orbiter 2024)
Mesh Visibility Mode
There are known issues with mesh visibility flags and clipping distance. Documentation regarding the flags should be reviewed and solutions searched for the clipping. It would be possible to render the exterior mesh of the focus vessel using interior clipping distance, but if the focus vessel is docked to a station then the entire station should be rendered using interior clipping otherwise z-ordering/depth-buffer would fail to render the docking port correctly. If the clip distance is too short Z-fighting would occur. I guess this should be tested in a test configuration to see how short the distance can be until problems arise. There's an issue raised about this on GitHub https://github.com/orbitersim/orbiter/issues/363
New Mesh File Format
New mesh file format 'MSHX2' would be added to address several issues. The overall layout of the format would be identical to 'MSHX1' format which, of course, will remain supported.
Right now there is no way to explicitly identify Virtual Cockpit mesh from the rest which is required for rendering VC shadows and other interior effects. New entry is required to tell what the mesh actually is. Also the shader that's required for rendering the mesh need to be identified in a mesh file.
Mesh materials will depend on shader being used, so, material entries would be identified with "DIFFUSE", "SPECULAR", "SMOOTHNESS", etc, keywords to avoid mix-ups and to do sanity checks. Right now there's just an array of values with no ID what they mean.
Mesh flags entry would be added for a flags that applies to entire mesh not just a single group.
Mesh groups would be categorized either as 'static const' or 'dynamic'. oapiEditMeshGroup() can be used only in a 'dynamic' group, using it for a 'static' group would do nothing. Of course, 'static' mesh groups can be animated and manipulated via matrices, since these operations do not require altering vertex data in a buffer.
In a 'MSHX1' format all mesh groups are 'dynamic' as they have always been and the mesh would be rendered with DirectX7 compatibility shader by default with normal map support, self shadows, dynamic ambient light (i.e. Earth Glow). PBR shaders could be supported (unofficially) for a backwards compatibility if PBR textures are provided, but due to lack of PBR material definitions, mesh groups without texture would render with default material.
In a 'MSHX2' format all mesh groups are 'static' by default and must be flagged as 'dynamic' to gain access via oapiEditMeshGroup() if needed. All shaders supported. Build in mesh debugger will be able to convert and save 'MSHX1' meshes in 'MSHX2' format as well as manage and configure all mesh properties.
Animations
Incremental animations will be removed. There's been problems with drift, when animation state is frequently incremented from a previous state it will slowly lose it's position over time (sometimes in a few minutes). Also if animation state is altered in a wrong callback it could contribute in a drift. "Absolute animations" are always updated from a default state for every frame (no drift). But backwards compatibility is less than 100%.
Stock Vessels
There is a pull request for BakedVC and VC Lighting update. It contains a lot of changes those are not so well tested, therefore, it might be better not to merge it to main before the release of Orbiter 2024. There are no vessels using those features anyhow. After the release it would be great idea to give a graphics update for the stock vessels (DeltaGlider, Atlantis). Especially textures and meshes would need some work.
Graphics Options
Current graphics options are somewhat disorganized since some graphics settings are in the Options tab and other ones under the "Advanced" button. So, maybe moving all graphics options in the advanced panel would be good idea and then making that panel to open from the "Options" button.
Old Planetary Textures
If we can make a tool to convert old planetary textures into a new format (TileFormat 2) then we could cleanup the source code by discontinuing the support for old *.tex files.
Math Cleanup
Math routines are messy and need some cleaning up and standardization. As an preparation step for Vulkan translation plan is to decouple DirectX math libraries from the D3D9Client by using FVECTOR data types instead of D3DXVECTOR data types.
Other Things
virtual void clbkDestroyRenderWindow (bool fastclose) needs cleaning up, remove fastclose. clbkDestroyRenderWindow is called multiple times with different 'fastclose'
Module::clbkShutdown() callback is required for releasing resources, surfaces, fonts, etc...
Last edited: