 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 5 Mar 1999 17:43:33 +0100, Daniele Varrazzo
<pir### [at] officine itnospam> wrote:
>> /
>>_ _ _ _ _ _ _ _ _/_ _ _
>> /\ \
>> /A \ B \
>>
>>The dotted horizontal line is your ray. At A, it hits an edge that should
>>not be counted. At B, it hits an edge that should be counted. Each is
>>shared between exactly two faces.
>
>
>What happens if we count even A as one intersection? Could there be errors?
>Would they be very noticeable?
Yes, there will be errors. A is either zero intersections or two intersections.
If you count it as one intersection, it will invert the insideness for every
point to the left of A. In practice, this shows up as a row of random-looking
pixels in your scene. The text and prism objects in the official POV-Ray used
to have this problem, too; I think the prism objects still do.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On a side note to this thread I have always assumed from what is specified
in the docs that mesh objects are not allowed in csg operations.
From the Pov v3.1d documentation:
------------------------
Finite Patch Primitives
There are six totally thin, finite objects which have no well-defined inside.
They are bicubic patch, disc, smooth triangle, triangle, polygon and mesh.
They may be combined in CSG union but cannot be use in other types of CSG
(or inside a clipped_by statement).
---------------------------------
It specificaly states that these objects CANNOT be used in any csg operation
except for a union. If you take a moment to render the code below this note
you will find that this is not altogether true. I put together 4 triangles
that make up a square flat face for simplicity sake. The csg operations
that I have illustrated below work perfectly and the only thing the parser
does in protest is issue a quiet warning that patch objects are not allowed
in csg operations.
Comments anyone ?
/******************************/
camera{location<0,0,-5>look_at 0}
light_source{<0,0,-30>rgb 1}
// first operation
intersection{
mesh {
triangle{<-1,-1,0>,<0,0,0>,< 1,-1,0>}
triangle{<-1,-1,0>,<0,0,0>,<-1, 1,0>}
triangle{<-1, 1,0>,<0,0,0>,< 1, 1,0>}
triangle{< 1, 1,0>,<0,0,0>,< 1,-1,0>}
pigment{rgb 1}
} // end mesh object
sphere{0,.5
pigment{blue 1}
inverse
} // end sphere object
translate<-1.5,0,0>
} // end intersection
// second operation
difference{
mesh {
triangle{<-1,-1,0>,<0,0,0>,< 1,-1,0>}
triangle{<-1,-1,0>,<0,0,0>,<-1, 1,0>}
triangle{<-1, 1,0>,<0,0,0>,< 1, 1,0>}
triangle{< 1, 1,0>,<0,0,0>,< 1,-1,0>}
pigment{rgb 1}
} // end mesh object
sphere{0,.5
pigment{blue 1}
inverse
} // end sphere object
translate<1.5,0,0>
} // end intersection
/*********************************/
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My understanding was that they are part-time workers in CSG. Either they
do or they don't function correctly in difference, intersection or
merge. What I don't understand is *when* that is the case. Believe it's
something to do with the intersection angle (of course) since the
primitives have to be found in the right way all along the CSG. I've
used these before too in CSG, regardless of the statements in the DOC,
as well as many other things I do right or wrong.
Ken wrote:
>
> On a side note to this thread I have always assumed from what is specified
> in the docs that mesh objects are not allowed in csg operations.
>
> From the Pov v3.1d documentation:
>
> ------------------------
>
> Finite Patch Primitives
>
> There are six totally thin, finite objects which have no well-defined inside.
> They are bicubic patch, disc, smooth triangle, triangle, polygon and mesh.
> They may be combined in CSG union but cannot be use in other types of CSG
> (or inside a clipped_by statement).
>
> ---------------------------------
>
> It specificaly states that these objects CANNOT be used in any csg operation
> except for a union. If you take a moment to render the code below this note
> you will find that this is not altogether true. I put together 4 triangles
> that make up a square flat face for simplicity sake. The csg operations
> that I have illustrated below work perfectly and the only thing the parser
> does in protest is issue a quiet warning that patch objects are not allowed
> in csg operations.
>
> Comments anyone ?
>
> /******************************/
>
> camera{location<0,0,-5>look_at 0}
> light_source{<0,0,-30>rgb 1}
>
> // first operation
>
> intersection{
> mesh {
> triangle{<-1,-1,0>,<0,0,0>,< 1,-1,0>}
> triangle{<-1,-1,0>,<0,0,0>,<-1, 1,0>}
> triangle{<-1, 1,0>,<0,0,0>,< 1, 1,0>}
> triangle{< 1, 1,0>,<0,0,0>,< 1,-1,0>}
> pigment{rgb 1}
> } // end mesh object
>
> sphere{0,.5
> pigment{blue 1}
> inverse
> } // end sphere object
>
> translate<-1.5,0,0>
>
> } // end intersection
>
> // second operation
>
> difference{
> mesh {
> triangle{<-1,-1,0>,<0,0,0>,< 1,-1,0>}
> triangle{<-1,-1,0>,<0,0,0>,<-1, 1,0>}
> triangle{<-1, 1,0>,<0,0,0>,< 1, 1,0>}
> triangle{< 1, 1,0>,<0,0,0>,< 1,-1,0>}
> pigment{rgb 1}
> } // end mesh object
>
> sphere{0,.5
> pigment{blue 1}
> inverse
> } // end sphere object
>
> translate<1.5,0,0>
>
> } // end intersection
>
> /*********************************/
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.htm
mailto:inv### [at] aolcom?PoV
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 07 Mar 1999 20:05:31 -0800, Ken <tyl### [at] pacbellnet> wrote:
>On a side note to this thread I have always assumed from what is specified
>in the docs that mesh objects are not allowed in csg operations.
There are indeed two reasons a mesh can't currently be used in an
intersection. One is that they have no inside: the "am I inside"
function for meshes always says "no." The other is that they don't
always return all intersections when asked. What we're discussing
is making those two statements no longer true. What you've found
must be a fluke. It's been done before, in POV 2.2 with heightfields
which at that time didn't have an inside either. But I wouldn't
count on it working from all angles.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] my-dejanewscom> wrote:
: It's been done before, in POV 2.2 with heightfields
: which at that time didn't have an inside either. But I wouldn't
: count on it working from all angles.
What do you mean? I just tested this and it seemed to work just fine:
http://www.cs.tut.fi/~warp/hftest.jpg
The code:
camera { location -z*26 look_at 0 angle 35 }
light_source { <100,200,-200>,1 }
light_source { <-200,-200,-50>,<.2,.4,.6> }
#declare Test=
difference
{ height_field { tga "hf.tga" translate -.5 scale <4,1,4> }
sphere { 0,1.5 }
pigment { rgb <1,0,0> }
finish { specular .5 }
}
object { Test rotate x*-90 translate -x*5+y*2.5 }
object { Test rotate x*-54 translate -x*0+y*2.5 }
object { Test rotate x*-18 translate x*5+y*2.5 }
object { Test rotate x*18 translate -x*5-y*2.5 }
object { Test rotate x*54 translate -x*0-y*2.5 }
object { Test rotate x*90 translate x*5-y*2.5 }
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8 Mar 1999 12:22:02 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>Ron Parker <par### [at] my-dejanewscom> wrote:
>: It's been done before, in POV 2.2 with heightfields
>: which at that time didn't have an inside either. But I wouldn't
>: count on it working from all angles.
>
> What do you mean? I just tested this and it seemed to work just fine:
>http://www.cs.tut.fi/~warp/hftest.jpg
Sorry, I wasn't clear enough. Height fields now have a well-defined
inside, but in POV 2.2 (or maybe it was 2.0... that's the problem with us
old farts, we're so forgetful...) they did not. That didn't keep people from
using them as clipping objects, though. There was even a demo scene in the
official distribution showing one such use. It just didn't always
work from every angle. The same now appears to be true of mesh objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote in message <36e3d8c8.0@news.povray.org>...
>On Sun, 07 Mar 1999 20:05:31 -0800, Ken <tyl### [at] pacbellnet> wrote:
>>On a side note to this thread I have always assumed from what is specified
>>in the docs that mesh objects are not allowed in csg operations.
>
>There are indeed two reasons a mesh can't currently be used in an
>intersection. One is that they have no inside: the "am I inside"
>function for meshes always says "no." The other is that they don't
>always return all intersections when asked. What we're discussing
>is making those two statements no longer true. What you've found
>must be a fluke. It's been done before, in POV 2.2 with heightfields
>which at that time didn't have an inside either. But I wouldn't
>count on it working from all angles.
I've found that doing what Ken has done usually works. You can usually use
differences to chop bits off meshes. If you try to reverse the difference,
take the mesh from the sphere, it doesn't quite work though. The mesh
appears as an infinitely thin surface (which makes sense I guess) and
appears to behave as such in CSGs.
On the topic in general, I would think the method of using the normals to
determine the "inside" was more useful as this way open meshes could also be
used. I still have a little trouble picturing how this would work exactly
though!
Regards
Gordon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 11 Mar 1999 22:03:44 +0800, Gordon <gbe### [at] birdcameroncomau> wrote:
>I've found that doing what Ken has done usually works. You can usually use
>differences to chop bits off meshes. If you try to reverse the difference,
>take the mesh from the sphere, it doesn't quite work though. The mesh
>appears as an infinitely thin surface (which makes sense I guess) and
>appears to behave as such in CSGs.
Are you sure? It seems it should work the other way, since meshes
are defined to have no inside. Difference is just intersection with
an inverse, so I'll use intersection to explain:
What intersection does is find all ray-object intersections with each
component object, then filter the results so only the intersections
that are inside all other component objects are returned. Since
nothing is inside a mesh, all intersections with non-mesh objects
should be ignored. Intersections with the mesh object would survive.
The result seems like it would be quite unlike an intersection.
difference{sphere{...}mesh{...}} would return all intersections
with the sphere, plus whatever mesh surfaces fall inside the sphere.
For opaque objects, the result should be a sphere.
difference{mesh{...}sphere{...}} would return whatever intersections
with the mesh fall outside the sphere, but no intersections with the
sphere. The result would be a hole in your mesh, not a spherical
cutout.
>On the topic in general, I would think the method of using the normals to
>determine the "inside" was more useful as this way open meshes could also be
>used. I still have a little trouble picturing how this would work exactly
>though!
Quite simply, it wouldn't really. The "inside" of such a mesh would not
be well-defined, as whether a given point were inside or outside would
depend on which triangle it hit when testing. Some points would always
be inside, of course, and some outside, but for anything but a simple flat
mesh you'd have lots of points that were undefined.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gordon wrote:
>
> On the topic in general, I would think the method of using the normals to
> determine the "inside" was more useful as this way open meshes could also be
> used. I still have a little trouble picturing how this would work exactly
> though!
>
> Regards
> Gordon
This sounds a bit like treating the triangles of a mesh as if they were
prisms which extend off to infinity in one direction (defined by the
normal) and just not drawing the sides. I've had a weird experience
along these lines with disks in an old version of the superpatch (the
compile I made for Linux was buggy so I didn't think much of it at the
time). Anyway, depending on where I put the camera relative to the
disk, I would get the standard warning about cameras inside non-hollow
objects causing problems with atmospheres. Is it possible that pov does
try to treat some of these non-3d objects as if they were some strange
variant of a prism?
Would it be possible to use this to make an inside for a mesh (even an
open one?) That way you could test if you are inside the prism of more
that one triangle and that should be enough to be inside your mesh, at
least for a simple mesh. Would have to sit down and scratch my head for
a bit to see how to treat complicated shapes. I just think that the
normals method is a nice way to go.
--
Carl Bartels, Department of Chemistry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 11 Mar 1999 18:08:17 -0500, Carl Bartels
<cab### [at] bravo436chemmcgillca> wrote:
>Would it be possible to use this to make an inside for a mesh (even an
>open one?) That way you could test if you are inside the prism of more
>that one triangle and that should be enough to be inside your mesh, at
>least for a simple mesh. Would have to sit down and scratch my head for
>a bit to see how to treat complicated shapes. I just think that the
>normals method is a nice way to go.
Consider a mesh of a bowl. Any point in the part where the Chocolate
Frosted Sugar Bombs go would be considered "inside" by this method, as
would a good number of points in the environment, including some below
the surface of the table (due to the rim of the bowl).
Even convex polyhedra would have problems. Consider a football (without
seams.) It's convex, but the intersections of the prisms associated with
triangles near opposite ends are outside the surface of the football.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
