[Bf-cycles] Viewport Cycles visible vertex edges ‘cracked faces’ possible solution? Much faster orthographic Viewport renders.

Brecht Van Lommel brechtvanlommel at pandora.be
Mon Apr 14 14:01:44 CEST 2014

On Fri, Apr 11, 2014 at 4:35 PM, David Black <db4tech at yahoo.co.uk> wrote:
> Viewport Cycles visible vertex edges ‘cracked faces’ possible solution? Much
> faster orthographic Viewport renders.
> Is it possible to fix a 3 year old issue of visible vertex edges (see linked
> images) in a Viewport Cycles rendered orthographic view by using code from
> camera draw routines (see linked blend file)?

We can improve this in some cases, by moving the camera closer based
on the scene bounding box. The problem is that the camera is very far
away. It's on my todo list to work on this. I don't we can reuse any
OpenGL rasterization code here though, raytracing is quite different.

> If already using the same draw routines, the following information may help
> in math problem solving. Recently discovered Blender’s Viewport default 35mm
> view is not the same as a 35mm camera focal length view, let me elaborate,
> to match a 35mm Viewport view a cameras focal length must either be 17.50 or
> default camera sensor size needs changing to 64:00. Only then will both
> views match (see last linked image). Even though previous comparison is
> based upon Perspective camera and Viewport views thought might help identify
> a possible calculation scale variance in draw routines.

I don't understand this, but don't think it's relevant to this problem
anyway. As far as I know the focal length and sensor values are
working correct and are compatible with other software.

> In linked blend file, begin Cycle Viewport render and toggle views using 0
> (zero) key. Around 70% faster render times with small complex objects while
> using orthographic Cycles Viewport render.

This performance difference happens because of the cracks and GPU
rendering. Some rays slips through while others don't, which means you
get divergence and slower rendering when most of the threads wait for
the few threads that are bouncing around inside the sphere.

> PS: While looking through code, found couple of things that may need
> changing?
> __init__.py file:
> --- # Copyright 2011-2013 Blender Foundation
> +++ # Copyright 2011-2014 Blender Foundation
> --- “blender”: (2, 67, 0),
> +++ “blender”: (2, 70, 0),

I'll fix these, thanks.


More information about the Bf-cycles mailing list