First, we’re not going to get an OBJ materials model in 930. 930 is crammed full of stuff, and I don’t want to add anything more! I am not sure when we’ll get OBJ materials, or even if this is how it will go down. But this is what I am thinking:
- Materials will be controlled on the “batch” level, that is, by using ATTRibutes. You’ll be able to change materials mid-object.
- Materials will be grouped into “material classes” – the material class will be mutually exclusive. So if we have a metal material class and a “plastic” material class, you won’t be able to combine them.
- There will be some kind of material class that corresponds to the current behavior, and all of the existing attributes will keep working; probably there will be a newer, cleaner way to state in an OBJ what you can already do now.
- You will set all material class parameters at once. This simplifies the syntax and assures that we don’t have any strange mix & match combinations.
To this last point, consider that OBJ currently has a number of strange cases where you can set attributes that don’t have any effect. For example, you can set the shininess while drawing the cockpit texture (which is unlit). Code like this has historically been buggy, partly because it’s not necessarily obvious to a human reader what the object should do.
I do not yet know how normal and gloss maps fit in. Normal maps may be useful to multiple material classes; gloss maps are somewhat material class specific (in that if a material class has no concept of gloss, the gloss map is moot). It is definitely advantageous to pack a normal map and gloss map into a single texture (a la blender).
The main point of material classes is to create the infrastructure for complex extensions to the material system in a clean way. Adding additional attributes creates an NxN problem – for each new attribute I add, I have to consider how it interacts with every other attribute. By comparison, a new material class by definition shuts all other material classes off.
i would suggest a material system with parameters that come from physical renders as e.g. maxwell:
1. you can have multiple layers of materials
2. each material has texture slots for:
– color (great would be 2 color slots to achieve fresnel effects)
– roughness b/w: b=perfect mirror (maximum specular) w=lambert (no light bounces of, aka no specularity)
– transmittance/alpha: b=opaque, w=completely clear ,color adds tint
– bump: eighter a bumpmap b/w or a normalmap
multiple material layers should be able to be weighted. the result be normalized. that way you can do metals (only one material layer) and plastics (2 layers: first is a lambert that gives the color from colorslot e.g. red and the second layer is the coating that adds reflectivity (specular highlights in the color that is a result of colorslot of that layer and lightsource color, mixed by the roughnessvalue of this coating layer)
krz – er, don’t get your hopes up. Seriously, those are good ideas, but it is unlikely that at least the first material classes will be significantly more complex computationally than what we have now. That would imply not being able to double the number of materials per triangle.
Bump (by any method) would be a lovely touch.
ya i dont expect anything (i prefer to be surprised:), i just hope that the system you implement will be easy to extend. the way mentalray has to introduce new shaders with every release is horrible and i hope that other renders think about a futureproof implementation (by mimicking real world physical phenomena). e.g. mental ray had a shader with slots for specularity and reflectivity and surface roughness…but in reality all this three parameters are the same thing. (specularity is a fake, reflektion and reflection is controlled by the micro-roughness of the surface). i was just worried that you want to optimize the system too much (as you mentioned you maybe plan to bind the normalmap to a glossymap, and i think these two parameters dont have anything to to with each other)
Hi KRZ,
I should clarify something: we will _not_ be getting a material system like "brick" (e.g. small repeating textures that can be changed). We will not be getting multiple textures at all. Texture atlasing will _continue_ te be a requirement for making OBJs.
So I think that the issue of "do normal and bump maps belong together" is a little bit moot. You can't mix & match the textures because there aren't more than one texture to mix & match per object, so there is no loss of flexibility to combining a 3 channel normal map with a 1 channel gloss map. There is also not going to be independent UV map control for each texture.