Nicolas George wrote:
> Neither solution are satisfactory. For a long time, I think that PoV is
> missing a way to cleanly deal with coincident surface: some declaration in
> the scene that says "these surfaces are *meant* to be coincident, you must
> handle them that way"

But how would it handle which texture to process first?

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Warp  wrote in message <462b9e75@news.povray.org>:
>> The encoding can be wrong.
>   How?

The XML declaration holds an encoding indication. The editor is not supposed
to parse it, therefore it will save the file in whatever encoding it
chooses. If the two encodings are not compatible, it will break. XML files
will often be in UTF-8, and editors will often save in ISO-8859-1 or
CP-1252.

>> The copy operation can insert strange markers (wrap indicators, for example;
>> it seems that it the case here).
>   XML shouldn't break if extra whitespace is added between elements.

"Wrap indicators" are not whitespace. For example, for a long time, I had
Vim configured with "showbreak=>", which means that when a line is too long
to fit on a single terminal line, a blue ">" was displayed at the left of
the second terminal line. It breaks mouse-based copy-paste, because this
blue ">" was copied along with the text.

>> The paste operation can re-wrap or re-indent the lines (which has no
>> consequence on XML validity, but can harm the result if some elements are
>> space-sensitive like the HTML <pre> element).
>   I can't even begin to imagine why an SVG would contain such an element.

That is true for basic SVG, but with SVG+CSS, you can do a lot of things. It
is enough to have "white-space: pre" in the style for some element.

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> Neither solution are satisfactory. For a long time, I think that PoV is
> missing a way to cleanly deal with coincident surface: some declaration in
> the scene that says "these surfaces are *meant* to be coincident, you must
> handle them that way"

  Yes. The way to to say that is to tell povray "this surface is lower
than this one". And you do that by translating the surface a bit.

-- 
                                                          - Warp

Post a reply to this message

Chambers  wrote in message <462ba23c@news.povray.org>:
>> Neither solution are satisfactory. For a long time, I think that PoV is
>> missing a way to cleanly deal with coincident surface: some declaration in
>> the scene that says "these surfaces are *meant* to be coincident, you must
>> handle them that way"
> But how would it handle which texture to process first?

That is exactly the point: we need a way to tell PoV what to do.

 From a theoretical point of view, it is quite trivial: if two objects use
the same surface, PoV computes only once the intersection, applies the
user-given rules to determine which one comes first, and keeps a flags for
any light ray it must then follow from this point.

 From a practical point of view, devising a syntax for that would require to
example all possibilities, but it can be done.

Post a reply to this message

Warp wrote:
> Nicolas George <nicolas$george@salle-s.org> wrote:
>> The encoding can be wrong.
> 
>   How?

I suspect he means something like UTF-8 getting turned into ASCII.

>> The copy operation can insert strange markers (wrap indicators, for example;
>> it seems that it the case here).
> 
>   XML shouldn't break if extra whitespace is added between elements.

This is incorrect. XML in general is whitespace-sensitive.

>   I can't even begin to imagine why an SVG would contain such an element.

There is that.

-- 
   Darren New / San Diego, CA, USA (PST)
     His kernel fu is strong.
     He studied at the Shao Linux Temple.

Post a reply to this message

Warp  wrote in message <462bb8eb@news.povray.org>:
>   Yes. The way to to say that is to tell povray "this surface is lower
> than this one". And you do that by translating the surface a bit.

And you get inter-reflection and such.

Furthermore, translating a surface is not always easy.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Nicolas George <nicolas$george@salle-s.org> wrote:
> >> The encoding can be wrong.
> > 
> >   How?

> I suspect he means something like UTF-8 getting turned into ASCII.

  I can't imagine why that would break XML, especially something like SVG.

> >   XML shouldn't break if extra whitespace is added between elements.

> This is incorrect. XML in general is whitespace-sensitive.

  The only thing which I can think can break is text strings, but even
that doesn't *break* the XML file, it just changes the text strings in
it. It should still be fully valid and readable.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>> I suspect he means something like UTF-8 getting turned into ASCII.
>   I can't imagine why that would break XML, especially something like SVG.

Well, in general, if the tag name is in Chinese, and you try to 
represent it in ASCII without doing some sort of transcoding, chances 
are it's not going to come out the same.

>>>   XML shouldn't break if extra whitespace is added between elements.
>> This is incorrect. XML in general is whitespace-sensitive.
> 
>   The only thing which I can think can break is text strings,

Err, no. If a tag is defined to not contain a body, then
<tag a="b"></tag>
and
<tag a="b">
</tag>
are two different elements.

In general. Likely something like SVG would be defined to ignore 
whitespace. But you actually do have to ignore it.

> that doesn't *break* the XML file, it just changes the text strings in
> it. It should still be fully valid and readable.

It may still be XML. Just not the XML you thought it was. In much the 
same way as I can take an XHTML file and change <h1> to <x1> everywhere, 
and it'll still be fully valid and readable, but it won't be xhtml.

-- 
   Darren New / San Diego, CA, USA (PST)
     His kernel fu is strong.
     He studied at the Shao Linux Temple.

Post a reply to this message

>> Neither solution are satisfactory. For a long time, I think that PoV is
>> missing a way to cleanly deal with coincident surface: some declaration 
>> in
>> the scene that says "these surfaces are *meant* to be coincident, you 
>> must
>> handle them that way"
>
> But how would it handle which texture to process first?

You could specify textures for boundaries rather than objects.

So the default would be the texture for the object/air boundary (same as 
existing syntax), but then you could specify additional "textures" for 
boundaries between two objects (eg glass/wine).  There could even be default 
boundary textures computed automatically using some (physically correct?) 
algorithm.

And then there could be a configurable "minimum gap", below which POV would 
assume two surfaces were coincident.

Post a reply to this message

Am Sun, 22 Apr 2007 15:36:42 -0400 schrieb Nicolas George:

> 
> That is exactly the point: we need a way to tell PoV what to do.
> 
>  From a theoretical point of view, it is quite trivial: if two objects use
> the same surface, PoV computes only once the intersection, applies the
> user-given rules to determine which one comes first, and keeps a flags for
> any light ray it must then follow from this point.
> 
>  From a practical point of view, devising a syntax for that would require
>  to
> example all possibilities, but it can be done.

I thought about that for a long time, too. The "solution" I came up with
is to make a difference between shapes and materials. Then we could apply
rules for the boundaries and interiors of shapes, like
(shape X & shape Y) & !shape Z => material A;
material A > material B = surface_shader S;
material A.interior = interior_shader I;
or something similiar. That way we could also replace CSG and save
calculations because there are fewer intersections. There could be a some
mechanism to treat the room inside a lathe as a different (sub-)shape to
make modelling filled glasses even easier ;) On the other hand that
doesn't look very intuitive and a bit scary. Nevertheless that would be
one feature I'd like to have in PoV 4.

btw, I have already used Inkscape's PoV-export for modelling my
neighbourhood from a plan. I simpliy scanned it and marked the corners of
the houses. Later, I modified the PoV-code a bit for the housetops. It
worked very well.

Post a reply to this message