As multiple users have reported in the past, the clipping plane is still a real pain in the a$$. Unfortunately as useful as it might turn out to be in certain situations, it becomes really painful when you actually want to extract visual data from your file. Both the print and view capture commands produce undesired results.
While thinking that Serengeti must have fixed the issue i came across multiple issues related to displaying the slipped objects.
please find attached files for both 5 and Serengeti as well as images of ScreenCapture(SCTF) vs ViewCapture(VCTF)
Any ideas if these issues will be addressed soon? No Workarounds needed
But even in the extremely simple example you can see that the clipping plane is occupying the same space. How do you clip something with a zero value, if it has no width?
Of course I’m not McNeel so it may be a bug but if your breaking point in the case of a box is still a single surface with the clipping plane occupying the same space then I guess the same problem would occur. Multiple clipping planes applied to multiple surfaces occupying the same space would be horrible.
When you render you’ll see the same issue if you had two fishtanks sat next to one another - you’d either have to remove one face or move them by a fraction of a millimetre to stop.
It s not about planes occupying same “space” as the faces of anything. it’s about bugs in the way clipping planes are being represented. Check the exact same setup in Rhino5 and it will show correctly. Then try to use the -viewcapturetofile command on both files RH5 and RH6 and you will see there is not connection between what is being displayed an what is getting exported as an image file. Use print, and you ll get similar representation errors or whatever they are.
We’ll see. It is a major feature that needs to be added. Once I get new shaders completed and merged with master I’ll be able to work on Clipping Planes and Shadows Only ground plane improvements, more or less the two remaining Huge Features that aren’t in Cycles yet.