How complicate is it to enhance Pov-Ray to do 2D by script to be used for
textures?

Best Rgds,
Holger :)

Post a reply to this message

H. Karsten <h-karsten()web.de> wrote:
> How complicate is it to enhance Pov-Ray to do 2D by script to be used for
> textures?

  I think you'll have to be a bit more specific.

-- 
                                                          - Warp

Post a reply to this message

in news:web.4f9b37f57cf8ee01a3bfeb720@news.povray.org H. Karsten wrote:

> 2D by script to be used
> for textures?

SVG would be nice to have,

ingo

Post a reply to this message

Am 13.05.2012 21:30, schrieb ingo:
> in news:web.4f9b37f57cf8ee01a3bfeb720@news.povray.org H. Karsten wrote:
>
>> 2D by script to be used
>> for textures?
>
> SVG would be nice to have,

... and probably complicated to implement. After all, the normal use 
case for rendering SVG is to rasterize the image, i.e. convert it to a 
classic bitmap image. Even for /that/ it appears to be difficult to find 
a suitable free platform-independent library. And it doesn't give you 
any significant benefit over converting the SVG to a bitmap format using 
some external tool. 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. I doubt that any such library does 
exist at all, let alone a free platform-independent one.

And no, I'm pretty sure the POV-Ray dev team will not put any effort in 
writing such a library themselves, due to the complexity of the format.

Then again, if anyone not yet involved in POV-Ray development would be 
willing to pick up that glove, they might find themselves welcome.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 13.05.2012 21:30, schrieb ingo:
> > in news:web.4f9b37f57cf8ee01a3bfeb720@news.povray.org H. Karsten wrote:
> > SVG would be nice to have,
>
[Snip some good points]
>
> Then again, if anyone not yet involved in POV-Ray development would be
> willing to pick up that glove, they might find themselves welcome.

If someone really wanted this, they could use XSLT to transmorgrify SVG elements
into corresponding POV-Ray objects (with some user-defined thickness)...

....Of course, "Now they have two problems."

Post a reply to this message

Am 15.05.2012 03:58, schrieb waggy:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 13.05.2012 21:30, schrieb ingo:
>>> in news:web.4f9b37f57cf8ee01a3bfeb720@news.povray.org H. Karsten wrote:
>>> SVG would be nice to have,
>>
> [Snip some good points]
>>
>> Then again, if anyone not yet involved in POV-Ray development would be
>> willing to pick up that glove, they might find themselves welcome.
>
> If someone really wanted this, they could use XSLT to transmorgrify SVG elements
> into corresponding POV-Ray objects (with some user-defined thickness)...
>
> .....Of course, "Now they have two problems."

That's fine with me, as long as nobody suggests to implement an XSLT 
processor as part of POV-Ray... >_<

Post a reply to this message

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?

ingo

Post a reply to this message

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