Inside3D!
     

Mirror textures standard

 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming
View previous topic :: View next topic  
Author Message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Aug 05, 2010 3:48 am    Post subject: Mirror textures standard Reply with quote

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 ...]
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
leileilol



Joined: 15 Oct 2004
Posts: 1321

PostPosted: Thu Aug 05, 2010 5:17 am    Post subject: Re: Mirror textures standard Reply with quote

Baker wrote:

[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
_________________
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Aug 05, 2010 12:04 pm    Post subject: Reply with quote

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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Thu Aug 05, 2010 12:50 pm    Post subject: Reply with quote

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?
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Aug 05, 2010 1:53 pm    Post subject: Reply with quote

mh wrote:
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.

Quote:
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 Very Happy) 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.

mh wrote:
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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
Sajt



Joined: 16 Oct 2004
Posts: 1026

PostPosted: Thu Aug 05, 2010 4:32 pm    Post subject: Reply with quote

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...
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
Back to top
View user's profile Send private message
goldenboy



Joined: 05 Sep 2008
Posts: 310
Location: Kiel

PostPosted: Thu Aug 05, 2010 4:52 pm    Post subject: Reply with quote

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.
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Thu Aug 05, 2010 5:30 pm    Post subject: Reply with quote

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.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group