Jump to content
  • Advertisement

Archived

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

Android_s

Quake3-style shaders

This topic is 5278 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

Hi there! This may be a very stupid question, but i feel completely out of options. Anyway, i try to make some simple use of the quake3 shaders for my yet simpler bsp viewer. Frankly, i just bother about the blendFunc params in the .shader file. I have made a small parser-function to do this and it seems to work out nicely (well..beeing so simple as it is and that much of a quick hack, it should...). My questions is how on earth i should go about to bind the shader data to the texture that will be blended? I have tinkered around a while trying to get it to work but it all ends up in me tearing my hear of. I don''t even know where to start anymore... Is there anyone of you that have made something similar or have any suggestions? And please, try to keep it a bit simple I started this project to see if i actually could made it. I would think i have got far, beeing able to load that darn map and get lightmap and stuff to work, but at the moment it feels like in the end i will burn my hands...burn them good! But at least i have to try... Well...thanks in advance

Share this post


Link to post
Share on other sites
Advertisement
What API are you using? additionally... i dont think this belongs in the begginer forum... ill betcha half the people dont know what a shader is, try the ogl forum or the direct x forum depending on which API your using... if your rendering with a software renderer that you coded... try the game programming or the general programming, I do believe i can help you, but only if its direct x, im unfamiliar with openGL
-Dan

Share this post


Link to post
Share on other sites
I''m not sure if this is exactly what you''re after, but here it goes:

I too wrote a q3-style shader management system for an old project of mine. Although this is not exactly how - the following is a very close description on how I did things. (Some optimization details are left out for clarity.)

I had a shader class and (for each shader read in) I had an object consisting of attributes for the entire shader. This shader class also had an array of "layers". Now each layer was essentially one texture plus it''s associated attributes.

The attributes for the shader were things that affected the shader as a whole: vertex animation, culling, polygon offset - anything that was common for all the textures. Each layer (essentially a texture) was blended one after the other - in the order they were defined. Every layer had blending attributes that said how to combine it with the previous layer.

In my system I identified shaders and textures with "handles". These handles were simply integer numbers that identified them. I first loaded the map, console, hud graphics etc but "simply" logged the names of the shaders. This allowed me to combine all references to the same names and thus to the same shader object and texture (once everything was set up). After all data had been loaded I then resolved these shader names by building the actual shaders themselves - I parsed the shader scripts. Once parsing was complete I then looked for references to shaders that had no script - I assumed they were actual textures and set up a generic one layer shader for each of those. After all shaders were set up, I finally loaded all the textures. This allowed me to load up each texture and apply any specific attribute to them such as "no mipmap".

During runtime, I selected the shader (as opposed to selecting a single texture) and then rendered the geometry. The trick was that I did not directly call the graphics api to render but rather called one generic subroutine to render the geometry. This routine looked at the shader and set up the required operations needed to render the geometry. Since the number of layers could vary between shaders, plus the number of texture units on the graphics card could also vary from machine to machine, this routine decided on how many passes to make with the given geometry. Some of this "folding" into a single pass was done upon shader load time as well (and is a good way to optimize the rendering code). This routine would only return once the pass(es) were completed on the geometry given.

The loading was surprisingly quick once I optimized it all - approx 560 physical files (including zip files) totalling approx 5500 files spanning about 860 meg (compressed) - was scanned in about 2 to 2.5 seconds on a P4 1.5Ghz system. The load time could have been further reduced but I was lazy and did not implement all optimizations I had planned. I mention this since it sounds like lots of overhead but I was pleasantly surprised by the results.

Some of the omitted details pertained to optimizations that minimized state changes - but this needs not be done in order to use shaders for what you described as a "simple" bsp viewer. I also left out the animation details but that could be introduced in the above setup as well.

I think (hope) that somewhere in that mess was the answer you were looking for.

Share this post


Link to post
Share on other sites
Thanks for the anwears!

JotDot: Thanks for the post! Now i have a few questions for you

First off, you wrote that you had an object consisting of every attribute for the entire shader. Do you with that mean you have variables for every param in a specific shader? (Like one for map, one for blendFunc...).

You also wrote that you read the shader names first. If i have understood you correctly you read the shader names and store the name with data in an array of for example a shader struct? Then you go through the textures and see if you have a match amongst the shader names, and if so you apply the correct data?

One thing that surprised me is that it sounds like you read the shaders first, then look in the shader data for the correct texture and then apply it. Or do you do it the other way around? That is read the textures, check for matches and apply data, and if no match render using a "shader" you have hard coded?


If i have understood you this seams like a neat way to do it. I must confess my "parser" is quite....quite ugly Not to mention it's limitations. Your method would open some new doors for me.

Is there perhaps some way to take a peak at your shader/rendering code and try to learn from it? It is essentially the method to bind the shader data to a texture and have it render correctly i am after. Make this thing work and enhance later

More questions will most likely come...

Thank you once more for the help. Much appreciated!

[edited by - Android_s on March 8, 2004 6:19:07 AM]

Share this post


Link to post
Share on other sites
Voodoo_john: If you have an idea how long i have searched for a site like that! I''ve just seen the "shader script tutorials"
Thanks man!

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!