|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"And" <49341109@ntnu.edu.tw> wrote:
> Hi, I have heard that POV_Ray can add mesh(solid) to CSG so I tried to
> difference a torus mesh export from Blender but it seems not ok.
I create it in Blender. A new torus, then export an .obj, then using poseray to
put into POV-Ray. That's all. I don't know what mistake I did.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.08.2016 um 17:44 schrieb And:
> Why?
> here is a union version. It's ok.
Union is special among the CSG operations in that it works fine with
non-solid objects. All other CSG operations need solid objects to work
properly.
To POV-Ray, "solid" means that there is a method to test whether any
given point is inside or outside a shape. The normal ray tracing
algorithm does not need such a test, since the only thing it cares about
is surfaces. Likewise, unions do not need such a test, since they do not
change what surfaces are rendered. Merge, difference, intersection and
clipped_by, on the other hand, work by selectively suppressing portions
of an object's surface depending on which other objects they're inside
-- and that's where the insideness test is crucial.
For meshes, the insideness test is implemented by tracing a ray from the
point in question in an arbitrary direction, and counting how many times
that ray intersects the object's surface. An odd number of intersections
indicates that the point in question is inside, while an even number
indicates that it is outside. For this algorithm to work properly, two
conditions must be met:
- The mesh must be properly closed (i.e. each and every triangle must
precisely share each of its edges with an odd number of other triangles).
- The "arbitrary direction" needs to be chosen. This is not done
automatically, but instead requires the use of the `inside_vector`
keyword, with a non-zero vector. (The actual direction does not normally
matter; however, if the vector happens to be almost but not quite
parallel to one of the triangles, there is a slight chance that
artifacts may occur, especially if that triangle is particularly large.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 04.08.2016 um 17:44 schrieb And:
> > Why?
> > here is a union version. It's ok.
>
> Union is special among the CSG operations in that it works fine with
> non-solid objects. All other CSG operations need solid objects to work
> properly.
>
> To POV-Ray, "solid" means that there is a method to test whether any
> given point is inside or outside a shape. The normal ray tracing
> algorithm does not need such a test, since the only thing it cares about
> is surfaces. Likewise, unions do not need such a test, since they do not
> change what surfaces are rendered. Merge, difference, intersection and
> clipped_by, on the other hand, work by selectively suppressing portions
> of an object's surface depending on which other objects they're inside
> -- and that's where the insideness test is crucial.
>
> For meshes, the insideness test is implemented by tracing a ray from the
> point in question in an arbitrary direction, and counting how many times
> that ray intersects the object's surface. An odd number of intersections
> indicates that the point in question is inside, while an even number
> indicates that it is outside. For this algorithm to work properly, two
> conditions must be met:
>
> - The mesh must be properly closed (i.e. each and every triangle must
> precisely share each of its edges with an odd number of other triangles).
>
> - The "arbitrary direction" needs to be chosen. This is not done
> automatically, but instead requires the use of the `inside_vector`
> keyword, with a non-zero vector. (The actual direction does not normally
> matter; however, if the vector happens to be almost but not quite
> parallel to one of the triangles, there is a slight chance that
> artifacts may occur, especially if that triangle is particularly large.)
Mmm... ok. Sounds that I need do this in another way.
Heee
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"And" <49341109@ntnu.edu.tw> wrote:
> Mmm... ok. Sounds that I need do this in another way.
> Heee
No, you just need to edit your mesh file and add
inside_vector <0, 0, 0> (or another vector) to your mesh definition.
http://www.povray.org/documentation/view/3.6.0/292/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/5/2016 8:29 AM, Bald Eagle wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>
>> Mmm... ok. Sounds that I need do this in another way.
>> Heee
>
> No, you just need to edit your mesh file and add
>
> inside_vector <0, 0, 0> (or another vector) to your mesh definition.
IIRC the OP mentioned using poseray which does that if I'm not mistaken
... for my current project I'm using blender->poseray->povray. I just
checked indeed that's already present
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 05/08/2016 à 14:36, Jim Holsenback a écrit :
> On 8/5/2016 8:29 AM, Bald Eagle wrote:
>> "And" <49341109@ntnu.edu.tw> wrote:
>>
>>> Mmm... ok. Sounds that I need do this in another way.
>>> Heee
>>
>> No, you just need to edit your mesh file and add
>>
>> inside_vector <0, 0, 0> (or another vector) to your mesh definition.
>
> IIRC the OP mentioned using poseray which does that if I'm not mistaken
> ... for my current project I'm using blender->poseray->povray. I just
> checked indeed that's already present
>
<0,0,0> is the only 100% BAD value.
Remember inside_vector is not a position, it's a direction.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <lef### [at] freefr> wrote:
> Le 05/08/2016 à 14:36, Jim Holsenback a écrit :
> > On 8/5/2016 8:29 AM, Bald Eagle wrote:
> >> "And" <49341109@ntnu.edu.tw> wrote:
> >>
> >>> Mmm... ok. Sounds that I need do this in another way.
> >>> Heee
> >>
> >> No, you just need to edit your mesh file and add
> >>
> >> inside_vector <0, 0, 0> (or another vector) to your mesh definition.
> >
> > IIRC the OP mentioned using poseray which does that if I'm not mistaken
> > ... for my current project I'm using blender->poseray->povray. I just
> > checked indeed that's already present
> >
>
> <0,0,0> is the only 100% BAD value.
>
> Remember inside_vector is not a position, it's a direction.
Look. To no avail.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "And" <49341109@ntnu.edu.tw> wrote:
>
>> Mmm... ok. Sounds that I need do this in another way.
>> Heee
>
> No, you just need to edit your mesh file and add
>
> inside_vector <0, 0, 0> (or another vector) to your mesh definition.
>
> http://www.povray.org/documentation/view/3.6.0/292/
>
It can't be a null vector and <0,0,0> IS a null vector.
It should be inside_vector<1,1,1>
If you get artifacts, change one of the values by a small amount and try
again.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <lef### [at] freefr> wrote:
> <0,0,0> is the only 100% BAD value.
>
> Remember inside_vector is not a position, it's a direction.
After I posted my hasty response, I realized that even if it WAS a location,
it's a torus, and that would be bad too :D
<1, 0, 0>*(MajorRadius) would be a good vector that would intersect the torus if
the test ray originates at the origin.
I would presume that if that inside_vector is part of the mesh definition, then
when the torus gets rotated, the inside_vector gets modified in the same
fashion.
It's always these little details. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.08.2016 um 19:03 schrieb Bald Eagle:
> <1, 0, 0>*(MajorRadius) would be a good vector that would intersect the torus if
> the test ray originates at the origin.
The `inside_vector` has no relation to /any/ points in space whatsoever;
it is a mere direction vector. Even the length does not matter.
> I would presume that if that inside_vector is part of the mesh definition, then
> when the torus gets rotated, the inside_vector gets modified in the same
> fashion.
Effectively, yes.
Technically, no -- rather than actually modifying the entire mesh data,
rotations and other transformations are instead just accumulated in a
pair of matrices, and whenever POV-Ray needs to do math on the mesh it
uses these two matrices to convert input and output data of the
algorithm, so that it can do the math on the original untransformed mesh.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|