 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
'ello. I mentioned this in the bug reports as well, but if someone in
the general audience :) could tell me if it's bug or feature, I'd
appareciate it.
Anyway, pardon me if my mathematics are insufficient to explain the
problem properly, but....
When doing some DIFFERENCEs where the, um, surfaces of the objects are
in the same plane it cuts a hole INTO the first object. That is, I can
see INTO the the block of the A object as if it were hollowed out with a
big spoon.
Follows code that shows the prob. It's a house block where I'm
subtracting a stair well. I got around this by the hack of adding .01 to
some of the x coordinates. That works. Looks a little ugly though.
danke,
--min
P200MMX w/ 128MB RAM running NT 4 SP3. Using the new Povray 3.1 (non
beta).
//
#declare T_Wall =
texture {
pigment {
color rgb<1,1,1>
}
finish {
ambient 0.2
brilliance .01
diffuse 1
roughness 1
reflection 0
}
}
#declare T_WallPaper =
texture {
pigment {
wood
turbulence 0
color_map {
[0 color rgb<.8,.8,.75>]
[.2 color rgb<1,1,1>]
}
scale .2
rotate <-90,0,0>
}
finish {
ambient 0.2
brilliance .01
diffuse 1
roughness 1
reflection 0
}
}
#declare T_Masonry =
texture {
pigment {
brick color rgb<.6,.6,.6>, color rgb<1,1,.9>
brick_size <8,3,4.5>
mortar .25
scale 1/8
turbulence 0
}
finish {
ambient 0.2
brilliance .01
diffuse 1
roughness 1
reflection 0
}
}
camera {
angle 90 //wide-angle
//location<36,3,-5>
location<32,1,-5>
look_at <32,0,12>
}
light_source {
<36,1,-4>
color rgb<.9,.9,.8>
fade_distance 2
fade_power 1
}
light_source {
<32,7.5,5>
color rgb<.8,.8,1>
fade_distance 2
fade_power 1
}
light_source {
<40,1,9>
color rgb<1,.5,.5>
fade_distance 2
fade_power 1
}
difference {
merge {
box { <0, -.1, 0>, <51.5,8.5,29.5> texture {T_Wall} }
box { <0, -.1, 0>, <51.5,-4,29.5> texture {T_Masonry} }
box { <-.5,-4, -.5>, <52,-10.6,30> texture {T_Masonry} }
}
merge {
box { <29.5, 3, 6.1>, <35.5, -5, -1.5> }
box { <29.5, -.1, 9.6>, <35.5, 8.1, 0.5> }
texture {T_WallPaper}
}
}
--
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usit net (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.fourthfoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html
You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)
"The comedy is over" -i pagliacci
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Differences of coplanar surfaces are not well defined.
Due to the finite precision of floating point operations.
You should always make sure the negative object overlaps
the positive one.
This is a well-known feature of POV, and other renderers,
as well.
Dan
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
>
> Differences of coplanar surfaces are not well defined.
> Due to the finite precision of floating point operations.
> You should always make sure the negative object overlaps
> the positive one.
>
> This is a well-known feature of POV, and other renderers,
> as well.
>
> Dan
>
Hmm. That makes life more difficult. :)
So, you're saying that I just have to make sure it overlaps by a small
amount (.001 or so) to fix it. And that's what every does?
That is, in fact btw, how I "hacked" the problem last night after
spending a few frustrating hours tearing apart my house model looking
for the stray object I thought was causing the prob.
Thanks for the info.
You know, a scene directory containing examples of all the "features" of
pov-ray might be useful. If anyone ever makes one, I'll donate my
preceding scene. ;-)
--min
> --
> http://www.flash.net/~djconnel/
--
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usitnet (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.fourthfoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html
You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)
"The comedy is over" -i pagliacci
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This, btw, is what I was talking about to anyone that was curious.
Later,
--
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usitnet (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.fourthfoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html
You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)
"The comedy is over" -i pagliacci
Post a reply to this message
Attachments:
Download 'bug1_pr31.jpg' (11 KB)
Download 'hackedbug1_pr31.jpg' (12 KB)
Preview of image 'bug1_pr31.jpg'
Preview of image 'hackedbug1_pr31.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lewis Sellers wrote:
> Hmm. That makes life more difficult. :)
Nt really -- you get accustomed to it quickly.
> So, you're saying that I just have to make sure it overlaps by a small
> amount (.001 or so) to fix it. And that's what every does?
Yes. It can either be an offset or a scaling. But make
sure it overlaps.
Also on unions where the components have different textures,
you must also avoid coincident surfaces for the same reason.
It's a classic raytracing problem.... as I said, one quickly
gets used to avoiding it.
Dan
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lewis Sellers wrote:
> You know, a scene directory containing examples of all the "features" of
> pov-ray might be useful. If anyone ever makes one, I'll donate my
> preceding scene. ;-)
>
> --min
Greetings
Actually there is a scene directory that has virtually
every feature that POV-Ray has to offer. It is the
example files that ship with each version of Pov.
They are not intended to be something to just render
so you can pretty up your hard drive. Each scene was
chosen, because it demonstrates a feature of the
program, that they feel either helps introduce a new
feature or it demonstrates some of the variables of a
feature that might otherwise be missed. They have
always done it this way and it is surprising to me
how many people seem miss it.
Anyway I'll get off of my soap box now.
While cruising several of the povray related sites today
I found a good on line tutorial detailing the use of csg
operations in POV-Ray. It offers straight forward examples
with image and text based explanations that are well
thought out and easy to understand.
Take a look at:
http://tqd.advanced.org/3285/language/csg.html#intersection
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Lewis Sellers wrote:
>
> > You know, a scene directory containing examples of all the "features" of
> > pov-ray might be useful. If anyone ever makes one, I'll donate my
> > preceding scene. ;-)
> >
> > --min
>
> Greetings
>
> Actually there is a scene directory that has virtually
> every feature that POV-Ray has to offer. It is the
> example files that ship with each version of Pov.
>
> They are not intended to be something to just render
> so you can pretty up your hard drive. Each scene was
Oh. Now you tell me, after I've rendered them all. :)
But anyway, I think I didn't make myself quite as clear as I intended. I
only meant that there should be another scenes folder, perhaps called
"bugs" or "things to watch out for". In it there would be little scenes
demonstrating CSG problems such as mine, with little comments on how to
overcome them.
I have actually renendered all the sample scene files and found them
very helpful. :)
--min
> Anyway I'll get off of my soap box now.
You're soap box's ior seems a bit off btw. ;-)
> Take a look at:
>
> http://tqd.advanced.org/3285/language/csg.html#intersection
ookie moo.
Thanks,
--min
>
> Ken Tyler
--
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usitnet (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.fourthfoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html
You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)
"The comedy is over" -i pagliacci
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
>
> Lewis Sellers wrote:
> > Hmm. That makes life more difficult. :)
>
> Nt really -- you get accustomed to it quickly.
>
>
> > So, you're saying that I just have to make sure it overlaps by a small
> > amount (.001 or so) to fix it. And that's what every does?
>
> Yes. It can either be an offset or a scaling. But make
> sure it overlaps.
>
> Also on unions where the components have different textures,
> you must also avoid coincident surfaces for the same reason.
>
> It's a classic raytracing problem.... as I said, one quickly
> gets used to avoiding it.
>
Ah. Still feels a bit messy, but thanks. I guess it's a good thing--my
first encounter with a "classic raytracing problem". I think it deserves
it's own month at IRTC. ;-)
Thanks,
--min
> Dan
>
> --
> http://www.flash.net/~djconnel/
--
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usitnet (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.fourthfoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html
You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)
"The comedy is over" -i pagliacci
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lewis Sellers <lse### [at] usitnet> wrote:
: So, you're saying that I just have to make sure it overlaps by a small
: amount (.001 or so) to fix it. And that's what every does?
: That is, in fact btw, how I "hacked" the problem last night after
: spending a few frustrating hours tearing apart my house model looking
: for the stray object I thought was causing the prob.
You talk like it was a bug which you have to avoid by hacking the scene
in some way.
No, it's not a bug. Povray works perfectly. How do you expect povray to
know which one of the coincident planes is at the most top? You have to
tell it to povray or it can't calculate it. And you tell that by placing
the topmost surface a little higher than the other.
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
> No, it's not a bug. Povray works perfectly. How do you expect povray to
> know which one of the coincident planes is at the most top?
No. It is a bug.
It is a simple fact of algebra that any object minus itelf equals zero,
or null. In POV this is not the case. Therefore it is a bug.
Does (sqrt 2)^2 - 2 = 0? Is 3 * (1/3) - 1 = 0? Of course. But computers
may not yield these results.
There is no ambiguity in the case of difference.
Now in the case of union, I agree with you.
Dan
P.S. Just because it is a bug doesn't mean it should be fixed, as
the problem is with the way computers represent floating point numbers,
and thus isn't something which POV should try to correct.
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly <djc### [at] flashnet> wrote:
:> No, it's not a bug. Povray works perfectly. How do you expect povray to
:> know which one of the coincident planes is at the most top?
: No. It is a bug.
: It is a simple fact of algebra that any object minus itelf equals zero,
: or null. In POV this is not the case. Therefore it is a bug.
No, it isn't a bug.
A bug is a programming error: The program should work in other way, but it
doesn't because of a human error while writing the program source code.
This isn't a programming error. It works exactly like the programmer
intended it to work, and there's no better way to do it.
It's a computer limitation, not a bug.
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay -- we agree. It depends how one defines "bug".
But I agree POV code is not incorrect.
Dan
> :> No, it's not a bug.
> : No. It is a bug.
> No, it isn't a bug.
> It's a computer limitation, not a bug.
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
> Okay -- we agree. It depends how one defines "bug".
> But I agree POV code is not incorrect.
>
> Dan
>
> > :> No, it's not a bug.
> > : No. It is a bug.
> > No, it isn't a bug.
> > It's a computer limitation, not a bug.
>
> --
> http://www.flash.net/~djconnel/
Reminds me of a Monty Python skit --
Yes it is !
No it isn,t !
Yeeess it is !!
Isn't !
Is too ! ....
Now for my 2 cents worth.
We all agree it is a nuisance. And my understanding of the
ambiguity is that it occurs at a level where the decimal
places are out somewhere around 5, 6, or more places.
Fine ! Why not put a trap directive in the program
(for csg only of course) that automatically re-scales the
object so this doesn't occur.
I know some of you math geek's are squirming in your
chairs right now but the facts are you can model a molecule
in hundreds of pov units. It's all a matter of perspective.
So the program sees a situation where the csg operation
is going to have perfectly aligned surfaces. Bing ! it quite
at random laps one surface over the other say by 0.0001.
This would be enough to rid the coincident surface from
the scene and calculating whose surface, is whose, is no longer
a problem.
If there is some one out there complains that they actually
use a scaling of .0001 or less in his/her scenes then I think
they need to get a life. The human eye cannot resolve these kinds
of distances anyway and the camera would have to be almost
touching the object to see the difference anyway.
I dare to challenge your sensibilities.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> Reminds me of a Monty Python skit --
> Yes it is !
> No it isn,t !
> Yeeess it is !!
> Isn't !
> Is too ! ....
>
> We all agree it is a nuisance. And my understanding of the
> ambiguity is that it occurs at a level where the decimal
> places are out somewhere around 5, 6, or more places.
> Fine ! Why not put a trap directive in the program
> (for csg only of course) that automatically re-scales the
> object so this doesn't occur.
Well, I think it logical to assume that if you have a large block of
wood (A), and cut out a smaller block of it (B), that the interior of
what remains of A would not suddenly go poof, and leave you with the
skin of A only. At least, I've never seen this happen to a wood carver.
:)
You mathematically endowed people say it's a limitation of the algebra
being using. Ok. I'll take your word for it. If so, it's not a "bug"
anymore than division by 0 is. But div by 0 can be trapped and special
cased so....
Anyway, I'm going to irritate someone working on povray if I keep
talking so I'm dropping out of this conversation. ;->
> If there is some one out there complains that they actually
> use a scaling of .0001 or less in his/her scenes then I think
> they need to get a life. The human eye cannot resolve these kinds
> of distances anyway and the camera would have to be almost
> touching the object to see the difference anyway.
Well, it does seem to break up the texture I was using noticiably when
I'm nearby. But.... that may just be a special case.
>
> I dare to challenge your sensibilities.
>
> Ken
--
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usitnet (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.fourthfoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html
You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)
"The comedy is over" -i pagliacci
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 04 Oct 1998 11:34:04 -0700, Ken <tyl### [at] pacbellnet> wrote:
> So the program sees a situation where the csg operation
>is going to have perfectly aligned surfaces. Bing ! it quite
>at random laps one surface over the other say by 0.0001.
So sometimes it gets it right, and sometimes it gets it wrong. How is
this better than the current situation? It can't decide which is on
top at random, or half the time it'll end up leaving a 'skin' anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ronald L. Parker wrote:
> On Sun, 04 Oct 1998 11:34:04 -0700, Ken <tyl### [at] pacbellnet> wrote:
> > So the program sees a situation where the csg operation
> >is going to have perfectly aligned surfaces. Bing ! it quite
> >at random laps one surface over the other say by 0.0001.
>
> So sometimes it gets it right, and sometimes it gets it wrong. How is
> this better than the current situation? It can't decide which is on
> top at random, or half the time it'll end up leaving a 'skin' anyway.
Although I believe you should be looking at the bigger picture here
I ask that you allow me to append the above by removing the
"it quite at random" words from my previous reply and substitute with --
it then evaluates a predefined set of conditional design rules.
Once satisfied that all conditions meet the criteria it then overlaps
one surface by a given amount to eliminate the undesired condition.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: So the program sees a situation where the csg operation
: is going to have perfectly aligned surfaces.
I want to see that function, which takes any two objects and checks if
they have coincident surfaces (note that the coincidence doesn't have to
be 2-dimensional, it may occur also in a 1-dimensional line (which causes
random black dots along this line)). For example it would check if a
7th order poly object and a blob have a coincident surface... Or a lathe
object and a bezier patch... :)
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Oct 1998 10:47:53 -0500, Nieminen Mika <war### [at] assaricctutfi> wrote:
>Ken <tyl### [at] pacbellnet> wrote:
>: So the program sees a situation where the csg operation
>: is going to have perfectly aligned surfaces.
>
> I want to see that function, which takes any two objects and checks if
>they have coincident surfaces (note that the coincidence doesn't have to
>be 2-dimensional, it may occur also in a 1-dimensional line (which causes
>random black dots along this line)). For example it would check if a
>7th order poly object and a blob have a coincident surface... Or a lathe
>object and a bezier patch... :)
Well, one could argue that if the first two intersections it finds while
tracing rays are within a specified tolerance, then it should kick into
"coincident surfaces resolution mode," but it's not entirely clear what
it should do in each case. I think it would have to walk the CSG tree
and determine which operation the two objects found have in common at
the lowest level, then decide whether there's really an intersection
there or not, and if there is which surface it should intersect with.
Then, of course, it should store that decision so it always reaches
a consistent conclusion when it hits that particular pair of surfaces.
(Meaning: if it hits it from the same direction, use the same surface;
if it comes from the other direction, use the other one.)
How to decide if there's really an intersection there? If the common
operation is intersection, should we throw the intersection away or
keep it? I think this depends on whether we're entering both objects,
leaving both objects, or entering one and leaving another. In the
first two cases, keep it. In the last case, throw it away. For
union, always keep it. For merge, keep it using the same criteria
as for intersection. Difference, of course, does not exist as a CSG
type, but the proposed intersection rules seem to do the right thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] my-dejanewscom> wrote:
: How to decide if there's really an intersection there? If the common
: operation is intersection, should we throw the intersection away or
: keep it? I think this depends on whether we're entering both objects,
: leaving both objects, or entering one and leaving another. In the
: first two cases, keep it. In the last case, throw it away. For
: union, always keep it. For merge, keep it using the same criteria
: as for intersection. Difference, of course, does not exist as a CSG
: type, but the proposed intersection rules seem to do the right thing.
Note that the coincident surfaces problem (this is a so used term it should
be abbreviated CSP :) ) can also occur with objects not in the same CSG.
Also note that a very special case of CSP occurs when a light source is
exactly on a surface: Povray can't calculate accurately if the light source
is inside or outside the surface, so black spots will appear in every
place which is illuminated by this light.
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
> Note that the coincident surfaces problem (this is a so used term it should
> be abbreviated CSP :) ) can also occur with objects not in the same CSG.
> Also note that a very special case of CSP occurs when a light source is
> exactly on a surface: Povray can't calculate accurately if the light source
> is inside or outside the surface, so black spots will appear in every
> place which is illuminated by this light.
>
> --
> - Warp. -
It can also appear if you have two flat surfaces abutting each other
but otherwise having nothing in common. I have seen it recently when
another pov user asked why one of the example scene files included
with pov, had black artifacts. It was a box resting on a plane and the
coincident surface occurred between them.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Oct 1998 11:14:19 -0500, Nieminen Mika <war### [at] assaricctutfi> wrote:
> Note that the coincident surfaces problem (this is a so used term it should
>be abbreviated CSP :) ) can also occur with objects not in the same CSG.
In this case, treat it as if their common ancestor were a union, since
adding a union around the whole frame should have no net effect.
> Also note that a very special case of CSP occurs when a light source is
>exactly on a surface: Povray can't calculate accurately if the light source
>is inside or outside the surface, so black spots will appear in every
>place which is illuminated by this light.
Well, one could see that the light source and one of the intersections
coincide within the same tolerance while looking for shadow rays. In
this case, one would always discard the intersection.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
