I agree that it would be great to have such simple way to define new materials.
But because shaders are usually not defined very often, I think that it is worth investing a little bit more time to provide a fixed Effect and fixed Material implementation (instead of having a dynamic shader and material).
After that your application will be able to benefit from the the following advantages:
objects, then the code that sets up material is performance critical - ideally it is called 60 times per second for each object and for each material property.
But because one of the main purpose of Ab3d.DXEngine is to provide easy to use access to DirectX 11, I am planning to write a sample that will show how to use DirectX 11 Effects framework - this provides a way to have a more dynamic-like access to shader properties. I currently do not have time to do that but have that quite high on my DXEngine todo list.
You may also check some other opinion on advantages and disadvantages of using a more dynamic approach (with Effects library) vs. static approach (standard constant buffers) on the following discussion:
https://gamedev.stackexchange.com/questi...-framework
But because shaders are usually not defined very often, I think that it is worth investing a little bit more time to provide a fixed Effect and fixed Material implementation (instead of having a dynamic shader and material).
After that your application will be able to benefit from the the following advantages:
- Much better performance. Setting material properties on a fixed constant buffer (a struct that defines the data for DirectX shaders) is much faster then setting properties on a dynamically compiled shader where you need to use lookup tables to find each property. Also using standard properties is much much faster then using DependecyProperties.
- Faster initialization time - with using dynamic shaders, your application will need to first load the SharpDX.D3DCompiler assembly and a native compiler dll and then compile the hlsl code of the shaders. This will need to be done at each application startup. When using precompiled shaders the shader load times are much shorter.
- With using precompiled shaders and a fixed Effect class, you will not need to reference SharpDX.D3DCompiler and worry about the native d3dcompiler_47.dll library that will need to be deployed with your application (see comments in the ShaderFactors sample project in the ShaderBuilderWindow.xaml.cs file).
- Because almost all the classes that are used in WPF 3D are not extendable (the only exception is ModelVisual3D class), this means that it is not possible to define your own material classes and have a nice looking XAML. To provide custom materials and material properties you need to use some WPF tricks that are only possible in code behind (for example using SetValue method to add custom properties to WPF objects).
objects, then the code that sets up material is performance critical - ideally it is called 60 times per second for each object and for each material property.
But because one of the main purpose of Ab3d.DXEngine is to provide easy to use access to DirectX 11, I am planning to write a sample that will show how to use DirectX 11 Effects framework - this provides a way to have a more dynamic-like access to shader properties. I currently do not have time to do that but have that quite high on my DXEngine todo list.
You may also check some other opinion on advantages and disadvantages of using a more dynamic approach (with Effects library) vs. static approach (standard constant buffers) on the following discussion:
https://gamedev.stackexchange.com/questi...-framework
Andrej Benedik