Mirrors and portals

Yes, LordKronos, that is the same article I used as well. When he says they don’t use it often, he means just that. He means that they didn’t fill levels with mirrors and portals. And in no level is more than one portal or mirror visible. Now it would not make sense at all, to render that image to a texture every frame, but whenever a mirror or portal is in view, the user clip plane is set every frame, and the geometry in the mirror or portal is drawn every frame. And no function is called to load any texture from frame buffer memory during this time either. I have a logfile of OpenGL calls that were issued while I had a mirror in view, in museum.bsp. Here are the final statistics of a short run, I started the game, loaded museum.bsp (it starts with you facing a mirror), and then quit the game:

Call Counts:
glAlphaFunc 88
glBegin 248
glBindTexture 3420
glBlendFunc 752
glClear 177
glClearDepth 2
glClipPlane 44
glColor4f 2
glColorPointer 2701
glCullFace 206
glDeleteTextures 301
glDepthFunc 178
glDepthMask 942
glDepthRange 88
glDisable 1426
glDisableClientState 1110
glDrawBuffer 56
glDrawElements 2613
glEnable 1549
glEnableClientState 5580
glEnd 248
glFinish 14
glGetError 303
glGetIntegerv 2
glGetString 4
glLoadIdentity 112
glLoadMatrixf 1056
glMatrixMode 464
glOrtho 56
glPolygonMode 222
glScissor 232
glShadeModel 2
glTexCoord2f 992
glTexCoordPointer 3097
glTexEnvf 177
glTexImage2D 1502
glTexParameterf 1210
glTexParameterfv 2
glVertex2f 992
glVertexPointer 1926
glViewport 232
wglCreateContext 1
wglDeleteContext 1
wglDescribePixelFormat 39
wglGetPixelFormat 4
wglGetProcAddress 6
wglMakeCurrent 2
wglSetPixelFormat 1
wglSwapBuffers 56

glActiveTextureARB 812
glClientActiveTextureARB 812
glLockArraysEXT 1926
glUnlockArraysEXT 1926

As you can see, it never called any function to read the frame buffer, nor did it call glCopyTexSubImage2D.

Well, first of all, that wasnt the article where I was saying I read about the textured mirror. I was just quoting something there that might relate in some small way to what I was saying.

Again, I DID NOT!!! say the texture was rebuilt every frame. I said it was rebuilt every few frames.

And yes, I ran the same test earlier this morning and see there is no glCopyTex functions called. Now, I do have a geforce2, and maybe this is something he does for slower cards.

And yes, it is also possible that either I remember incorrectly, or the article I read was incorrect. I dont remember what the article was titled or where I found it. I dont remember if it was JC himself who wrote the article, or someone else. I just DISTINCTLY remember reading the article (this was RIGHT after I added mirrors to my portal engine) and thinking to myself “why would he do it that way…its just as easy to use a mirror matrix to mirror all the geometry” (which is how I did it). Thats the one thing that sticks out in my mind, was thinking exactly that.

Now, I do have a geforce2, and maybe this is something he does for slower cards.

Nope, I have a TNT .

mfugl,steps to render flat mirror are:
assume mirror is in world space
set clip plane
pushMatrix
glMultMatrixf(mirrorMatrix);
reverse face orientation
compute reflected cam position
draw scene from new cam position
restore face orientation
popMatrix
disable clip plane
clear depth buffer
render mirror to depth buffer
or blend it with reflected scene
continue with normal scene

What is the point in having the clip plane here?

What is the point in having the clip plane here?

To prevent objects drawn in the mirror or portal view from poking through the plane of the mirror or portal.

Originally posted by DFrey:
To prevent objects drawn in the mirror or portal view from poking through the plane of the mirror or portal.

In the method I outlined there is no poking through.

Because u use the clip plane!

I can absolutely assure you, having seen the source code to said game and having stepped through our driver many times while running it, that it does use a clip plane for mirrors and portals.

  • Matt

mfugl, in the method you outlined earlier, there could be apparent poke through. Imagine that you are looking straight at the mirror. Now imagine there to be a parallelpiped next to the mirror that extends beyond the plane of the mirror, sort of like this:

             | <- parallelpiped
             |

-----------------|-------------
^ mirror ^ |
|
\ /
O ← viewpoint

In your method the reflection of the parallelpiped could appear to extend beyond the plane of the mirror if its reflection was within the projected area of the mirror.

A clip plane will prevent the real geometry extending beyond the plane of the mirror from being reflected about the plane of the mirror (well, it is reflected, but the plane prevents it from being drawn).

[This message has been edited by DFrey (edited 02-18-2001).]

I don’t get where the discussion has gone.
mfugl sets the clip plane is step 2 or 3. Then he said that he would have no faces poking through after DFrey said clip plane would help with that poking through.

You definetely need a clip plane, and mfugl used it in his attempt. I think you’re talking about the same somehow.

Originally posted by Michael Steinberg:
You definetely need a clip plane, and mfugl used it in his attempt.

Im not positive if you are talking about his scenario in particular, or overall, but to be clear on this topic, you dont ALWAYS need to use a clip plane. You only need to use a clip plane if either
a) you dont use stencil to mask off everything but the mirror.
OR
b) you have objects that physically poke through the mirror itself (not just the plane of the mirror, but the actual mirror).

You need it always unless you won’t use the texture attempt.
If you’re using the stencil buffer, that is to prevent anything what is going outside the shape of the mirror/portal, but that’s for it. It won’t test wether the poly that should be behind the portal really is behind it. So you’ll need a clip plane here. (After all we’re speaking about portals in a bsp engine, not in a portal engine, where the sectors don’T contain any polys that would intersect the portal).

I don’t get your point b) though.

Originally posted by mcraighead:
[b]I can absolutely assure you, having seen the source code to said game and having stepped through our driver many times while running it, that it does use a clip plane for mirrors and portals.

  • Matt[/b]

Well go take a look in the source Matt, and tell us what you see!
(he probably doesn’t understand it )

Originally posted by DFrey:
[b]mfugl, in the method you outlined earlier, there could be apparent poke through. Imagine that you are looking straight at the mirror. Now imagine there to be a parallelpiped next to the mirror that extends beyond the plane of the mirror, sort of like this:

[quote]

             | <- parallelpiped
             |

-----------------|-------------
^ mirror ^ |
|
\ /
O ← viewpoint

In your method the reflection of the parallelpiped could appear to extend beyond the plane of the mirror if its reflection was within the projected area of the mirror.

A clip plane will prevent the real geometry extending beyond the plane of the mirror from being reflected about the plane of the mirror (well, it is reflected, but the plane prevents it from being drawn).

[This message has been edited by DFrey (edited 02-18-2001).][/b][/QUOTE]

You are right that it is nescessary with mirrors, but it is conceptually easier to talk about portals. I can’t see the need when using portals, though we know it is there.

Let me see if I can straighten out this thread.

Michael, originally, mfugl posted a different method, look towards top of thread. He later repeated Michail Bespalov’s method and asked why it used a clip plane.

I answered why Michail used a clip plane. And then showed mfugl an instance where his method would fail without a clip plane.

Ok?

[This message has been edited by DFrey (edited 02-18-2001).]

Yep, got it. Let’s make a conclusion so I know I got it all correctly.

We need to get sorted out these terms. In quake 3 a portal is something that beams someone from one point to another and lets him also look at the destination before, means, the portal and the viewable geometry are not connected physically.
A portal in a portal engine is something that is a window from one convex room to another convex room, which are adjacent on the plane of the portal. And then there are these what I call effects-portal, which do something similar like quake3’s portal. An effects portal of one sector is connected with another one in a different sector (ideally, the portals have the same shape, so you don’t need to beam the user through, you can let him go through). The sectors don’t have to be adjacent in any plane in this case.
q3 and portal-engine effect portals for me are portals of the type 1. Portal engine’s normal portals are portals of type 2.

So you can use portals of type 1 as mirrors, with small changes to the transformation. In a portal engine, any portals are at the edges of a sector, means, there is nothing of the sector behind the mirror, so you won’t need a clipping plane in a portal engine for mirrors (I’m not too sure about it). The zbuffer clearing is unnecessary in some cases.
Same should apply to the type 2 portals in a portal engine.

In a bsp engine, you will not need the clipping plane as well for type 1 portals, when target type 1 portal lies on a bsp clipping plane, because then you could just leave out the geometry that is “behind” this plane, which is a lot cheaper to achieve I think.

Am I talking crap stuff? Judge me.

In a bsp engine, you will not need the clipping plane as well for type 1 portals, when target type 1 portal lies on a bsp clipping plane, because then you could just leave out the geometry that is “behind” this plane, which is a lot cheaper to achieve I think.

Regarding q3 bsp,you couldn’t. q3 doesn’t split faces with bsp.Also it is posible to have patch or triangle model or moving object that crosses portal plane.This will require spliting each frame.

[This message has been edited by Michail Bespalov (edited 02-19-2001).]

Yes I see. Does q3 use depth buffer also for solid geometry then? (I mean, because the faces aren’t split)

q3 has no sw rendering.
you can’t sort transparent surfaces with q3’s bsp.
you can’t sort patches with bsp.
Where is no need to travel bsp from front to back or from back to front I think.
Depth buffer is more efficient than bsp for
hidden surface removal.
Beyond doubt q3 does use depth buffer.

[This message has been edited by Michail Bespalov (edited 02-19-2001).]

Originally posted by Michail Bespalov:
[b]In a bsp engine, you will not need the clipping plane as well for type 1 portals, when target type 1 portal lies on a bsp clipping plane, because then you could just leave out the geometry that is “behind” this plane, which is a lot cheaper to achieve I think.

Regarding q3 bsp,you couldn’t. q3 doesn’t split faces with bsp.Also it is posible to have patch or triangle model or moving object that crosses portal plane.This will require spliting each frame.

[This message has been edited by Michail Bespalov (edited 02-19-2001).][/b]

Regarding rendering a view which includes a portal/teleporter in q3, could you give a problem-example where an extra user clip plane is nessacary?