Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Materials architecture - current issues and some ideas #65

Open
pigiuz opened this issue Jun 23, 2011 · 0 comments
Open

Materials architecture - current issues and some ideas #65

pigiuz opened this issue Jun 23, 2011 · 0 comments

Comments

@pigiuz
Copy link

pigiuz commented Jun 23, 2011

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant