 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
'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
|
|
| |
| |
|
|
|
|
| |
|
|
