How severely does this bug affect you? Not much; I’m just letting you know about it.
More an informational bug … the documentation for the fisheye node says it is limited to 180 degrees. Do you mean that a fisheye projection in limited to 180 degrees, or that the node is limited to 180 degrees. Because a fisheye projection is certaintly not limited to 180 degrees, indeed it can be applied to any angle up to and past 360 degrees, although after 360 degrees there is a radial wrapping.
To the operation of the fisheye itself, it is far from ideal. I would propose an option to clip to a unit circle or not … this applies to any angle fisheye. Even 180 is not actually limited to being clipped to the unit circle as in the current node, although that may an implementation limitation, not sure. And it wold be useful to be able to extend the FOV past 180 degrees.
Based on the underlying code, our node is limited to 180 degrees. The current hemispherical fisheye projection code is based on “Realtime Dome Imaging and Interaction” by Bailey/Clothier/Gebbie 2006. If you can point us to a technique that satisfies your criteria (and also produces the same result for FOV < 180), we’d certainly look at incorporating it. The Vignette Width/Sharpness ports can let you clip to a unit circle by setting both to 1. We’ll take a look at making that clearer in the documentation.
As to the more general fisheye, your composition renders a scene 6 times using perspective cameras, then feeds them to an image filter shader to combine them into a circular fisheye image, then renders them to a window. That’s less efficient since it’s performing 8 render passes. We think the already proposed FR, Render scenes to equirectangular panoramas and cube maps could be expanded to include circular fisheye. Would that be an acceptable solution?
I accept there is a performance hit with this approach.
Isn’t the equirectangular solution already also going to be a 6 camera pass? Or a different method?
With regard to the vertex shader used in the current fisheye node, it unfortunately does not give the correct results, unless it internally tessellates the geometry into very small triangle sections. By “prewarping all the vertices” it assumes that a straight line between two vertices is a straight line in the projection … true for a planar projection plane but not true for a fisheye projection. So a triangle that occupies a reasonable amount of the FOV the resulting fisheye is incorrect.
We believe expanding the fisheye camera functionality should be approached as a feature request. Our approach would be to add an input port on the Make Spherical Camera node to allow switching between rendering as circular fisheye and equirectangular (or eventually other formats like cubemap or HEALPix). We think the already proposed FR, Render scenes to equirectangular panoramas and cube maps could be expanded to include this enhanced circular fisheye functionality.
Alternately, if you know of some other approach to implementing support for angles > 180º that would be about equally efficient as the current Make Fisheye Camera, please let us know.
We are labeling this “not a bug.”
Isn’t the equirectangular solution already also going to be a 6 camera pass? Or a different method?
Yes, either image-based method (6 cameras to equirectangular or 6 cameras to circular fisheye) will have roughly the same performance.
So a triangle that occupies a reasonable amount of the FOV the resulting fisheye is incorrect.
This is consistent with what we mentioned in the Make Fisheye Camera node documentation. You can work around that limitation by starting with a finer mesh (more rows/columns on Make Sphere/Square/Tube/Cone/Torus/Gridlines/Supershape/Parametric; more subdivisions in Make Icosphere; using Spike 3D Object as a tessellator).