![](/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) |
<wimper>
320*240. No radiosity, no photons and no aa. Just one glass
multi-coloured blob on its own. 140PPH and dropping after 3 pixels
into object. Sheeesh. I figure around 4 months? And I used to love my
Celeron 500. I'll try again in a couple of years time.
And a different scene with photons - after a 3 hour parse - "Slab
Building Error: Out of memory. Cannot allocate 327680 bytes for
photons." Mummy! Make that nasty Windows go away!
</wimper>
There, now I feel better ;)
Alf
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) |
I've only been at this a year, but something seems out of whack. Have
you checked your max trace level and adc bailout settings? I have also
seen big jumps in run times when I accidentally create coincident
surfaces. How complicated is your blob object?
Bill P.
Alf Peake wrote:
>
> <wimper>
> 320*240. No radiosity, no photons and no aa. Just one glass
> multi-coloured blob on its own. 140PPH and dropping after 3 pixels
> into object. Sheeesh. I figure around 4 months? And I used to love my
> Celeron 500. I'll try again in a couple of years time.
>
> And a different scene with photons - after a 3 hour parse - "Slab
> Building Error: Out of memory. Cannot allocate 327680 bytes for
> photons." Mummy! Make that nasty Windows go away!
> </wimper>
>
> There, now I feel better ;)
>
> Alf
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) |
I've encountered this some time ago as well. It seems, that
the calculations for component-based textures are very
excessive.
And, thinking about it, its no surprise. First of all,
POV probably averages all textures, weighted by their
distance to the position being sampled. Its like
sampling the entire blob, with all textures, for every
pixel you hit, to actually get POV to know which
rgb/finish/normal you have on that position (you know
that when using pigment, you actually use a texture with
changed pigment, but default normal and finish, do you?).
When using glass, reflections/refractions, this can get quiet
an amazing task for POV...
Go figure why POV doesn't just stop.
I'd like to know more about blobs, but perhaps you should
ask your question with a more blob-fitting title?
Regards,
Tim
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmx de
> I've only been at this a year, but something seems out of whack. Have
> you checked your max trace level and adc bailout settings? I have also
> seen big jumps in run times when I accidentally create coincident
> surfaces. How complicated is your blob object?
> Bill P.
>
> Alf Peake wrote:
> >
> > <wimper>
> > 320*240. No radiosity, no photons and no aa. Just one glass
> > multi-coloured blob on its own. 140PPH and dropping after 3 pixels
> > into object. Sheeesh. I figure around 4 months? And I used to love my
> > Celeron 500. I'll try again in a couple of years time.
> >
> > And a different scene with photons - after a 3 hour parse - "Slab
> > Building Error: Out of memory. Cannot allocate 327680 bytes for
> > photons." Mummy! Make that nasty Windows go away!
> > </wimper>
> >
> > There, now I feel better ;)
> >
> > Alf
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) |
I assume you have individual textures for each blob component. When
giving individual blob components textures with reflection and/or
refraction, the render time is extremely slow. The reason is that
POV-Ray traces the reflected and refracted rays for each texture that is
averaged, so with many blob components occupying the same space, that's
a lot of rays.
On my POV-Ray wish list is the ability to tell POV-Ray to average the
blob component textures in a different way. I would like POV-Ray to
average the pigment, normal and finish independently, and only *after*
that trace the reflected and refracted rays, so that it's only done
once. In most cases that's what you want anyway, but still the feature
should be optional.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com (updated July 12)
POV-Ray Ring: http://webring.povray.co.uk
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 <3d681183@news.povray.org>,
"Alf Peake" <alf### [at] peake42 freeserve co uk> wrote:
> And a different scene with photons - after a 3 hour parse - "Slab
> Building Error: Out of memory. Cannot allocate 327680 bytes for
> photons." Mummy! Make that nasty Windows go away!
> </wimper>
Well, that is a POV error, not a Windows one. It ran out of memory while
generating photons.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray 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) |
"Christopher James Huff" wrote:
>
> > And a different scene with photons - after a 3 hour parse - "Slab
> > Building Error: Out of memory. Cannot allocate 327680 bytes for
> > photons." Mummy! Make that nasty Windows go away!
> > </wimper>
>
> Well, that is a POV error, not a Windows one. It ran out of memory while
> generating photons.
I vote for a user error ...
If the user doesn't watch out for the mem-usage of his scene, what
should POV do? Should POV do an online-compression to allow even bigger
scenes, that will then abort after 6hrs parsing?
naa ...
When I develop scenes, that create a lot of objs I also have a look
on the taskmanager to see the memoryusage. If the parsing stage uses
more than 2/3 of the available RAM, I mostly decide to stop the parsing
and search for a way to minimize the RAM usage of the scene, because
there will also be a need for RAM to store also the Image itself
(3200x2400 will be ~22MB), HiRes-Textures(will also load on Parsing, yes),
Photons (depends on used obj/textures), and Radiosity (this will need a lot).
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) |
"Rune" <run### [at] mobilixnet dk> wrote in message
news:3d68cda1@news.povray.org...
[snip]
> On my POV-Ray wish list is the ability to tell POV-Ray to average
the
> blob component textures in a different way. I would like POV-Ray to
> average the pigment, normal and finish independently, and only
*after*
> that trace the reflected and refracted rays, so that it's only done
> once. In most cases that's what you want anyway, but still the
feature
Sounds good to me.
I'm not asking for advice. I realised long ago that it was the
individual textures that were the problem :/ I'm just complaining
about my lack of patience. I've been returning to this object for more
than 3 years and have just replaced the messy pigment calculation with
a spline. These are some results with a Celeron 500:
A blob with 600 components, filter=0, (filter=1 is the one I keep
returning to) individual textures, 320*240 +a0.3. Fast - around 25
secs.
http://www.peake42.freeserve.co.uk/pix2/blob99.jpg
Blob, 800 components with a single radial texture, photons and aa,
800*600 126K I think took around 2 hours.
http://www.peake42.freeserve.co.uk/pix1/glassb3.jpg
This is a merge of 400 spheres, each with their own texture, 400*300
64K. No photons, around 18 hours.
http://www.peake42.freeserve.co.uk/pix1/twistagn.jpg
I'm going to have to wait for my new 10gig Athlone :)
Alf
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) |
"Christopher James Huff" <chr### [at] mac com> wrote in message
news:chr### [at] netplex aussie org...
> In article <3d681183@news.povray.org>,
> "Alf Peake" <alf### [at] peake42 freeserve co uk> wrote:
>
> > And a different scene with photons - after a 3 hour parse - "Slab
> > Building Error: Out of memory. Cannot allocate 327680 bytes for
> > photons." Mummy! Make that nasty Windows go away!
> > </wimper>
>
> Well, that is a POV error, not a Windows one. It ran out of memory
while
> generating photons.
I understood it was a Windows error? W98SE refuses to release unused
resources that it reserves for itself. I have 160M ram, not a lot
these days. In this case Pov stopped at 78K photons and I've been up
to 5M in other scenes with no errors.
Alf
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) |
"Alf Peake" <alf### [at] peake42 freeserve co uk> wrote in message
news:3d681183@news.povray.org...
> <wimper>
> 320*240. No radiosity, no photons and no aa. Just one glass
> multi-coloured blob on its own. 140PPH and dropping after 3 pixels
> into object. Sheeesh. I figure around 4 months? And I used to love
my
> Celeron 500. I'll try again in a couple of years time.
For anyone who wants to play with the basic scene look for _Try this
blob_ in p.t.s-f.
Alf
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |