mirrors multiple reflections?

This can be accomplished quite easily with a portal engine. Just reflect the geometry on the other side of the portal and render. This can be done recursively.

Quote:

Original post by crowley9 This can be accomplished quite easily with a portal engine. Just reflect the geometry on the other side of the portal and render. This can be done recursively.

Thanks Crowley9,

I thought that might be the case, and was planning on researching that next.

any game engine you would recommend (for portals, and just in general)? i'm actually thinking of using Valve Source (since i already have the SDK downloaded) but not certain yet. I'm not developing a commercial product, so open source engines would be great also. Too much out there to choose from. C# is best, but c++ fine. If the question is really just to large to answer, no worries, but opinion is valued.

bigshiny90

when i've thought about mirrors for my engine i've always come back to the answer being portals as well, which lends itself to also (as you might guess) having actual portals or viewscreens and so on. ofcourse for a mirror to work you need to do a bit of math on your geometry to actually have it reflect as opposed to look like a portal.

If your renderer supports passes you should be able to set this up pretty easily. Each time you find a mirror object in your frustum culling results, you push a new pass on top (bottom passes are dependent on passes above them). Then just render the pass queue from top to bottom. This could easily lead to infinite recursion in the case you described. So you'll want to eventually stop spawning passes after say 6 or so have been created for this object in this viewport.

This method will give you instantaneous reflections at the cost of doing a bazillion passes per frame. If it's a small mirror or you don't need many bounces, you could just use the previous frame's result. So you'd render each mirror's view once per frame (instead of 6). The first frame will have only 1 mirror bounce, the second frame will have 3, and so on to infinity. The problem is they will become very laggy after 1 bounce.

I'm leaning towards portals...

in my scenario, the surfaces would need to act like mirrors but if walked into, would actually spit the player back into the original room at the new orientation.

it seems that portals would be a more logical starting place for this, though i'll have to do a little more research on it.

thanks all for your replies.

A portal that leads to itself is not a mirror. A mirror flips left-to-right, a portal does not. Walking into a mirror is impossible, you'd come out of the same side; walking into a portal is possible (if you're going sideways, that is), since you'd come out the other side.

Both portals and mirrors are just a concept. The implementation is very similar. You just need a method of describing multiple scenes, each through some type of viewport. Be it a portal or a mirror. The way that you'll collect mirrors and portals during rendering should be identical.

It's recursive:

1.) Frustum cull down, pushing on passes for each portal or mirror found.
2.) Render the passes traveling back up the list, so the required surface information is available.