 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Colefax <cco### [at] geocities com> wrote:
: intersection {
: plane {_MB_normaldir * _MB_normal1, 0 translate FP1}
: plane {_MB_normaldir * _MB_normal2, 0 translate FP1}
: plane {_MB_normaldir * _MB_normal3, 0 translate FP1}
: plane {_MB_normaldir * _MB_normal4, 0 translate BP1}
: plane {_MB_normaldir * _MB_normal5, 0 translate FP4}
: plane {_MB_normaldir * _MB_normal6, 0 translate FP2}
: }
Wouldn't it be a good idea to bound that object with a bounding box?
I have understood that povray tests the intersection of the viewing ray
with each one of those planes for each pixel since they are infinite shapes
(well, I don't know if pov3.1 has a better automatic bounding box generation
routine). A bounding box should speed up raytracing.
I haven't tested this on pov3.1, so I'm sorry if this message is useless.
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
>
> Mark R. wrote:
> >
> > IMHO, it might be both easier (well okay, slightly easier) and more helpful to
> > add a new object with four corners instead of eight.
>
> I think, Mark, you mean 6 corners here, as this is the required
> number to fully specify the planar-face structure.
>
> Actually, I thought Chris's structure (with the exception of the
> possible problem associated with the coplanarity test via
> the equality test for functions of floats) was nicely elegent.
> The file itself serves as a nice little tutorial on the behavior
> of patches, which aren't really well explained in the documentation.
>
No, I'm fairly sure I meant (and mean) four; a tetrahedron. I wasn't thinking
of the box so much as a 3D object that's a bit more flexible. The metabox (the
flat one, anyway) could be made from a union (or merge, etc.) of a few
tetrahedrons but there would be many other uses, e.g. most meshes could be
made solid(!) by adding a fourth point (somewhere in the middle of the
mesh--the number of extra points needed would depend on the mesh's shape) to
each triangle and making them tetrahedrons instead.
I guess the prism object would work here too, with some work, but that's still
not as nice as just having the object itself.
just a thought :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> No, I'm fairly sure I meant (and mean) four; a tetrahedron.
Oh -- I apologize! I read your original post too quickly.
I agree : the tetrahedron is the fundamental building block
of 3-dimensional solids. It would be a wonderful addition
to the primary object set.
Dan
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Believe it or not, I have been thinking in the same way.
Indeed, assume a tetraeder object, defined by the four corners, that can be
CSG'ed. From this a body with 5 cornerpoints can be defined as the union of
two tetraeders: the first one defined with the first 4 vertices, and the
second one with the first three and the fifth
vertex. This pattern can easily be extended to form objects with 6 7, 8, and
so on corners.
The only difficulty will be the numbering of the vertices, but I am sure
there is some nice mathematical rule for this, and for the obvious case of
the octaeder a macro wrapper can be written.
The advantage is that the space described by the object can be concave (not
possible using a union of planes), and that the object can be of any
complexity.
But, so thinking further, what is the actual reason that a mesh can not be
used for CSG? I assume this is because :
1 - there is no guarantee that a mesh describes a closed surface, so no
'real' inside or outside
2 - there is no guarantee that all triangles are consistently defined with
their corner vertices arranged such that a normal vector defined by the
right hand rule points outward. (or was it the left hand rule? with POV you
never know).
3 - there is no guarantee that the surface does not intersect itself,
exposing the inside surface to the outside, and having the normals pointing
inward. (hard to tell this in words, but no time to render an image)
But, what if we would allow meshes that are closed, consistently defined,
and not self-intersecting to engage in CSG?
A practical solution would be to add a keyword 'CSG' to the definition of
the mesh, like:
#macro flat_metabox (FP1, FP2, FP3, FP4, BP1, BP2, BP3, BP4)
mesh {
CSG // I, user, herewith declare and confirm that the follwing
mesh definition complies with the THREE RULES
triangle {FP1, FP2, FP3} triangle {FP1, FP3, FP4} // Front
triangle {FP1, BP1, BP2} triangle {FP1, BP2, FP2} // Top
triangle {FP1, FP4, BP4} triangle {FP1, BP4, BP1} // Left
triangle {BP1, BP4, BP3} triangle {BP1, BP3, BP2} // Back
triangle {FP4, FP3, BP3} triangle {FP4, BP3, BP4} // Bottom
triangle {FP2, BP2, BP3} triangle {FP2, BP3, FP3} // Right
}
#end // with many thanks to Chris Colefax !!
In adding the CSG keyword the USER would assure that the above conditions
are fulfilled, and POV can just do its work. If the mesh is not compliant,
the user may end up with errors in his picture, and probably some warnings
or messages from POV. Too bad for him. This approach would minimize the task
of the highly praised and overworked POV team.
An algorithm to check a mesh for the above conditions is not so difficult.
It comes down to checking that:
Condition 1 - a ray fired at the object from far away hits the surface on
what we want to be the outside, typically this can be judged by checking the
sign of the scalar product of the ray vector and the normal. When the object
appears to be 'reversed', the checker may be of use to 'flip' it (i.e.
reverse the two first vertices in each triangle)
Condition 2 - all edges are used exactly two times, in opposite directions,
so in the above example: side FP1, FP2 must have a counterpart FP2,FP1. This
means that there are no free edges, and the edges are used to bound two
triangles defined in the same direction.
Condition 3 - no edge of any triangle passes trough another triangle. This
check is not difficult, but just a load of work,that needs to be done only
once. One more reason to have a separate mesh-checker.
By the way, meshes converted from say Autocad or 3DS files, do they normally
comply with these Rules?
And: a mesh usually renders more quickly than a complex union of solids.
Frans
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Jul 1998 23:04:15 +0200, F.VERBAAS <106120,444### [at] COMPUSERVECOM> wrote:
>But, so thinking further, what is the actual reason that a mesh can not be
>used for CSG? I assume this is because :
>1 - there is no guarantee that a mesh describes a closed surface, so no
>'real' inside or outside
True.
>2 - there is no guarantee that all triangles are consistently defined with
>their corner vertices arranged such that a normal vector defined by the
>right hand rule points outward. (or was it the left hand rule? with POV you
>never know).
I've never understood this rule. While it can make the job of determining
insideness easier, it's not really necessary. All you have to do is shoot
a ray in an arbitrary direction and count how many times it intersects the
mesh surface. If it intersects at a boundary between two or more triangles,
you'll need to shoot another ray, but I believe this condition is easy to
detect, as the intersection queue will contain a duplicated point.
>3 - there is no guarantee that the surface does not intersect itself,
>exposing the inside surface to the outside, and having the normals pointing
>inward. (hard to tell this in words, but no time to render an image)
>But, what if we would allow meshes that are closed, consistently defined,
>and not self-intersecting to engage in CSG?
If you don't care about the surface normals, self-intersecting but otherwise
closed meshes have insides. Yes, even a 3d representation of a Klein bottle
has a well-defined inside.
>A practical solution would be to add a keyword 'CSG' to the definition of
>the mesh, like:
An even more practical solution is to only use "good" meshes in CSG
operations. If you get strange results because you gave it a strange mesh,
that's your problem, just as it is now if you use an open cylinder or SOR
in a CSG. Perhaps a keyword to declare that your normals are all
well-behaved, as in your point 2, would be useful to speed up calculations
for such meshes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's a rather altered version of Colefax's metabox macro, which I changed to
work create a tetrahedron. I haven't tested it a whole lot and I'm not certain
that the signs in front of the 'vcross' functions are right all the time--I
arrived at this by more trial and error than I would like--but it *seems* to
work. Anyway, the syntax would be
tetrahedron (P1, P2, P3, P4)
and as far as I can tell, the order of the points doesn't matter.
//-----------Tetrahedron Macro
#macro tetrahedron (P1, P2, P3, P4)
#local _TH_centroid = (P1 + P2 + P3 + P4) / 4;
#local _TH_normal1 = vcross(P2 - P3, P2 - P4);
#local _TH_normal2 = -vcross(P1 - P3, P1 - P4);
#local _TH_normal3 = vcross(P1 - P4, P2 - P4);
#local _TH_normal4 = -vcross(P1 - P3, P2 - P3);
#if (vdot(_TH_normal1,_TH_centroid) > vdot(_TH_normal1,P2))
#local _TH_normal1 = 0 - _TH_normal1;
#end
#if (vdot(_TH_normal2,_TH_centroid) > vdot(_TH_normal2,P1))
#local _TH_normal2 = 0 - _TH_normal2;
#end
#if (vdot(_TH_normal3,_TH_centroid) > vdot(_TH_normal3,P2))
#local _TH_normal3 = 0 - _TH_normal3;
#end
#if (vdot(_TH_normal4,_TH_centroid) > vdot(_TH_normal4,P2))
#local _TH_normal4 = 0 - _TH_normal4;
#end
intersection {
plane {_TH_normal1, 0 translate P2}
plane {_TH_normal2, 0 translate P1}
plane {_TH_normal3, 0 translate P1}
plane {_TH_normal4, 0 translate P1} }
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There is an include file devotes completely to tetrahedra
at:
http://quark.vpplus.com/~redbeard/raytrace/POVRay-Util.html
called :
http://quark.vpplus.com/~redbeard/raytrace/utils/pyramid.zip
I haven't tried it, though.... it advertises offering
pyramids in a variety of coordinate specifications.
It is dated 27 Oct 1996, so will need macro conversion
to make it competitive with Mark's version.
Dan
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mikael Gustafsson wrote:
>
> Sorry for a second post but the last sentence was a bit confusing.
>
> With POV-Ray 3.1 I think it would be possible to incorporate a new object.
> Well, here's my two cents on the subject. The current box is probably one of
> the most used objects in POV, but it has some drawbacks. The current syntax
> only allows boxes with 90 degree corners. But if POV inwoked a new object
> that lets the user define all eight corners of the box, it would among other
> things help creating #while loops that have flat areas as complex matrix
> transformations that are required with the current boxes coule be avoided.
>
> Mikael Gustafsson
> mik### [at] nettifi
I've always thought when making 'warped' boxes that if you could define
a plane in terms of three points that lie *on* the plane and one that
lies outside it, it would be a lot easier to use CSG's of six planes or
more to create complex solid shapes. Calculating normals or using
rotations is time-consuming and it makes my brain hurt after a while -
with a 3+1 point plane, you'd just give the locations of three corners
of each side, and another point to indicate which side is the inside and
which is the outside. The eight-point metabox would probably be easier,
but the 3+1 plane would possibly be more versatile. Opinions?
Cheers,
Dylan
---------------------------------------------------------
Dylan Beattie dmb### [at] ecssotonacuk-nospam
Electronics & Computer Science, University of Southampton
---------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
/*
On Thu, 16 Jul 1998 16:24:24 +0100, Dylan Beattie
<dmb### [at] ecssotonacuk-NOSPAM> wrote:
>I've always thought when making 'warped' boxes that if you could define
>a plane in terms of three points that lie *on* the plane and one that
>lies outside it, it would be a lot easier to use CSG's of six planes or
>more to create complex solid shapes.
*/
////////////////////////////
//
// File: plane3.inc
// Author: Ronald L. Parker
// Date: 16 July 1998
//
// Requires POV Version 3.1 or newer
//
// This macro creates a plane that passes through points A, B, and C and
// has a normal such that Outside is outside the plane. If you know a
// point inside the plane instead, use the inverse keyword in your object
// definition.
//
// Use of collinear points for A, B, and C will cause a degenerate normal.
//
// To use this macro, create an object like so:
// object {plane3(Q1,Q2,Q3,Q4) texture{ ... } }
//
// If you're not going to specify a texture or other modifiers such as
// inverse or hollow, you may leave off the enclosing object{}.
//
////////////////////////////
#macro plane3( A, B, C, Outside )
#local N=vnormalize(vcross(B-A,C-A));
#if ( vdot( Outside-A, N ) < 0 )
#declare N=-N;
#end
plane { N, vdot(A,N) }
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dylan:
When I was modeling the new sanctuary that my church built I found a
need to define many walls (planes). I read the blueprints and discovered
that with the many oddly angled planar surfaces it had, I needed to find
a way to give me the planes based on three points. The three points were
based on an arbitrary coordinate system that I defined for the
blueprint. All I needed to do was to specify the three coordinates and
the program spits out the normal and the distance from my origin. I have
included the source code below. It compiles under Borland C++ 5.0, I
believe, and hopefully under anything else. It's just basic C stuff. I
have the .exe if you want it. I hope this is useful to you.
Jon Berndt
--- start ---
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <string.h>
main()
{
float pt[3][3];
float vec[2][3];
float res[3];
float len;
float len2;
float len2root;
int i, j;
start:
printf("\nEnter x, y, z coords of plane base vector start point: ");
scanf("%f %f %f",&pt[0][0],&pt[0][1], &pt[0][2]);
printf("\nEnter x, y, z coords of plane base vector end point: ");
scanf("%f %f %f", &pt[1][0],&pt[1][1], &pt[1][2]);
printf("\nEnter x, y, z coords of plane second vector end point: ");
scanf("%f %f %f",&pt[2][0],&pt[2][1], &pt[2][2]);
for (j=1;j<3;j++) {
for (i=0;i<3;i++) {
vec[j-1][i] = pt[j][i] - pt[0][i];
}
}
res[0] = vec[0][1]*vec[1][2] - vec[0][2]*vec[1][1];
res[1] = vec[0][2]*vec[1][0] - vec[0][0]*vec[1][2];
res[2] = vec[0][0]*vec[1][1] - vec[0][1]*vec[1][0];
len = res[0]*pt[0][0] + res[1]*pt[0][1] + res[2]*pt[0][2];
len2 = res[0]*res[0] + res[1]*res[1] + res[2]*res[2];
len2root = sqrt(len2);
printf("For a plane with collinear points:\n\n");
printf(" %7.3f %7.3f %7.3f\n", pt[0][0], pt[0][1], pt[0][2]);
printf(" %7.3f %7.3f %7.3f\n", pt[1][0], pt[1][1], pt[1][2]);
printf(" %7.3f %7.3f %7.3f\n\n", pt[2][0], pt[2][1], pt[2][2]);
printf("The normal is:\n\n");
printf(" (%7.3f)i + (%7.3f)j + (%7.3f)k\n\n",res[0]/len2root,
res[1]/len2root, res[2]/len2root);
printf("Distance from origin is: %7.3f\n\n", len/len2root);
goto start;
}
--- end ---
Dylan Beattie wrote:
>
> I've always thought when making 'warped' boxes that if you could define
> a plane in terms of three points that lie *on* the plane and one that
> lies outside it, it would be a lot easier to use CSG's of six planes or
> more to create complex solid shapes. Calculating normals or using
> rotations is time-consuming and it makes my brain hurt after a while -
> with a 3+1 point plane, you'd just give the locations of three corners
> of each side, and another point to indicate which side is the inside and
> which is the outside. The eight-point metabox would probably be easier,
> but the 3+1 plane would possibly be more versatile. Opinions?
Post a reply to this message
Attachments:
Download 'smime.p7s.dat' (3 KB)
|
|
| |
| |
|
|
|
|
| |
|
|
