 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
yep, a wrong value for max_trace_level was the reason,
but... this is still a mystery to me, because I know I didn't specify
ANY global_settings in the scene file yesterday, and POV-Ray still
produced garbage; today I tried again (I didn't make any changes) and
these black squares were gone! The only explanation I can imagine is
that POV-Ray crashed (which happens under Windoze95 quite often) and
after restarting POV-Ray it got a bit confused and somehow used a
wrong value (6 or 7?) for max_trace_level!?
Anyway, there is left a strange white vertical line in the middle of
the rendered picture. Does anyone know why?
btw I'm using version 3.1a.watcom.win32 [Pentium II optimized]
would it be possible to achieve the same result (without that white
line of course *g*) by using density_map / color_map on a _single_
cube instead?
Daniel
Post a reply to this message
Attachments:
Download 'rgb_cube_2nd_try.jpg' (4 KB)
Preview of image 'rgb_cube_2nd_try.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fact is there are actually no coincident surfaces anyway in Daniels
script. The individual boxes are reduced to nine tenths their original
size (which if left unscaled would have been a potential problem,
maybe?). Being that much smaller however might be leading to some
trouble though, leaving gaps between each cube.
Dave Kreskowiak wrote:
>
> I ran into a problem probably similar to yours. I was trying to render
> billowing smoke from something like a gasoline or oil fire. There spheres I
> was using for containers intersected (overlapped) each other without any
> coincident surfaces. The black areas I got were intermittent, but were
> always confined to the INTERSECTION of the spheres, not coincident surfaces.
> Moving the spheres around slightly got around the problem but it appears to
> be a bug in POV.
>
> In my experience, coincident surfaces tend to render a jittered imaged of
> both textures, not a black spot. How about this... try it out 2 images
> using just 2 boxes, side by side, and the texture that your using. In one
> image put one box about half way into the other and render it and in the
> other, make the boxes just touch each other (coincident surfaces) and render
> it. Just to see what happens.
>
> I'd try it and show you what I mean right now but I have a 6 day render
> running right now with 4 days to go...
>
> news:379a139b@news.povray.org...
> >
> > Hi all!
> >
> > I wanted to create a rgb-cube by putting together 10^3 smaller cubes
> > filled with an emission media. But there are some strange black
> > squares between the smaller cubes! Changing density, transmit and/or
> > filter values didn't help.
> >
> > Does anyone know where the problem is??
> >
> > Thanx in advance,
> > Daniel
> >
> >
> >
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto://inversez@aol.com?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I overlooked the scaling down of each individual box before. There is no
possibility of coincident surfaces.
Bob Hughes wrote:
>
> Yes. there is a need for a higher max_trace_level. About 15 seems okay,
> but 150 was better, somewhere inbetween perhaps then. I was going to say
> it probably is coincident surfaces but the effect goes away, or appears
> to anyway. The container objects being invisible to start with might not
> make it obvious but still cause trouble, not sure. At the default trace
> level it didn't show any change when I rescaled the boxes down slightly.
>
> Ken wrote:
> >
> > Ken wrote:
> > >
> > > >
> > > > Hi all!
> > > >
> > > > I wanted to create a rgb-cube by putting together 10^3 smaller cubes
> > > > filled with an emission media. But there are some strange black
> > > > squares between the smaller cubes! Changing density, transmit and/or
> > > > filter values didn't help.
> > > >
> > > > Does anyone know where the problem is??
> > > >
> > > > Thanx in advance,
> > > > Daniel
> > >
> > > I don't have time to look at your source now but try adding a
> > > nax_trace_level in your global settings. I would start with
> > > something like 30 or more with this many objects in the scene.
> >
> > I didn't see the image either until now. Um there is a problem in
> > pov called coincident surfaces where if you have transparent objects
> > whose faces occupy the same space like two boxes abutting each other
> > the raytracer cannot decide which surface belongs to which object.
> > The easiest way to avoid this is to seperate them by a tiny amount
> > or have them overlap by a tiny amount. If you overlap them you can
> > also use a merge operation to remove all of the inner surfaces.
> > Read up in the docs about csgs and coincident surfaces.
> > max_trace_level can still be an issue so don't hesitate adding
> > that to your scene too.
> > --
> > Ken Tyler
> >
> > mailto://tylereng@pacbell.net
> > http://home.pacbell.net/tylereng/links.htm
>
> --
> omniVERSE: beyond the universe
> http://members.aol.com/inversez/homepage.htm
> mailto://inversez@aol.com?Subject=PoV-News
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto://inversez@aol.com?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shift your camera or rotate the entire cube itself (using a union) ever
so slightly and the vertical white line will disappear. It's a result of
the opposite front and back edges lining up.
>
> yep, a wrong value for max_trace_level was the reason,
> but... this is still a mystery to me, because I know I didn't specify
> ANY global_settings in the scene file yesterday, and POV-Ray still
> produced garbage; today I tried again (I didn't make any changes) and
> these black squares were gone! The only explanation I can imagine is
> that POV-Ray crashed (which happens under Windoze95 quite often) and
> after restarting POV-Ray it got a bit confused and somehow used a
> wrong value (6 or 7?) for max_trace_level!?
>
> Anyway, there is left a strange white vertical line in the middle of
> the rendered picture. Does anyone know why?
>
> btw I'm using version 3.1a.watcom.win32 [Pentium II optimized]
>
> would it be possible to achieve the same result (without that white
> line of course *g*) by using density_map / color_map on a _single_
> cube instead?
>
> Daniel
>
> [Image]
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto://inversez@aol.com?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> Fact is there are actually no coincident surfaces anyway in Daniels
> script. The individual boxes are reduced to nine tenths their original
> size (which if left unscaled would have been a potential problem,
> maybe?). Being that much smaller however might be leading to some
> trouble though, leaving gaps between each cube.
The only problems I foresee with that would be the increased number
of intersection tests needed. This of course can be compensated for by
increasing the max trace level to an adequate amount.
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>but... this is still a mystery to me, because I know I didn't specify
>ANY global_settings in the scene file yesterday, and POV-Ray still
>produced garbage; today I tried again (I didn't make any changes) and
>these black squares were gone! The only explanation I can imagine is
>that POV-Ray crashed (which happens under Windoze95 quite often) and
>after restarting POV-Ray it got a bit confused and somehow used a
>wrong value (6 or 7?) for max_trace_level!?
Hi, Daniel. This was a known bug and has been fixed since POV-Ray for
Windows v3.1d (we are now at v3.1g). As per Changes.txt that accompanies
POVWin:
o Fixed MAX_TRACE_LEVEL global not being re-initialized.
--
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alan Kong wrote:
>
>
> >but... this is still a mystery to me, because I know I didn't specify
> >ANY global_settings in the scene file yesterday, and POV-Ray still
> >produced garbage; today I tried again (I didn't make any changes) and
> >these black squares were gone! The only explanation I can imagine is
> >that POV-Ray crashed (which happens under Windoze95 quite often) and
> >after restarting POV-Ray it got a bit confused and somehow used a
> >wrong value (6 or 7?) for max_trace_level!?
>
> Hi, Daniel. This was a known bug and has been fixed since POV-Ray for
> Windows v3.1d (we are now at v3.1g). As per Changes.txt that accompanies
> POVWin:
>
> o Fixed MAX_TRACE_LEVEL global not being re-initialized.
>
> --
> Alan
Alan,
I was wondering what that bug meant. Now it makes sense - thanks.
Daniel,
There are also other important bug fixes since that version you
are using and you are encouraged to upgrade now to avoid other
similar problems.
http://www.povray.org
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Shift your camera or rotate the entire cube itself (using a union)
ever
>so slightly and the vertical white line will disappear. It's a result
of
>the opposite front and back edges lining up.
it helped a bit but there was still not much improvement... some dots
disappear, others reappear :-/
Post a reply to this message
|
|
| |
| |
|
|
From: Dave Kreskowiak
Subject: Re: rgb-cube and problems with media
Date: 25 Jul 1999 20:30:14
Message: <379bac16@news.povray.org>
|
|
|
| |
| |
|
|
Maybe I'll go back and try the MaxTraceLevel on the smoke again to see if it
corrects the problem I was having. (Didn't do anything with it because it
took too long to try and fix a problem and test!)
Thanks!
Bob Hughes <inv### [at] aol com> wrote in message
news:379B3FC1.A567748D@aol.com...
> Fact is there are actually no coincident surfaces anyway in Daniels
> script. The individual boxes are reduced to nine tenths their original
> size (which if left unscaled would have been a potential problem,
> maybe?). Being that much smaller however might be leading to some
> trouble though, leaving gaps between each cube.
>
>
> Dave Kreskowiak wrote:
> >
> > I ran into a problem probably similar to yours. I was trying to render
> > billowing smoke from something like a gasoline or oil fire. There
spheres I
> > was using for containers intersected (overlapped) each other without any
> > coincident surfaces. The black areas I got were intermittent, but were
> > always confined to the INTERSECTION of the spheres, not coincident
surfaces.
> > Moving the spheres around slightly got around the problem but it appears
to
> > be a bug in POV.
> >
> > In my experience, coincident surfaces tend to render a jittered imaged
of
> > both textures, not a black spot. How about this... try it out 2 images
> > using just 2 boxes, side by side, and the texture that your using. In
one
> > image put one box about half way into the other and render it and in the
> > other, make the boxes just touch each other (coincident surfaces) and
render
> > it. Just to see what happens.
> >
> > I'd try it and show you what I mean right now but I have a 6 day render
> > running right now with 4 days to go...
> >
> > news:379a139b@news.povray.org...
> > >
> > > Hi all!
> > >
> > > I wanted to create a rgb-cube by putting together 10^3 smaller cubes
> > > filled with an emission media. But there are some strange black
> > > squares between the smaller cubes! Changing density, transmit and/or
> > > filter values didn't help.
> > >
> > > Does anyone know where the problem is??
> > >
> > > Thanx in advance,
> > > Daniel
> > >
> > >
> > >
>
> --
> omniVERSE: beyond the universe
> http://members.aol.com/inversez/homepage.htm
> mailto://inversez@aol.com?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Not sure then, must be the version, I'm using 3.1g now. When I shifted
the camera or cube a bit it went completely away with a max_trace_level
of 30.
>
> >Shift your camera or rotate the entire cube itself (using a union)
> ever
> >so slightly and the vertical white line will disappear. It's a result
> of
> >the opposite front and back edges lining up.
>
> it helped a bit but there was still not much improvement... some dots
> disappear, others reappear :-/
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto://inversez@aol.com?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
