mirror

mirror is it inposible ?

If you mean one that you can look in and see yourself; yes, I'm affraid it is.

I'm assuming that by the fact you are 'afraid' that it is possible, that this isn't a particularly easy or elegant thing to do? I'm insteresting in this too, but if it's going to be nasty then I'll have to find another way to decorate =)

Actually, I was saying I was afraid it's impossible (afraid as in sorry).

There's no way to do an actual reflection that would show avatars, and making one that reflects prims would:
a) require a space behind it equal to that which is being reflected in front of it (i.e. the entire room)
b) be incredibly hacky and difficult to make dynamic (one that isn't dynamic can be crated by modelling)

Mirrors can't be made in SL.

Sorry...

Does OpenGL not have reflection support? Perhaps it could be put into a feature request with some sensible limits. My only ideas on how to limit would be to have a max of say 4 objects with reflective surfaces per 512m square of land (this wouldn't change buy buying extra plots in the same sim, they would to be spread out).
In addition these would have a limited range, so would only be suitable for use in a room.

Although a hall of mirrors would be awesome, it would also kill most people's computers. A client side limit might be wise in case several adjacent plots have all the mirrors near to their joining edges (ie to cluster them together despite the limit).

It would just be nice to have small mirrors in places, especially when the engine should be capable of it out of the box =)

OpenGL supposts load of nice stuff that isn't in SL. I believe SL's bump mapping is software based, for example. I expect there's still a lot of people using SL who don't have graphics cards capable of some of these more advanced features.

Plus, I'd guess a lot of people wanting to use mirrors would have prim hair with lots of twisty tori in it. It's bad enough rendering all the polys in these once, to do it twice would kill performance.

Implementing reflective surfaces requires a completely different approach to rendering, called raytracing. Real-time raytracing is not yet practical: there are approaches to hardware-supported raytracing that may be possible with dedicated purpose-built hardware no more complex than today's graphics cards, but so far as I know nobody's actually implemented such hardware in any consumer system.

Where videogames DO implement reflection they di it by effectively duplicating the scene behind the mirror. This is practical in a game where the camera angle and scene is controlled, but it's not a useful approach for a free-form environment like this.

Though, for an interesting experience, go have a look at Colony 6 in Devil's Moon.

Actually, these days mirrors in games are created by rendering the scene for a second time (usually at a lower resolution) from the viewpoint of the mirror and then mapping that image onto the surface of the mirror. I haven't seen a game using the duplicated scene method for quite a while now.

The closest approximation I've managed to come up with (short of the incredibly wasteful reproduction of the room in prims) is to use the camera to take a snapshot of the room, apply this as the texture of the mirror and flip it horizontally. With a bit of tweaking of the camera angle and the horizontal/vertical repeats you can create an effect that is at least passable at first glance.

The main drawback to this is that the 'reflection' is really only correct from one angle.

Oh! And I've also tended to find that using 'shiny' with this method tends to detract from the effect, although changing the colour of the prim to slightly darken it compared to the room usually makes it look slightly more believable.

IM me in-world if you'd like to see an example of where I've used this technique

I'm wondering if, perhaps, applying the reversed snapshot to the inside of a hollowed sphere and setting it to fullbright might work nicely? It might be necessary to adjust the FOV when taking the snapshot for this...

Hmm... haven't tried this - I might take a look at trying this out tonight
(in UK and at work currently )

That's still raytracing. What that's doing is performing a single level of raytracing for a specific plane surface only. It's fairly cheap to implement it in the program that's rendering the scene, but it can't be done in the general case by OpenGL except by duplicating the scene behind the mirror, and that's only possible with very careful selection of the scene geometry that's not possible in Second Life. That's why I said it's not possible to do raytracing in OpenGL directly (and also the purpose of the last paragraph of my message... Sable Sunset and you should head over to Colony 6 and check it out).

Technically, an OpenGL implementation could use raytracing to render the scene. It wouldn't be necessary to change the program at all, other than to possibly some flag to turn on the feature and probably some new texture options. But I don't think anyone's going to implement this any time soon... though the necessary hardware to do rendering this way (albeit with '80s-quality realism) should be in reach today.

Bravo Bravo had a mirror that "cheated" by being a sit target.

When you "sit" on the mirror, you stay in your normal pose, but the camera is swung around to the opposite side of the mirror plane. The effect is that the camera is now looking "through" the mirror at your av's original location, creating the effect of your av being seen in the mirror and being inverted.

It would be really, really nice if scripts could take snapshots but I can't see it happening..

My SO bought one of those (or one like it) - it rawks! Damn clever.

If I had to implement mirrors in an SL-like app, I would (per frame) set up the scene with the camera at a point behind the mirror, with the same offset as real-camera-to-mirror, just on the other side of the mirror plane. Clip rendering to the mirror surface (as though it were a window being looked through), render to a texture.

For the buffer actually being displayed, position the camera at it's real position and render as usual, but with the saved tex on the mirror surface.

Have a client-side configuration to allow the user to select the recursion depth (or perhaps make it dynamic by limiting the amount of time aloowed per frame to do mirror stuff)

Any mirror surface past the recursion limit renders with it's normal basic texture - it's up to the builder to supply their own "default" this way. They could choose a generic silver-surface, or maybe even a pre-baked approximation.

Personally, I'd say it's more an approximation of raytracing than actual raytracing.

Thanks for pointing out Colony 6; I've seen reflections done like that in SL before, but it is particularly pretty there.

That's probably the best way to implement raytracing for the special case of surfaces designated mirrors given the limitations of OpenGL, if you don't control the scene. If you do control the scene and you have enough GPU memory to do it in one pass... it's probably going to be more efficient to avoid the extra GPU-CPU-GPU round trip if you can. Check out the location I mentioned in my previous message.

You're performing the same computations that a raytracer would perform to render that particular surface... it just happens that flat perfectly reflective surfaces are the simplest ones to raytrace since you only need to sample one ray. An approximation that doesn't approximate anything is too obscure a concept for my brain.

I could be wrong (and it's quite likely I am since I've just picked up bits and pieces on the subject from all over the place) but if it was actual raytracing wouldn't it calculate where the ray for each and every pixel on the area of the screen covering it ends up after bouncing off the reflective surface?

OK, you're right, it's not actually traversing the surface pixel-by-pixel. I was thinking about the optics being modelled and not the code doing the modelling.

I still don' t think approximation is the right term... because unless you were raytracing the whole scene, and not just that surface, the operation would end up producing the same image.

Bah, I've fallen into a terminology black hole and can't get out. I guess this is one of those places the term raycasting fits. Though that usually applies to radiosity...

heh, sorry about the black holeyness - I don't always use the right words.

I've just noticed a hole in my undertanding of rendering techniques (to do with light sources) I don't have time to fill at the moment (to be honest, I shouldn't even be posting ), and so I can't comment on how fitting "approximation" is.

Isn't raycasting the technique used in the first Doom though?

Nah, I brought up the word.
As I would use it, raycasting is a general term for performing the reverse operation to raytracing... rather than projecting rays from the viewer to the scene, to render the image, you project rays from some other location to modify the textures in the scene.

In radiosity (simplified) you cast sample rays in all directions from a light source, then repeat the operation from that point, and use the result of each intersection to modify the color of the surface, until the reflected rays are too dim to make a difference. This is of course hugely expensive.

In DOOM-type games you basically render the objects you're going to raycast as sillouettes as seen by the light source and project them onto the textures of walls and objects (like baking the shadows of trees and other objects people talked about in a recent thread).

What's being cast in this case is the rendered view of the scene in the mirror, ONTO the mirror.

Oh good, that's what I thought it was. Still gotta get my head around the technicalities though.
Sorry, I don't understand what you're saying here. IIRC the level geometry's drawn using raycasting (can't remember how it was textured) and the objects are all sprites.
Eek, I don't think that technically it's casting (though I can see reasoning why the term would make sense). I believe it's just written straight to the frame buffer (perhaps after some processing for effect).

That would involve a use of the term "raycasting" with which I'm not familiar. Pretty much all these games render by calculating the set of polygons (triangles, actually) visible to the camera and drawing those in some order that keeps more distant polygons from overwriting closer ones. I can't see how DOOM could have done anything differently. I think you're thinking about the lighting.
A reflection can't be written directly to the frame buffer... in fact, it may never be written to the frame buffer because the mirror may be obscured by another object... but it still has to be generated because the first pass (the one that calculates the texture in the mirror) doesn't know what the second pass (the one that calculates the texture for the camera) can see.

And on a modern video card the "frame buffer" is an abstraction, really. It's just another bitmap/texture... that's how overlays work, by doing an extra compositing step between the camera texture and the texture written to the screen. On Mac OS X, you can even have translucent windows from other programs in front of the second life window... though it doesn't do anything good for the frame rate.

Hehe, this conversation's getting past where my technical knowledge stretches and confusing me; so I'm really gonna have to look stuff up if I'm gonna continue further. ^^

What I can say though, is that Doom style rendering doesn't use polygons (in the triangle sense). It doesn't have lighting either (each section is set to a brightness manually). It's actually a realy simplistic engine compared to current stuff: each map was constructed from 2D vectors (not sure that's the right term, but still...) with height values for each segment.