"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