-
Notifications
You must be signed in to change notification settings - Fork 67
Material and Instancing Model
Most X-Plane properties that should be adde to Blender materials are already present. Things that need to be added:
- Draped materials. This sets up draped geometry, which is sort of like polygon offset but cut to the ground. Draped materials also can use their own texture and essentially get their own complete material and shader state.
Note that a number of properties are --not-- available for a draped material: polygon offset, manipulators, panel texture, camera collision, hard surfaces, etc.
- Blend mode in X-Plane 10 has 3 states: blended, alpha tested with a cutoff, and shadow tested (with a cutoff). This last mode is alpha blended for drawing but alpha tested for shadow production and can be used to get correct shadow behavior with translucent "dirty" windows.
To be deprecated but kept for compatibility:
- Override specularity - I would like to have material properties live in only one place.
Finally, we need a clear mapping between properties supported in Blender and X-Plane:
- Specularity
- Bump height (draped only)
- Textures (albedo, emissive, normal + specular combined map)
- RGB tinting (emissive and diffuse) - ... can we deprecate these?
The export context is also mostly complete already. To be added:
- Instancing mode. When checked: -- Use of non-instance-friendly attributes and animation is an export fail. -- All supported attributes use global variant.
- When instancing is not checked, we never use global attributes when ATTR_ variant is possible. Instancing mode provides one-stop shopping for all instancing features - authors simply have to know whether they intend to use an object more than once.
- Add layer group for both object and draped material. Layer group consists of a group name and an offset.
- Add LOD max distance for draped layer.
To deprecate:
- Deprecate specific setup of global specularity and blending - these should be set by using instancing mode.
Auto-detect of textures from common material: the export context should be able to use the materials the user used - it is an export failure to try to export if too many textures are used.
Here is the proposed scheme for handing material texture assignments:
Albedo (4 channels - RBGA) Put map into blender’s <diffuse: basic color> channel
LIT (3 channels - RGB) Put map into blender’s <shading: emit> channel for export recognition. For previewing the LIT texture in the emit channel, the use alpha checkbox needs to be turned off so that it forces the use of only the RGB, otherwise it’ll blow out the LIT channel. Additionally, the LIT texture also needs to be tied to the <diffuse: basic color> channel for proper visualization. The plugin visualization slider will need to control the ratio of both channels simultaneously for the proper effect.
Normal (2 channels - RG) Author should create a standard tangential normal map Blender should read the standard RGB normal map in tangent space AND with the check box saying that “yes, I’m a normal map" Put map into blender’s <geometry: rendered normal> channel
Roughness (1 channel - channel assignment TBD) Put map into blender’s <specular: hardness> channel Author just needs to make a greyscale map for roughness OR author needs to assign a hardness value for the roughness channel within the material attributes. These need to be treated exclusively (you get one or the other, never both). The roughness map is without a doubt the most important of the texture maps and authors really need to make these maps and make them well. There are only a few cases where assigning a generic hardness value would be appropriate (a flat matte surface for example).
Reflectivity (1 channel - channel assignment TBD) Put map into blender’s <specular: specular reflectivity> channel Author just needs to make a greyscale map for reflectivity OR author needs to assign a value for reflectivity within the material attributes. These need to be treated exclusively.
The plugin ought to provide the author with a couple of material options that have the correct settings in place. Through the use of a set up wizard, we would be able to have the author select the texture maps and automatically have them placed into the correct texture channels (and ensure that the UV map selection is also correct). For aircraft authorship, 2 options would be necessary (one for opaque surfaces and one for glass / transparent surfaces). This will ensure that glass gets exported with alpha considerations and ordering considerations taken into account.
One material per object would still be necessary.
Through this process, it would also be possible to assign scenery materials (asphalt, water, grass, concrete, etc.)
Another plus point is that by having some default material sets for the authors, they can be ensured of a good preview (textured with normal mapping and LIT).
Preference is to have RGB tinting and emission tinting be hidden. They have no place in the default export environment. My personal preference is to be able to use RGB values when I'm modeling to color code pieces of the project. The current laminar scripts ignore these RGB values completely during export and I'd like the same behavior here (so that I don't have to go and change all of my color values back to 1.0 for the export). For legacy integration, there does need to be a checkbox to allow people to still use the RGB tinting features. The same goes for emission tinting.
Likewise, shininess ratios need to be completely ignored and not written into the obj file when there are texture maps being utilized in the roughness and reflectivity channels in favor of a global specular level set to 1.0 in the header of the obj file. (Specular hardness and specular reflectivity channels in blender UI). Let the texture maps do the work here.
Weights should be hidden by default as we're building the exporter to be able to automatically handle and optimize ordering. A checkbox can enable them if absolutely necessary. The bottom line is that we don't want to be confusing the authors with extra options that they generally will never need.
We ought to build in a tool that automatically combines shader map files (normal, reflectivity & roughness) on export. With up to 4 channels being used now, and it being critical that there are no alpha errors (try doing this in photoshop and you'll understand!), it makes better sense to let blender handle this through python. We will of course need a logic for how to handle missing channels. This will ensure that we eliminate authorship problems and that everything will be consistent with how x-plane expects it to be. This also gives us the ability to output the shader maps automatically as a dds file. As part of this new shader system, we may want to consider a new texture extension for the shader maps as part of determining legacy behavior within x-plane. How the sim handles legacy behavior still needs to be worked out.