Would added support for SVG files be of any use to anyone?

I can think of at least one area where they would offer greater accuracy (height
fields) than the current supported file formats. Since at best, the height field
can only be anti-aliased, the result is still "pixelated".

I realize that SVG files are basically just text files, which POVRAY has support
for reading and writing. I suppose someone could write a macro to do this.
However it would be a very large and cumbersome macro, and probably beyond the
scope of what the macro language was originally intended to do, which is why I
think this feature might be of possible use.

Are there any other areas I'm missing where support for vector formats might
provide added benefits?

Post a reply to this message

"Woody" <nomail@nomail> wrote:
> Would added support for SVG files be of any use to anyone?
>
> I can think of at least one area where they would offer greater accuracy (height
> fields) than the current supported file formats. Since at best, the height field
> can only be anti-aliased, the result is still "pixelated".

I'm not sure I understand how this would affect height_field accuracy, or how
the process would work. Since a HF is, by nature, made of triangles, the SVG
'image' would have to be rasterized(?) to produce pixels (so that the standard
HF code could then use them to get triangle vertices.) Am I correct so far?

If so, then how would POV's standard HF code determine what triangle
*resolution* to use to make the HF?

However, I *can* see advantages when using an SVG graphic with one of the HF
mesh generators in shapes.inc (where we can choose the HF resolution.) In such
a case, a very hi-rez, detailed HF could be made.

Ken W.

Post a reply to this message

My apologies.

I had misunderstood how the heightfield is actually constructed. I had thought
that the "height of the triangle area" was what depended on the the pigment
value, when it was more accurate to say that "corners of the triangle" are a
function of the pixel pigment.

It would be kind of difficult to do this for an image that's not pixel based.
Since it is always possible that the area otherwise occupied by a single pixel
could be non-constant. That is a vector path might separte two or more distinct
pigments.

On the other hand when this happens, it might be interesting to see the effect
of "averaging out", or "weighting by area", of the different pigments, to
determine the ultimate height of corresponding triangle corner.

I was ultimatley thinking about how an image, even anti-aliased still would
appear jagged, despite higher resolutions. This would ulitmatley be a result of
that fact that the image is pixel based.

I will try to upload an example when I get home from work.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> "Woody" <nomail@nomail> wrote:
> > Would added support for SVG files be of any use to anyone?
> >
> > I can think of at least one area where they would offer greater accuracy (height
> > fields) than the current supported file formats. Since at best, the height field
> > can only be anti-aliased, the result is still "pixelated".
>
> I'm not sure I understand how this would affect height_field accuracy, or how
> the process would work. Since a HF is, by nature, made of triangles, the SVG
> 'image' would have to be rasterized(?) to produce pixels (so that the standard
> HF code could then use them to get triangle vertices.) Am I correct so far?

Well, your SVG file can be rasterized at any resolution. That means that you can
control the granularity/accuracy of your height_field.

> If so, then how would POV's standard HF code determine what triangle
> *resolution* to use to make the HF?

By using some keyword for accuracy ("resoluton .001", as in vertices per
pov-unit or something) for it.

I sometimes use a low-resolution HF while modeling, just to re-render the HF
source image at a way higher resolution for the final image. Using some SVG
would take care of that, while at the same time eliminating the high memory
cost/parsing time of a 4k*4k HF. And "hf_grey_16" would become obsolete :).

I think this would be a really useful improvement, as scaling your
svg-heightfield would eliminate the chance of artifacts.

Post a reply to this message

Hello

For a svg plugin, it not will just work for HF but for texturing or other stuff,
because the advantage of texturing with povray is for the infinite resolution,
not like basic image as the games we can play, the advantage of image is to
create as we want.

I think that we can create a plugin for add svg when we can use bmp or png, for
texturing, HF, bumpmap, texturemap (it will increase the experience)

Post a reply to this message

PeYo56 -- MmTr1x3 schrieb:
> For a svg plugin, it not will just work for HF but for texturing or other stuff,
> because the advantage of texturing with povray is for the infinite resolution,
> not like basic image as the games we can play, the advantage of image is to
> create as we want.
>
> I think that we can create a plugin for add svg when we can use bmp or png, for
> texturing, HF, bumpmap, texturemap (it will increase the experience)
>   


Note that SVG is fundamentally different from bitmap images, which may 
make it significantly more difficult to handle in POV-Ray, and 
eventually have the whole "infinite resolution" advantage break down.

POV-Ray needs to look up texture values on a point-by-point basis; in 
bitmap textures, this is straightforward: Evaluate the 4 closest pixels, 
and interpolate between them (for bilinear interpolation; or a few more 
points for bicubic interpolation).

For function textures, it is straightforward as well: Just evaluate the 
function for the given coordinates; the same principle applies to 
pattern textures.

For SVG, you have two major options: (a) basically evaluate the whole 
SVG over and over again for *every* point to be looked up; the required 
algorithmical and computational effort might be close to that of a 
moderately simple raytracing engine; or (b) evaluate the SVG once, 
somehow caching the data in a lookup structure of inherently limited 
resolution; this of course would forfeit the main benefit of SVG.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> PeYo56 -- MmTr1x3 schrieb:
> > For a svg plugin, it not will just work for HF but for texturing or other stuff,
> > because the advantage of texturing with povray is for the infinite resolution,
> > not like basic image as the games we can play, the advantage of image is to
> > create as we want.
> >
> > I think that we can create a plugin for add svg when we can use bmp or png, for
> > texturing, HF, bumpmap, texturemap (it will increase the experience)
> >
>
>
> Note that SVG is fundamentally different from bitmap images, which may
> make it significantly more difficult to handle in POV-Ray, and
> eventually have the whole "infinite resolution" advantage break down.
>
> POV-Ray needs to look up texture values on a point-by-point basis; in
> bitmap textures, this is straightforward: Evaluate the 4 closest pixels,
> and interpolate between them (for bilinear interpolation; or a few more
> points for bicubic interpolation).
>
> For function textures, it is straightforward as well: Just evaluate the
> function for the given coordinates; the same principle applies to
> pattern textures.
>
> For SVG, you have two major options: (a) basically evaluate the whole
> SVG over and over again for *every* point to be looked up; the required
> algorithmical and computational effort might be close to that of a
> moderately simple raytracing engine; or (b) evaluate the SVG once,
> somehow caching the data in a lookup structure of inherently limited
> resolution; this of course would forfeit the main benefit of SVG.


It seems like some aspect of this is present and addressed in the object
pattern, since the object also has arbitrary resolution.

I also seem to remember a discussion about using the svg format to allow users
to define a spline, which it seems like another good use for svg.

-Reactor

Post a reply to this message

Reactor schrieb:
> clipka <ano### [at] anonymousorg> wrote:
>   
>> For SVG, you have two major options: (a) basically evaluate the whole
>> SVG over and over again for *every* point to be looked up; the required
>> algorithmical and computational effort might be close to that of a
>> moderately simple raytracing engine; or (b) evaluate the SVG once,
>> somehow caching the data in a lookup structure of inherently limited
>> resolution; this of course would forfeit the main benefit of SVG.
>>     
>
>
> It seems like some aspect of this is present and addressed in the object
> pattern, since the object also has arbitrary resolution.
>   

The object pattern is yet another different animal: It uses code that's 
in POV-Ray anyway; and all it does is test whether a given point is 
inside a single given object or not - there is no need to skim through a 
long list of objects (unless you're using a complex CSG object, but in 
that case things may get slow pretty quickly with the object pattern as 
well).

> I also seem to remember a discussion about using the svg format to allow users
> to define a spline, which it seems like another good use for svg.
>   

I think so, yes.

Post a reply to this message