Spike, your pictures are dark and don't show much.

Come on man, you surely can do more pictures of your FX on water, with a better/clearer view.

A short video, maybe ? 

You could try downloading them then gamma-adjusting them.

But anyway, there are two pictures, "no bumps" and "bumps".

The "no bumps" picture shows reflection without a bumpmap and it looks just like a flat mirror. Not at all liquid-like.

The "bumps" picture shows reflection with a bumpmap and it looks more correct.

So the point Spike is making is that the kind of reflection/refraction effect you're asking for requires using a bumpmap. 

@barnak - I've done a number of tests with reflective liquids using a few different methods in Darkplaces. The demonstration I posted in the screenshots/beta thread a couple days ago has a bit with some reflective blood using realtime reflections and subtle refraction. This is a massive gif of that area. The floor uses realtime reflections and the walls use bump + gloss. Also, here is an old caustics test. This is just an animated decal so it can be used pretty much anywhere and isn't expensive.

You can you use a combo of bump+gloss+cubemaps to get an ok look on small sections of liquid such as puddles, but cubemaps just don't work well on large areas. If you're feeling really sassy you can just copy and flip world geometry and place it behind a transparent liquid texture to get pretty ok fake reflections :P (just kidding, don't do this).

IMO, however cool looking, realtime reflections/refractions are too resource intensive for general use. The effort needed to make them look 'good', especially in a quake-like setting, makes them route even more prohibitive. 

Both of your animations looks very good.

So if I understand clearly what you said, the first rendering is too intense on the frame rate, even for liquids only ?

Would it be reasonable to add the second effect to QS ? 

realtime reflections/refractions are too resource intensive for general use
If your system isn't too antediluvian you should be able to run most Quake maps fine. My old Core2duo E6750 and GeForce GTX 650 can run DP Pretty Water @ at least 30fps in medium to large maps. I only have trouble with the hugest ones (AD, Something Wicked...). 

So if I understand clearly what you said, the first rendering is too intense on the frame rate, even for liquids only ?

Realtime reflection/refraction are expensive, yes. However, in vanilla-ish quake maps without realtime lights with decent hardware you'll get good framerate (though it will still take a large hit).

Would it be reasonable to add the second effect to QS ?

bump+gloss+cubemap or the caustics? Either way, I have no idea of the technical aspect, I'm not a programmer. Practically speaking, there isn't a demand for reflective liquids in general and other engines already do this (FTE, DP). So, "reasonable"? Ask someone that would actually be doing the work :P

at least 30fps

1/8 of the way to an acceptable framerate! 

 

@Qmaster. Thanks for the answer. That makes sense.

It also makes sense to address the limits issue once and for all rather than constantly just 'applying bandages'... :) 

1/8 of the way to an acceptable framerate!
Why? 30fps is enough for the eye to perceive fluidity. And I forgot to mention this was with RTlights on, of course... Should be quite higher off. 

Why? 30fps is enough for the eye to perceive fluidity.

It may be enough for the eye (although remember that movies which run at 30fps use a lot of motion blur which games may not have) but it's not enough for the reflexes/reactions.

There's plenty of work been done on this, we shouldn't have to rehash it and prove it all over again. 

Never noticed a sizeable gameplay diff between fluid and fluider but my precision skills may not be that accurate... ;) 

At 30fps you've got 33ms latency between input events and the response to them; that's the equivalent of a network link from New Orleans to Denver (source: https://serverfault.com/a/137357/5234).

You really don't wanna be doing that. 

Thanks for the info. 

depends on the game and scenario.

For instance, it doesn't matter if you play a point and click game running at less than 30fps. But it matters in a fast paced competitive shooter. 

im with MH, even using motion blur to hide screen tearing, and quake's client-side aim, 30fps is not playable. 60 maybe; i might be a mutant but I can tell the diff between 60 and 120fps
just saying. 

This may have been answered before/elsewhere? How come I can't set 32 bit colors on my machine? Highest depth is 24 bit. Only just noticed that on some laptop it ran on 32 so something must be off here. 

32 and 24 are the same colour depth (8 bit per channel) so it's probably nothing to worry about. The extra 8 bits would be unused by qs.. not sure if it's just padding or an alpha channel. 

...that I thought I'd relay here. This person is having trouble running the old XMen TC on the latest QS build. I've tested it on QS-admod/0.92.2 and although it starts up with the XMen background image, I get the same error messages when I try to start a new game.

It works fine on QS 0.92.0, though, so this seems to result from some very recent change/s to QS.

Original Quaddicted post:
Hey. I thought I'd give this TC a try but I've encountered this error in Quakespasm (0.92.2):

UNKNOWN COMMAND "GL_KEEPTJUNCTIONS"
HOST_ERROR: PF_LIGHTSTYLE: STYLE=255

Anyone else have this?

https://www.quaddicted.com/forum/viewtopic.php?pid=2289#p2289

PS: I'm not posting this because I want to play the XMen TC at all costs (I tried it once a long time ago and that sufficed for me); I just thought this could be something ericw (and others working on QS?) might want/need to know about.

Thanks for constantly improving this fantastic engine, by the way! 

The quote should have ended after "Anyone else have this?". The rest are my words. I guess I forgot to type "< / q >". 

there's apparently already a fix for that, just no new releases. for that mod just use the old build until then, or other engines. 

Ok, thanks. As I said, I'm not interested in the mod; just thought it was perhaps indicative of a bug or problem. 

Just out of interest - what is the correct value for MAX_LIGHTSTYLES anyway? There are places in the engine where it's 64, other places where it's 256. 

About this bug with xmen, I caught a case where something was calling PF_lightstyle with a style between 64-67. Since there was no bounds check, this happened to overwrite the next thing in server_t, num_edicts, which blew up the engine and was a pain to trace back to PF_lightstyle.

So initially I put in an aggressive Host_Error, but that broke Xmen, so I changed it to a debug warning + ignore the lightstyle call. 

the bsp limit for MAX_LIGHTSTYLES should be 255, not 256. it doesn't make sense to go higher than that, other than to skip the validation when parsing svc_lightstyle messages, which isn't too significant.
the 256th lightstyle might be usable for rtlights, but all the various bsp formats that use a byte for lightstyles can use a max of only 255, with the 256th (index 255) being 'no more styles'.
xmen is just buggy.... 

Type "gamma fps" in the console to get higher fps.