Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: falcon2105 on February 17, 2009, 11:51:26 pm
-
Well this is kind of a continuation of http://www.hard-light.net/forums/index.php/topic,60430.0.html but I think I sort of solved my own problem and I wanted to know why or how. I figured out that some file in mv_core was causing the problem and narrowed it down to the files in the effects folder. So I went through one by one and added each file and checked if the lighting was fixed or not. So I finally got to two files, lbgsnh-f.sdr and lbn-f.sdr which when added make the lighting the type where full textures suddenly get way brighter and then suddenly stop being bright when a gun is fired near them. Without those files, most textures show the proper lighting, where the lighting on the texture reflects the position and color of whatever is near it. However I did notice that some textures show the other weird form of lighting. What are sdr files? What do those two mentioned above, and all the others in the mv_core file do? Thanks
Edit: Also, when I place only lbgsnh-f and lbn-f in the effects folder, fs2 crashed after loading the mission. All these trials are being done using derelict scp.
-
.sdr files are the GLSL shaders. You can figure out what each one provides with this little key:
- l - lighting enabled
- b - uses base/diffuse map
- g - glow map
- s - specular map
- n - normal map
- h - height map
- e - environment map
The -v files are vertex shaders, the -f files are fragment shaders.
I see from that other thread that you have an ATI card, which are currently known to have to lighting related issues with the shaders. One thing to try, if you are willing to be a test subject, is to try a new set of shaders that have a couple of lighting changes. Be sure to delete any .sdr files that you extracted and put in you data/effects folder, then download and extract http://icculus.org/~taylor/fso/misc/ma_shader.rar into the folder where you have your MediaVPs. See if that helps any, but just know it's possible that the new shader set might be even worse.
-
Ah cool, I'll give your new shaders a shot sometime soon. Lighting from beams and lasers falls under spec map right? So theoretically if i only add all the sdr files from mv_core that dont have an s in the name should my problem be somewhat solved? And what exactly do these new shaders do different from whatever was in the last mv release? Thanks again for the help.
-
Lighting from beams and lasers falls under spec map right? So theoretically if i only add all the sdr files from mv_core that dont have an s in the name should my problem be somewhat solved?
No, lighting would be any shader with a "l" in the name. The "s" ones let you take advantage of specular maps, which is definitely something that you want, and though it can make a difference in how lighting looks it merely changes aspects of it and shouldn't be related to your problem.
And what exactly do these new shaders do different from whatever was in the last mv release? Thanks again for the help.
They use an old technique I once had for doing the lights that should be more compatible and slightly faster. This was all tested early on in the development of the shader support and that method really didn't work out too well at the time. The lighting function in the shaders was significantly improved over time however, but I never went back to that old method to see if it worked any better. This new set simply changes how multiple lights are handled using that old method with the newer lighting function.
-
OK so I tried your other shaders, the ones you linked me to. Sadly they dont work and everything has the funky lighting effects. After I replaced w/e I had in the effects folder before I tried your shaders, i noticed that some ships have the proper lighting (I'm just looking at damage effects in the f3 lab thing), such as the fenris and the herc. However others do not, such as the artemis and the orion. I would just not include all the sdr files with an l in the name, but thats almost all of them, and I know that some of those files dont mess up the lighting. The non-borked lighting looks so amazing haha, i can't give up. Any more ideas? Or is my only choice to just continue going through each file and testing? And do any of the files interact with each other? For example, would having only file A not do something, only file B do something, but then having both Files A and B do something completely different? Thanks
-
I am working this issue out right now. I _think_ it is probably a case of mixed constants.
In other news, I am checking out the code to hopefully offer assistance in the direct application of OpenGL. And any further removal of DirectX if there is anything left at this point.
-
I'm definitely interested seeing how you go with this Zacam
-
falcon2105: from the related thread, you have everything on (with the exception of height which is un-needed).
This means only the following should be applicable:
lne-v.sdr, lbgsne-f.sdr.
(lbgsnhe-f, lbsne-f and lbsnhe-f are also linked to lne-v.sdr)
So, how the two above mentioned files are causing any issues is beyond me.
But no worries. I should, after additional testing, have something for you to try.
-
Double post FTW.
http://www.mediafire.com/?5n7bnd5y9jt
These are some new shaders in a VP file. If requested, I can offer a non-vp, but what would be the point?
So far, there is only 1 issue that I am aware of with the shaders: The Nameplates. However, unlike previous where any angle BUT straight on created the issue, now it only shows up from the bottom left and bottom right looking up at the nameplate. It has to do with the lighting passes, but I have tried numerous changes to the -f and -v files and the best I can do (without breaking ****) is mitigate the issue.
Oh, and taylor: While previous iterations of the mediavp shaders have probably been disappointing to you in terms of how they worked or were modified, I'd love any feedback you may have on these ones.
-
I can't get it to download for some reason (site error) so I'll try and grab them a bit later.
I think that the only shader revisions that I have disappointed with were my own. ;) What I released was always intended to just be a reference set, something that people/mods should modify to their own liking. The shaders I did were set up in a way that they should work with the least number of problems in all mods, but they aren't necessarily best suited for one data set in particular. I'm definitely interested to see what other people come up with as far as changes though. But as I've said before, every single line in the shaders I released was chosen for a specific reason. That reason was either to solve a problem, to work more efficiently on a wider range of hardware/drivers, and/or to address concerns by the content makes and testers.
The ones in the MediaVPs contain two main changes from what I released, but those aren't changes that I hadn't tried myself. The first change in the MVP versions is to deal with the conditional return, however the comparison creates a known performance hit with NVIDIA drivers. The ma_shader VP that I made fixes this to use an older style if() set up that, due to changes in the lighting function since I last tried this method, actually works now. That method is what was originally recommended in order to handle multiple lights in GLSL without resorting to a conditional return. The second change in the MVP versions is to the offset for the height maps. The original shaders I made during testing used the same value, but after playing around with it testers/artists preferred 0.02 instead so that is what was eventually settled on.
As far as the nameplate issue goes, I've mentioned before that it was always known. I just never could figure out a good way to address the problem without major code changes. Simply modifying the shaders never proved to be a good way to do it. Every single change that I made to fix the nameplates just ended up breaking something else (with SoL being the best place to test for those breaks). I just gave up and figured that the only way to actually fix the problem was with a material system.
-
Ok, the download finally worked. But going over the changes I don't really see any actual "changes". What I do see is: 1) some map stuff is moved around a little bit, which shouldn't do anything, 2) changed to normalize halfVec twice in the fragment shaders, 3) added a max() check to dotV, but it's already clamped to [0..1] so it will never be < 0 anyway. So, maybe I just missed it, but what is supposed to be in there besides a higher instruction count? ;)
-
By your compare, maybe not much. But compared to what was in the MediaVP's, a lot.
Instances of .rgb at the end being gone as a supposed fix: undone.
There are also a lot of consistency fixes in several files even in ma_shaders. In two or three cases, specLight= between some files was completely different.
vec3 halfV = normalize(halfVec) was pulled because in many files, halfV was only used once when it could have been used twice, though in some cases it was used three times instead of normalize(lightVec) being used to float diffuseLight (and I don't mean the float dotV). Speaking of which, vec3 lightVecNormalized = normalize(lightVec); was done away with due to A: Inconsistent usage and B: it really is not any shorter. lVecN would have been good, short and fast, but frankly, after setting the two above to long form, I did not notice either a rendering or FPS change that merited one over the other, So in the case where each is only used once, why make more text? Over all, it saves file space doing them this way.
The re-order took place because, while I can post no argument against whether it _should_ have any effect, the results says that it _does_ have an effect. At one point the bump sections got placed above ENV to make them work right. Given that many of them were using c_env = textureCube(sEnvmap, envReflect+(c_bump * lightVecNormalized)).rgb; and the lightVecNormalized was placed after the bump, it had no chance working where it was. c_env = textureCube(sEnvmap, envReflect).rgb; is the right way of doing it, but the move was already made, so I just laid it out logically: Normal Map is the detailing to the physical lines over which the base (diffuse) map is painted over. It sounds strange, but it seems to be the perceptive case that it does do something.
While many of what is detailed above was largely already present in the ma_shaders, they were not in the mediavp shaders, so try comparing those two some time. Even compared to what was supposed to be the final version for the patch shows a lot of changes.
And for all else, it was a training exercise in load the -v, fiddle with related -f's, don't break anything, and then make sure every thing works. So far it does. If you don't notice any difference in their use given what I know I have changed, then they are doing their job.
Now to see what falcon2105 says.
-
Yeah I'm hoping to see the results on a range of hardware now. I'll have to give it a shot myself, maybe with forced AA too :)
-
Sorry it took so long, I thought people had forgotten bout this thread and stopped checking for a while :D. I just tried those other shaders zacam posted but sadly they dont solve my problem. I don't know if it matters or can help you at all, but after more screwing around with the shaders from the core vp i isolated lbse-f, lbgse-f, lbgs-f, and lbgsne-f as files that when added with all the other shaders mess up my lighting. However if i put only them in the effects folder with none of the other shader files everything is fine. However i think i missed one file since lighting on the hecate and aeolus is still funky. If you want me to test anything else just let me know and ill be happy to help.
-
That is just bizarre. I'm a little stumped, but I'll look at it more this weekend.
It suggests to me that if those files themselves work just fine unless other files are present, that the issue may not be with those files specifically, but other files in relationship to them. Otherwise, it shouldn't work on those files if they were the broken ones.
Here is a test. Extract all the shaders from the VP I posted. Dump them in to the data/effects folder. Then remove all of the LFB*-f.sdr and LF*-v.sdr files. (Note the F). Tell me if you are still having a problem with the remaining shader files.
-
Well I tried your shaders after removing all LFB*-f.sdr and LF*-v.sdr files. Still had borked lighting. Then I put those back and removed the files that I mentioned in my previous post. Lighting was fixed for everything except the hecate and aeolus. And I started transcend since i started this thread (i don't know if that matters in its own right) but all of the extra ships that come with the mod had messed up lighting. Thanks for your help, but if this problem isn't gonna solve anything for anyone else you can stop trying :lol: since I'm sure you have other more important stuff to do, I wouldn't really care.
-
.sdr files are the GLSL shaders. You can figure out what each one provides with this little key:
- l - lighting enabled
- b - uses base/diffuse map
- g - glow map
- s - specular map
- n - normal map
- h - height map
- e - environment map
The -v files are vertex shaders, the -f files are fragment shaders.
Offtopic question:
Is this info in Wiki? I think it can be useful.
If it weren't, where should it go? (I don't mind adding it myself).
-
Thanks for your help, but if this problem isn't gonna solve anything for anyone else you can stop trying :lol: since I'm sure you have other more important stuff to do, I wouldn't really care.
I probably do have other more important stuff to do. And the state of the existing shaders on the whole is release ready. However, I still don't like that it is not working for somebody, and that I care about, so I am still going to work on it. And it may be possible that you are not the only one having this problem, but with the general difficulty of getting the shaders to work on the older ATi cards may mean that other people are not posting that they are. So, I am going to branch the shader development on my end until I can find a solution that works.
So, I'll see what my noggin comes up with. Thank you for trying in any case.
-
.sdr files are the GLSL shaders. You can figure out what each one provides with this little key:
- l - lighting enabled
- b - uses base/diffuse map
- g - glow map
- s - specular map
- n - normal map
- h - height map
- e - environment map
The -v files are vertex shaders, the -f files are fragment shaders.
Offtopic question:
Is this info in Wiki? I think it can be useful.
If it weren't, where should it go? (I don't mind adding it myself).
:nervous: :nervous: No answers?? :nervous: :nervous:
This is an ultimatum. If I don't get an answer before 24h, I'm gonna post it wherever I like, in Spanish (or better in Latin), with a lot of typos, written from right to left and using Greek or Cyrillic alphabet (or even better, a mixture of them).
HA, HA, HA, HA, ... (you ALL are doomed).
Signed: the Wiki avengerTM.
-
You could create a new page called GLSL Support or something and link to it from the Development Reference page (http://www.hard-light.net/wiki/index.php/Development_Reference).
-
You could create a new page called GLSL Support or something and link to it from the Development Reference page (http://www.hard-light.net/wiki/index.php/Development_Reference).
Done: OpenGL Shaders (GLSL) (http://www.hard-light.net/wiki/index.php/OpenGL_Shaders_(GLSL))
(I've also tweaked Command Line help. It didn't contain -normal, -height, -weapon_choice_3d, -no_glsl, ...)
-
Great job, lots of good info there. If you see any other place on the Wiki that should link to that article, don't hesitate to add it. I just picked the first one that made sense.
-
Made one minor correction: The coded number of supported shaders (ATM) is 66, not 67. The MediaVP shaders currently have a miscellaneous orphan file.
I also added 2 (General) Wiki links on defining Shaders and GLSL as well as the link to the OpenGL GLSL docs page.
I also added links for Shader Tools or Libraries by various Vendors that I could easily find. The list contains links to OpenGL Orgs own Shader Designer, nVidia's FX Composer, ATI's Render Monkey and recent ASHLI and Apples OS-X OpenGL stuff.
-
Made one minor correction: The coded number of supported shaders (ATM) is 66, not 67. The MediaVP shaders currently have a miscellaneous orphan file.
I also added 2 (General) Wiki links on defining Shaders and GLSL as well as the link to the OpenGL GLSL docs page.
I also added links for Shader Tools or Libraries by various Vendors that I could easily find. The list contains links to OpenGL Orgs own Shader Designer, nVidia's FX Composer, ATI's Render Monkey and recent ASHLI and Apples OS-X OpenGL stuff.
:yes: :yes:
Hey, guys feel free to MODIFY the whole page if you want. I can assure that you do know more than me about shaders (it doesn't matter how little you know ;) )
-
Why are there no l-f.sdr and lf-f.sdr in use when there are l-v.sdr and lf-v.sdr files?
Why are the vertex shaders for which no fragment shaders can be created? If I create such files their outputs are ignored. What gives?
-
Why are there no l-f.sdr and lf-f.sdr in use when there are l-v.sdr and lf-v.sdr files?
Because l-f and lf-f wouldn't have any maps attached. In such a case there is the null-f.sdr which is used instead and only applies shading. But that should only ever happen in the lab, never in a mission (unless the model is b0rked), so a fog version isn't needed.
Why are the vertex shaders for which no fragment shaders can be created? If I create such files their outputs are ignored. What gives?
All of them are paired up by functionality and hard-coded in the exe. You can only modify what's there, not create anything new, unless code changes are made. And any changes that you do make to the shaders need to still fit in with the functionality assigned to that pair of shaders or else it won't work properly.
-
Why are there no l-f.sdr and lf-f.sdr in use when there are l-v.sdr and lf-v.sdr files?
Because l-f and lf-f wouldn't have any maps attached. In such a case there is the null-f.sdr which is used instead and only applies shading. But that should only ever happen in the lab, never in a mission (unless the model is b0rked), so a fog version isn't needed.
IN that case the pair should be lb-v.sdr and lb-f.sdr instead of l-v.sdr and lb-f.sdr as right now. That is confusing.
-
IN that case the pair should be lb-v.sdr and lb-f.sdr instead of l-v.sdr and lb-f.sdr as right now.
The "b" indicator says that it's for a base (diffuse) map, which the vertex shader doesn't care about. In the case you specify l-v.sdr and lb-v.sdr would be exactly the same, line for line. It would be a complete waste and duplicate code needlessly, and there is already more than enough code duplication in there already.
Like I mentioned, it is paired up by functionality. The vertex shaders are: null-v, which offers color/shading only; l*-v, which offers lighting; *e-v, which adds the env translation matrix; *n-v, which provides access to the tangent space data needed for normal maps; *f-v, which gives you fog support. And the pairing is based on what the fragment shader needs. So, the only special thing that lbgs-f needs is lighting, which means it only has to be paired up with l-v. But lbgse-f needs envmap support too, so it is paired up with le-v which has access to the env translation matrix.
-
Like I mentioned, it is paired up by functionality. The vertex shaders are: null-v, which offers color/shading only; l*-v, which offers lighting; *e-v, which adds the env translation matrix; *n-v, which provides access to the tangent space data needed for normal maps; *f-v, which gives you fog support. And the pairing is based on what the fragment shader needs. So, the only special thing that lbgs-f needs is lighting, which means it only has to be paired up with l-v. But lbgse-f needs envmap support too, so it is paired up with le-v which has access to the env translation matrix.
Mercilessly plagiarized to wiki: http://www.hard-light.net/wiki/index.php/OpenGL_Shaders_(GLSL)#Description_of_shaders :p
EDITED:
I've checked the used letter order in the Mediavp shader set and I've ordered the Wiki shader letters too. (I mean that you have lb shaders but not bl ones). Please check that it's OK.
OTOH, I've just noticed that there are no env shaders without spec. I've also checked in game (F3 lab) and indeed it seems that env is switched off whenever spec is off, (in both GLSL and legacy). Am I right? (I ask this in order to update Wiki -env help with a comment about needing -spec).
-
OTOH, I've just noticed that there are no env shaders without spec. I've also checked in game (F3 lab) and indeed it seems that env is switched off whenever spec is off, (in both GLSL and legacy). Am I right? (I ask this in order to update Wiki -env help with a comment about needing -spec).
Correct. The env map is modulated against the spec map, so if there was no spec map then the env stuff would just look all wrong. So -env does require the use of -spec for it to actually do anything.
-
i'm mucking about with something, so the base cleanest shaders to play with should be l-v.sdr and lf-v.sdr?
also, what is the fog stuff used for exactly?
-
Correct. The env map is modulated against the spec map, so if there was no spec map then the env stuff would just look all wrong. So -env does require the use of -spec for it to actually do anything.
OK, Wiki updated.
Nevertheless, I thought that the spec map usage from env was optional. I thought that, despite of -spec setting, env was modulated in this way:
- If there wasn't a -spec map, then a fixed hardcoded, (within shader or within game exe), amount of env was used.
- If there was a -spec map with alpha channel, this value was used.
- If there was a -spec map without alpha channel, the same fixed hardcoded amount was used.
So I thought that -env didn't need -spec flag. It just used the -spec map alpha channel info if available, despite the status of the specular effect itself.
Taylor, you've just posted that env DOES need spec. Could you explain if my other suppositions were right?
(I remember adding more or less this info to Texturing section in Wiki, so I would like to correct it if needed).
-
If there wasn't a -spec map, then a fixed hardcoded, (within shader or within game exe), amount of env was used.
Nope, it requires the spec map. Without that it doesn't have any way to tell how to properly blend the env map onto the model. If env was applied without the spec map then it would have to be modulated against the diffuse map. In such a case you end up with something where it was really shiny all over the model, but with practically no env on the cockpit glass. And how shiny the model would be is tied directly to the color of the model, so light colored models would be less shiny and dark colored models would be more shiny. There just isn't a way to make it look remotely decent in other words. It must be modulated against a map which was specifically designed for that purpose.
If there was a -spec map with alpha channel, this value was used.
If there was a -spec map without alpha channel, the same fixed hardcoded amount was used.
Correct on the first count but not on the second. If the spec map doesn't have an alpha channel then it is modulated against the RGB values of the spec map, so it's not some fixed/hardcoded amount in the code or shaders.
-
This thread is made of cookies and bunnies and all things win.
-
Just to be sure that I've understood before updating the wiki :nervous: :nervous: :
- If there's no -spec map then there's no env effect.
- If there's a -spec map with alpha channel. This channel value is used for the env effect. Are -spec map RGB values used in any way?
- If there's a -spec map without alpha channel. RGB values are used for the env effect. I suppose the env amount depends on the luminosity/luminance however you define it. I mean from the RGB data, you obtain L of an equivalent "HSL-ish" space. Am I right?
OTOH, and this is maybe a feature request rather than any other thing, and possibly it's worthless (too much work for nearly nothing). Env effect seems fully independent from spec one. Env just uses -spec maps, (in a different/complementary way than the spec effect). So would it be possible to make them fully independent? I mean that env effect didn't need -spec flag to work.
-
If there's no -spec map then there's no env effect.
Correct.
If there's a -spec map with alpha channel. This channel value is used for the env effect. Are -spec map RGB values used in any way?
Correct. Spec map RGB values will always be used for the specular light addition, and if there is alpha in the spec map then the alpha is used for the envmap blending.
If there's a -spec map without alpha channel. RGB values are used for the env effect. I suppose the env amount depends on the luminosity/luminance however you define it. I mean from the RGB data, you obtain L of an equivalent "HSL-ish" space. Am I right?
Pretty much, yeah. The math is literally: color = env * spec.
OTOH, and this is maybe a feature request rather than any other thing, and possibly it's worthless (too much work for nearly nothing). Env effect seems fully independent from spec one. Env just uses -spec maps, (in a different/complementary way than the spec effect). So would it be possible to make them fully independent? I mean that env effect didn't need -spec flag to work.
That would make sense of course, and would probably just involve a single line change to do, it just hasn't ever been done.
-
If there's a -spec map with alpha channel. This channel value is used for the env effect. Are -spec map RGB values used in any way?
Correct. Spec map RGB values will always be used for the specular light addition, and if there is alpha in the spec map then the alpha is used for the envmap blending.
Sorry if I seem to be dumb...
What I wanted to ask was if env effect used -spec map RGB values when an alpha channel is present. Or whether in this situation, it only uses this last channel info. (I DO know that specular effect uses -spec map RGB values, despite env or no env. :D).
-
why am i being ignored?
:p
i'm mucking about with something, so the base cleanest shaders to play with should be l-v.sdr and lf-v.sdr?
also, what is the fog stuff used for exactly?
-
What I wanted to ask was if env effect used -spec map RGB values when an alpha channel is present. Or whether in this situation, it only uses this last channel info. (I DO know that specular effect uses -spec map RGB values, despite env or no env. :D).
I thought that was the answer, but it may be a bit too vague. :)
For the env map blending it will use from the spec map RGB or alpha (in the case that the spec map has an alpha channel).
why am i being ignored?
I thought that I answered you actually. Guess I forgot though. :D
If by "cleanest" you mean the most simple, then that would be l-v. There really isn't a whole lot different between l-v, le-v and lf-v though, as far as complexity goes. But there really isn't a whole lot to do with the vertex shaders (since it's not very flexible without a material system). If you want to play around with the light settings then that's where you would do it, but otherwise you would mostly just be wasting your time. You can turn off some of the lights to get a good speed boost (if you dropped 2 or 3 lights out then you would probably get about a 40-50 FPS improvement on most models), but then you lose some visual effects in the process. Most visual changes would come from changes to the fragment shaders, but like with the vertex shaders, you don't have a whole lot of room to play with it all without a material system in place.
And the fog stuff is for full nebula missions. They aren't used otherwise.
-
i'm looking for some base code to scroll through and modify, some yesterdays attempts were... rather unsuccesfull...
null-f.sdr would be considered the most basic fragment shader, right?
-
Thanks, Taylor.
Well, I've updated and fixed Texturing in Wiki (http://www.hard-light.net/wiki/index.php/Texturing). There were several places with wrong info about env because of my "un-knowledge".
Please, somebody check that everything is fine now.
-
Nicely done, ARSPR.
Careful, though. May have to change your "Title" to "Preys on Mantis, Stalks on Wiki" :D
No?
"Crouching Mantis, Hidden Wiki"? :nervous:
;7
-
okay... very specific question time... which shaders are used when the model is viewed with no diffuse, no glowmap, no specular, no normal, no env map flags in the ship lab?
(in other words, when only light is applied to the ships bare polygons...)
-
okay... very specific question time... which shaders are used when the model is viewed with no diffuse, no glowmap, no specular, no normal, no env map flags in the ship lab?
(in other words, when only light is applied to the ships bare polygons...)
l-v & null-f
-
okay... very specific question time... which shaders are used when the model is viewed with no diffuse, no glowmap, no specular, no normal, no env map flags in the ship lab?
(in other words, when only light is applied to the ships bare polygons...)
l-v & null-f
Wikified.
And then it makes me asking another question. If null-f uses l-v, when would null-v be used?
I think that I don't really understand the difference between null and l :confused: :confused:. My answer for pecenipicek question would have been l-v and l-f.
Could you explain me the difference between null and l, please?
EDITED...
I've checked in mv_core that there's no l-f shader. So although my previous post is more or less fine, now I think that:
- There's no l-f shader because, if lighting is enabled over texture effects, you need to use at least one effect. So l*-f always need something (b, g, s, whatever). There's no point in a lonely l-f shader.
- If null-f uses l-v, when would null-v be used? (I've verified that it exist in mv_core.vp)
- OTOH, there are also b-v, b-f, bg-v, bg-f shaders. Where are they used?
Please, could someone explain it?
-
"null" is empty, so null-v is no special vertex effects like lighting or mapping, and null-f is no maps in use. So in the lab, if you turn off all maps and leave lighting enabled, then it would use l-v (for lighting support) and null-f (since there aren't any maps). If you turn off lighting and enable at least one map then it would use b-v and b-f (or bg-f if there is a glowmap). The b-v/b-f/bg-f shaders are really just used for the models shown in the hud target box.
And bg-v is just a packaging mistake, it's not used by the code.
-
Wikified again in http://www.hard-light.net/wiki/index.php/OpenGL_Shaders_(GLSL). Please check. I think this is the last time :nervous: :nervous:
And bg-v is just a packaging mistake, it's not used by the code.
Made one minor correction: The coded number of supported shaders (ATM) is 66, not 67. The MediaVP shaders currently have a miscellaneous orphan file.
I suppose I've "found" the extra file :D :D
-
I added a listing of the V to F shader sets.
Extrapolated from the Log in addition to the code in gropenglshader.cpp.