 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
...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?
Post a reply to this message
Attachments:
Download 'ouch.jpg' (80 KB)
Preview of image 'ouch.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm going to have to go Catholic on this on and say "Well, it's a mystery."* I
have no idea what that error means, but I like the tree. It looks like all the
leaves are coming down off of the branch, though.
Josh
"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?
>
> [Image]
*This line is from George Carlin, not me. Flame with caution.
--
Josh English -- Lexiphanic Lethomaniac
eng### [at] spiritone com
The POV-Ray Cyclopedia http://www.spiritone.com/~english/cyclopedia/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 22 Sep 2000 10:53:08 -0500, "Tony[B]"
<ben### [at] panamac-comnet> 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?
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.' Not that
it helps ease the pain but at least now you know. If I know what I'm
rambling, that is.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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?
Is there any way that MegaPOV could precalculate the needed RAM before
rendering? That would be helpful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm going to have to go Catholic on
> this on and say "Well, it's a mystery."*
Uh... I don't get it, so we'll let that one pass...
> I have no idea what that error means, but I like the tree.
Yes. Everyone loves Gilles' trees. They're my favorites of the choices out
there. Splinetree is better, but many of the leaves don't actually touch the
branches. You can tell if you zoom in a lot.
> It looks like all the
> leaves are coming down off of the branch, though.
I guess the angle is a bit too much?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 22 Sep 2000 11:31:33 -0500, Tony[B] wrote:
>> 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?
>Is there any way that MegaPOV could precalculate the needed RAM before
>rendering? That would be helpful.
It goes in RAM because the hard disk would be too slow. The octree is used
to find the closest sample while rendering, so looking it up in a database
would kinda suck, render-time-wise.
It can't precalculate because it computes the radiosity samples as they're
needed.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Proudly not helping RIAA and SDMI steal my rights --
http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What is an octree block,
> and why did it eat up all my RAM?
Isn't that an ocTREE in your image? ;-)
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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?
>
It's radiosity data, but I'm not sure why you ran out of memory; don't you have
any swap space? Anyway, you should still be able continue the render, discarding
the old octtree and generating a new one. The render will be slower, though.
As for the render time, that's nothing. You'll see, when my current render
finishes :)
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote...
> It goes in RAM because the hard disk would be too slow. The octree is
used
> to find the closest sample while rendering, so looking it up in a database
> would kinda suck, render-time-wise.
Actually, if done properly, many of the leaf nodes could be stored on disk
and cached in memory only as needed. I'm thinking of something similar to
what can be used for raytracing displacement maps (I read a paper about that
once).
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh, please do look into it Nathan. If anyone can do it it's you. (Or Chris
H., or Ron P. or... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> ...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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39cc0505@news.povray.org>, "Tony[B]"
<ben### [at] panamac-comnet> 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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" <ben### [at] panamac-comnet> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Jérôme
--
******************************* Jérôme M. BERGER
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Berger wrote:
> 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.
Does it mean that a good strategy when rendering a large radiosity image likely to
cause "out of memory" problems is to render it in a batch ?
+ER300 +C
+ER600 +C
+ER900 +C
etc.
Each successive partial render picks up the image where the previous one left it
(solution not tested ?).
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
>
> Does it mean that a good strategy when rendering a large radiosity image likely to
> cause "out of memory" problems is to render it in a batch ?
> +ER300 +C
> +ER600 +C
> +ER900 +C
> etc.
>
> Each successive partial render picks up the image where the previous one left it
> (solution not tested ?).
>
No because in that case, either you didn't save the radiosity data and
you'll see it in the final image, or this data will be reloaded each
time and the last render will use as much memory as the whole would
have...
Jérôme
--
******************************* Jérôme M. BERGER
* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme Berger" <Jer### [at] enstfr> wrote in message
news:39D1EF0C.943C7518@enst.fr...
| Gilles Tran wrote:
| >
| > Does it mean that a good strategy when rendering a large radiosity image
likely to
| > cause "out of memory" problems is to render it in a batch ?
| > +ER300 +C
| > +ER600 +C
| > +ER900 +C
| > etc.
| >
| > Each successive partial render picks up the image where the previous one
left it
| > (solution not tested ?).
| >
| No because in that case, either you didn't save the radiosity data and
| you'll see it in the final image, or this data will be reloaded each
| time and the last render will use as much memory as the whole would
| have...
Seemed okay when I tested Gilles idea. Memory remained constant on all
three partial renders. I also used save_file to keep the radiosity info and
pass it to the next segment with load_file. Of course you can't start out
with a +C if there's a previous test render done.
The only problem was with post_process find_edges, where it apparently uses
only the first segment to apply the change for each successive segment.
Same with depth, however soft_glow was okay (I think so) and posterize
almost did okay (not perfect). Those were the only I checked on.
Attached image shows what I mean.
I didn't see any mention of post_process not working right with partial
renders, maybe this is one of the reasons it didn't make it into POV-Ray
3.5.
Bob
Post a reply to this message
Attachments:
Download 'radiosityagain2.jpg' (5 KB)
Preview of image 'radiosityagain2.jpg'
|
|
| |
| |
|
|
|
|
| |
