Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

ArnoAtWork

Shaders.

This topic is 5636 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am currently developping an engine. In this I would like to support all type of shaders. So, I was thinking about shader as a module able to be changed quickly and easily. I really think that using a vertex shader or vertex program could be the easiest way. In fact, the shader is like a script and so I will be able to edit it, change it, ... But using vertex shader for simple thing such as camera transformation and simple lighting calculation, is it as quick as using normal pipeline? You will say me if I am right, but the best way(and the more supported one) to use vertex shader is to code in assembler rather than using Cg? Thanks a lot. Arno. [edited by - arnoatwork on April 18, 2003 8:21:47 AM]

Share this post


Link to post
Share on other sites
Advertisement
Definitely go ahead with Cg or HLSL. The inefficiencies of letting a compiler generate the code are far outweight by the ease of tweaking and experimenting with the shaders.

There''s nothing unsupported about Cg. Compile the shaders as part of the build process, then ship with the compiled VSH/PSH files, or use the runtime, link with the Cg lib and compile on startup.

For almost all purposes, the difference in speed between the fixed function pipeline and an equivalent shader is negligible; on NVIDIA chips there is a slight advantage to the fixed function pipeline when you have many lights configured.

On DX9 level hardware (such as the 9600s and 5200s many of us would be running in a few months) the fixed function pipeline is emulated with shaders anyway.

Share this post


Link to post
Share on other sites
Sounds like you''ve got the idea; Quake 3 style shaders are basically texture scripts. A lot of people seem to miss that point. To avoid confusion, you might want to call them materials (it''s more of an appropriate term anyways). The way I handled vertex shaders in my engine was like this.

A material would just have a ''inlined'' shader call, like this:


  
ShipTexture1
{
VertexShaderBin "Data/VShader.vsh"

OR

VertexShaderTxt
{
vs 1.0
mul r0, etc...
}

OR
VertexShaderTxt "Data/VShader.txt"

Pass
{
Texture "Data/ShipTexture.png"
NormalMap "Data/ShipTexture_n.png"
}
}


So I used the vertex shader to modify an entire material and all it''s pass''s, and I could either put the vertex shader text right in there, link to another filewith the vshader text, or load an already compiled binary vshader file, which is what happens to the other ones anyways. The code is also smart enough to see that I have the normal map in the first pass, so it''ll try to use multitexture but if it can''t it''ll break down the pass into two passes as a pre-process.

"Love all, trust a few. Do wrong to none." - Shakespeare

Dirge - Aurelio Reis
www.CodeFortress.com
Current Causes:
Nissan sues Nissan

Share this post


Link to post
Share on other sites
It's also a fairly good idea to use a scripting language of some sort (Lua, Python, whatever) that will have access to the games objects. The reason for that is that most shaders require input and it's generally not a good idea to hardcode the functions that generate it into your code. As long as shaders are kept apart from the main code it seems reasonable to keep the functions that support them at the same level. Scripting languages provide a good way to write these functions and keep them together with the rest of the shader code.

EDIT: Dirge brought up a very good point: Quake 3 shaders are simply material scripts. I really don't know why they called them shaders...

[edited by - CoffeeMug on April 19, 2003 3:57:47 AM]

Share this post


Link to post
Share on other sites
I see much better how I have to develop my engine. It''s obvious in fact that using shaders separatly of the engine is really nice.

I never used any scripting language and so, I don''t really understand the point of using scripts to "interface" between shaders and objects. Could you give me a brief example.

Thanks a lot.

Have a nice weekend.

Arno.

Share this post


Link to post
Share on other sites
It''s fairly simple. Imagine you have a vertex shader that twists a cube to a certain degree. The degree to which you need to twist it is a parameter to the vertex shader. Suppose in your game this degree is determined by the power of the explosion. Now, you do a script like this this:

  
model Cube
{
VertexShader
{
// the source code of the shader

}
Parameter: GetTwistDegree()
}


Now, consider GetTwistDegree(). This function calculates the parameter for the vertex shader by examining the explosion. How are you going to accomplish that? One way is to put GetTwistDegree() into your game code. Then you sort of loose the point of keeping the vertex shader outside the game code. It would be nice of all supportive functions would be kept in the same place with the vertex shader. This is where a scripting language comes in. You could use it to calculate the parameter like this:

  
model Cube
{
VertexShader
{
// the source code of the shader

}
Parameter: GetTwistDegree()
{
// Scripting language code

return 1.0f - Explosion.GetStrength();
}
}


As you can see you just embed the code into your material. Nice and simple. As the shader changes, you can also add/remove/modify the functions that provide its parameters. The functions also interface with your game''s objects (in this case Explosion). That''s all there is to it

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!