Artists need an intuitive method for selecting materials found within plants; I came face-to-face with this challenge when selecting shapes for each component of my mushroom in my last video, wherein using dropdown lists with image tooltips proved insufficient as a solution.
An asset browser provides the optimal solution and Quixel Megascans provides an outstanding example to learn from.
Megascans' archive holds hundreds of materials and 3d models that artists can search quickly; its filtering tools offer them assistance when narrowing down their search process, so I plan to implement similar functionality for Bright Life as well.
Rebuilding Quixel Megascans
Establishing the interface for an asset browser can be done relatively simply; where things become trickier is creating individual items for browsing purposes.
Utilising some simple tricks of HTML, designing the user interface of each item was made relatively effortless. But to accurately categorise and filter them correctly, additional information was necessary; to meet that need I developed two custom metadata formats --one for meshes and materials-- to store this metadata information.
These files utilize a similar structure as Bright Life project files, enabling me to use Bright Life's existing loading system efficiently and save time. At launch, Bright Life will search out and process metafiles found for shapes and materials, creating Asset Browser Item entries with each one; then using each item's metadata filtering function instantly select only relevant entries; This improves Plant Shape Selection instantly!
Now that the Asset Browser is complete, artists need to access it within Bright Life itself. I developed a PropertyGrid editor as part of shape selection to replace my initial drop-down checklist; designing PropertyGrid editors takes some practice but eventually comes together.
Existing values for shape selections are passed onto the Asset Browser so it can pre-select shapes already being utilized by Bright Life users. Thanks to metadata files, no preloading of plant component meshes is needed; now Bright Life only loads assets when they're actually required; furthermore using Bright Engine's dynamic memory management system shapes that no longer make use of are removed from memory quickly resulting in faster load times and reduced RAM usage.
Launching the Material Browser from Bright Life editor was quick and effortless: just fill the material tab that was previously left empty until now with materials randomly assigned to components at random. Similar to how artists adjust individual parameters when creating plant geometry generation processes. Artists can select multiple materials which will be randomly allocated against target components.
Building a PBR Material System
Materials themselves can be divided into two distinct classes. The Standard Material class contains links to shaders and textures stored in Bright Engine Resource Manager; its counterpart, Smart Material class contains references back to Standard Materials that can be modified through Bright Life's Material Tab by artists themselves.
As part of my code base enhancements, I also developed three additional classes to better organize and access these materials across it all. PlantShapeLibrary and PlantMaterialLibrary classes store pointers to the metadata associated with meshes and materials as well as managing asset loading for their connected assets.
While adding another step may add complexity, this makes sure no data duplication exists in memory. Finally, we come to SmartMaterialManager: the third supplementary class responsible for creating and managing Smart Materials using information provided from PlantMaterialLibrary.
The SmartMaterialManager stores pointers to all active smart materials as well as its default material that's automatically applied to plant components that haven't been assigned a material by an artist.
Solving The Mipmapping Issue
Although adding materials wasn't too complicated, their implementation revealed an issue related to load speed. All 4K materials currently available through Bright Life were saved as PNG files as this format allowed for optimal compression resulting in relatively smaller file sizes on hard drives; however, choosing PNG format over mipmaps missed one key consideration that must be considered in any optimization solution - mipmappings.
Mipmaps are used in most textures within a game and function as optimised image sequences generated from original textures with each subsequent Mip halving in resolution; game engines use mipmaps dynamically changing resolution of textures in real-time using mipmaps as part of dynamic resolution scaling technology.
Assets far away from the camera don't usually require full detail; therefore a lower-level mipmap of high-resolution textures may be generated whenever they're loaded into memory to speed up rendering speeds and reduce rendering costs.
Generating mipmaps may not be difficult, but the time required can be extensive. Generating mipmaps for one 4k resolution material with seven PBR textures took nearly 30 seconds on its own - loading times for plant projects became extremely problematic until DirectDrawSurface format came along as a solution.
Though published over 25 years ago, Bright Life format still serves most game engines including Unity and Unreal Engine today. While its exact workings may be complicated, Bright Life stands out by providing pre-generated Mipmaps in texture files themselves to further decrease loading times per material by less than one second.
Performance was further improved by saving PBR textures as channel-packed images, rather than individual files per material. Roughness, ambient occlusion metallicity and height maps all use grayscale textures that could easily fit within red green blue alpha channels in one file for storage per material; this resulted in reduced I/O calls from CPU as well as texture binding events from GPU and thus significantly accelerated loading and render speeds respectively. To add another level of efficiency a PBR Shader was developed.
Once material selection is done and dusted, the next step should be building a fully functioning PBR shader. Bright Life previously utilized a basic color shader to display geometry within its viewport; whereas PBR shaders require much more complex implementation with regards to environmental data requirements as discussed previously in dev log videos in this series.
There are various approaches that Bright Life could take; each has their own advantages and drawbacks. Similar to Bright Engine, however, Bright Life uses roughness/metallic workflow rather than specular/gloss. This approach is more intuitive, while all colour values stored within an albedo map increase grayscale texture generation which opens more channel packing opportunities.
Artists will still be able to export materials compatible with both workflows. For those curious about physically-based rendering techniques, here are my choices of methods:
