No announcement yet.

Material System

  • Filter
  • Time
  • Show
Clear All
new posts

    Material System

    Hi all!
    Few days ago between me and my friend were happened a discussion. Essence of it: I suggested to create the system of materials, proper the real models, and system of physical materials logically related to it. that would allow to create certain optimization, because all materials would be inherited from 10-20 master-materials, and also would drive all present now jumble to some system...

    For example:
    render: ferruginous metal
    polished metal
    physical property: metal

    render: natural wood
    polished wood
    physical property: wood

    and etc.

    Further, from these master-materials I would create material instances for all my graphical content.
    Opposite, my friend asserted that actually it is not necessary and in an Unreal Engine 3 it is possible for every model to create new material, with the unique tuning, and it will not affect performance and consumable resources.

    What is your opinion?


    That's what material instances are for. They bring some benefits over creating new materials 'per model':
    - Less materials means less shader compiling (changing MI doesn't force you to recompile material)

    - MIs are better in terms of performance
    -MIs allow to easily create multiple variants of master material with custom parameters (shiny or rusty metal surface etc)
    - Changing single Material automaticly propagates changes to all MAterial Instances that derive from that material

    So, Material Instances are quite cool solution and not using them would be much more problematic and possibly cause performance issues.


      Yeah, I understand this. But I need some proofs.


        The proof is in the pudding; how many games, (like UT3), have merrily employed the existing material shader and material instance system already?


          Material Instances are much cheaper than Materials. (memory wise)

          In fact you don't even need a master material per material type as material instances can set the physical material.

          In general you should make a single master material that handles most basic surfaces and use static switches to enable and disable parts of the shader as needed in the instances.

          From there it's most optimal to make one off custom materials for things like FX and other complex shader needs.

          - ook


            All, or most, because I don't know all of them, of game engines use material instances as the predefined and parametrized shaders. It's so since Q3A if I remember correctly. In UDK parametrization may be realtime (variables) on compiletime (macros).

            What UDK's material instances provide in the first place, is much better control over groups of similar materials - or materials that are share the same properties. Consider that, 90% of static geometry share the same features and thus it's easier to create a single master material and modify some of its properties using instances, than recreating the same master material for each object.

            If you need totally different properties for different models, it really doesn't matter if you use a single complex master material with tons of 'switch' parameters or separate materials.


              Two words about the performance, because I missed that part.

              You got two types of material parameters:

              1) those converted to variables (passed by app to/or between the vs/gs/ps) like for eg. vector3 param.

              Variables are always slower that constants. Therefore a heavy parametrized master material will be always slower that it's not parameterized constant version. This is why, you got the 'technique' thing in FX/CG shaders - to walkaround the lack of conditional compilation feature.

              2) those used in the shader compilation process - like for eg. the staticswitch param.

              Those parameters extend the number of master materials because each use creates additional material.