Suggestion for new material type: Mirror

THANK YOU. I've only been saying that THIS WHOLE THREAD.
Check out my reply (post #5)

dracos18, read this as well. You both seem to be assuming realtime full-frame-rate mirrors. The hack I'm talking about doesn't provide that, which is why it's so much cheaper.

The client wouldn't need to load any more copies to generate the "mirror texture". It would do an offscreen render from the mirror's point of view (or, rather, from the point of view of your reflection, clipped to the mirror surface) just like you'd navigated your camera to that location for one frame, and flipped in the viewing plane.
An offscreen render using the same objects from your reflection's viewpoint would be optically identical to a view of this second copy from your viewpoint. There's no reason to load any additional objects.
Photorealistic rendering of mirrors isn't, no. Rendering the texture for a mirror for a single frame at Second Life's graphics quality is no more expensive than rendering a single extra frame of the existing scene. No extra objects need to be loaded. If you allow the image in the mirror to lag and to render at a much lower frame rate (which would be consistent with other effects in SL) it wouldn't have a significant effect on performance. It would be cheaper than Ripple Water.
Indeed, which is why I only brought them up to point out that SL isn't doing the tricks that would require inserting extra copies of objects, and that's why SL's actually got an advantage here.

True, it wouldn't be more expensive than a current frame, but seeing as we only get 10-15 FPS, rendering a mirror would be HALF OF THOSE.

Unless someone manages to figure out how to do that, then it'd be 1/3 or 1/4 or 1/10th. Until you go to insanely low renders for the mirror, you'll have noticable lag. Even at 1/10th for the mirror reduces my frame rate from 10-15 to 9-13.5 and I stop seeing the mirror as a mirror, because I move the camera or whatever and it doesn't change for a full second or more.

No, it isn't, but a whole new render off screen is the equivelent of doubling the number of polygons (and textures, lighting, and everything else), no?
I work with Maya and or 3D studio EVERY WEEK for the last 9 months. I think I know what raytracing costs. Geometry can double and I see no difference in render time. If I use strait bitmap textures, rendertimes don't go up. If I add a light, physics, or any kind of raytracing OR cheapo-hacked reflectivity my render times go up. A lot. From 2-4 FPS to 3-5 SPF (seconds per frame).

Only if the mirror is rendering at multiple frames per second.

What I'm suggesting is that the mirror texture is only re-rendered AT MOST once per second, and at most once every 10 frames.
which is 1/4 what turning on Ripple Water does, and it wouldn't be that high because the rendering for the mirror image would be clipped to the texture boundaries.We're talking about SL, where pivoting the camera off someone's head can stop the whole world rendering for a full second or more, where animations and sounds can be delayed multiple seconds, and where a texture might blur out for a full minute after rezzing... a second's delay before a mirror updates is par for the course.

And for slow camera motion, you can actually do the initial render outside the clipping region and pan it as the camera moves. It won't be perfect, but it'll be less jerky.
It's the equivalent of rendering up to a whole new frame. But it doesn't involve new objects (using up GPU memory with more scenery).
Er, yes, I DID agree that photorealistic mirrors (which is implicitly implied by raytracing, no, you can't do photorealistic without at least doing raytracing) was expensive.

To do the clipping you keep talking about requires at least 2 raytraces--how else do you know where to clip? And what do you do if the prim is tortured or non-cube? A texture doesn't wrap onto a sphere the same way as a reflection would look. And where would you raytrace to?
If you want me to, I'll make up a quick scene in 3D Studio and apply the "reflective" material to a cube and turn off Render Raytracing and tell you how long it takes and show you what it does.

The scene gets rendered twice if you have only ONE mirror.

Each visible mirrored face in the scene will require a separate scene render and clip operation.

You can see how this all stacks up.

Photorealistic mirrors wouldn't be so bad if you're doing raytracing, I think the decrease in framerate should only be logarithmic, so even 10 mirrors should only cut the framerate in half. This is assuming realtime raytracing hardware that we don't have of course

Um....do you even know what raytracing is? It's an ungodly expensive task of drawing a ling from the camera to a point in the scene and seeing what it hits first. Which means you have to check on a Real Number scale (i.e. float calues) and you have to check *every single one.*

And that gets you one pixel.

why in gods name are you wanting a feature implimented as a 'hack'? Bad Idea(tm).

so you intentionally want them to add in a mirror that DOESNT EVEN FUNCTION properly at the cost of slowing down client render capabilities. We DONT want cheap hacks, especially ones that dont even work.

do you not realize that you have to fully render a given viewpoint BFEORE clipping? And even the items completely out of view has to get clipped by occlusion testing which is EXPENSIVE.

I dont use water ripples because of its performance hit either. You're not winning votes on that comment.

And this is part of my and Draco's points. We dont need yet another performance killing feature on top of the other timing issues.

which will be the equivilant of the entire angle being wrong till another mirror texture is rendered. UGLY hack.

no an offscreen render is the equiv of adding additional polygons to the CURRENT render frame. If on the other hand you take a frame of render time to NOT update the avatars point of view and ONLY render the mirror angle you DONT increase polygons but are STILL bleeding FPS away from the avatar and causing skips/jerkiness in the normal scene rendering. Both are bad.


And the only person who seems to understand the technical aspects of what they're talking about. Thank You.

I never said anything else. I just seemed to remember reading that the time complexity of raytracing is O(log N) where N is the number of objects, so I just figured that a mirror would essentialy mean twice so it would be O(log NM) where M is the number of mirrors. Maybe I'm wrong.

It doesn't require any raytraces, it just requires calculating the projected corners of the face... that's what, a dozen mul-adds?
If the surface isn't plane and rectilinear I'd say you're justified in doing anything you want, including generating the texture as if it was plane and rectilinear, turning it "shiny" instead, and leaving it as a loading texture forever.

You're trying too hard, this isn't photorealistic-quality rendering here, this is SL-good-enough-if-it-kinda-works rendering.

It gets rendered one additional time per mirror update, which is less than real time.

Mirrors would be limited like lights, which also cause the same kind of runaway computation problem.

Yes, I knew what raytracing was when I wrote a simple raytracer in 1982.

because this is SL. EVERYTHING in SL is implemented as hacks on top of hacks on top of hacks. Look at animations, vehicles, teleportation, elevators, shiny, flexible, water, flight, sensors, ...
I want them to add a mirror that you can *choose* how well it works, or turn it off completely, the same way they added particles, lights, fog, and everything else in SL.
You'd use the same appricimation as they do for occlusion culling, just base it on the centroid and bounding box of the objects as a whole. It's an optimization, it doesn't have to be accurate.
I turn water ripples on and off, as I feel like. I turn particles, fog, and every other feature and object on and off as I feel like it. This would be another feature you could enable and disable as you like. You would disable it, mirrors would be rendered as shiny, and you wouldn't lose one skerrick of performance.
For slow movement in front of a typical mirror you'd never notice until you got pretty close.
That's another way of saying the same thing, without the implication that you're adding more objects to the GPU's limited memory.

Yes, of course it would reduce FPS to turn it on. Not only do I not contest that, you responded to my comment to that effect, so you know I said it and I have no idea why you're belaboring the point.

It would reduce it less than many optional features that people use, and you wouldn't need to turn it on if you didn't want that loss.