 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bill Pragnell <bil### [at] hotmail com> wrote:
> Well, it'd certainly be nice to be able to use SVGs as image_maps - no
> interpolation required! I know you can almost do this already with object
> patterns but it's a bit fiddly. Would it also cut down on memory usage if
> you had many simple image_maps?
How would you determine that a given point is, for example, on a
polyline or inside a polygon?
The thing with vector graphics is that they are easy to draw as a whole:
Just draw a line for each line in the input, fill polygons for filled
polygons, and so on. However, if you have to determine for a random point
what is its color, it becomes a bit more complicated.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> How would you determine that a given point is, for example, on a
> polyline or inside a polygon?
Well, you know the line thickness. Just represent lines as additional
polygons then process only polygons (for example; there's bound to be a
quicker way).
> The thing with vector graphics is that they are easy to draw as a whole:
> Just draw a line for each line in the input, fill polygons for filled
> polygons, and so on. However, if you have to determine for a random point
> what is its color, it becomes a bit more complicated.
It might not be trivial but it's hardly insurmountable. You know the
stacking order, surely it's just a matter of working down that until your
point is inside a polygon or you run out of polygons to test? It can't be
much more complicated than interpolating bitmaps.
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The thing with vector graphics is that they are easy to draw as a
>> whole:
>> Just draw a line for each line in the input, fill polygons for filled
>> polygons, and so on. However, if you have to determine for a random point
>> what is its color, it becomes a bit more complicated.
>
> It might not be trivial but it's hardly insurmountable. You know the
> stacking order, surely it's just a matter of working down that until your
> point is inside a polygon or you run out of polygons to test? It can't be
> much more complicated than interpolating bitmaps.
Or just stack the polygons in the Z direction, then use an orthographic
camera and trace a ray along the Z direction, ... ermmm, hang on :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge <stb### [at] THIShotmailcom> wrote:
> If this were implemented, it would be nice if the user were able to call
> on individual layers of the image.
SVG doesn't use layers like Photoshop, AFAIK.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 15 Jun 2007 14:56:10 -0400, SharkD wrote:
> SVG doesn't use layers like Photoshop, AFAIK.
Inkscape's "Plain SVG" export includes layer functionality, though, using
the <g id="LayerName"> tag. Surely that's something that could be parsed
on, and as plain SVG, I'd assume it's standards-compliant.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Btw, this is a good example of why POV-Ray needs a new SDL, and it has
been planned for pov4 to have one. If someone wants eg. support for SVG
in povray, he can simply go and implement an SDL script which reads the
SVG and then eg. creates a shader from it. No need to patch the binary
nor contaminate the already-cluttered keyword namespace.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> Samuel Benge <stb### [at] THIShotmailcom> wrote:
>> If this were implemented, it would be nice if the user were able to call
>> on individual layers of the image.
>
> SVG doesn't use layers like Photoshop, AFAIK.
>
Not layers in the sense that each object has the same dimension. But SVG
files ARE comprised of separate objects which are placed in "layers".
One on top of the next, just like Adobe Illustrator files, Macromedia
Freehand files, or any other vector graphics format. A layer is a layer
because object three came after object two, and so forth. So I guess you
could call them object number one, two, etc., instead of "layers" if you
wish.
~Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You should remember that SVG is a format exclusively intended to be
rendered to a raster output. I don't think there is any SVG interpreter
that does something different like the backwards rendering required by
POV-Ray (i.e. the possibility to determine the color at an arbitrary
point without rasterizing the whole SVG at a certain resolution).
A lot of SVG features would be very difficult and extremely slow to
access this way. This means even if support for this existed it would
be more efficient to generate a raster image from the SVG at the
required resolution before.
Christoph
--
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous apporta ses lumieres en ce 2007/06/15 07:06:
> Bill Pragnell <bil### [at] hotmailcom> wrote:
>> Well, it'd certainly be nice to be able to use SVGs as image_maps - no
>> interpolation required! I know you can almost do this already with object
>> patterns but it's a bit fiddly. Would it also cut down on memory usage if
>> you had many simple image_maps?
>
> How would you determine that a given point is, for example, on a
> polyline or inside a polygon?
>
> The thing with vector graphics is that they are easy to draw as a whole:
> Just draw a line for each line in the input, fill polygons for filled
> polygons, and so on. However, if you have to determine for a random point
> what is its color, it becomes a bit more complicated.
>
You could use a method similar as the one used for fonts rendering. After all,
TTFs are a kind of, specialised, vector drawn images. At least, that's what it
looks like when you use a font editor to create or modify a font file.
--
Alain
-------------------------------------------------
"The way England treats her prisoners, she doesn't deserve to have any."
--Oscar Wilde
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> You could use a method similar as the one used for fonts rendering. After all,
> TTFs are a kind of, specialised, vector drawn images.
Actually I don't know how povray renders ttf fonts. However, my guess
is that it creates a kind of prism object from the text using the font.
In other words it doesn't evaluate the font for each ray, but only a
precalculated prism. (Please someone correct me if my guess is wrong.
It would be interesting to know.)
If this is so, then font rendering in povray is quite a different thing.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
