![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Har har... ;) I'm rendering a version without the little man, or the grass.
It's just the tree and the leaves on the ground. I hope this one finishes,
at least.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Isn't that an ocTREE in your image? ;-)
you need to remove its block, and dispose of it carefully in a red bag....
Rick
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> ...when a render doesn't finish after 1 day, 7 hours, 29 minutes and 1
i dont let my renders go on for more that 16 hours, you should put your foot
down and demand they stop messing around !
looks very good tho
Rick
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nathan Kopp <Nat### [at] kopp com> wrote:
: Actually, if done properly, many of the leaf nodes could be stored on disk
: and cached in memory only as needed.
Doesn't any disk cache do this already? Most systems use a disk cache
(even DOS if you use smartdrive).
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39cc0505@news.povray.org>, "Tony[B]"
<ben### [at] panama c-com net> wrote:
> Oh, please do look into it Nathan. If anyone can do it it's you. (Or Chris
> H., or Ron P. or... :)
Not me...I haven't touched the radiosity code, and don't know much of
the algorithms and math behind it. Nathan seems to be the radiosity
expert...Nathan?
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Tony[B]" <ben### [at] panama c-com net> writes:
> > You're using radiosity. The radiosity samples are stored in an octree
> > for faster access. Seems you ran out of memory and when (M)POV took
> > another radiosity sample (during the actual rendering) and tried to
> > store it, it could not 'allocate 144 for [the] octree block.'
>
> Why can't this [friggin'] octree be stored to the hard disk instead of RAM?
Increase your swap space! By this you use the hard disc instead of RAM.
It is however up to the OS which parts of the memory are transferred to
the disc. Today's hard discs are so large that a GB of swap space is
feasible.
I hope this helps
Thomas
--
http://www.thomas.willhalm.de/ (includes pgp key)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Tony[B]" wrote:
> ...when a render doesn't finish after 1 day, 7 hours, 29 minutes and 1
> second, reporting that there was a "Rendering error. Out of memory. Cannot
> allocate 144 bytes for octree block." Yup, that hurts a lot. Especially when
> you've tried to leave the machine alone, so it renders faster during this
> time period. Can someone tell me why this happened? What is an octree block,
> and why did it eat up all my RAM?
>
Ahh, just happened to me on a 800*600 radiosity image, and I did raise the swap
up to 450 Mb... But I could resume the render without any problem (it had the +C
switch). At least it didn't crash Windows, like post-process does when out of
memory.
I wonder what's going to happen when I'll render the same picture at 16 times
the current size, though. Perhaps I'll render it chunk by chunk.
G.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Does the render show discontinuity at the point of +C or did you save the
radiosity to a file?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Tony[B]" wrote:
> Does the render show discontinuity at the point of +C or did you save the
> radiosity to a file?
No visible discontinuity, but it's in a pretty dark zone, so it's hard to
tell. I didn't save the radiosity to a file. Megapov stopped rather cleanly
and removed the rca file as if it had correctly finished the picture (or so I
remember).
What seems strange to me is that the memory use is lower when only a part of
the picture is rendered.
G.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gilles Tran wrote:
>
> What seems strange to me is that the memory use is lower when only a part of
> the picture is rendered.
>
That' not too surprising: there are less radiosity samples to store,
therefore it uses less memory.
--
* Doctor Jekyll had something * mailto:ber### [at] iname com
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |