Mirror textures standard

[Baker]

FitzQuake and related engines support skyboxes and fog. They are NOT using SVC_SKYBOX or SVC_FOG (don't get me started on how they aren't even the same SVC in, say, FitzQuake versus DarkPlaces ... memory says it is 51 in FitzQuake and 41 in DarkPlaces for skyboxes, as an example).

Anyway, to the question at hand ...

Let's say mirror textures are a standard and they do not require an SVC_

What it is the appropriate way to implement in worldspawn in your opinion?

Goal: I want textures either named "mirror" or starting with "mirror_" to activate mirror capability for said map. I want reflective ice, etc. No I am not thinking about reflective water like Vengenace R2 at this point ... the key words being "at this point". I'm sure that on this same day in 2011 that answer will differ ...

[Advanced goal ... figure out how to rip software renderer mirrors from eDuke32 ... a challenge for another day ...]

[leileilol]

[Advanced goal ... figure out how to rip software renderer mirrors from eDuke32 ... a challenge for another day ...]

Build engine license is not compatible, and build doesn't work with brushes. Sector effector portal mirrors can not translate to brush surface mirrors

LOOK BEFORE YOU FRICKIN' LEAP

[Baker]

Thinking about this some more, I can't imagine having Quake render mirrors in the software renderer working out too well.

Yeah, I'm sure the code in eDuke32 isn't license compatible. I haven't read the license, but just seeing the gist of the idea was what I was thinking of.

Either way, mirrors in software probably are a "bad idea".

I'm trying to think what kind of worldspawn key would make sense for this.

[mh]

If memory serves "mirrors" in Duke are just another copy of the same room with the same objects in it, just flipped left-to-right and included in the map. Not certain if eDuke does them that way (haven't looked much at the code) but the original engine did. I'll try to dig up a source on that one later on.

IMO, perpetuating the awful r_mirroralpha code in the engine is a baaaaaad idea, and if mirrors are going to be done at all they should be done right. I'm failing to see why a worldspawn key is needed though - surely just agreeing on a texture name prefix is sufficient?

[Baker]

If memory serves "mirrors" in Duke are just another copy of the same room with the same objects in it, just flipped left-to-right and included in the map. Not certain if eDuke does them that way (haven't looked much at the code) but the original engine did. I'll try to dig up a source on that one later on.

Interesting.

I'm failing to see why a worldspawn key is needed though - surely just agreeing on a texture name prefix is sufficient?

Yeah I wasn't thinking that through.

My initial thought was using the worldspawn to activate the r_mirroralpha feature.

But even in that theoretical situation, it could be done by checking to see if any "mirror_" textures were present in the map.

Part of me is wondering if mirrors could represent a problem for vis? Like if part of the map is visible in a mirror that isn't visible from the player perspective.

I'm also thinking of doing some security camera experiments, but that would almost certainly require sv_novis support.

The security camera concept is that maybe you have a texture "security_camera_viewscreen" (ignore the fact Quake only supports 15 length texture names ) that somehow conveys to the engine that instead of being a "mirror" of where the player is, is a projection of some x,y,z, roll, pitch, yaw of some other part of the map.

IMO, perpetuating the awful r_mirroralpha code in the engine is a baaaaaad idea, and if mirrors are going to be done at all they should be done right.

Maybe so ... but my r_mirroralpha experiments have had some very cool results. I can't remember if I have posted pics. I don't think I did.

[Sajt]

In portal-based raycasting/raytracing engines, mirrors and warp portals can be done naturally.

In non-raytracing engines, one of the problems with mirrors and warp portals is when the room seen through it "overlaps" the room you're in (in terms of the depth buffer). To solve this in hardware usually involves the stencil buffer (if you're not using it for other things) or render-to-texture. You could probably also do a ton of manual polygon clipping (in OpenGL, GL_CLIP_PLANE0 et al) if your mirror surface is a simple polygon, but stencil buffer seems the most natural choice. And there's another solution: to divide the depth range into as many equal portions as you have recursing warps/mirrors, but I don't like the sound of that. In software the most logical solution as far as I can tell would be to implement a stencil buffer.

Security cameras would be much simpler and probably a better idea to tackle first, since you don't have to worry about the transformation math, and you're just using a fixed-size off-screen colour+depth buffer...

[goldenboy]

As a mapper, I can't think of anything I'd use mirrors for, off the top of my head. Sure, once a feature exists, it gets used, but TMK there hasn't been a huge demand for this feature.

Portals are something else, portals are pretty cool at least in prey. So is switcheing the gravity around, incidentally.

[Spike]

a mirror is just a portal with an angle that depends upon your current angle. An engine that can do q3-style portals can fairly easily do mirrors too, and vice versa.
Portals are actually a little easier as you don't need to flip the scene(and the culling that this entails). However, you do need a way to say where the portal displays.
Security cameras are just a render to texture. Simple enough with software rendering, its harder to update the rendering code to scale it properly if anything.
But again with security cameras, you need a way to say where it points.
I could say 'use csqc' but that's not relevent as you do also need to modify the server to support merging PVS regions in order for the client to actually see anything other than pure brushwork on the other side, if csqc were used, it would be purely a wrapper to the ssqc/server, so doesn't really provide too much except alternative networking.

In duke3d, the mapper needs to create the room. The engine will copy sprites over (you can place your own stuff in the mirrored room and they will be visible only in the mirror).

Yeah, you can set up clip planes around the edges of the mirror to ensure that only the region inside the mirror is shown. You can use stencil tests too (if you don't want rtlights).
You don't need any of that stuff for security cameras, you can do it with just glCopyTexture or whatever it is that grabs the framebuffer and shoves it in a texture. However, you would need to draw it first in order to avoid messing up the current scene.

Complicated stuff like mirrors facing mirrors is generally too slow anyway. With render-to-texture, it only needs to be done once per frame.
However, with render-to-texture, you do have to pay attention to texture coords. For portals/mirrors you would presumably set it up as eye linear. While security cameras would require the mapper to ensure that its aligned correctly and doesn't wrap.

Q3 doesn't actually play with stuff like halving depth buffer precision or anything. It just draws portals/mirrors first, along with the scene, clears the depth, then writes a depth-only (or depth+transparent) surface over the top. q3dm0's mirror+portal works because the portal surface is opaque by the time the mirror is visible (thus the portal is not drawn).
If you can ensure that your portals/mirrors will always be vertical, you can probably get away with scissor tests to permit multiple mirrors, but the 45-angle roll on death will break things then... as would looking up/down, although a mapper could place them far enough apart that it would never be an issue.