external shader compiler or monkey translator?

[adamredwoods]

choose which method to use.

[sascha-schmidt217]

Regarding monkey To glsl/hlsl/cg trans target:

I like the idea of being able to write shaders in monkey...
But I think, creating monkey targets for each shader platform is too much work, because
that would mean to maintain at least 5 targets(glsl/hlsl/hlslfx/cg/agal/..). Probably each with its own peculiarities.

A single cg target sounds more reasonable...

BTW: I make progress with the redevelopment of the render pipeline, And will probably
soon be able to run a cg shader test on all platforms. look forward To it :)
I'm gonna use a simple translation tool based on cg toolkit. Gonna plug it
into transcc for automagically shader creation..

Xna sucks again.
it forces you to HLSL effect, which means that you can not just use only cgc ... I'm still thinking if I should do that with monkey or prefer pure c + +

[sascha-schmidt217]

just wanted to link here also

http://blogs.unity3d.com/2010/07/17/unity-3-technology-surface-shaders/
http://docs.unity3d.com/Documentation/Components/SL-SurfaceShaderExamples.html

Writing shaders that interact with lighting is complex. There are different light types, different shadow options,
different rendering paths (forward and deferred rendering), and the shader should somehow handle all that
complexity.
Surface Shaders in Unity is a code generation approach that makes it much easier to write lit shaders than
using low level vertex/pixel shader programs. Note that there is no custom languages, magic or ninjas involved in
Surface Shaders; it just generates all the repetitive code that would have to be written by hand. You still write
shader code in Cg / HLSL.

I find this concept very promising.
It's simpler and more flexible than ordinary shader fragments...

What I have(not yet running) looks like this.

<shader name="diffuse_bump">

    <option fallback="diffuse_texture" 
                    lightmap="false" 
                    lighting="true" 
                    fog="true"/>

    <properties>
        float4 color;   
        Sampler2D colorMap;
        Sampler2D normalMap;
    </properties>

    <input>
        float2 uv0;
    </input>

    <surf>
        OUT.Albedo = tex2d(colorMap, IN.uv0) * color;
        OUT.Normal = UnpackNormal (tex2D (normalMap, IN.uv0));
    </surf>

</shader>

But I needed to design a completly shader driven renderpipline + common graphics interface(driver).
So, I plugged gles11 and xna_reach into 'fallback', because of the missig shader support...as kind of 'hard coded' TRender implementation.
The forward- and deferredrender implementations based on minib3d.driver using the same shaders...

• minib3d
  • driver
    • gles20
    • d3d11
    • xna_highdef
  • render
    • shader
    • forwardrender
    • deferredrender
    • fallback
      • gles11
      • xna_reach

I really whold like to have feedback for this approach. There are other approaches and I'd love to work out the pros and cons..

I wanted to have some runnable example at this point... but I was too lazy and did it probably somewhat underestimated...

edit:
I considered to use OpenGL ES 3.0, because it is backwards compatible with OpenGL ES 2.0 and otherwise offers some advantages(state objects/ uniform buffers /.. )

[adamredwoods]

http://www.altdevblogaday.com/2012/08/01/shader-generator/