Yes, its true. Clipping has now been added to the Papervision3D trunk (2.0). For those of you unfamilier with the concept of clipping, it solves a very common and very annoying problem in 3D Engines - and does a few other things too. The problem I'm referring to is when a face is culled when part of it extends past the camera. You have probably noticed it in racing games or other various demos where the camera gets too close to an object and triangles start disappearing. The previous solution was trying various things with zoom levels and being more restrictive with camera position to avoid the problem altogether. Clipping (namely Near plane clipping) resolves this issue by cutting a face into new faces that *don't* pass the camera's fov. Thus, no more disappearing faces.
Something else clipping helps with is not spending time drawing triangles that are outside the viewing frustum. When you use full frustum clipping, faces are clipped to the sides of the screen. Nothing is drawn "outside" the viewable area. In addition, it removes the need to even project vertices that aren't visible to the camera (don't get too excited, it slows things back down by having to cut faces).
Use
So, using it is way to easy. There is really only one class you have to know. FrustumClipping. This class takes 1 parameter which defines which planes you want to clip against. You can use multiple planes to clip against by using a bitwise OR (I). The possible planes you can use are ALL, NEAR, TOP, BOTTOM, LEFT, RIGHT. I didn't include a far plane since it would just add unwanted computations in most instances. If you want it let me know its easy to add now.
So, to set the clipping, you simply assign it to the RenderEngine's clipping property:
-
renderer.clipping = new FrustumClipping(FrustumClipping.ALL);
Now, all objects will be clipped to the planes you specified. You can disable on object being clipped by setting DisplayObject3D.useClipping = false; When that parameter is set, clipping will not be tested and you won't have any performance change.
Features/Information
- Set camera.useCulling. When this value is turned on, you get 2 benefits. 1) Objects outside the frustum aren't considered, but 2) ONLY objects that actually cross a frustum plane will be clipped on. Meaning, objects in the scene that don't touch the edge of the screen are ignored and not even tested.
- Full Frustum clipping is a costly procedure and often unnecessary. If you just need general good clipping, and don't want the overhead, only use the near clipping plane: new FrustumClipping(FrustumClipping.NEAR); I will be working on improving overall performance of the clipping but for now just be aware.
- Papervision's render pipeline now has the following flow: culling->clipping->projection->draw. FrustumClipping only projects and draws the vertices that remain after the clipping test. If you do not use clipping, all vertices will be bulk projected (as before).
- Use less faces when using clipping! If you can get away with it, lower the face count as much as possible. Clipping will add faces where it needs them, but the more faces that have to be tested the slower the performance.
- Set useClipping = false for all objects that don't leave the screen! (doesn't matter if you set culling though).
Demo and Source
and
26 Comments, Comment or Ping
great job!
this definitely solves one of the worse problems of pv3d.
would it be possible to use this way to duplicate every face and double the render quality? I mean, taking a look to demos by alternativa platform I noticed they’re doubling faces during the “idle” and halfing them during interactions….
September 26th, 2008
Hey, great news! Very good job!!!
This enhancement let me sleep a little deeper. ;o)
If someone comes out with an good z-sorting i’m in haven.
Ciao André
September 26th, 2008
If there was a prize for the most amazing blog post of the year…this would be it
September 27th, 2008
This is great Andy, thanks!
September 27th, 2008
WOW!!
amazing result!
September 28th, 2008
great job andy! this is very import for the future of the engine! congrats!
September 29th, 2008
Hi!
Now I’m working on virtual gallery project, now I’m realizing 3D room with pictures. And this solution is just on time for me. But today I found, that for performance it is better my old solution – with camera long away from object (room) and big zoom. Can you advice me something for that?
And I have question about other problem in PV3D: interaction. This is big problem for all 3D frameworks – correctly display interaction, I know. But in my case all objects doesn’t interact: walls, pictures on them. May be any way to tell object that it is solid and must be shown always (pictures)?
September 29th, 2008
Nice work Andy!
September 29th, 2008
This is fantastic!
Great, it really helps for a lot of cases
Thanks guys!
October 1st, 2008
From my side a very big thanks for your work, too. The results are amazing at simple environments and (as Piergiorgio and André already wrote) it’s a very important milestone
As you already mentioned, the performance is the dark side of the medal. By using the NEAR-planes in my test-environment (two rooms with some columns, a skybox and the possibility to walk out of the rooms) the framerate sunk from about 17fps below 8fps. I lowered the number of polygons of the model but the result was not satisfying. The framerate rose about 1fps but the textures were deformed extremely.
Summing up the frustrum clipping is the first step in the right way, but it’s a very long way. I won’t use it at the moment, playing around with camera.focus and camera.zoom is for complex environments a better solution.
October 1st, 2008
@Thomas - You are right - it still needs some work to become the default use case. Some bugs have already turned up and I’ve found some issues that when fixed will hopefully lead to more satisfying FPS. BUT, I am happy that this functionality is available, and it will only be getting faster!
October 1st, 2008
Andy, this is really cool.
I’m seeing some weird z-sorting when the clipping is in action. Specifically, some triangle points from the back wall are showing inside the sphere, possibly due to your solution for keeping the faces out of camera range or something. But overall it works, the missing faces show up! Great work as usual.
October 2nd, 2008
@Moses - What you are seeing is just the ever-present z-fighting issues. Sometimes the spheres will generate next to a wall and z-fighting will cause some tri’s to show through. Working on a solution for that too
October 2nd, 2008
2 words PIMP JUICE
October 2nd, 2008
Absolut great. This solves the problems in my current projekt. thanks, a lot.
October 3rd, 2008
Very cool. But when I set fov and zoom on the camera, the side planes seem to be in the wrong place (sometimes inside the viewport, sometimes outside, depending on the fov I set).
Is the implementation limited to the standard camera settings, or am I doing something wrong?
October 16th, 2008
this has been available in away3d for a while. does papervision handle it any faster than away3d does? also how do the rest of the z sorting options compare?
anyway great to hear that papervision has this now. thanks!
I’ve actually bumped into the article in which the solution was presented to away3d, saying “why cant we just do this” and he had a demo etc. Cool stuff.
October 28th, 2008
Nice, thou the splitting seems wrong at the edges, thats why you use larger frustum than is necessary?
Anyway i added frustum clipping to my 3D engine, which is not yet public but i wrote a post about some optimization especially when splitting with more than 1 plane, if anyone interested its http://blog.flash-core.com/?p=52 another plus to this new method is that it can accept anything on its pipeline (triangles, quads, polys). I am not going into much technical detail there but i think the principle can be grasped.
October 30th, 2008
I think there is a bug with the edges - seems be ok until you rotate the camera. Here’s and example…
http://testing.usecake.com/game2.html
It seems like, when the camera rotates, the scene is clipped before the planes are updated.
December 11th, 2008
Ok I found a fix but I think it will probably need to be optimised.
I’ve basically stuck this:
renderSessionData.camera.updateTransform();
On line 145 — just before this line:
_matrix.copy( renderSessionData.camera.transform );
December 11th, 2008
hi Andy,
I was wondering what camera.useClipping does. Does it do anything? Is it an alternative way of clipping? Or should you use useClipping only on 3d objects, setting it to false?
What is the relationship between useClipping and the FrustumClipping class?
thanks for your great work,
Tony.
April 3rd, 2009
Nice explanation, but by now i’m losing my head, i’m doing a racecar game and having big troubles with the render engine, when i enable culling, the clipping is simply not working, any ideas about that?
August 31st, 2009
@EPOX - you are right. when culling is turned on, clipping doesn`t work (I work with INFO: Papervision3D 2.1 rev920 (August 11th, 2009)).
To get this working you have to add your object which you want to clip not to scene,but to another DisplayObject3D.
Check out my code:
var _loc_1 : DisplayObject3D = new DisplayObject3D();
scene.addChild(_loc_1);
camera.useCulling = true;
renderer.clipping = new FrustumClipping(FrustumClipping.NEAR);
var plane1 : Plane = new Plane(null, 2000, 2000, 8, 8);
plane1.localRotationX = -90;
plane1.y = -100;
var plane2:Plane = new Plane(null, 2000, 2000, 8, 8);
plane2.localRotationX = 90;
plane2.y = 100;
scene.addChild(plane2);
_loc_1.addChild(plane1);
The plane plane2 is not clipped. The plane plane1 is clipped. But I have no idea why
Anybody knows why?
December 5th, 2009
Reply to “Papervision3D - Now Featuring Frustum Clipping”