 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> Nicolas Alvarez <nic### [at] gmail com> wrote:
> > SharkD wrote:
> > > If you look closely at the intersection you'll see that the object is not
> > > solid (there are no walls). Instead, it seems to work more like
> > > clipped_by.
> >
> > Are there walls in the difference?
>
> Yes. I provided links to the renders in my message, so you can see for yourself.
>
> In beta 29 the results are similar, except the road surface is missing a pigment
> (which I'm actually not worried about).
>
> -Mike
No! The walls aren't there. I was fooled the optical illusion. I wonder how you
are supposed to get the walls to appear (in either case).
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> Yes. I provided links to the renders in my message, so you can see for
> yourself.
And what I saw myself was that they didn't have walls either, hence my
post :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> SharkD wrote:
> > Yes. I provided links to the renders in my message, so you can see for
> > yourself.
>
> And what I saw myself was that they didn't have walls either, hence my
> post :)
So, do you know of any way to retrieve the walls? Should I file it as a bug
(beta 29 behaves similarly)?
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
>
> So, do you know of any way to retrieve the walls? Should I file it as a bug
> (beta 29 behaves similarly)?
No, it's definitely *not* a bug. It's just behaving in a way *you* don't expect.
CSG only works (properly) with solids. As your mesh isn't closed, it's not a
solid, and therefore *cannot* give any sensible results (unless you want to
exploit exactly what PoV-ray happens to make of it).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> No, it's definitely *not* a bug. It's just behaving in a way *you* don't expect.
>
> CSG only works (properly) with solids. As your mesh isn't closed, it's not a
> solid, and therefore *cannot* give any sensible results (unless you want to
> exploit exactly what PoV-ray happens to make of it).
If it's not a solid, then Constructive *Solid* Geometry should not work with it
at all.
You yourself even said earlier that, "There's nothing really strange about solid
meshes which do not form a closed surface, as long as the inside_vector is
defined properly." Have you changed your mind since then or something?
Further, you said that a non-closed solid mesh should behave just like a plane
or heightfield. This is *not* happening in this case, therefore--if one should
consider your earlier statements to be true--it must be considered a bug.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> "clipka" <nomail@nomail> wrote:
> > No, it's definitely *not* a bug. It's just behaving in a way *you* don't expect.
> >
> > CSG only works (properly) with solids. As your mesh isn't closed, it's not a
> > solid, and therefore *cannot* give any sensible results (unless you want to
> > exploit exactly what PoV-ray happens to make of it).
>
> If it's not a solid, then Constructive *Solid* Geometry should not work with it
> at all.
>
> You yourself even said earlier that, "There's nothing really strange about solid
> meshes which do not form a closed surface, as long as the inside_vector is
> defined properly." Have you changed your mind since then or something?
>
> Further, you said that a non-closed solid mesh should behave just like a plane
> or heightfield. This is *not* happening in this case, therefore--if one should
> consider your earlier statements to be true--it must be considered a bug.
>
> -Mike
Woops. I confused you with Warp.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> > CSG only works (properly) with solids. As your mesh isn't closed, it's not a
> > solid, and therefore *cannot* give any sensible results (unless you want to
> > exploit exactly what PoV-ray happens to make of it).
>
> If it's not a solid, then Constructive *Solid* Geometry should not work with it
> at all.
So you're saying that it should give an error instead of rendering at all?
The problem here is that PoV-ray would have to actually test whether a mesh is
solid or not, which could become a quite intensive thing with large meshes.
There would also be numercial precision issues; simply put, some meshes may
turn out to be "almost-but-not-quite solid" not because they have real
significant "holes", but just minor impurities because of the way they were
generated, which wouldn't interfere with CSG in practice; so it would be hard
to draw a clear line between "solid" and "non-solid".
So for the sake of parsing speed, software complexity and robustness, it's
easier to leave it up to the user to ensure that his mesh is "solid enough" to
be used in CSG.
> You yourself even said earlier that, "There's nothing really strange about solid
> meshes which do not form a closed surface, as long as the inside_vector is
> defined properly." Have you changed your mind since then or something?
No, that was someone else who stated that...
> Further, you said that a non-closed solid mesh should behave just like a plane
> or heightfield. This is *not* happening in this case, therefore--if one should
> consider your earlier statements to be true--it must be considered a bug.
.... and this as well. *My* only mistake might have been to not vehemently
protest against these statements back then.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> "SharkD" <nomail@nomail> wrote:
> > > CSG only works (properly) with solids. As your mesh isn't closed, it's not a
> > > solid, and therefore *cannot* give any sensible results (unless you want to
> > > exploit exactly what PoV-ray happens to make of it).
> >
> > If it's not a solid, then Constructive *Solid* Geometry should not work with it
> > at all.
>
> So you're saying that it should give an error instead of rendering at all?
Is there a good reason not to? The results are afterall "insensible".
> The problem here is that PoV-ray would have to actually test whether a mesh is
> solid or not, which could become a quite intensive thing with large meshes.
> There would also be numercial precision issues; simply put, some meshes may
> turn out to be "almost-but-not-quite solid" not because they have real
> significant "holes", but just minor impurities because of the way they were
> generated, which wouldn't interfere with CSG in practice; so it would be hard
> to draw a clear line between "solid" and "non-solid".
>
> So for the sake of parsing speed, software complexity and robustness, it's
> easier to leave it up to the user to ensure that his mesh is "solid enough" to
> be used in CSG.
>
> > You yourself even said earlier that, "There's nothing really strange about solid
> > meshes which do not form a closed surface, as long as the inside_vector is
> > defined properly." Have you changed your mind since then or something?
>
> No, that was someone else who stated that...
>
> > Further, you said that a non-closed solid mesh should behave just like a plane
> > or heightfield. This is *not* happening in this case, therefore--if one should
> > consider your earlier statements to be true--it must be considered a bug.
>
> .... and this as well. *My* only mistake might have been to not vehemently
> protest against these statements back then.
The whole point of the inside_vector is that it doesn't *matter* whether the
mesh is closed or not. As long as the ray only intersects one surface, then
anything starting from this surface and extending in the direction of the
inside_vector is considered *inside*, and therefore should behave properly in
CSG.
POV already subtracts the proper volumes in CSG operations; the *only* problem
is that the walls are missing. You can check and see whether closed meshes
behave better by rendering a box instead.
Lastly, the deficiencies you're pointing out in open meshes apply equally to the
plane. It doesn't make sense at first that a plane takes up a large volume in
CSG because it's perfectly flat. Yet it does.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> > So you're saying that it should give an error instead of rendering at all?
>
> Is there a good reason not to? The results are afterall "insensible".
As already mentioned, the "good reason not to" is the high "cost" (regarding
both processing time and user- and 3rd-party-tool-friendliness) of a test for
"solidness" of a mesh.
> The whole point of the inside_vector is that it doesn't *matter* whether the
> mesh is closed or not. As long as the ray only intersects one surface, then
> anything starting from this surface and extending in the direction of the
> inside_vector is considered *inside*, and therefore should behave properly in
> CSG.
No, this is what you may *think* is the point.
Or, well, yes, in a way that *is* the point. But it's not designed with "totally
non-solid" meshes in mind, but rather "almost solid" meshes, that may have
slight flaws that don't really impact how well they are suited to CSG.
So what the inside_vector is designed to work around is not gaping holes, but
tiny "fissures" due to numeric precision issues.
> POV already subtracts the proper volumes in CSG operations; the *only* problem
> is that the walls are missing. You can check and see whether closed meshes
> behave better by rendering a box instead.
There is a misconception here:
POV does *not*, from a technical point of view, just "subtract volumes".
Instead, when doing CSG it rather renders intersections (or differences) of
*surfaces* with volumes.
Your mesh has the proper volume, but lacks some of the corresponding surface, so
it doesn't work properly with this approach.
The essence is that every surface to show up in the final CSG object must
already be there in the component objects.
> Lastly, the deficiencies you're pointing out in open meshes apply equally to the
> plane. It doesn't make sense at first that a plane takes up a large volume in
> CSG because it's perfectly flat. Yet it does.
There is a difference here:
First of all, the plane is *infinite*, i.e. (a) it *does* divide the space into
two distinct volumes, and (b) every additional surface that you would ever
expect from CSG involving a plane is contributed by the other component
objects, not the plane.
Second, POV's plane is *defined* to actually not be a plane, but "everything
'below' the plane", for CSG purposes. (If this wasn't explicitly defined this
way, the plane would actually not work in CSG either, as it then would lack the
"volume".)
That's why it works, while your mesh - unfortunately - doesn't.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> No, this is what you may *think* is the point.
Be nice. There's no reason this discussion can't remain civil.
> Or, well, yes, in a way that *is* the point. But it's not designed with "totally
> non-solid" meshes in mind, but rather "almost solid" meshes, that may have
> slight flaws that don't really impact how well they are suited to CSG.
> So what the inside_vector is designed to work around is not gaping holes, but
> tiny "fissures" due to numeric precision issues.
Yes, this is as I said in the bug reports group.
> The essence is that every surface to show up in the final CSG object must
> already be there in the component objects.
Ah, I see now. This happens in the case of the heightfield as well. My only
request is that this behavior be toggled on and off. With other shapes (such as
the heightfield) it is easy to create the closed volume defined as being
"inside" the object via an intersection with a box or other primitive. But with
a mesh this is non-trivial.
> Second, POV's plane is *defined* to actually not be a plane, but "everything
> 'below' the plane", for CSG purposes.
....and the heightfield, and the disc, and, incidentally, the mesh.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
