Picking up where the last entry left off, I'll start with materials, and meshes.
The trend these days seems to be keeping vertex data to the absolute minimum. All the material surface details are supplied by multiple high-resolution textures. Of course these high-res textures won't fit in VRAM at the same time, so they need texture streaming. Of course they will take up a lot of space on disk, so they need custom compression schemes. Of course, at runtime you will need to transcode them to a GPU friendly format. Then you need servers to manage the really huge textures between multiple workstations. Version control, custom tools...
I say screw all that, and keep it simple. So for my materials, it will be a combination of texture and vertex data. The goal here is to get sufficient pixel density for my materials to look good, but not have several giant textures per object, and all the hell that approach would bring.
For the sake of efficiency, the engine will support RGBA8, DXT1, and DXT5 textures. The expected average texture resolutions for most objects will be 1024 x 1024, 512 x 512. Most textures will default to trilinear mipmap filtering, not giving artists control over this option.
Most objects/characters will be limited to an albedo map and a normal map, in order to cut down on texture memory. Shared detail maps will be used to provide greater pixel density, as well as specular variance across the surface.
Emissive and specular color/intensity will be will be provided per-mesh, per-texture layer. Emissive might benefit from a unique texture, but only when there are a lot of different colored sources all over the object. Otherwise it would end up with a high-res texture that is mostly filled with black, with only small spots of emissive. Specular color/intensity would be better with a unique texture, but can be approximated well enough with per-mesh specular and detail maps.
- float3, Position
- float3, Normal
- short4, Tangent
- uchar4, Detail texture masks
- uchar4, Directional Occlusion
- uchar4, Albedo tint color
I plan to split the data up into two interleaved arrays, one with dynamic data and the other with static data. I'm trying to figure out a scheme that would allow each to be 16-byte aligned. However, I think I will be fine with 32 and 16.
I believe I will be able to get away with using a normalized short type for my texcoords, but I am not sure about my tangents. I have considered using the half type for these two attributes. However, my plan is to perform animation on the CPU, so I am not sure it would really be worth the extra calculations.
The second array is all about material data, allowing an artist to control the distribution and color of detail maps per-mesh, per-vertex. Doing things like masking and occlussion per-vertex may seem old-fashioned, but it will drastically reduce VRAM usage. It also allows the values to be smoothly interpolated, even at higher screen resolutions.
That's all for now. Starting to sound intereting yet? ;)