Am 15.05.2012 21:47, schrieb ingo:
> in news:4fb0dd4a@news.povray.org 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