Three.js: user defined clip plane

You should be able to get the WebGL context with renderer.context.
From there it's up to you and the WebGL spec :)

I recently encountered the same problem while implementing reflective flat surfaces (aka 'mirrors' :smile: ) into three.js
As far as I know, you can not have user-defined clipping planes with WebGL, at least not with the 'simple' openGL way you described.
The trick is to use the "Oblique View Frustum" method, which is explained in this paper: http://www.terathon.com/lengyel/Lengyel-Oblique.pdf
The purpose of this method is to replace the near clip plane of your mirrored camera frustum by the plane defined by the reflective surface.
There is even some source code provided (in C++ though): http://www.terathon.com/code/oblique.html

I successfully ported that method in three.js and here is a sample scene to show this live: http://jsfiddle.net/slayvin/PT32b/

The only remaining issue is that the renderTarget is rendered a frame behind, and I have no clue why! This causes some flickering when the camera moves too fast and when the mirror is going through other objects.

Any idea on how to fix this? Do I need to implement a kind of multi-buffering method, or is it simply because I don't udpdate the camera matrix after modifying the frustum? If so, how can I do that?

Mmmhh... I've tried setting scene.autoUpdate to false and call scene.updateMatrixWorld() by hand to make sure all the renderers had the same stuff but doesn't seem to solve anything... Neither calling mirror.updateMatrix() before extracting the rotation from there...

Pretty cool though! Maybe we could abstract this into it's own object.

Sweet.

I also tried making sure the relevant matrices were current. If you are worried about lag, you have to update them before you use them. Unfortunately, it did not seem to matter when zooming quickly...

mirror.updateMatrixWorld();

camera.updateMatrixWorld();

camera.matrixWorldInverse.getInverse( camera.matrixWorld );

Hey many thanks guys!!

Your suggestions made me reconsider the problem, and I noticed that there was no 'general' lag, but only flickering when the near clip plane changes (the mirror position compared to the mirrored camera position).

So, you were almost there @WestLangley: it's the matrices of the mirrored camera you need to update, not the camera itself.

Result: no more 'lag' : http://jsfiddle.net/slayvin/PT32b/2/ :smiley:

Maybe we could abstract this into it's own object.

Yes, I've thought about it. It would be great to have a new THREE.mirror() that handles everything. I'll try to code something...