Aranuvir wrote:Since BI has gone, now (
Link), and we are rewriting our glcode, we should review our materials pipeline, too, I guess.
Yes. This will be a nice and natural byproduct of working over the opengl code.
As to pipelines, there have been any number of "special node set-ups" published by our artistic experts on this forum. I wonder if collecting links to as many of those posts as possible in one place would give us some ideas about PROPERTIES we need to support. I'm not convinced MH should support a whole node system. This is partly why Manuel moved back to being a Blender plugin when he started MBL. He hated the idea of code duplication and saw .mhx2 as becoming unnecessarily bloated by duplication of downstream function in MH itself.
Thomas upgraded from mhx to mhx2 precisely so MH creations could be imported into other downstream tools like Maya, Max, Unity, or Unreal with the help of custom importers. The idea was to create independence of the export and import process. I suppose we could take the approach of making a Blender plugin to Export node setups in some sort of node descriptor file that could be associated with MH material files and parsed by the Blender Importer or any other importer that would be written. Joel has taken a few steps toward creating direct transport layers communication in his one Blender plugin that avoids the need for a "saved file" altogether. This concept scales to multiple downstream apps as well. All this by way of saying, we need some thinking about natural breaks in the artists pipeline to make the creative process as seamless as possible.
Anyway, there is a lot to think about here. We need some thought about HOW to support advanced materials as well as thought about how to make those MATERIALS FLOW downstream in a seamless fashion to a variety of downstream apps.