Materials has too many dependencies and are not modular enough to ease the creation of custom materials.
When people is creating custom materials they're likely to be extending DefaultMaterialBase because it has built in useful properties (diffuse\specular\normals\etc are already there, no reason to reimplement them from scratch by extending MaterialBase). Further, they're likely to be creating a custom screenPass, however the screenpass is initialized within the constructor of DefaultMaterialBase and it's private, so it's not accessible from an extending class.
What i'd do in the short run is:
set all properties as protected (already submitted in another issue)
create a function "init" called by the constructor of each material starting from MaterialBase, which is in charge to initialize all the material passes
What I'd do in the long run is:
refactor the way materials are designed by using a more modular factory pattern.
I'd prefer materials to have a construction such as
the FactoryMaterial class is then retrieving the passes instances from a factory which can be relative to the current context3D.
Moreover, the factory should be retrieving the passes instances from a pool.
With this approach a user who want's to create a custom material is not going to extend an existing material but he's just writing the code he needs and he's composing a material with the classes provided by the framework.
Moreover the framework is still able to provide "shortcut" materials to the user by providing "prebuilt" materials with few parameters for a quick use (or for dumb users :)). I mean: BitmapMaterial(bitmapData : BitmapData,etc) should just be extending FactoryMaterial and passing in the constructor exactly the classes it's right now using and inheriting by DefaultMaterialBase.
I hope to have been clear :)
If you need some help I'll gladly help you, just ping me in twitter @pigiuz
Materials has too many dependencies and are not modular enough to ease the creation of custom materials.
When people is creating custom materials they're likely to be extending DefaultMaterialBase because it has built in useful properties (diffuse\specular\normals\etc are already there, no reason to reimplement them from scratch by extending MaterialBase). Further, they're likely to be creating a custom screenPass, however the screenpass is initialized within the constructor of DefaultMaterialBase and it's private, so it's not accessible from an extending class.
What i'd do in the short run is:
What I'd do in the long run is: refactor the way materials are designed by using a more modular factory pattern. I'd prefer materials to have a construction such as
new FactoryMaterial( [ DiffusePassClass, AmbientPassClass, WhateverPassClass ], [ [argForDiffuse], [argForAmbient,argForAmbient2], [argForWhatever] ] )
the FactoryMaterial class is then retrieving the passes instances from a factory which can be relative to the current context3D. Moreover, the factory should be retrieving the passes instances from a pool.
With this approach a user who want's to create a custom material is not going to extend an existing material but he's just writing the code he needs and he's composing a material with the classes provided by the framework. Moreover the framework is still able to provide "shortcut" materials to the user by providing "prebuilt" materials with few parameters for a quick use (or for dumb users :)). I mean: BitmapMaterial(bitmapData : BitmapData,etc) should just be extending FactoryMaterial and passing in the constructor exactly the classes it's right now using and inheriting by DefaultMaterialBase.
I hope to have been clear :)
If you need some help I'll gladly help you, just ping me in twitter @pigiuz