POV-Ray : Newsgroups : povray.binaries.images : It hurts... (~113kau) Server Time
1 Jul 2025 05:29:32 EDT (-0400)
  It hurts... (~113kau) (Message 4 to 13 of 23)  
<<< Previous 3 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Tony[B]
Subject: Re: It hurts... (~113kau)
Date: 22 Sep 2000 12:34:19
Message: <39cb8a0b@news.povray.org>
> 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

From: Tony[B]
Subject: Re: It hurts... (~113kau)
Date: 22 Sep 2000 12:36:35
Message: <39cb8a93@news.povray.org>
> 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

From: Ron Parker
Subject: Re: It hurts... (~113kau)
Date: 22 Sep 2000 14:31:55
Message: <slrn8sna66.5rh.ron.parker@fwi.com>
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

From: MikeH
Subject: Re: It hurts... (~113kau)
Date: 22 Sep 2000 14:31:58
Message: <39CBA568.5286754C@aol.com>
> 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

From: Margus Ramst
Subject: Re: It hurts... (~113kau)
Date: 22 Sep 2000 19:24:50
Message: <39CBDC1A.164DD32F@peak.edu.ee>
"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

From: Nathan Kopp
Subject: Re: It hurts... (~113kau)
Date: 22 Sep 2000 20:22:33
Message: <39cbf7c9@news.povray.org>
"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

From: Tony[B]
Subject: Re: It hurts... (~113kau)
Date: 22 Sep 2000 21:19:01
Message: <39cc0505@news.povray.org>
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

From: Tony[B]
Subject: Re: It hurts... (~113kau)
Date: 22 Sep 2000 21:19:50
Message: <39cc0536@news.povray.org>
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

From: Rick [Kitty5]
Subject: Re: It hurts... (~113kau)
Date: 23 Sep 2000 10:34:12
Message: <39ccbf64@news.povray.org>
> 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

From: Rick [Kitty5]
Subject: Re: It hurts... (~113kau)
Date: 23 Sep 2000 10:34:13
Message: <39ccbf65@news.povray.org>
> ...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

<<< Previous 3 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.