Low resolution reflections in FTEQW

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Low resolution reflections in FTEQW

Post by toneddu2000 »

Hy guys I modified a little altwater.glsl in FTEQW and added the OPACITY filed modifiable by shader like this:

Code: Select all

//OPACITY=0 - total mirror / OPACITY=100 - no mirror at all
textures/world/mywall
{
	program ton_reflections#OPACITY=10
	{
		map $reflection
	}
	
}
And then ton_reflections.glsl:

Code: Select all

varying vec4 camtransform;
#ifdef VERTEX_SHADER
void main (void)
{
	camtransform = ftetransform();
	gl_Position = camtransform;
}
#endif
#ifdef FRAGMENT_SHADER
#define reflectionpass s_t0//st0 is the first {}block in the shader. Make sure that $reflection is the first block!
uniform sampler2D reflectionpass;
void main (void)
{
	vec2 screnspace;
	vec3 reflectionvector;
	screnspace = (1.0 + (camtransform.xy / camtransform.w)) * 0.5; //this stores reflection
	#ifdef OPACITY
	reflectionvector = texture2D(reflectionpass, screnspace).rgb/OPACITY;
	#else
	reflectionvector = texture2D(reflectionpass, screnspace).rgb;
	#endif
	gl_FragColor = vec4(reflectionvector, 0.1);
}
#endif
Effect is cool and works great but:

Since cubemaps glsl, without help from a skilled coder, can be considered trash (and, incredible as it may sound, it's a frame dropper worse than true reflections! :shock: ), I was trying to use low resolution reflections to impact a little less on frame rate, because on an empty scene with 480/500 fps, with reflections activated on all six walls and just one entity framerate drops to 200 /250 fps!

So I edited gl_backend.c GLBE_SubmitMeshesSortList from this

Code: Select all

r_refdef.vrect.x = 0;
r_refdef.vrect.y = 0;
r_refdef.vrect.width = vid.fbvwidth/2;
r_refdef.vrect.height = vid.fbvheight/2;
r_refdef.pxrect.x = 0;
r_refdef.pxrect.y = 0;
r_refdef.pxrect.width = vid.fbpwidth/2;
r_refdef.pxrect.height = vid.fbpheight/2;
to

Code: Select all

r_refdef.vrect.x = 0;
r_refdef.vrect.y = 0;
r_refdef.vrect.width = vid.fbvwidth/16;
r_refdef.vrect.height = vid.fbvheight/16;
r_refdef.pxrect.x = 0;
r_refdef.pxrect.y = 0;
r_refdef.pxrect.width = vid.fbpwidth/16;
r_refdef.pxrect.height = vid.fbpheight/16;
And, infact, resolution becomes very low and blocky, that, together with an high OPACITY value, seems blurry, which it's kinda cool! :)
The problem is that framerate remains the same! :shock: There's a way to reduce reflection texture size and save some fps?
And, since cubemaps as said it's useless for now, there could be the method to use reflections also on non-flat surfaces with some extra work?

Thanks guys! It's fun messing with GLSL when you have no idea what you're doing! :lol:
Meadow Fun!! - my first commercial game, made with FTEQW game engine
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Low resolution reflections in FTEQW

Post by mh »

This demonstrates exactly why you should measure milliseconds per frame rather than frames per second. It actually isn't a catastrophic framerate drop, it's perfectly normal.

At 500 fps a frame takes 2 milliseconds to draw.
At 250 fps a frame takes 4 milliseconds to draw.

The cost of drawing your reflections is therefore (4 - 2) an additional 2 milliseconds, which is also equal to the cost of drawing a normal frame. That's expected behaviour and it just means that the cost of scene traversal, state changes and issuing draw calls is the same in both cases. There would be something wrong if it wasn't.

Getting no performance increase from switching to lower-resolution cubemaps just means that you're not bottlenecked by fillrate.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Low resolution reflections in FTEQW

Post by toneddu2000 »

thanks mh for the explanation, I didn't know that kind of measurement. I learned something new about draw calls! :D
And what about my second question: could it be possible to show reflections on non planar surfaces?
Thanks again
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Low resolution reflections in FTEQW

Post by Spike »

'map $reflection' isn't intended for multiple surfaces (really just water and maybe the occasional imperfect mirror/glass pane). the problem being that reflections that can see reflections can see the original reflection and it all gets a bit recursive.
I'm not entirely sure if fte's batching is even aware of it...

as mh says, frametimes beat framerates because they are linear. in other words, division sucks. this is also true with your OPACITY thing - you should really have used a 0-1 scaler instead of a division-by-zero/really-tiny-but-still-not-0-scaler. it makes interpolation much easier that way.

reflections on curved surfaces are pretty much a nightmare. you can get away with ripples or other distortions if you're okay with the reflection potentially sampling things that are behind of offscreen (really off-fbo), but this should only really happen at the edges. actual curves however are too unreliable really.

precomputed cubemaps can of course reflect in any direction they fancy (including curves). and because the mapper specifies where the central point of the reflection cube is, they can avoid it being stupid like inside a wall or whatever. however, you lose paralax. when each point is assumed to reflect from the same point you do at least avoid the worst of the distortion.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Low resolution reflections in FTEQW

Post by toneddu2000 »

the problem being that reflections that can see reflections can see the original reflection and it all gets a bit recursive.
In Blender, when using raytraced reflection, there's a 'depth' value to set that sets (as appear on field popup) the "maximum allowed number of inter-reflections". Could it be feasible in realtime too?
as mh says, frametimes beat framerates because they are linear. in other words, division sucks. this is also true with your OPACITY thing - you should really have used a 0-1 scaler instead of a division-by-zero/really-tiny-but-still-not-0-scaler. it makes interpolation much easier that way.
Ah ok, thanks
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Post Reply