I have linked an image comparison of three views of jam5_hypnos.bsp.

http://i.imgur.com/WIAAvmL.png

It shows how the fog looks in Darkplaces versus Quakespasm 0.90. You will see that if I look across the grimy water in QS the fog colors all of its surface light blue even near me. However, if I walk right to the edge and look down, the liquid texture appears in place of the fog color. In other words, the direction I am looking affects how the liquid surface looks, which is weird.

I'm not sure what is going on here. Could I be using some odd fog setting accidentally that makes it work this way? Does anyone else see this, or does it look more like the Darkplaces screenshot to you in Quakespasm too? 

The rendering effect I described above happens when I have r_oldwater set to 0. If I enter r_oldwater 1 in the console, the scene looks similar to the DP screenshot.

So if you try to reproduce, see if the two different r_oldwater settings have the same effect for you. 

Hmm, thanks for the report. At first glance I can't reproduce that, with QS 0.90.0 r_oldwater 0/1 look the same (except the slight difference in water quality). Here's r_oldwater 0:
https://www.dropbox.com/s/z4n1kibgu13qr2i/primal1.jpg?dl=0

I have a guess at what's happening from you screenshot - with "r_oldwater 0" the water texture gets drawn on the screen between frames and copied back to a texture, it looks like it's picking up the fog there.

Would you mind checking whether you get the same issue with fitzquake 085? http://www.celephais.net/fitzquake/

Also, what's your graphics card? 

I ran fitzquake with Wine and got the same result when I set r_oldwater to 0 in the console. Same thing with the water texture coming out when looking downwards too.

I have 64-bit Ubuntu on my laptop with an integrated gfx card. Here are some lines from my glxinfo.

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30 

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.