🔒 Locked 🤖 Godot

Shader/Material system

Started by TheFallen Sep 17, 2005 at 12:58 PM 1 reply 850+ views

Original Post

Sep 17, 2005 at 12:58 PM

Hi, I am currently working on a shader/material system (based on OpenGL) similar to the Effects Files (.fx) of DirectX. My shader files are based on XML and look like this:


<shaderfile version="0.1">
  <shader name="test">
    <pass>
      <stage>
        <texture name="$T1" />
        <state name="BLEND" value="true" />
        <parameter name="BLENDFUNC_SRC" value="SRC_ALPHA" />
        <parameter name="BLENDFUNC_DEST" value="ONE" />
      </stage>
    </pass>
    <world matrix="$M1" />
  </shader>
</shaderfile>

This is a shader with one pass and one texture stage. $T1 and $M2 are variables, that can be set from within the application. For example:


shader.setTexture("T1", myTexture);
shader.setMatrix("M1", worldMatrix);

So the previous shader would be executed as (some pseudo code):


glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, loadTex(M1));
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE);
drawMe();

First at all: What do you think? Is this system flexible enough? Especially I don't really know if it's a problem, that every parameter can have only one value. That's why I have to split the glBlendFunc parameters into to parts. Would something like this be better?


<parameter name="BLENDFUNC" src="SRC_ALPHA" dest="ONE" />

But here I've got special cases for all the OpenGL functions that have more than one parameter... Future support for pixel/vertex programs is planned, and should look like this:


<shader name="test2">
  <pass>
    ...
    <program type="vertex">
      // some vertex program here
    </program>
  </pass>
</shader>

One more question: should a shader "unload" itself on exit? So should it change the states to some predefined values? Pro: outside a shader I do always have the same environment, so I could draw something outside a shader without checking every state, whether it has the correct value or not. Contra: This results in heavy state changing, especially when using the same shader twice, because at first the shader is unloaded and then loaded again. I think it would be better to provide some "standard shader", that you can load, for rendering "without a shader" (or avoid this at all). Opinions? Ideas? Suggestions for improvement? thx, fallen

python_regious

103

python_regious

Sep 17, 2005 at 1:46 PM

You might want to read this thread, and follow with the current shader discussion in this forum.

I implemented a similar system a couple of years ago (as in using texture environments), however not using XML. It worked really well, however you might want to add support for texture coordinate transformations, and things like texture transitions. In effect to bring it up to par with something like Q3 uses.

I'm not sure what "stage" means in your script however... I presume you mean you're using another texture environment? I'd use the second form for the blending function - however I don't think it matters per-se, as it's doing the same thing.

The shader should revert settings IMO. However, you can keep common settings between shaders (so, you batch draw calls using the same shader - and do the state changes once, and so on).

TheFallen

Author

TheFallen

Sep 17, 2005 at 2:00 PM

Thanks for your answer.

Quote:

I implemented a similar system a couple of years ago (as in using texture environments), however not using XML. It worked really well, however you might want to add support for texture coordinate transformations, and things like texture transitions. In effect to bring it up to par with something like Q3 uses.

I think a XML framework should be flexible enough to add some extra features later on. I've already written some small Q3 renderer a few years ago and one of my first goals is, that my shader system can handle all the effects Q3 can do, including texture coordinate transformation etc.

Quote:

I'm not sure what "stage" means in your script however... I presume you mean you're using another texture environment? I'd use the second form for the blending function - however I don't think it matters per-se, as it's doing the same thing.

"stage" just means the different textures in a multitexturing environment. So every stage is an extra texture for which you can set the blending options etc.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.