There are like 3 or 4 different fog implementations in engines and that sucks. 

Here is a little bit of video that shows how looking down changes the appearance of the slime.

I'd like to add that I can simply set r_oldwater to 1 and not worry about this glitch at all. So please don't spend too much time on this as long as it is just my system which has this problem.

http://i.imgur.com/7EhYPvi.gifv

(I should know by now how to record windows without including the header bit, but I forgot to do it right again while making this one. Derp.) 

I will have a look, I should be able to fire up ubuntu on a Haswell laptop. 

happens for me too, Ubuntu 14.10,
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.0 Mesa 10.3.0

Will poke around a bit more 

The problem seems to be mesa is choosing to use vertex fog, which it is allowed to do in OpenGL. I tried adding glHint(GL_FOG_HINT, GL_NICEST) but still get vertex fog.

The other half of the problem is, there's a water textured func_illusionary stretching across the whole map; water doesn't get cut up by qbsp, so there are two giant triangles. Since the corners of the triangles are so far away they get fogged to solid white. You can see the issue if you do r_drawworld 0, r_oldwater 0, r_showtris 1, and noclip up above the map. "r_oldwater 1" avoids the issue because it chops up the water surface into smaller triangles that look ok with vertex fog.

So there's not much we can really do... I was thinking of upgrading the fitzquake "r_oldwater 0" effect to glsl at some point, and that would fix the problem since we can force per-pixel fog in the shader. 

Thanks for looking at this, EricW. 

http://texelstorm.tumblr.com/post/106248773719/anyone-with-access-to-an-oculus-development-kit 

cause I posted it on my quakeguy blog ;) 

So, i just downloaded Quakespasm source and i'm curious about the software renderer. Has it been removed? Is it possible to compile the engine without GL? 

QS is OpenGL only, which dates back to Fitzquake.

Check out Fitzquake Mark V which re-adds the software renderer to Fitzquake. 

@ericw ... when you modified how the map is drawn by removing DrawSequentialPoly, did you discover any side-effects? And did you fix them?

I recall someone saying something about alpha or sorting --- perhaps alpha entities or water in some odd situations could be wrong. 

I don't think there were any issues with the final version of the patch.. the overall draw order is the same as before (opaque entities, world water, transparent entities). Only real difference is, within a particular entity, instead of drawing the faces in the order from the bsp file, they're now sorted by texture.

Maybe it was mh or metlslime pointing out that fitz doesn't depth-sort all of the alpha surfaces. So in your example, fitz and qs should always draw transparent entities on top of water.. this will look wrong if you have a transparent window underwater, viewed from above. MH's engines do sort every transparent surface properly, I looked at that but it's a bit of work to set up.

I do have a test map for checking weird cases like water textured bmodels, fullbrights on transparent bmodels, alpha bmodels in water, etc. Was meaning to upload it but forgot about it. I'll dig it out and upload it tomorrow. 

Yeah, it's quite a bit of work to sort all the alpha surfaces properly and even more if you want to add sorting for other stuff like alpha MDLs, sprites, particles, etc. Particles in particular are a bitch; you need to add a second level of "emitters", "active_emitters" and "free_emitters", otherwise you're measuring distance and sorting for every individual particle.

I think the payoff is worth it but it's not something you can just drop in quickly. 

Of course even then intersecting surfaces won't work.

People have been asking for a programmable blend stage for years and programmable blending would go a long way towards proper per-fragment fast order-independent translucency. Being able to select between "src + (dst - src) * alpha" or "dst + (src - dst) * alpha" based on a depth comparison should do it. 

@Baker here you go:
http://quaketastic.com/files/misc/rendering-testmap2.zip
It's a quoth map, it uses mapobject_custom to load an external bmodel (crates.bsp). There's lots of unusual stuff, I don't remember exactly but the .map is included. Make sure to play with different wateralpha values.

MH, yeah, I'd like to fix it in QS sometime. It's not really uncommon to have the issue show up in maps, either. The teleporter behind you at the start of telefragged.bsp is a good example, it's just a free-floating liquid brush, but QS draws the rear surface in front of the front one. 

Interesting, I'll check it out. 

What are people's thoughts on rotating bmodel bounding boxes when the "angles" field is set, as described in Baker's tutorial here:
http://forums.inside3d.com/viewtopic.php?f=12&t=2376

This lets you do "real" rotating doors without setting up func_movewalls.
I had a request to add this feature to QS. As far as I know the only quake singleplayer map to need it is e3m3rq.bsp, from the rmqwinter11 demo.

Here are some pros/cons I thought of:

Cons:
- strictly speaking, this is a breaking change. for example, in those maps that have a func_train with 'angles' set, (recall the offset elevators in add.bsp or apsp1.bsp), with fitz 0.85, only the visual part of the model is rotated, the bounding box is left in the original place the mapper put it. If you add bbox rotation to the engine, the bounding box is lined up with the visible part of the model. Both maps still seem playable with bbox rotation, but it's possible other content is broken.

Pros:
- better for mappers than hipnotic rotation, no need for func_movewall
- possible to make rotating fans, etc, with no qc
- already implemented in many engines: mark V (only if you use sv_protocol 668), fte, darkplaces, quakeforge, qbism.
- IMO the chance of breaking existing content is small; because you could consider the fact that bboxes don't rotate in vanilla quake a bug, and it's unlikely that somone would deliberately have the physics bbox in one place and the visual part of a model rotated away from that.

Question for Baker, was there any compatibility reaason you left this disabled in protocol 666 in MarkV? 

Remember the apsp1 issue with an entity being rotated a little? With a rotation of -1 or something? It had something to do with that, but I can't remember off hand --- it might have been of the "an entity has a strange rotation, do we honor it or ignore?" So I chose to disable rotation until the feature gains some usage. But I haven't thought about this in a while, so my memory could be wrong but I wanted to err on the side of compatibility.

The reason for protocol 668 was for smooth rotation. Something like FitzQuake interpolations positions nice and smooth, but not angles.

But yes, I'd love to see rotation go into mainstream usage. 

This was an angle key of -1 on the entity signifying something meaningful to mappers; probably the direction in which a moving brush model should move, I can't recall exactly what, but it was valid usage in Quake.

This wasn't a problem in the original Quake because angle-to-byte quantization with truncation meant that the value was transmitted as 0.

In FitzQuake it became an issue because it used a Q_rint call for better rounding, and so the -1 value suddenly became visible on the client.

It was only ever an issue on the client; -1 was insignificant enough that on the server things were just off by a little.

It seems that it should be possible to detect these entities at load time and flag them for special handling in the edict_t struct.

Another, possibly bigger, thing to watch out for with rotated bboxes is that some of the maps have an angles key set; e3m3 is one example from ID1. Things go quite insane if you don't exclude the world from bbox rotation. 

I believe the cause of the -1 angles in those maps is a door that was converted to a plat or train, without deleting the angle key. For doors the -1 is meaningful and i think the quakec even zeroes it out after doing its special thing. For plats and trains the angle isn't used, which means the unnecessary key is left alone to cause this bug.

Otherwise you'd see weird angled stuff in every level in fitzquake because almost ever level has a vertical-moving door (angle -1 or -2) 

To have true rotation instead of the hacky method.

Maybe enable it as a default on variable so if some map or mod does rely on weird qc usage it can be turned off. 

...is that you're pushing the solution on to the player. 99% of the time the player won't take up the solution and then it's going to be your fault anyway. Deervedly so, because you didn't fix it proper nor proive a sensible default to begin with. 

But you choose the default that works with most old cases, and place the onus on new modders to choose the one that they want in their rc or whatever. 

Here is a zip rotate.zip

Do -game rotate, map rotate or map rotate2

There is an old Mark V in there "fitzquake_mark_4.exe" which has rotation working and under both 666 and 668.

Rotate2.bsp only works right under DarkPlaces, I'm not sure why and I swear that ages ago I had that working in engine tests. I don't think even the RMQ engine does that map right. Try DarkPlaces and you will be standing on rotating platform to see the correct behavior.

Try Rotate.bsp with the provided fitz under 666 and 668. Pay particular attention to shooting the "drawbridge" and standing on it when it raises and lowers with 666 and 668 and try DarkPlaces too doing the same. 

The Problem With Cvar Controlled Stuff...
...is that you're pushing the solution on to the player. 99% of the time the player won't take up the solution and then it's going to be your fault anyway. Deervedly so, because you didn't fix it proper nor proive a sensible default to begin with
Haha :) Fix it proper for 1000 Q1 maps/mods ?
Sensible defaults vary according who to joe dick and harry are. Roughly - QS tries to provide sensible defaults and interface for the Average Joe, and *document* cvars, workarounds, etc, for more technical users/features.