Suggestion for new material type: Mirror

We were just discussing things and came to the conclusion that having a reflective 'mirror' surface ability would be quite a useful thing to have.

Lewis

It's been high on the "wants list" for as long as I've been here... There are rendering issues, I think that make it unlikely, at least with the currnet rendering engine.

It'd be a killer on graphics cards when some idiot decides to build a 1024m2 all mirror building. Could this be why it hasn't been implemented yet?

When thinking of any new "feature" that you'd want to see and can't figure out why LL hasn't done it yet, don't think about how you'd use it, think of how the uninformed or morons would use it.

That could easily enough be overcome by things like limits to how many mirrors you render at any time, or prim distance to the mirror. e.g if the distance were 16m, then a mirror would only reflect things 16m from it, anything else would be ignored, so your 1024m wall would merely appear shiny except at the parts you are close enough too?
Things like limiting it from reflecting reflections as well (thing parallel mirrors creating that endless tunnel effect, they can stop it by just saying "don't reflect reflections".

Even restricted like this it could allow for neat things, mirrors in your home being the major one, but a 'hall of mirrors' could be an application to confuse people in a fair-ground and stuff.

Mirrors would LAG like CRAZY. First off, even the simplist "reflective" property capable of a "proper reflection" essentially doubles the number of triagles the engine has to render (the origginal, which we know SL does do any occlusion) and the copy to be reflected. And because it would be dynamic, you'd need to duplicate all the triagles that the mirror could reflect, in other words, half of what you're already rendering.

If the mirror had a high fall off ration (i.e. only render stuff within 16m) I can fist say that this would be abused. Someone would make a huge totured torus mirror that reflected out to 64m. Second, what color do you make the area that isn't reflecting anything? Third, in addition to #2, make the reflection range too short and it won't look any good and people will just increase it. Fourth, it gets abused again and someone makes a mirror-prim full-body avatar.

A mirror, at the very least, would double every polygon that could be reflected in it. At its worst will double every polygon in the area. This is because the graphics rendering engines are polygon based and not ray traced.

So if you're rendering 1million triangles now, expect to render 2million with mirrors.

And that's only if you have ONE mirror. If you have 2 mirrors expect 3 million triangles to render, so on and so forth.

Actually, not so sure a "mirror surface" would be all that big a problem. I used to be on a tiny little (comparatively speaking) 3-D board that could actually be accessed via dial-up that had a mirror that worked perfectly fine. If they can put together floppy prims, some kind of "reflective" surface shouldn't be all that hard. After all, consider: the screen we see isn't really 3d. It's a 2-d representation of a 3d landscape. A reflective surface is exactly the same; you don't have to reproduce every prim... all you have to reproduce is an inverted "photo" of the 2-d screen behind or to the side of the avatar. So all it would really entail is some angular mathematics and representation of the reflected 2-d image. If that other system could do it, surely SL could as well.

To see an example: visit WORLDS.COM and go down the first hallway, look to your left.

Incorrect. What if I'm looking at a mirror that is parrallel to my camera, and thus allowing me to the the BACK SIDE of an object. That is not a 2D reflection of my screen in any fassion.
Not only that, have you seen the text burned into the right side rearview mirror of a car? "Objects in mirror are closer than they appear." Meaning, that a mirror increases the ray-distance you are from an object, and the perspective between two objects in a line from the mirror (i.e. one is behind the other in the reflection) will be different that if you just looked at them (assuming they are still in line with each other).

HORROR!!! - Think of seeing yourself in a mirror every morning in SL TO!! Arghhhhhh)

I think or know or.. that Xandi Mars have on at her store - Her own sim.. Del Sol.

Its a script of course - you must sit in a chair in front of a mirror - and I have tested that and it WORKS!


.. or mirrors exists in SL but we dont se us - as we AL are Vampires..

/Tina

In my experience with other 3D programs, any mirrored textures can double or triple render times. Talk about rez hell. Eek.

I've asked about mirrors in the past... Wasn't possible but the lindens liked the idea. I don't see why it's not possible. Even Duke Nukem 3D had mirrors.

Instead of rendering the mirror every frame, have the client create a texture of the view in the miror, and only update it every few seconds. You could even make it a slider "Mirror update rate" from 1s down to 10s or "off" (in which case it'd render as shiny).

This means that the image in the mirror would be jerkier than the rest of the view, but mirrors wouldn't impact SL as badly as they do other games... not only would the mirror be less often updated, SL doesn't cull the mesh based on direction... just through LoD and in 1.10 object-object occlusion.

There are more issues than that. The client only asks the server to send it data on objects within its line of sight. Objects behind the character load on a much lower resource priority. Having mirrors would break that feature because now all 360 degrees would need near equal priority for a scene to properly render with more objects being given higher transfer queue levels increasing not just polygon counts but bandwidth for both server and client. And a server with an increased bandwidth requisite means everyone in the sim reiceves things slower overall.

So in addition to bandwidth issues the server would need to load offscreen a completely mirrored copy of all objects behind you. So objects IN view are loaded once, objects BEHIND the avatar are loaded twice, once to recieve the original and once to create a version where all polygons are mirrored. Then it would need to take these mirrored items and run occlusion tests to see which would be visible in the angle percieved by the avatar in relation to the mirror. Then it would need to render the view.

Btw thats what it actually takes to 'just create a texture'. Its not a simple thing.

It is not all that hard, I can even make the texture here

+-----------------------+
| . . . . . . . . . . . . . . . |
| . . . . . . . . . . . . . . . |
| . . . . . . . . . . . . . . . |
| . . . . . . . . . . . . . . . |<--- this is a mirror
|. . Imagine your . . . |
|. . . . .reflection. . . . |
|. . . . . . here. . . . . . |
| . . . . . . . . . . . . . . . |
| . . . . . . . . . . . . . . . |
| . . . . . . . . . . . . . . . |
+-----------------------+

Again I have to point out... this is not that hard to do. It just takes some "creative" thinking.

Treat the mirror as an avatar. Have it "view" whatever is in front of it, take a "snapshot" and display that snapshot inverted on its surface. I think one user already pointed out it could be a "refresh every X seconds" type thing. Not a major problem nor a major lag issue. They could even include a "Mirror" toggle switch for those who are worried about lag and don't want mirrors.

Optionally, you could have a "mirror" that you walk up to and press a button. It takes a snapshot from its point of view, and displays the pic, inverted. Zero lag until the button is pushed, and then only a teeny bit, at the permission of the button pusher.

Whenever someone says "Can't be done" I have to wonder why. As far as I am aware, when it comes to computers there is very little that "can't be done". What it's usually a matter of is skill and imagination.

Those who say "it can't be done" are the ones who wind up kicking themselves when someone else does it.

You missed the point. Taking a snapshot means the entire scene needs to get processed and rendered. For a mirror view this means the objects have to have reverse angles of creation. 'Taking a snapshot' inside a 3d rendered environment isnt the same as hitting print screen on your keyboard. On your keyboard you are just copying the pixel data that has ALREADY been rendered. To handle mirror functionality this means your computer has to do massive ammounts of extra resournce allocation and management. I never said its not possible to do. I said its not WORTH it to do.

Maybe far into the future when the minute you link an object the server builds a custom mesh to send to any clients instead of massive object information and when they have fixed the issues with ONLY realavent data on objects being sent and stop doing these 'full updates' arbitrarily the clients will be in a position to do mirror surface rendering. Its not now and wont be anytime soon.

And a house of mirrors wouldn't be horrible at all.

Wally's Fun House - Event at 11:00PM! Come join the fun!

I didn't miss the point at all. Taking snapshots of a 3-d environment is what SL is all about; it's a bona-fide 3d processing engine. Wanna test it? Hit that little snapshot button and see how long it takes for a picture to appear. Not a lot of lag there.

So rather than "the sky is falling" scenarios, might be realized that this is a feasible concept. If the client doesn't want to see mirrors, he could turn off that option. And again I will point out: I saw a little, tiny, pint-sized 3d board do this very thing. So it not only is possible-- it's been done elsewhere, as a couple of people have already pointed out.

Might be realized that nothing is ever accomplished by standing around and saying "it can't be done".

That said, I absolutely feel that this is something that should NOT be done until a whole slew of other more important things are taken care of. I mean, mirrors would be cute and all, but they are definitely not front-burner top-priority concepts. They're just more unnecessary eye-candy and need to take a way-in-the-back-seat to other more essential SL functions.

The snapshot feature you have on screen doesnt have to do an extra render. It PAUSES updates to the render scene and then grabs the ALREADY RENDERED graphical data currently in the OGL buffers. Thats why its fast. Its not doing some massive ammount of graphical work on its own merits cause the work was already done to get the picture on-screen in the first place.

good point

Good point. Yet, the same would be true for a mirror object. It could snap its surroundings and leave it at that until an object within its range changes, at which time that single object would rez just like they do now to avatars. An avatar's entire viewpoint doesn't suddenly change becaues one new object enters his field of vision. Same with a camera. It wouldn't have to be constantly resolving whole new viewing fields; it would only have to resolve new items... usually the avatar himself that approaches or triggers the mirror.

And again, I have to point out... it's already been done elsewhere. Proof positive that it can indeed be done. Folks can argue all they want about how it can't be done, but that would be like someone arguing it's impossible to land a man on the moon. Apparently it is possible.

The "interest list" that determines what priority textures get loaded (and it seems to be mostly textures, since other aspects of objects (lighting, particles, shadows) have an effect on you even if you can't see them) is a lot more complex than that, and if you just sit there you do load all the objects around you eventually. Mirrors might be an added complexity, yes, and would also change the effectiveness of object-object occlusion, but both the interest list and occlusion are far from perfect and in the worst case you could simply ignore reflections in calculating the interest list and objects in the mirror would take longer before they were fully rezzed.

That's not a big deal.
I'm sorry, I don't understand what you're talking about. The server loads all the object in the sim whether you're looking at them or not, because it has to deal with them in the physics model whether you're looking at them or not (or even whether there's any avatars in the sim or not).
Say what? OK, I REALLY have no idea what you're talking about now. What part of the system are you talking about that's loading these objects twice? The server's not "loading" any textures at all, ever... the server never knows about textures except as 128 bit UUIDs... all this is happening in the client.

Err, the "massive object information" is being sent because it's smaller than a mesh.
It's BECAUSE they provide full information on all objects in draw distance to the client that the client can implement reflection as cheaply as I'm suggesting... because it's already building a full OpenGL model of the environment around the client, and baking another local texture every second or so just means rendering one frame in 10 from a different viewpoint and pasting the result on the mirror surface.

I was referring to the client loading the 2 copies NOT the server for the obvious reason that the server doesnt perform rendering. And that would be because as it loads the data to load (client side) the prims behind you, it would also need to load a mirrored copy. Reflections are inverse of originals so you couldnt just do an offscreen render of the scene from the mirrors point of view. Or when you texture the prim it will be inverse to what a mirror SHOULD display. And if you just inverse the picture you will get perspective distortion of what would really be in a mirror. The only way to get it accurate would be to do an offscreen (memory only) full render of the scene using inverse objects. So you can either load those extra copies into memory (hoggish and faster) or you can just perform run-time inversions along an arbitrary axis of the one copy of the object and render that (horridly slower but less memory requirement).

Mirrors ARE NOT quick. They are not easy. They are not simple by any means and they are not effecient under any circumstance. Comparing the mirror effects capable in FPS games that have NON DYNAMIC scenes and several magnitudes of lower prim counts is also an invalid comparison.

And as for massive object information, currently the client has to be updated with all the size / rotation paremeters on all faces of every prim in an entire object regardless of how much is visible and how much is hidden due to various overlap. If on the other hand the server could do a one-time mesh generation as an object is linked and calculate a texture mapping it could send a single texture with the mesh to reduce the total load. No information on faces or twists would need sent. The 'full update' data refreshes that c urrently hog bandwidth would be no more. And if the calculated mesh+prebake texture is larger than the sum of parts it could still make note of that fact and send the prim data and the CLIENT could set up a queue where it would locally convert any non active object into a mesh for optimized local display.