 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 25 Jul 1999 20:28:46 -0400, "Dave Kreskowiak"
<dkr### [at] homecom> wrote:
>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!
Replacing the spheres with the equivalent blob (of threshold 0.0001 or
similar) will result in a much faster and smoother render, and you
won't need to set max_trace_level too high. (You might need the
'sturm' keyword if there're a lot of elements, but that's all.) I have
too overlooked this method in the past until Chris Colefax opened my
eyes.
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
>
> On Sun, 25 Jul 1999 20:28:46 -0400, "Dave Kreskowiak"
> <dkr### [at] homecom> wrote:
>
> >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!
>
> Replacing the spheres with the equivalent blob (of threshold 0.0001 or
> similar) will result in a much faster and smoother render, and you
> won't need to set max_trace_level too high. (You might need the
> 'sturm' keyword if there're a lot of elements, but that's all.) I have
> too overlooked this method in the past until Chris Colefax opened my
> eyes.
>
> Peter Popov
> ICQ: 15002700
Why would this be ?
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 26 Jul 1999 01:55:17 -0700, Ken <tyl### [at] pacbellnet> wrote:
>> Replacing the spheres with the equivalent blob (of threshold 0.0001 or
>> similar) will result in a much faster and smoother render, and you
>> won't need to set max_trace_level too high. (You might need the
>> 'sturm' keyword if there're a lot of elements, but that's all.) I have
>> too overlooked this method in the past until Chris Colefax opened my
>> eyes.
>>
>> Peter Popov
>> ICQ: 15002700
>
>Why would this be ?
I didn't believe it either before I did the tests. First of all,
multiple containers for multiple media proved a lot faster and
smoother than multiple media in a single container. The reason is
that, as the media are better enclosed each in its own container, a)
fewer unnecessary calculations are performed and b) media intervals
are closer together. Or, if we choose a container that's fast and
tightly fitting the media, then it's ok too. With that said, there are
three ways to go:
Union of spheres - fast, but has the problem of the high
max_trace_level needed. Also, if the spheres are closely packed, it
gets really slow. I think the reason is that every time the ray
enters/leaves a sphere and leaves/enters another, that segment of it
gets media sampled. Imagine what happens with 150 closely packed
spheres.
Merge of spheres - the problems typical for the union of spheres are
avoided, but merge is really slow as is.
Blob - the fastest of all three due to the bounding hierarchy and it
also avoids the problems that an union of spheres has. Also, each
element gets its media sampled separately (or so it seems) and this
yields a smoother image.
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
>
> On Mon, 26 Jul 1999 01:55:17 -0700, Ken <tyl### [at] pacbellnet> wrote:
> >> Replacing the spheres with the equivalent blob (of threshold 0.0001 or
> >> similar) will result in a much faster and smoother render, and you
> >> won't need to set max_trace_level too high. (You might need the
> >> 'sturm' keyword if there're a lot of elements, but that's all.) I have
> >> too overlooked this method in the past until Chris Colefax opened my
> >> eyes.
> >>
> >> Peter Popov
> >> ICQ: 15002700
> >
> >Why would this be ?
>
> I didn't believe it either before I did the tests. First of all,
> multiple containers for multiple media proved a lot faster and
> smoother than multiple media in a single container. The reason is
> that, as the media are better enclosed each in its own container, a)
> fewer unnecessary calculations are performed and b) media intervals
> are closer together. Or, if we choose a container that's fast and
> tightly fitting the media, then it's ok too. With that said, there are
> three ways to go:
>
> Union of spheres - fast, but has the problem of the high
> max_trace_level needed. Also, if the spheres are closely packed, it
> gets really slow. I think the reason is that every time the ray
> enters/leaves a sphere and leaves/enters another, that segment of it
> gets media sampled. Imagine what happens with 150 closely packed
> spheres.
>
> Merge of spheres - the problems typical for the union of spheres are
> avoided, but merge is really slow as is.
>
> Blob - the fastest of all three due to the bounding hierarchy and it
> also avoids the problems that an union of spheres has. Also, each
> element gets its media sampled separately (or so it seems) and this
> yields a smoother image.
>
> Peter Popov
> ICQ: 15002700
Then as I understand it Pov will treat the blob method as a single blob
entity with multiple cells as opposed to sphere which it must treat as
multiple entities. Yes ?
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 26 Jul 1999 03:34:34 -0700, Ken <tyl### [at] pacbellnet> wrote:
> Then as I understand it Pov will treat the blob method as a single blob
>entity with multiple cells as opposed to sphere which it must treat as
>multiple entities. Yes ?
I can't tell more without a) peeking into the source code or b)
speculating. I wish to do neither therefore I will leave these musings
to the more qualified and take it as is.
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
