Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Default vertex/fragment shaders.

  1. #1
    Member Newbie
    Join Date
    Mar 2008
    Posts
    32

    Default vertex/fragment shaders.

    I am learning how to use vertex and fragment shaders. In a program I'm writing now, I want to have all the default functionality except I want to modify one small thing in the vertex and fragment shaders.

    Unfortunately, of course, using a vertex and fragment shader means you have to reimplement everything the graphics card normally does.

    So... does anybody know where I can find vertex and fragment shaders that do everything the graphics card normally does? It's frustrating because, for example, I still want lighting to work as normal in my application, and I am not interested in learning about the intricacies of lighting and material calculations right now -- and what I'm doing has absolutely nothing to do with lighting or materials. However, I need it to work. Same with textures (esp. multitexturing), fog, all that stuff. I don't want to sit here and attempt to reimplement everything that, say, GL_ARB_multitexture already does -- and then also have to test to make sure it's identical to the original functionality (heck, I'm having a hard enough time just finding out what the original functionality actually is, let alone implementing it in GLSL, which I just started learning about 4 hours ago).

    Thanks,
    Jason

  2. #2
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,574

    Re: Default vertex/fragment shaders.

    For this there was this GLSL ShaderGen tool from 3Dlabs, but apparently they removed it from their website.

    It allows to select your fixed function elements, generate the emulating GLSL code, and see the result. You can even edit the GLSL code and test the changes. Is is said to be "educational" and not for performance though.

    As the license allows its redistribution in unmodified binary form, I will try to make it available.
    I don't have the original installer, but it should be fine.

    Here it is :
    http://dl.free.fr/onatV6lt8/GLSLShaderGen.zip

  3. #3
    Member Contributor
    Join Date
    Feb 2005
    Posts
    90

    Re: Default vertex/fragment shaders.

    Hi,

    The author can be found at http://www.prideout.net/index.html .
    Try emailing him for the 3D programs he did for 3DLabs.

    Ido

  4. #4
    Member Newbie
    Join Date
    Mar 2008
    Posts
    32

    Re: Default vertex/fragment shaders.

    Thanks for the link ZbuffeR. I am playing around with that program now and I am noticing two things:

    1) You have to have a different set of shaders for every combination of glEnable/glDisable/etc. features you use...? Is this always the case? For example, changing the texgen mode isn't supported in the shaders it generates -- you have to pick the one you are going to use and then regenerate the GLSL code that emulates the options you set. So if I wanted to use some shaders in an application that uses two different texgen modes, do I have to have to separate shaders one for each mode, and maintain two copies of my own modifications...?

    2) Lighting doesn't seem to work quite right in the generated shaders. Specifically, only light 0 seems to work, and it's a little brighter than the fixed functionality mode one.

    There has got to be an easier way to deal with this stuff. The reason I assume there must be an easier way is there is virtually no Google results searching for default implementations or related information, very few forum posts regarding this, and the GLSL ShaderGen program was removed from the 3DLabs web site. If it was a common problem, you'd expect many solutions to exist. And if ShaderGen was a commonly used tool, you'd expect it to still be there and maintained. I feel like I am missing something -- it seems like nobody has this problem except me and maybe a very small handful of others. How do other people manage to write small shader programs for use in applications that use a lot of OpenGL features? Does everybody somehow just, know exactly how to reimplement everything the card already does for them? This doesn't make any sense to me...

    I've contacted the author of ShaderGen about the issues with that program at least, if I get some more info I'll post it here.

    Thanks,
    Jason

  5. #5
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,574

    Re: Default vertex/fragment shaders.

    1) that is almost the way it worked with the old fixed GL. You enabled/disabled some hardware paths. Now you select the shader you use. Another way is to have an "uber shader" that computes everying but some parts have zero contribution depending on what you "enable". Real dynamic branching is only effective on the latest hardware, and for quite large chunks of the code, that is why it is often preferable to switch the shader. You can decompose a shader in common and specific parts, and assemble your different combinations at runtime, it is easier to maintain.

    Another thing is that most of the time you will only need a small subset of the complete fixed GL spec.

    And something even more important : a lot of stuff will be done done in the pixel shader and very differently. You can now do fresnel shading, refraction, parallax bump maps, procedural shading, etc etc.

    2) for me (win2000 Geforce6800 forceware 163.44) all lights (and everyng else in fact) works and produce perfectly equivalent results compared to fixed point, at least within 1% precision, tested with my bare eyes and this line at the end of the fragment shader :
    gl_FragColor = color+0.01; // I see this difference

    Don't forget to "build" when you change the GL settings, and when you customize the shader, use "compile" then "link" to see the result.

  6. #6
    Member Newbie
    Join Date
    Mar 2008
    Posts
    32

    Re: Default vertex/fragment shaders.

    1) That seems ridiculous. So you are saying that, for example, if I have an application, perhaps a 3D model editor where a user can enable/disable lighting, two-sided lighting, culling, and texturing, per object on the screen (or whatever features that the shaders take care of), I have to either:

    A) Prepare 2*2*2*2 = 16 (or whatever, 2^number_of_things_i_enable) separate programs each with every possible combination of things I want to do, and switch based on current settings rather than simply using glEnable/glDisable as I do now, and as I render objects in my scene, continuously check large combinations of settings and switch to the appropriate programs, or

    B) Define each "feature" as a separate program, losing any possible optimizations I could make *across* features (since they're all implemented as modular, separate programs), and linking each one on the fly as I render (so relink an entire fragment program rather than simply glDisable(GL_LIGHTING)). I suspect glDisable(GL_TEXTURE_2D) is *slightly* faster than relinking and switching fragment programs but I may be wrong.

    Those are my only options? And that's not just difficult with the example I gave, let's say I'm trying to make a nice library of code that can use, perhaps a depth peeling library with fragment shaders for support and I want to be able to use it in any situation -- that is impossible unless I come up with a separate shader program for every single one of the thousands of possible combinations of GL states that any application using my library is likely to use?

    Furthermore, do shaders -not- give access to current glEnable/glDisable states? Does that mean that I -have- to use, say, my own uniform variables to "enable" and "disable" things, and so if I have an existing application with a lot of rendering stuff going on that I want to add some shader functionality to, I have to then go back and rework the entire application to use my own custom enable/disable things?

    If I write my own fragment shader can I no longer use OpenGL's texturing API, like glTexImage2D? Do I now have to reimplement that all myself with some kind of uniform sampler variables or something?

    Another question I have is: Have you ever been able to reuse a shader program in two different applications? It's looking like every time I want to do a small thing, I have to code up a new GLSL program specifically optimized for that application. Do I want lighting support? Do I want multitexturing (and good bye ARB_multitexture convenience)?

    Was ARB_vertex_shader and ARB_fragment_shader designed with only large teams of programmers with the resources to work on large applications in mind? Is it intentional that it takes 60 hours of coding and research and a thousand lines of shader code for one person to implement even the most trivial new feature (like emulating the sadly forgotten EXT_paletted_texture or something)?

    2) I did "build", the lights do not work. This is WinXP with an ATI Mobility Radeon X1400, I'm not sure which driver version (not at that machine right now) -- it's the last version I got via Windows Update, but I'm sure it's newer than the last revision of this software (which was around Dec. 2005-ish).

    In general: Is it possible to use small vertex and fragment programs conveniently? Or will using them always add a weeks worth of work, testing, and general hassle to any application development? Every site you see with examples of some interesting thing you can do with shaders shows a small bit of example code, but unfortunately leaves out the 200000 lines of code you need just to bring the rest of the functionality back up to ground level.

    Thanks...
    Jason

    P.S. When new extensions come out do you start seeing forum posts with people scrambling for GLSL code, like "does anybody have a shader program to reimplement the possibly proprietary and highly-complex, extensively researched EXT_some_great_texturing_extension (or whatever) that just came out?" Are people relying on shader programs for certain features unable to use certain new built-in GL features that may come out without reimplementing them all on their own?

  7. #7
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,574

    Re: Default vertex/fragment shaders.

    First, calm down a bit.
    Then, take some time to read "OpenGL Shading Language (2nd Edition)" aka "The Orange Book" http://www.3dshaders.com/ to get more of the big picture about shaders.
    For example you will see that multitexture with GLSL is very simple. And I am glad I went directly from single texture to GLSL, skipping the whole clunky register combiners/crossbar etc

    I am pretty sure it is not possible to get proper video drivers via windows update, instead try the ATI/AMD driver directly from their website. And mobile cards are even more of a pain. But something like that may help :
    http://game.amd.com/us-en/drivers_ca...xp/mobility-xp


    Edit: and on 3dshaders you have the GLSL ShaderGen source code this may help you.

    Edit2: re your PS : you get it backwards. New GL extensions either extend GLSL, or are orthogonal (like floating points textures).
    The only case of "GLSL implemented replacement" I am aware of is to support PCF shadows an ATI, whereas it is an automatic feature on Nvidia.

  8. #8
    Member Newbie
    Join Date
    Mar 2008
    Posts
    32

    Re: Default vertex/fragment shaders.

    Quote Originally Posted by ZbuffeR
    First, calm down a bit.
    No. I will not calm down. I hate new things. In fact, I strongly believe that vertex_shader and fragment_shader should be moved to a new extension category, WTF, creating WTF_vertex_shader and WTF_fragment_shader.

    Then, take some time to read "OpenGL Shading Language (2nd Edition)" aka "The Orange Book" http://www.3dshaders.com/ to get more of the big picture about shaders.
    I think that this stuff is way more difficult than it needs to be but, I will keep an open mind, and work on that book over the next few days. Thanks for that link, I was actually just wondering why none of the 3DLabs developer stuff was around but it's nice to see that it's still alive somewhere.

    I am pretty sure it is not possible to get proper video drivers via windows update, instead try the ATI/AMD driver directly from their website. And mobile cards are even more of a pain. But something like that may help :
    http://game.amd.com/us-en/drivers_ca...xp/mobility-xp
    Thanks once again for a helpful link. I do have the latest version of the drivers, but I'm still having a problem with ShaderGen. Maybe you can figure out what is going on here. So here are the steps to reproduce the problem I'm having:

    1. Start up ShaderGen.
    2. In "Light" tab disable L0 and L2, so only L1 is enabled. Leave all other settings at initial defaults.
    3. "Build".


    When I do that, fixed functionality mode has the default red L1, but equivalent shader mode uses the diffuse color and light position (and other light parameters) of L0 instead of L1 (producing a yellow light, at the wrong location, for L1). I get the same results when I use L2. However, I am able to "fix" this by editing the generated vertex shader -- in the pointLight() function, if I replace all occurences of [ i] with [1] (or [2] for L2), it works! For example, changing the Diffuse calculation to:

    Code :
    Diffuse += gl_LightSource[1].diffuse * nDotVP * attenuation;

    Correctly uses L1's diffuse color rather than L0's. This seems strange to me because it looks like pointLight() is indeed being passed the correct index down in flight():

    Code :
    pointLight(1, normal, eye, ecPosition3);

    But it gets weirder. I did some further investigation. Using L1 and the default generated vertex program, I added this debugging code to the very end of pointLight() as a sanity check:

    Code :
    if (i==0)
      Diffuse = vec4(1,0,0,1);
    else if (i==1)
      Diffuse = vec4(0,1,0,1);

    So if i is 0 it makes the object red, and if it's 1 it makes the object green. Since it seems to be using index 0 regardless of the value of i passed to the function, I expected the output to be red. Well, when pointLight(1, ...) is called, lo and behold, it's green. So it knows i is 1... yet it still uses [0] when i is used to index the lights array! WTF[_vertex_shader] is going on?

    It's really weird. I also tried renaming "i" to something else ("iii" in my case) just for grins, but that didn't help. Is there some strange syntax problem with the generated vertex program?

    Anyways, I got the source code, maybe I will try to make a Linux port some day, too (I dual boot Linux/Windows on my laptop, am developing an application in Linux but all the useful tools are for Windows, I can't count how many times I've had to reboot in the last 2 days messing around with all this stuff).

    Jason

  9. #9
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,574

    Re: Default vertex/fragment shaders.

    Well strange indeed.

    About the tools running only on windows, you can try to run directly the binary through wine, it works surprisingly well.

  10. #10
    Senior Member Frequent Contributor
    Join Date
    May 2006
    Posts
    701

    Re: Default vertex/fragment shaders.

    Quote Originally Posted by JCipriani2
    There has got to be an easier way to deal with this stuff. The reason I assume there must be an easier way is there is virtually no Google results searching for default implementations or related information, very few forum posts regarding this, and the GLSL ShaderGen program was removed from the 3DLabs web site. If it was a common problem, you'd expect many solutions to exist.
    I think you're missing the obvious: it isn't a common problem because few people want to do this.

    Most people use shaders to implement their own material/lighting model. This flexibility is what shaders are all about. They're not interested in OpenGL's inflexible and dated fixed function lighting and texturing.
    Georg Kolling, Imagination Technologies
    Please ask questions specific to PowerVR hardware or SDKs on the PowerVR Insider Forum
    DevTech@imgtec.com | http://www.powervrinsider.com

Page 1 of 3 123 LastLast

Similar Threads

  1. Transformation between vertex and fragment shaders
    By RedSonja in forum OpenGL: Advanced Coding
    Replies: 2
    Last Post: 03-15-2010, 11:47 AM
  2. GLSL: Default GL Fragment and Vertex Shader
    By Loicus in forum OpenGL: GLSL
    Replies: 2
    Last Post: 12-12-2009, 07:41 AM
  3. vertex and fragment shaders in same file
    By RS in forum OpenGL: General
    Replies: 15
    Last Post: 03-15-2007, 12:36 PM
  4. Texture mapping w/vertex & fragment shaders
    By Mr. HDTV in forum OpenGL: Advanced Coding
    Replies: 8
    Last Post: 11-19-2002, 12:28 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean