- Joined
- Mar 28, 2008
- Messages
- 2,666
- Reaction score
- 795
- Points
- 128
I try to explain what's going on here. Also you should check the D3D9GraphicsGuide in /OrbiterSDK/Doc
First of all, the client is designed to run meshes and models created for the DX7 inline engine. Therefore, the way that the client will understand a Specular color is tied to a DX7 behavior. A Modern PBR pipelines do understand the specular slightly in a different way than a DX7. What a typical PBR pipelines mean by "Specular" is in our case called "Reflectivity" since the the word "Specular" is already reserved for compatibility. So, if you have a "Specular" texture map designed for modern PBR pipeline it should be assigned for D3D9Client as reflection map <*_refl.dds>
The second thing that should be noted is that "roughness" and "specular.power" are basically one and the same thing using a different scales. If you have a "roughness" texture map and you manipulate a specular power setting then it does create a confusion for the renderer of which one to use. This could explain the sudden jumps in appearance you have described.
Texture maps don't need to be the same size. So, if you have constant color "Reflectivity" you can simply assign 4x4 pixel miniature texture to a mesh containing the color you want.
First of all, the client is designed to run meshes and models created for the DX7 inline engine. Therefore, the way that the client will understand a Specular color is tied to a DX7 behavior. A Modern PBR pipelines do understand the specular slightly in a different way than a DX7. What a typical PBR pipelines mean by "Specular" is in our case called "Reflectivity" since the the word "Specular" is already reserved for compatibility. So, if you have a "Specular" texture map designed for modern PBR pipeline it should be assigned for D3D9Client as reflection map <*_refl.dds>
The second thing that should be noted is that "roughness" and "specular.power" are basically one and the same thing using a different scales. If you have a "roughness" texture map and you manipulate a specular power setting then it does create a confusion for the renderer of which one to use. This could explain the sudden jumps in appearance you have described.
I would also prefer for the configurations to be tied to a mesh like <mesh_name>.cfg but the problem is that the client doesn't always get the file name for a meshes. If a mesh is load using oapiLoadMeshGlobal() then a client does get the file name but if oapiLoadMesh() is used instead then the name isn't forwarded for a client. About 50% of addons use the first one and another 50% the second one. The lack of mesh file name has been a show-stopper for some features we have planned. In a case when we don't have the name we need to rely on vessel class name and mesh index. That's not exactly very reliable.But the problem is a bit that I would really like to have those materials applied by mesh, not by vessel, since the mesh might appear in multiple vessels.
Texture maps don't need to be the same size. So, if you have constant color "Reflectivity" you can simply assign 4x4 pixel miniature texture to a mesh containing the color you want.
Yes, texture map and additional D3D9 specific configuration will override settings from a mesh file. That should apply everything including "Diffuse", "Ambient", "Emission" material properties.the PBR shader ignores the orbiter .msh settings and either takes the values from the cfg file or from the maps. Which would be a bit confusing, because it totally does respect the diffuse and ambient color settings. Is this intended behaviour?