 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Currently doing what I hope will be my final, final render. :-) As
suspected, I seem to have made the scene render more slowly than it did in
October. I hope I've enhanced it in the process.
I've heard a couple people mention that they had dropped out of the
competition, but I hope we will have more participants in the extended
competition. If not, well perhaps I've got a chance. ;-)
Good luck to everyone!
--
Jeremy
www.beantoad.com
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jeremy M. Praay" <sla### [at] hotmail com> a écrit dans le message de
news:41e1ce6a@news.povray.org...
> Currently doing what I hope will be my final, final render. :-) As
> suspected, I seem to have made the scene render more slowly than it did in
> October. I hope I've enhanced it in the process.
>
> I've heard a couple people mention that they had dropped out of the
> competition, but I hope we will have more participants in the extended
> competition. If not, well perhaps I've got a chance. ;-)
>
> Good luck to everyone!
>
> --
Hi
I joined The Comp since deadline was extended.
My final render is currently tracing ...about 10 days to run (6 hours for
the upper 80% of the image!!)
Well... luck has few to do here, just hope no more hardware failure.
My CPU/motherboard/RAM fried once during my WIP so no more, please, Gods of
raytracing.
(Any advice if sacrificing a primitive -and which one- could be helpfull?)
Knowing some who are competiting I expect a postcard size Zazzle poster. (I
guess the dual opteron will come with a spanish keyboard :p)
Regards
Marc
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Marc Jacquier a écrit :
> ...
> guess the dual opteron will come with a spanish keyboard :p)
Unfair :-((((
> Regards
>
> Marc
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"LightBeam" <s.f### [at] tiscalifr> a écrit dans le message de
news:41e560b0@news.povray.org...
> Marc Jacquier a écrit :
> > ...
> > guess the dual opteron will come with a spanish keyboard :p)
>
> Unfair :-((((
>
I do think it's fair :-)
Marc
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Marc Jacquier" <jac### [at] wanadoofr> wrote in message
news:41e239bb$1@news.povray.org...
>
> Well... luck has few to do here, just hope no more hardware failure.
> My CPU/motherboard/RAM fried once during my WIP so no more, please, Gods
> of
> raytracing.
Windows XP decided to install an update last night (I forgot to turn that
feature off), so I got rebooted at 3:00am, about 75% complete. I just
discovered this a few minutes ago. Arrgghh.
But, now I see a couple of things that I want to nitpick over, so I probably
would have restarted anyway.
--
Jeremy
www.beantoad.com
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Windows XP decided to install an update last night (I forgot to turn that
> feature off), so I got rebooted at 3:00am, about 75% complete. I just
> discovered this a few minutes ago. Arrgghh.
+C ? Unless you're using radiosity...
- Slime
[ http://www.slimeland.com/ ]
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <fak### [at] emailaddress> wrote:
> +C ? Unless you're using radiosity...
At least in the past using +C with radiosity was not a problem.
If it's a problem currently, it's a bug, imho.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> a écrit dans le message de
news:41e7a1ab@news.povray.org...
> Slime <fak### [at] emailaddress> wrote:
> > +C ? Unless you're using radiosity...
>
> At least in the past using +C with radiosity was not a problem.
> If it's a problem currently, it's a bug, imho.
>
Here I've not any issue with +C and radiosity
Marc
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:41e7a1ab@news.povray.org...
> Slime <fak### [at] emailaddress> wrote:
>> +C ? Unless you're using radiosity...
>
> At least in the past using +C with radiosity was not a problem.
> If it's a problem currently, it's a bug, imho.
>
I did a +C and it looks ok (even with radiosity), but it happened to crash
right where there is a natural horizontal line in the image, so any problems
wouldn't likely be noticed anyway. It's only a 4-day render, and there are
a couple things that I'm still not 100% happy with, so it will likely be
re-rendered regardless.
But... If I recall correctly, using +C with radiosity was a problem in 3.5.
Is that what you mean? If there was a way around it (short of saving the
radiosity data before doing the render), I was never aware of it. You
basically end-up with a line where the continuation took place. At least,
that's what I recall.
--
Jeremy
www.beantoad.com
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > At least in the past using +C with radiosity was not a problem.
> > If it's a problem currently, it's a bug, imho.
>
> But... If I recall correctly, using +C with radiosity was a problem in
3.5.
> Is that what you mean? If there was a way around it (short of saving the
> radiosity data before doing the render), I was never aware of it. You
> basically end-up with a line where the continuation took place. At least,
> that's what I recall.
Yeah, that's what I was referring to. Without a save_file and load_file, I
would be surprised if the horizontal line could be avoided, since the second
time through, POV-Ray can't have the radiosity data from the first time
through.
Of course, it *works*, in that the image continues to render from where it
left off, but the results can be bad.
- Slime
[ http://www.slimeland.com/ ]
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> At least in the past using +C with radiosity was not a problem.
> If it's a problem currently, it's a bug, imho.
>
It usually is no problem but there are technical differences - not all
data stored in memory during a radiosity render is also written to the file.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeremy M. Praay <jer### [at] questsoftwarecom> wrote:
> But... If I recall correctly, using +C with radiosity was a problem in 3.5.
> Is that what you mean?
No. Using +C with radiosity was precisely not a problem with 3.5. If it
is a problem with the current version, it's a bug.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <fak### [at] emailaddress> wrote:
> Yeah, that's what I was referring to. Without a save_file and load_file, I
> would be surprised if the horizontal line could be avoided, since the second
> time through, POV-Ray can't have the radiosity data from the first time
> through.
Incorrect. Interrupted rendering and radiosity was never a problem with
POV-Ray. Haven't you noticed how POV-Ray saves the radiosity data in a file
during rendering precisely for the purpose of supporting interrupted renders?
The save_file and load_file features were not innovations. They simply
gave more user control to the file which POV-Ray was already creating.
> Of course, it *works*, in that the image continues to render from where it
> left off, but the results can be bad.
They were bad only if you deleted the temporary radiosity file POV-Ray
had created. Else it was just ok.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> It usually is no problem but there are technical differences - not all
> data stored in memory during a radiosity render is also written to the file.
If that is so, then imho it should be fixed.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:41ebaf49@news.povray.org...
> Jeremy M. Praay <jer### [at] questsoftwarecom> wrote:
>> But... If I recall correctly, using +C with radiosity was a problem in
>> 3.5.
>> Is that what you mean?
>
> No. Using +C with radiosity was precisely not a problem with 3.5. If it
> is a problem with the current version, it's a bug.
>
I tried to prove you wrong (with version 3.5). I set count to various
values (all the way down to 1) in a simple radiosity scene. I started and
stopped it repeatedly but it worked just fine every time. I even stopped
and restarted POV-Ray, and it still worked just fine. I'm going to assume
that you are correct, and that I was remembering something else, such as
splitting-up a render across different machines.
--
Jeremy
www.beantoad.com
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Incorrect. Interrupted rendering and radiosity was never a problem with
> POV-Ray. Haven't you noticed how POV-Ray saves the radiosity data in a
file
> during rendering precisely for the purpose of supporting interrupted
renders?
No, I hadn't. Cool!
I vaguely recall seeing a scene, I think posted in these newsgroups, where
someone was complaining that +C wasn't working with their image and it had
the problem I described. It's possible that some people (including myself)
accidentally concluded that radiosity was the cause. That was a long time
ago though, so either it was a separate bug or just the fault of the person
making the image.
- Slime
[ http://www.slimeland.com/ ]
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeremy M. Praay <jer### [at] questsoftwarecom> wrote:
> I tried to prove you wrong (with version 3.5). I set count to various
> values (all the way down to 1) in a simple radiosity scene. I started and
> stopped it repeatedly but it worked just fine every time. I even stopped
> and restarted POV-Ray, and it still worked just fine. I'm going to assume
> that you are correct, and that I was remembering something else, such as
> splitting-up a render across different machines.
When you stopped rendering, did you check if an extra file had
appeared in the same directory where the scene was? (Or it might appear
in the same directory as the final image is written; I don't really know
which.) It's the radiosity cache file (it is removed after the rendering
ends).
But certainly if you render half of the image and then the other half
as a separate render (with start/end row options) you will most probably
get a visible line.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:41ed08c4@news.povray.org...
>
> But certainly if you render half of the image and then the other half
> as a separate render (with start/end row options) you will most probably
> get a visible line.
>
I'm assuming that this is because radiosity uses some sort of random numbers
in the generation of the data. If that's the case, it might be a nifty
feature if the user could supply a "radiosity_seed Float" to ensure that it
used the same random seed. Otherwise, the only alternative of which I am
aware, is to create the radiosity data in advance of the actual rendering.
Just a thought.
--
Jeremy
www.beantoad.com
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm assuming that this is because radiosity uses some sort of random
numbers
> in the generation of the data. If that's the case, it might be a nifty
> feature if the user could supply a "radiosity_seed Float" to ensure that
it
> used the same random seed.
Having the same random seed wouldn't mean you have the same data that was
calculated in the first rendering. To get that, you'd have to rerender from
scratch (using the seed) - which defeats the purpose.
- Slime
[ http://www.slimeland.com/ ]
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Currently doing what I hope will be my final, final render. :-)
I have also managed to put together a scene which I will submit (thank
goodness for the deadline extension). I have at least four "final" renders
in my image folder now. =)
Thankfully, unlike you crazy people, I refuse to render anything slower than
5 pps. Right now I'm going at about 30 or so.
- Slime
[ http://www.slimeland.com/ ]
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeremy M. Praay <sla### [at] hotmailcom> wrote:
> I'm assuming that this is because radiosity uses some sort of random numbers
> in the generation of the data.
Nope. It's because the radiosity algorithm reuses the data calculated
so far. If you start from the middle of the image, there's no data from
the first half to be reused. This usually causes the illumination to
differ visibly.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <fak### [at] emailaddress> wrote in message
news:41edfbd4$1@news.povray.org...
>> Currently doing what I hope will be my final, final render. :-)
>
> I have also managed to put together a scene which I will submit (thank
> goodness for the deadline extension). I have at least four "final" renders
> in my image folder now. =)
I don't have any 'final' renders as yet, but I think I might be the only
person to create three *heavy-ish* scenes for one comp this time around. I
lost the first two... :o/
>
> Thankfully, unlike you crazy people, I refuse to render anything slower
> than
> 5 pps. Right now I'm going at about 30 or so.
Heh... ;) I've just aborted a 1pps image at 1280x1024... 18hrs, line 3...
It took nearly 20 minutes to abort... (What's with that?) :o(
~Steve~
>
> - Slime
> [ http://www.slimeland.com/ ]
>
>
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Heh... ;) I've just aborted a 1pps image at 1280x1024... 18hrs, line
3...
1280x1024... have you compensated for the non-4:3 aspect ratio? Just
checking since some people might not realize that 1280x1024 is not 4:3.
> It took nearly 20 minutes to abort... (What's with that?) :o(
Was it thrashing? It could have been trying to free memory.
- Slime
[ http://www.slimeland.com/ ]
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <fak### [at] emailaddress> wrote in message
news:41edc6b2$1@news.povray.org...
>> I'm assuming that this is because radiosity uses some sort of random
> numbers
>> in the generation of the data. If that's the case, it might be a nifty
>> feature if the user could supply a "radiosity_seed Float" to ensure that
> it
>> used the same random seed.
>
> Having the same random seed wouldn't mean you have the same data that was
> calculated in the first rendering. To get that, you'd have to rerender
> from
> scratch (using the seed) - which defeats the purpose.
>
Oops. Got it. That severely limits the usefulness of my suggestion.
--
Jeremy
www.beantoad.com
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <fak### [at] emailaddress> wrote in message
news:41eebe50$1@news.povray.org...
>> Heh... ;) I've just aborted a 1pps image at 1280x1024... 18hrs, line
> 3...
>
> 1280x1024... have you compensated for the non-4:3 aspect ratio? Just
> checking since some people might not realize that 1280x1024 is not 4:3.
>
>> It took nearly 20 minutes to abort... (What's with that?) :o(
>
> Was it thrashing? It could have been trying to free memory.
>
I think it can only abort when it finishes rendering a pixel. So in your
case, it took about 20 minutes to render a pixel. I'm probably commenting
about something where I'm wrong again, but that never stops me from trying.
My best guess is that this has to do with threaded execution. The thread
probably only checks the abort state after it finishes rendering a pixel. I
don't think POV 3.5 acted that way.
--
Jeremy
www.beantoad.com
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <fak### [at] emailaddress> wrote in message
news:41edfbd4$1@news.povray.org...
>> Currently doing what I hope will be my final, final render. :-)
>
> I have also managed to put together a scene which I will submit (thank
> goodness for the deadline extension). I have at least four "final" renders
> in my image folder now. =)
Great to hear!
>
> Thankfully, unlike you crazy people, I refuse to render anything slower
> than
> 5 pps. Right now I'm going at about 30 or so.
>
If it's not around 5 pps, then I need to turn up the radiosity settings.
;-)
--
Jeremy
www.beantoad.com
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <fak### [at] emailaddress> wrote in message
news:41eebe50$1@news.povray.org...
>> It took nearly 20 minutes to abort... (What's with that?) :o(
>
> Was it thrashing? It could have been trying to free memory.
Not sure, but my little orange CPU light was going crazy, so I would
guess that you're correct.
~Steve~
>
> - Slime
> [ http://www.slimeland.com/ ]
>
>
|
|
| |
| |
|
|
|
|
| |
