 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
When I intersect two solid meshes I get weird artifacts, as can be seen
in the following images. The red object is the main object, the green
object is the one I'm trying to subtract. The artifacts aren't _always"
there. Sometimes they disappear when the radius of the green object
changes. Any clue why this is happening?
--
http://isometricland.com
Post a reply to this message
Attachments:
Download 'main_and_diff_objects.jpg' (36 KB)
Download 'main_object.jpg' (34 KB)
Download 'not_always_artifacts.jpg' (35 KB)
Download 'sometimes_artifacts.jpg' (37 KB)
Preview of image 'main_and_diff_objects.jpg'
Preview of image 'main_object.jpg'
Preview of image 'not_always_artifacts.jpg'
Preview of image 'sometimes_artifacts.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I wasn't aware that you could use CSG with meshes. I would generally do that
before exporting to create the mesh. Could it be that there are occasionally
"holes" in the mesh that's created?
SharkD wrote:
> When I intersect two solid meshes I get weird artifacts, as can be seen
> in the following images. The red object is the main object, the green
> object is the one I'm trying to subtract. The artifacts aren't _always"
> there. Sometimes they disappear when the radius of the green object
> changes. Any clue why this is happening?
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/17/2010 12:08 PM, tom millican wrote:
> I wasn't aware that you could use CSG with meshes. I would generally do that
> before exporting to create the mesh. Could it be that there are occasionally
> "holes" in the mesh that's created?
The meshes were generated algorithmically using a macro I created. Any
holes could only be the result of rounding errors AFAIK.
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.06.2010 18:08, schrieb tom millican:
> I wasn't aware that you could use CSG with meshes.
They need to be solid in order to do that - i.e. they need an
"inside_vector", and should be fully closed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.06.2010 17:48, schrieb SharkD:
> When I intersect two solid meshes I get weird artifacts, as can be seen
> in the following images. The red object is the main object, the green
> object is the one I'm trying to subtract. The artifacts aren't _always"
> there. Sometimes they disappear when the radius of the green object
> changes. Any clue why this is happening?
What's your inside_vector? Does it happen to be pointing along the blue
line (whatever axis that may be)? If so, try changing that to something
pretty random.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/18/2010 7:40 AM, clipka wrote:
> What's your inside_vector? Does it happen to be pointing along the blue
> line (whatever axis that may be)? If so, try changing that to something
> pretty random.
I'm a bit confused by input_vector. Is it a vector or a point? I have
simply been placing it at the exact center of each mesh, which sometimes
happens to be the origin.
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> I'm a bit confused by input_vector. Is it a vector or a point? I have
> simply been placing it at the exact center of each mesh
It's a direction so you should never set it to 0. Otherwise,
the value is completely arbitrary in theory, although numerical
issues may cause artefacts for some values.
[To test if a point is inside a mesh you can shoot a line
from that point to infinity in some direction and calculate
the number of intersections, if that is odd the point is
inside the mesh. Of course, for convex objects the count
would then always be 1].
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.06.2010 18:08, schrieb SharkD:
> On 6/18/2010 7:40 AM, clipka wrote:
>> What's your inside_vector? Does it happen to be pointing along the blue
>> line (whatever axis that may be)? If so, try changing that to something
>> pretty random.
>
> I'm a bit confused by input_vector. Is it a vector or a point? I have
> simply been placing it at the exact center of each mesh, which sometimes
> happens to be the origin.
As the name suggests, inside_vector (not input_vector, btw) is indeed a
vector.
POV-Ray's implementation of intersection and difference CSG uses two
operations: Computing intersections between a ray and the member
objects, and testing whether such an intersection point is inside the
other member objects.
For most object types, the inside-test is defined via a mathematical
formula (for instance, for a sphere you just test whether the distance
between the point in question and the center is smaller than the
sphere's radius). For meshes, this is not so easy; so instead, POV-Ray
shoots a "random" test ray from the point in question and tests how many
times it intersects the mesh: If the number of intersections is odd, the
point must be inside, otherwise outside.
inside_vector specifies the "random" direction in which to shoot that
test ray. Theoretically the direction should not matter, but in rare
cases this algorithm might lead to artifacts - which then can be made to
disappear by choosing a different test ray direction.
An inside_vector of <0,0,0> is equivalent to specifying no inside_vector
at all, i.e. leaving the mesh non-solid.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/19/2010 1:20 PM, clipka wrote:
> As the name suggests, inside_vector (not input_vector, btw) is indeed a
> vector.
Oops, sorry!
On 6/19/2010 1:20 PM, clipka wrote:
> POV-Ray's implementation of intersection and difference CSG uses two
> operations: Computing intersections between a ray and the member
> objects, and testing whether such an intersection point is inside the
> other member objects.
>
> For most object types, the inside-test is defined via a mathematical
> formula (for instance, for a sphere you just test whether the distance
> between the point in question and the center is smaller than the
> sphere's radius). For meshes, this is not so easy; so instead, POV-Ray
> shoots a "random" test ray from the point in question and tests how many
> times it intersects the mesh: If the number of intersections is odd, the
> point must be inside, otherwise outside.
>
> inside_vector specifies the "random" direction in which to shoot that
> test ray. Theoretically the direction should not matter, but in rare
> cases this algorithm might lead to artifacts - which then can be made to
> disappear by choosing a different test ray direction.
>
> An inside_vector of <0,0,0> is equivalent to specifying no inside_vector
> at all, i.e. leaving the mesh non-solid.
I still don't understand what value I /should/ be using for
inside_vector. Someplace inside the mesh that is not <0,0,0>?
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> I still don't understand what value I /should/ be using for
> inside_vector. Someplace inside the mesh that is not <0,0,0>?
Like clipka suggested, any direction will do in most cases, though if
your mesh isn't completely closed you might get various results for
different vectors. I recently tried changing inside_vector when I
encountered strange behavior after converting the mesh to an object
pigment, and was presented with odd effects unique to the values I was
passing to inside_vector. I'm pretty sure it wasn't a properly closed mesh.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
