View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002721 | ParaView | (No Category) | public | 2006-01-13 16:18 | 2009-12-09 14:51 | ||||
Reporter | Ken Moreland | ||||||||
Assigned To | Dave DeMarle | ||||||||
Priority | normal | Severity | minor | Reproducibility | unable to reproduce | ||||
Status | closed | Resolution | unable to reproduce | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0002721: SNL: Camera animation + large object + client/server = zbuffer fighting | ||||||||
Description | Start with a large object (about 1000 units along any axis) with a polygon surface. Make an animation where the camera completely spins around it. Now animate the camera. If you are in client/server mode and the composite flag in the view properties is on, you should see some artifacts appear in the animation. (Note, you really only need 1 process on the server. Actual compositing need not occur, only rendering on the server.) The artifacts appear to be zbuffer fighting. I am guessing that for some reason during animation the near plane of the camera is set to close to the viewpoint. Once you see the artifacts, they remain after you turn the animation off and use the mouse to change the camera. The artifacts go away if you hit the reset view button and return if you go to any time step. | ||||||||
Tags | No tags attached. | ||||||||
Project | |||||||||
Topic Name | |||||||||
Type | |||||||||
Attached Files | animbug.pvs [^] (26,037 bytes) 1969-12-31 19:00 vtkSMRenderModuleProxy.cxx.patch [^] (1,317 bytes) 1969-12-31 19:00 [Show Content] | ||||||||
Relationships | |
Relationships |
Notes | |
(0003569) Ken Moreland (manager) 2006-01-13 18:35 |
I have attached a patch to ParaView/Servers/ServerManager that seems to fix the problem. It changes the behavour of ResetCameraClippingRange to set the range tightly to the object bounds. The previous behavior takes the previous clipping range of the camera and grows it as necessary. The problem with that approach is that it can potentially make the range too big. In the case of this bug, the animation controls left the clipping range the default. When that was mixed with the actual bounds of the object, a range to large was created. The solution I presented will work fine as long vtkSMRenderModuleProxy::ResetCameraClippingRange() gets called every frame. I think this is the case, but I am not sure. |
(0003656) Berk Geveci (administrator) 2006-01-31 11:28 |
This would take 1 day. |
(0005669) user521 2006-11-07 16:39 |
I ran the trace with today's CVS HEAD and I could not reproduce the problem. Printing out the near and far settings does not show the that they are no longer continuously increasing. If this is still happening at your end, let me know and I will look further. |
(0005670) user521 2006-11-07 17:04 |
Sorry about the double negative, what I meant to say was that printing the near and far values does not show them constantly increasing. They appear to be getting reset and rebuilt properly now. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2009-12-09 14:51 | Berk Geveci | Project | @3@ => ParaView |
2011-06-16 13:09 | Zack Galbreath | Category | => (No Category) |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |