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

Nicolas George nous apporta ses lumieres en ce 22-04-2007 15:36:
> 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.
You have "normal" textures.
You have interior_texture. (an optional element)
Add "coincident_texture" (as another optional element) with a 
coincidence_treshold parameter (defaulting to epsilon*2 for example) defining 
the maximum gap that can separate the surfaces to be considered as coincident.

For those unfamiliar with the term, the "epsilon" value is the smalest value you 
can have before it's considered as zero.

-- 
Alain
-------------------------------------------------
Christian Science: When shit happens, don't call a doctor - pray!

Post a reply to this message

Am Wed, 25 Apr 2007 18:49:09 -0400 schrieb Alain:

> You have "normal" textures.
> You have interior_texture. (an optional element) Add "coincident_texture"
> (as another optional element) with a coincidence_treshold parameter
> (defaulting to epsilon*2 for example) defining the maximum gap that can
> separate the surfaces to be considered as coincident.
> 
> For those unfamiliar with the term, the "epsilon" value is the smalest
> value you can have before it's considered as zero.

I know epsilon as the lowest number, where the floating point
representation of the sum of this number and 1 and 1 is greater than 1.
Checking whether to floating point numbers are roughly the same is still
not that easy. If you want to be really correct abs(a-b) < epsilon is not
enough, because epsilon is more like a factor. It all depends on the
calculations done with a and b before.

I think that syntax would get us into a great mess. Is that texture
applied on both sides of these surfaces? Where will the ray be reflected
and transmitted? In my opinion a sort of CSG with more options than
"inside" and "outside" would be better.

Post a reply to this message