[falcon2105]

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.

[taylor]

.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.

[falcon2105]

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.

[taylor]

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.

[falcon2105]

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

[Zacam]

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.

[Echelon9]

I'm definitely interested seeing how you go with this Zacam

[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.

[Zacam]

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.

[taylor]

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.

[taylor]

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?

[Zacam]

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.

[chief1983]

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

[falcon2105]

Sorry it took so long, I thought people had forgotten bout this thread and stopped checking for a while . 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.

[Zacam]

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.

[falcon2105]

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  since I'm sure you have other more important stuff to do, I wouldn't really care.

[ARSPR]

.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).

[Zacam]

Thanks for your help, but if this problem isn't gonna solve anything for anyone else you can stop trying  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.

[ARSPR]

.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).

  No answers?? 

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 avenger^TM.

[chief1983]

You could create a new page called GLSL Support or something and link to it from the Development Reference page.