Mirrors and portals

[mfugl]

How are mirrors and portals implemented i Q3 and Unreal? I believe none of them are using stencil or destination-alpha. Regarding Q3 I read something about a single extra clip plane...

[Michael Steinberg]

Yeah, q3 is most probably using a clip plane that lies over the "portal", since it isn'T a native portal engine, while unreal is a native sector/portal engine, where the sectors don't intersect. However, these from the front a portal from the back solid portals also have to do some tricks, to only draw where the portal is.

[mfugl]

Originally posted by Michael Steinberg:
Yeah, q3 is most probably using a clip plane that lies over the "portal", since it isn'T a native portal engine, while unreal is a native sector/portal engine, where the sectors don't intersect. However, these from the front a portal from the back solid portals also have to do some tricks, to only draw where the portal is.

I thought unreal was bsp based. But polygons do overlap if you dont do an expensive 2d-convex-polygon clipping for every single polygon. Is there a unreal spec available anywhere?

I dont understand the rest of your english/german http://www.opengl.org/discussion_boards/ubb/smile.gif

[LordKronos]

Actually quake 3 renders a "reflection texture" for each mirror, then when rendering the scene, it can treat the mirrors as regular textured polys. Im not sure where I read it, but I *THINK* it only updates the texture every other frame or so (as a way of amortizing the cost of the "render-to-texture" over multiple frames).



[This message has been edited by LordKronos (edited 02-17-2001).]

[Michael Steinberg]

No, quake 3 is not using textures for the portals. If you switch on r_showtris, you can see that there are triangles.
Unreal seems to be a funny mixture of both, though I think it supports portals natively. In quake 3 that is only an ugly fix. These transport portals (beamers?) are really ugly. You can achieve really great effects when supporting portals which don't lie on the same plane physically. That are leaks in the space it's like moving in another room but you may have moved a lot further.

[Michael Steinberg]

And polygons may overlap, but do not intersect! In every sector there aren'T any overlapping polys, since the sectors have to be convex. Then, you can depth sort the sectors (ie. draw the one behind the farthest away portal).

[mfugl]

Originally posted by LordKronos:
Actually quake 3 renders a "reflection texture" for each mirror, then when rendering the scene, it can treat the mirrors as regular textured polys. Im not sure where I read it, but I *THINK* it only updates the texture every other frame or so (as a way of amortizing the cost of the "render-to-texture" over multiple frames).

[This message has been edited by LordKronos (edited 02-17-2001).]

Yes it could be done that way, though one should think there are better ways. This principle is so expensive, that I find it hard to believe. It would be simpler to:
1) Set the scissorbox to an appropirate area. Render the portal view
2) Clear the z buffer
3) Render the portal-polygon with writing to the framebuffer turned off
4) Render the normal view

Any better suggestions?

Michael: It could still be a texture, if it was generated with this triangle feature on as well.

But what about this single user clipping plane?

[DFrey]

I suspect Quake3 uses the user clipping plane to prevent the scene geometry in the portal from poking out beyond the plane of the portal.

[Michael Steinberg]

Which resolution of a texture would result in pixel exact triangle-lines? quake3's using the user clipping plane and resets the depth buffer after having rendered the portal. Afterwards it just blends a totally transparent portal there, to set the z-values of the portal.

[mfugl]

Originally posted by Michael Steinberg:
Which resolution of a texture would result in pixel exact triangle-lines? quake3's using the user clipping plane and resets the depth buffer after having rendered the portal. Afterwards it just blends a totally transparent portal there, to set the z-values of the portal.


Good point with the texture-thing. The r_showtris dons not work on my Q3???

Generally you have a communication problem. What does "quake3's using the user clipping plane and resets the depth buffer after having rendered the portal" mean?

[Michael Steinberg]

Yeah, I'm sorry for my bad english. I should be trying harder to explain myself better. What I meant is this:
In quake 3, portals are something like cameras whose images can be seen on a plane. Now, to any camera belongs a target. The target is a directed point or plane somewhere in the world. Now, when you want to display the image on the screen, you must cut away the pieces of the world, that would be lying between the screen and the player. That can be done with a user clipping plane, which lies exactly in the plane which the screen (the image of the camera or what you called portal earlier) describes. Now, you've got rendered only the image of the camera. But you rendered parts of the image, which don't lie on the screen, so there's also z information saved which makes it tricky to render the world around the player. Also, there may be parts of the real world around the player which intersect with the image of the camera. A solution is, to clear the z-buffer, and draw poly which is the screen completely transparent. This way, you set the z-information only inside the camera image and the real world can overwrite the picture buffer all outside the camera screen. You will also have set the nearest z there, so the real world will not intersect with the image.

I tend to name it camera, since it doesn't give the feeling that it is part of the world, something like a structural anomaly. It's just a camera screen, and when you get nearer, you get teleported to its target.

[This message has been edited by Michael Steinberg (edited 02-17-2001).]

[XBCT]

Hi!
Michael: Where did you get all this info from? Are you just guessing or do you have some other info?

Greets, XBTC!

[This message has been edited by XBCT (edited 02-17-2001).]

[DFrey]

There exists an OpenGL wrapper that catalogs all the OpenGL functions as they are called. So it is possible to use that tool to reconstruct at least the order of operations. From that info and the details of the scene, it is possible to draw educated guesses. That is at least what I did.

[mcraighead]

Some of us also have access to the source code to said game. http://www.opengl.org/discussion_boards/ubb/smile.gif

- Matt

[LordKronos]

Im not guessing here. I actually read that quake3 uses textures for MIRRORS (not portals).

For portals, from what I read, no it does not use textures. BUT, just because you can see triangle outlines through the portal does NOT automatically mean that texture arent used. Think about it...if you have r_tris on when you build the texture, you will see the triangle outlines in the texture instead of the textured polys.

[DFrey]

I think what you read is incorrect. If it used a texture, it would be slower than rendering directly, and there would be no use for the user clip plane. And JC has already publicly stated that he uses the user clip plane when rendering a portal. And the only obvious reason to use it is to clip geometry in the portal scene to prevent poke through. A simple texture would not have a poke through problem at all since it is just 2D to begin with. And a mirror in Quake3 is the same thing as a portal in Quake3, the portal target is simply implied.

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

[LordKronos]

OK first of all, When I was thinking "portal" I was thinking the "doorway" between 2 connecting rooms. These do not use textures for rendering. If you are talking about the teleportation portals, I think these MIGHT use textureslike the mirrors (although what I remember reading was specifically talking about mirrors.

Also, when rendering the texture, you can use a user clip plane to make sure only the correct geometry shows up in the texture. So the fact that he uses the clip plane doesnt automatically mean he doesnt use textures for mirrors

And as for the speed, as I said before, if you dont update the texture every frame, you will make up the speed difference.

Here is possibly more supportive evidence that textures are used for portals. This is from http://www.quake3arena.com/news/glopt.html


The only weird thing we do with geometry is enabling a single user clip plane when looking through a portal in the game. This usually punts drivers to an unoptimized path, so we don’t use it very often

If he knows that clip planes are usually unoptimized in the drivers, he might figure that it would be best to perform the unoptimized clip-plane-rendering once every several frames and then just use a normal texture the rest of the time.

I guess there is only one thing to do...try to track down the document where I read this. Oh yeah, that will be fun, but I'll try.

[Michael Steinberg]

I wouldn't believe that LordKronos.
XBCT: It's just logical guessing. I'm always good in guessing, but I've a hard time to get practical if you know what I mean.

[Michael Steinberg]

I once ran q3 in 1024*768 (quite slow on my comp...), and the triangle outlines did not blur. For me that is evidence that there is not texture being used.
I'll buy a new comp on my birthday!!! I will use my old TNT then and wait for the NV20, since NVidia always does a good job. That one goes also to you Matt!

Well, to get to english. Can one "poke" another one? Is that murdering? In case somebody knows. http://www.opengl.org/discussion_boards/ubb/smile.gif

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

[Michail Bespalov]

I'm sure q3 uses clip plane.
q3 logs all opengl calls in file
just type in console :
devmap q3dm0
r_logfile 1
Take a look at the gl.log file.

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

Portal is equivalent,the only difference I can see,is how to compute new cam position and new modelview matrix.

Where is a good document about mirrors TimHall_Reflections
you will easy find it or I can email it.

About stencil buffer.q3 doesn't need it
Since q3 always renders portals or mirrors first and then clears depth buffer,parts of
reflected scene outside mirror polygon will be overwriten by normal scene or black sky
(on space map,q3tourney6 for example).
Also,you can create mirror mask with depth buffer.

I don't anything about Unreal.

Sorry for my ugly english.
Michail.

[DFrey]

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.

[LordKronos]

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.

[DFrey]

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

Nope, I have a TNT http://www.opengl.org/discussion_boards/ubb/frown.gif.

[mfugl]

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?

[DFrey]

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.

[mfugl]

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.

[Michael Steinberg]

Because u use the clip plane! http://www.opengl.org/discussion_boards/ubb/smile.gif

[mcraighead]

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

[DFrey]

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).]

[Michael Steinberg]

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.

[LordKronos]

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).

[Michael Steinberg]

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.

[mfugl]

Originally posted by mcraighead:
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

Well go take a look in the source Matt, and tell us what you see!
(he probably doesn't understand it http://www.opengl.org/discussion_boards/ubb/smile.gif )

[mfugl]

Originally posted by DFrey:
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).]

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.

[DFrey]

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? http://www.opengl.org/discussion_boards/ubb/smile.gif

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

[Michael Steinberg]

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.

[Michail Bespalov]

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).]

[Michael Steinberg]

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

[Michail Bespalov]

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).]

[mfugl]

Originally posted by Michail Bespalov:
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).]


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?

[DFrey]

Easy, assume a face to the side of the portal target, extends only partially into the portal target frustum. Now you have two options. You either clip the face to the frustum involving up to 6 plane-plane intersection tests and then project and render the clipped polygon, or you can just project the whole face and clip it by a single plane. Which would you do?

[mfugl]

Originally posted by mcraighead:
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

How about disabling the user clip plane in your driver experimentally, and tell us what artifacts you see when looking at a portal/teleporter ?

[mfugl]

Originally posted by DFrey:
Easy, assume a face to the side of the portal target, extends only partially into the portal target frustum. Now you have two options. You either clip the face to the frustum involving up to 6 plane-plane intersection tests and then project and render the clipped polygon, or you can just project the whole face and clip it by a single plane. Which would you do?

I dont see the picture. The normal frustrum culling should take care of everything.

[DFrey]

If you download the source code to glTrace, you could easily modify it to ignore all glEnable(GL_CLIP_PLANE0) calls, and see for yourself.

[DFrey]

I went ahead and did exactly that, and took a screenshot of the result. Here you can see the artifact I've been speaking of: http://personal.lig.bellsouth.net/~dfrey/noclip.jpg and http://personal.lig.bellsouth.net/~dfrey/noclip2.jpg


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

[mfugl]

Originally posted by DFrey:
I went ahead and did exactly that, and took a screenshot of the result. Here you can see the artifact I've been speaking of: http://personal.lig.bellsouth.net/~dfrey/noclip.jpg and http://personal.lig.bellsouth.net/~dfrey/noclip2.jpg


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

GlTrace is a nice utility. I can see that some geometry may get in the way if it is placed near the back of the target view of the portal. I guess there is none with most of the portals, so the clip plane could often be optimized away.

It's nice that we finally reached 'the way' Q3 does this thingy http://www.opengl.org/discussion_boards/ubb/smile.gif

Now we could need some info on Unreal!!

[LordKronos]

DFrey,
Am I missing something, because I dont see the problem in the second image.
http://personal.lig.bellsouth.net/~dfrey/noclip2.jpg

As far as I can tell, thats supposed to be how it looks.

[DFrey]

No, that dark part in the portal image is not supposed to be there since it is behind the portal target. Try going to that spot in q3dm7 and see if you can see it. You shouldn't be able to see it, instead you should see the farther away curved wall.

See: http://personal.lig.bellsouth.net/~dfrey/q3dm7_clipped.jpg


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

[LordKronos]

Yeah, now I see it. I actually modified glTrace so that it only enables the clip plane if the shift key is down. The strange thing I noticed was that even with the clip plane disabled, none of the geometry extended outside of the portal. You could see it through the portal, but that's it.

[DFrey]

Exactly, because after all the geometry in the portal is rendered, the depth buffer is cleared, and then the portal surface is blended over it, preserving the portion of the errorneous geometry that is within the projected area of the portal, and then the rest of the scene is drawn, overwriting the portion of the erroneous geometry that is outside the projected area of the portal.

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

[Tom Nuydens]

From NVidia's OpenGL performance FAQ:
23. Are user-defined clip planes hardware accelerated?
Yes, a number of user-defined clip planes are hardware accelerated through use of texture mapping and special hardware features.

The next paragraph in the FAQ explains that every unused texture unit buys you two hardware-accelerated clipping planes. This means that, strictly speaking, LordKronos wasn't wrong when he stated that they use texture mapping for the portals http://www.opengl.org/discussion_boards/ubb/smile.gif

- Tom

[LordKronos]

Originally posted by Tom Nuydens:
The next paragraph in the FAQ explains that every unused texture unit buys you two hardware-accelerated clipping planes. This means that, strictly speaking, LordKronos wasn't wrong when he stated that they use texture mapping for the portals http://www.opengl.org/discussion_boards/ubb/smile.gif

Nice try Tom, and thanks for the defense, but when Im wrong, I guess Im wrong. That surely wasnt what I was referring to.

After extensively looking for the document I read over a year ago, I still cant seem to find it. I was thinking about it, and maybe it was an old one (when he first started Q3) where John was talking about what he PLANNED on doing in quake 3, or maybe it was even quake 2. I did find in a Quake 3 FAQ (http://www.pavenet.net/users/westmore/faq.html) this bit of info:



Previously, the engine couldn´t handle more then 1 static mirror at a time. In Q3A, multiple views can be reflected allowing to create dramatic effects such as rotating mirrors, etc. John Carmack has warned, that use of rotating mirrors will make a huge hit on the pefomance.

Two things here. First it says that quake2 had a 1 mirror limitation. This may indicate that he set aside one texture for a mirror texture. Second of all, he said that rotating mirrors in Q3 will be a huge performance hit. Im not sure what would be so huge about this unless he planned on generating textures for the reflection. Otherwise all he would have to do is build a single reflection matrix from 3 points each frame (not exactly a noticable performance hit).

So, In retrospect, I think the artice I read was either talking about the quake 2 engine (I dont have the game, so I cant confirm anything) and/or an early version of the quake 3 engine.

[LordKronos]

By the way, since it was brought up, for anyone who is curious about why clip planes use up texture units on nvidia cards, here is what I think is going on...

Think of implementing a clip plane as a 2D 2x2 texture. This 2x2 texture has a left column, a right column, a top row, and a bottom row. The left column means "clipped by clipping plane 0", whereas the right column means "not clipped by clipping plane 0". The bottom row means "clipped by clipping plane 1" and the top row means "not clipped by clipping plane 1". Now, if you assign an alpha value of 1 to the top right texel, alpha values of 0 to the other 3, and enable the alpha test, any fragment that doesnt get textured with the top right texel will not be visible (ie: it will be "clipped"). Then you just use the appropriate texgen modes to select the appropriate texel based on whether or not the fragment lies in front of or behind the corresponding clip plane (ie: clip plane 0 is used to configure s-coord tex gen, and clip plane 1 configures t-coord tex gen).

Thats my take on it, and I might even be wrong (any comment matt?). Thought it might be insteresting to some, and perhaps it might even give you other ideas.

[DFrey]

Interesting, trick for accelerating clip planes. It does give me some ideas http://www.opengl.org/discussion_boards/ubb/biggrin.gif. I wonder if the TNT does something similiar. That OpenGL performance FAQ doesn't cover the TNT so I have no idea.

[Tom Nuydens]

Knowing that the clipping planes burn a texture unit, I figured I'd try if I could push the driver into software by creating a Q3A map with recursive mirrors.

I couldn't - it never actually enabled more than one mirror at a time. I don't see any logic in how it decides which mirror to enable. Furthermore, when a mirror goes "blank", the picture in it sort of fades out.

I've taken some screenshots of this, at http://www.gamedeveloper.org/delphi3d/misc/temp . The mirror*.jpg files show how only one mirror is active at a time, the fade*.jpg files show how the image in a mirror fades to black when the mirror is disabled.

I wonder if this was done on purpose to prevent the software fallback?

- Tom

[EDIT] I did manage to get it to display two mirrors next to one another by placing a single misc_portal_surface entity between them, as shown in 2mirrors.jpg at the above URL. Strange.

[This message has been edited by Tom Nuydens (edited 02-20-2001).]

[DFrey]

I suspect those 2 mirrors were able to work because they were in the same plane and using the same entity (so as far as the engine was concerned that describes one mirror?). I got to looking at the fading out effect, and I think that is just a bug. Try using the gauntlent while looking at the reflections of the blacked out mirrors. The resulting saturation surely was not something id desired. For the blackened mirrors, it appears the mirror routine starts to draw the mirror by blending a quad and then abruptly aborts, it appears to be the same texture that it uses at the start of rendering each one. Ironicly it also still clears the depth buffer for each mirror. Just appears some logic (with poor hysteresis) uses viewing direction and lighting to determine which mirror to complete.

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

[XBCT]

Hi!
Now I read my way through this whole mess! http://www.opengl.org/discussion_boards/ubb/smile.gif

Hmm...If I understand everything correctly the way Q3 does it´s mirrors is very slow and unelegant. ´Cause if I get it right you render the whole scene from the portal´s camera first and afterwards you render the whole scene again as seen from the player´s viewpoint. This means that a mirror might easily double the poly-count. And you render alot of unseen polys ´cause all those polys lying outside of the mirror-poly are never seen in the final image....

Are you really sure that Q3 does it this way?
On my machine the mirrors don´t slow down the game that much. The big mirrors yes but not the teleporters.

Greets, XBTC!



[This message has been edited by XBCT (edited 02-28-2001).]

[mfugl]

As I see it it is more or less the 'only way'. I guess the z-buffer clearing could be avoided if splitting up the z-buffer.

Most of the portals in Q3 are placed at locations with very little geometry, so the polygon count doesn't get too big.

Actually map q3dm0 in front of the mirror kills my fps tremendously, something like a factor 5 compared to average framerate. All the portals render very good.

[mfugl]

Originally posted by Tom Nuydens:
Knowing that the clipping planes burn a texture unit, I figured I'd try if I could push the driver into software by creating a Q3A map with recursive mirrors.

I couldn't - it never actually enabled more than one mirror at a time. I don't see any logic in how it decides which mirror to enable. Furthermore, when a mirror goes "blank", the picture in it sort of fades out.

I've taken some screenshots of this, at http://www.gamedeveloper.org/delphi3d/misc/temp . The mirror*.jpg files show how only one mirror is active at a time, the fade*.jpg files show how the image in a mirror fades to black when the mirror is disabled.

I wonder if this was done on purpose to prevent the software fallback?

- Tom

[EDIT] I did manage to get it to display two mirrors next to one another by placing a single misc_portal_surface entity between them, as shown in 2mirrors.jpg at the above URL. Strange.

[This message has been edited by Tom Nuydens (edited 02-20-2001).]


With the technique we have been talking about, it should not be a problem with several mirrors and with multiple itterations as long as the mirror is rendered first. So it's starnge that Q3 does not have this feature. It would really kill performance though.

[DFrey]

You can go to Gamasutra and listen to Brian Hook's GDC 2000 presentation. He explains how mirrors and portals work (actually outlines the code that we have already presented above), and why they decided to make them non-recursive. Of course the presentation covers much more than just mirrors and portals.

[This message has been edited by DFrey (edited 03-01-2001).]

[Pentagram]

Has anyone tought of the Quake1 source code. Quake1 also had mirrors (set r_mirroralpha to 1)

[DFrey]

Those were hacks plain and simple.

[XBCT]

Hi!
Thanx for replying guys.... http://www.opengl.org/discussion_boards/ubb/smile.gif
Very dissapointing....I hadn´t expected such a crappy solution from Carmack.
It´s the easiest and slowest solution I can think of. Although I don´t have a better idea right now, I´m sure there are more effective ways of doing mirrors(Especially without that much overdraw). Does anyone happen to know how they are done in Unreal?
If you remember Unreal´s impressive Intro with those reflective floors and surfaces.
It runs really fast although there are *alot* of mirrors.

Thanx in advance, XBTC!

[This message has been edited by XBCT (edited 03-01-2001).]

[This message has been edited by XBCT (edited 03-01-2001).]

[Roderic (Ingenu)]

I'm sorry not being able to help more on the subject, I'm both tired and busy at the time so the only way I can help you is to point you to this Portal Engine tutorial : http://www.flipcode.com/portal/

I think they are other docs about portal rendering on flipcode.

[Tom Nuydens]

Originally posted by XBCT:
Very dissapointing....I hadn´t expected such a crappy solution from Carmack.
It´s the easiest and slowest solution I can think of. Although I don´t have a better idea right now, I´m sure there are more effective ways of doing mirrors(Especially without that much overdraw).

My gut instinct would be that they could've used the shape of the portal to clip away additional geometry on the other end. I.e. transform the portal polygon so that it's relative position to the teleport destination is the same as that to the player, then construct clipping planes around the displaced portal.

However, I don't see this working very well for a non-portal engine. They use a PVS, and dynamically throwing in some extra clipping planes wouldn't really work, I think. A pure-portal engine would have an advantage here.

I guess they could've also used the stencil buffer to avoid the additional Z-buffer clear (clearing Z and stencil could be a bit faster than clearing Z twice?), but stencil support was a bit iffy at that time.


Does anyone happen to know how they are done in Unrea?
If you remember Unreal´s impressive Intro with those reflective floors and surfaces.
It runs really fast although there are *alot* of mirrors.

I don't recall ever seeing more than one mirror at a time. If anyone has Unreal and knows UnrealEd, maybe he could try to create a small map with recursive mirrors in it?

At http://unreal.epicgames.com/UnrealFeatures.htm, they mention something about "Dynamic Scene Graph" technology, but as usual they say nothing about how it works. Is Unreal a pure portal engine by any chance?

- Tom

[DFrey]

Unreal is a portal based engine so reflections are no more difficult to handle than a doorway from one sector to another. It also is capable of handling recursive reflections, though I never stopped to count how deep the recursion was taken. Off the top of my head I remember a level in which the north wall was a portal to the south wall, and the east wall was a portal to the west wall, and vice versa and it had a recursion depth of at least 3 iirc. The effect was rather wild.

[XBCT]

Hi!

First of all thanx alot for your answers....

>However, I don't see this working very well for a non-portal engine. They use a PVS, and dynamically throwing in some extra clipping planes wouldn't really work, I think. A pure-portal engine would have an advantage here.<

Yes this might be possible but as you said I can´t imagine how it would work efficiently with a PVS\BSP approach.

>I guess they could've also used the stencil buffer to avoid the additional Z-buffer clear (clearing Z and stencil could be a bit faster than clearing Z twice?), but stencil support was a bit iffy at that time.<

Those people here who have used this utility which logs all OpenGl calls have never reported that Q3 makes use of the stencil buffer....And as you said stencil-buffer support wasn´t that great at the time and I think the mirrors even work on a voodoo1(which AFAIK doesn´t support a stencil buffer, although I´m just guessing here http://www.opengl.org/discussion_boards/ubb/smile.gif).

DFrey: Yes Unreal really has a very impressive engine and I still find it´s engine as good as Quake3 if not better in terms of features and image quality although it is alot older....Especially the lighting always impressed me.

Greets, XBTC!





[This message has been edited by XBCT (edited 03-01-2001).]

[Space Dog]

I'm not sure anyone realizes this (maybe you do), but mfugl's method simply can't support multiple mirrors/"portals" of any kind. (All further references to mirrors and "portals" in this message will be just "mirrors".) Here's his method again:

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

Now think about it. You're using the depth buffer clear and the later mirror render to eliminate geometry outside of the mirror. However, once you do the first mirror, you run into two problems...

1) How do you render the next mirror without potentially overdrawing the previous one with polys from the second mirror?

2) Even if the mirror poly isn't overdrawn, your second depth buffer clear will finish it off for good.

If you could solve problem one by somehow blocking the overdraw (stencil buffer? multiple clipping planes?) you could solve problem two by drawing all the mirror polys simultaneously. However, this doesn't take into account recursive mirrors.

I'm not as knowledgable about OpenGL as most of you, so am I making any sense here?

[Phill Poly]

Originally posted by Michail Bespalov:
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).]

No, I suppose DepthBuffer is not good solution because angle of camera always changes to mirror therefore we get bad quality. Is'not it? We have to clip all faces and each face(which crosses plane) as well!

[Michail Bespalov]

Hi
Space Dog,you are right,this method can not handle multiple mirrors.

But we are talking about mirrors in q3
and q3 works only with one mirror.

Take look at
'Improving Shadows and Reflections via the Stencil Buffer' by Mark J. Kilgard.

Method described in this paper can handle
multiple recursive mirrors.

Thanks.

[mfugl]

1) How do you render the next mirror without potentially overdrawing the previous one with polys from the second mirror?

- you should render the second mirror first.

[kaber0111]

Didn't really read _all_ the posts..

but, www.gamasutra.com (http://www.gamasutra.com) has a video from brian talking about how they did this..

pretty trvial.

[CGameProgrammer]

Seems to me you would *not* clear the depth buffer. Instead, you'll change the depth range. If the comparison is GL_LEQUAL, and the regular range is 0..1, then when you want to draw the mirror, you'll change the range to -1..0. That way, the mirror polygons will be drawn over anything previously drawn. When you're done drawing the mirror, um... I don't know if this is possible, but you'd try drawing the mirror's surface itself as an invisible polygon, with z-reading disabled but writing still enabled, so it would set the depth buffer to the appropriate values... but if you've already drawn stuff in front of the mirror that obscures it, the mirror will poke through it. With back-to-front rendering, it should be OK, though...