Am 15.05.2012 21:47, schrieb ingo:
> in news:email@example.com clipka wrote:
>> In order to take full advantage of SVG, we'd need a
>> library capable of probing random points of the image /without/
>> converting it to a bitmap first.
> just interested, would you need points or a rendersize dependent bounding
> box that can be rasterized and then mapped? Like zooming in on the SVG?
I'm not sure whether I understand your question.
In a normal scene it could possibly suffice to rasterize the SVG to a
heuristically determined resolution, e.g. proportional to render image
resolution divided by distance to the camera. But there are various
scenarios where such a heuristic would break down.
There might be ways to employ bitmaps generated from the SVG to improve
speed for large, "flat" areas, but in the end it will be necessary to
have a library that can tell the exact color for an arbitrary point in
2D space, as long as you want any benefit over using an external
SVG-to-bitmap conversion tool.
POV-Ray renders objects by shooting individual rays, and computing the
object surface properties at the ray-object intersection point; at that
time, POV-Ray has no reliable knowledge of how close the "neighbor" rays
will hit, and therefore no way of telling what spatial precision it will
need for looking up the surface properties.
It should theoretically be possible to make POV-Ray aware of the spatial
precision of individual rays, but it would require solving not only an
object's surface function (which describes the object's shape) and its
derivative (which describes the surface orientation aka normal), but
also its second derivative (which describes the surface curvature). This
would have to be implemented for each and every geometric primitive, and
might be far from trivial for some of them.
Post a reply to this message