GLSL problems on Mac (really broken now)

[ds01]

Just now I realize bloom and fog won't work with that. Bloody maddening :-\

[edit: rev. 2 patch bloom works]

[KadaverJack]

Just now I realize bloom and fog won't work with that. Bloody maddening :-\

That might not be entirely your fault. The neon tubes on nexdm08 are broken with current cvs builds & r_glsl enabled.
However bloom (on health packs and viewmodel) and fog are both working.

[ds01]

That might not be entirely your fault. The neon tubes on nexdm08 are broken with current cvs builds & r_glsl enabled.
However bloom (on health packs and viewmodel) and fog are both working.

Thanks a lot for telling me this

I thought bloom wasn't working, so I presumed fog also (don't know where fog is?) - the "Glow Arena" is what I used to double-check for bloom. (They look like plastic tubes without bloom on them lol.) Did you notice that if you increase the bloom intensity way too high, then you can see the bloom coming from the tubes in the glow arena (still not coloured correctly though)?

Updated the patch in the post above - removed the tempcolor vec and cleaned it up a bit, also added a force-check for the last block in the fp shadercode. Bloom was partly working before, but in this patch it should really be working.

KadaverJack do you know if nexdm03 (the map with the glowing green 'plasma' tubes) is supposed to work with cvs, because it doesn't for me with GLSL on. The effect is strange - entire bloom's are shifting like the psychadelic underwater effect from the original glquake 1 - causing the map to be unplayable. I usually don't have it in rotation, but I ran through all the maps once to look at things (lots of new stuff in release candidate!) and all the others are playable.

[LordHavoc]

Fog isn't used in Nexuiz, it can be turned on with this console command:
fog 0.1 0.1 0.1 0.1

That makes a somewhat dark grey fog fill the level, pretty densely, the parameters are density red green blue.

Naturally the fog can be set in any map that wishes to do so, but it disables skybox (because it's global fog and the skybox is infinitely far away... so logic dictates it hides the skybox).

P.S. the bloom doesn't use a shader, it's stock OpenGL 1.1 blending and texture copying stuff, it could be sped up a bit with a shader (texture fetches are cheaper than pixel blends) but I haven't gotten around to it, it works on any card, even an old TNT, but then pretty much everything in DP works on even the oldest cards

[ds01]

P.S. the bloom doesn't use a shader

I associated "bloom" with "glow" in my mind, it's easy to confuse variables in an engine with so many effects

[KadaverJack]

KadaverJack do you know if nexdm03 (the map with the glowing green 'plasma' tubes) is supposed to work with cvs, because it doesn't for me with GLSL on.

Yes, those don't work either.
This is how they look here:

[LordHavoc]

KadaverJack do you know if nexdm03 (the map with the glowing green 'plasma' tubes) is supposed to work with cvs, because it doesn't for me with GLSL on.

Yes, those don't work either.

That's insightful, but I'm still not sure how r_glsl 0 would be behaving any differently from my looks at the code.

[ds01]

KadaverJack, have use tried r_glsl_deluxemapping?

It looks like that here also, but there is a more prominent issue - it seems the effects are on a different "plane" as the textures/models? Using the latest rc pk3 data, this only happens with nexdm03. Using the data from cvs in addition, then nexdm10 also shows this "multi-planar" effect (lava level). The diff plane moves in a swaying motion like a boat effect. Also causes the text to go messy and the 'real' plane with the textures/models twigs out well shimmer would not be the correct term - sort of looks like it's not in tune only very very slightly (like out of sync HSync TV) and not swaying like the effect planar.

That only happens in certain areas of those maps, near green plasma in dm3 and red lava in dm10 - but thing is, if I turn away from those texture places and i.e. look at plain wall or go someplace else without those then everything (text/effects/sync) goes normal?!

Like I said before the lava map (dm10) does not do this with just rc data even with r_glsl=1, it does it with cvs data added. BUT you can make it do it with just rc data, by forcing r_glsl_deluxemapping=2. Could it be that those textures when deluxemapped make the engine freak out? (using the cvs + patch so I can use GLSL). I don't know how a deluxemap is generated, but if those textures are removed before the deluxemap is created then it would probably fix the problem right - does anyone else see the same thing here (please tell me it is not just me). I noticed all the maps are getting deluxedmap conversions into cvs, so this could be a big problem if more maps start using methods of that sort for textures.

This link following, the server has per-hour b/w limit, so be warned if you bang on refresh you hose it for everyone:
Link to screenshots of the issue in nexdm03

[KadaverJack]

KadaverJack, have use tried r_glsl_deluxemapping?

Yes, it's on by default and the map was from svn, already recompiled with deluxemaps.
Of course it is only enabled on the r_glsl 1 shot...

Link to screenshots of the issue in nexdm03

Now that looks really weird...

[LordHavoc]

Link to screenshots of the issue in nexdm03

Looks like an offset bloom texture, I wonder what would be messing with the bloom texturing? Does it scroll around? If so it's probably the driver ignoring one of the glLoadMatrixf calls on the GL_TEXTURE matrix, and thus leaving it in a bad state when it advances to rendering other multitexture stuff like applying bloom (r_textureunits 1 would probably hide this artifact by using a multipass method to blend the final bloom texture onto the screen).

Regarding the glow problems, I just realized why that happens on deluxemapping, but am not sure of a solution at the moment. The issue is that the q3map2 deluxemaps are modelspace (which I hate), so the rendering needs the deluxemapping to be disabled on the vertex lit stuff, or at the very least it needs a better direction vector than the non-existent one it's using on vertex-lit stuff.

Basically, deluxemapping doesn't affect vertex lit surfaces, and those are.

We might have an easy way out because those surfaces probably have the NOLIGHTMAP flag set on them, thus being batched in a separate texture chain, if so that could disable deluxemapping on the batch, but we don't know for sure if that is always the case without doing some tests or research on the data.