On 1/11/2014 4:13 AM, Le_Forgeron wrote:
> The scene is fine... if you have at least 17 GB memory, it renders fast
> (the parsing is not that long either, yet longer than the render)
> (test done on linux, with enough ram)
>
> The top resident memory size in kbytes is 17320752, 17 320 752 kB !
> (data from /usr/bin/time -f "%M" ...)
>
> The issue is that your system has only 3GB, so it is going to use
> heavily the swap... and that will crawl, whatever the action of aborting
> or continuing.
>
> The nice thing is that you use a 64 bits system. A 32 bits system would
> have killed your process at the early start.

I'm not worried about the scene. I know other people have rendered it 
just fine. My question was in regard to POV-Ray's strange behavior. I.e. 
not quitting when encountering a memory allocation error, the end render 
WAV sound playing twice instead of once, and the program not 
de-allocating my RAM.
You raise some additional points though. How big does my swap file need 
to be? I raised it to 40960MB and it _still_ results in a memory 
allocation error. Do I need to raise it further?


Mike

---
This email is free from viruses and malware because avast! Antivirus protection is
active.
http://www.avast.com

Post a reply to this message

On 1/11/2014 7:04 PM, posfan12 wrote:
> I'm not worried about the scene. I know other people have rendered it
> just fine. My question was in regard to POV-Ray's strange behavior. I.e.
> not quitting when encountering a memory allocation error, the end render
> WAV sound playing twice instead of once, and the program not
> de-allocating my RAM.
> You raise some additional points though. How big does my swap file need
> to be? I raised it to 40960MB and it _still_ results in a memory
> allocation error. Do I need to raise it further?
>
>
> Mike


Here's a newer version of the scene. Transparency, reflections, 
radiosity etc. are enabled in this one.


Mike


-- 
http://isometricland.net


---
This email is free from viruses and malware because avast! Antivirus protection is
active.
http://www.avast.com

Post a reply to this message

Attachments:
Download 'datsville_povray_rev385.zip' (2965 KB)

Le 12/01/2014 01:13, posfan12 nous fit lire :

> 
> Here's a newer version of the scene. Transparency, reflections,
> radiosity etc. are enabled in this one.

lg_defs.inc is missing.

Post a reply to this message

On 1/12/2014 4:52 AM, Le_Forgeron wrote:
> Le 12/01/2014 01:13, posfan12 nous fit lire :
>
>>
>> Here's a newer version of the scene. Transparency, reflections,
>> radiosity etc. are enabled in this one.
>
> lg_defs.inc is missing.
>
>
>

Ah yes, I forgot to mention that you need the LightSysIV library installed:

http://www.ignorancia.org/en/index.php?page=Lightsys

As well as the LGEO parts library:

http://www.digitalbricks.org/lgeo.html


-- 
http://isometricland.net

---
This email is free from viruses and malware because avast! Antivirus protection is
active.
http://www.avast.com

Post a reply to this message

I tried rendering the scene again last night this time with two 40GB 
swap files on different partitions (I am running out of storage space). 
It got to 30001 tokens before I went to bed. 14 hours later when I 
checked to see the render progress it was... still at 30001 tokens.

It basically did absolutely nothing overnight. No errors or messages either.

 >:(

-- 
http://isometricland.net

---
This email is free from viruses and malware because avast! Antivirus protection is
active.
http://www.avast.com

Post a reply to this message

Le 13/01/2014 04:23, posfan12 nous fit lire :
> On 1/12/2014 4:52 AM, Le_Forgeron wrote:
>> Le 12/01/2014 01:13, posfan12 nous fit lire :
>>
>>>
>>> Here's a newer version of the scene. Transparency, reflections,
>>> radiosity etc. are enabled in this one.
>>
>> lg_defs.inc is missing.
>>
>>
>>
> 
> Ah yes, I forgot to mention that you need the LightSysIV library installed:
> 
> http://www.ignorancia.org/en/index.php?page=Lightsys
> 

That one I had.
> As well as the LGEO parts library:
> 
> http://www.digitalbricks.org/lgeo.html
> 
> 
That one is new.

Yet, lg_0975.inc is missing (not part of the downloaded zip)... it's
spelled lg_0975.INC :-)

Same story for lg_0976 and lg_0977
lg_71137.inc has a parse error at line 137, due to version.
(that's at 27828K tokens) and it occured a bit before for lg_51011.inc
too ;-) (but only as possible parse error, whereas lg_71137.inc is Parse
Error.)

It went to 29 GB of mem at that point.

A lot of complain about CSG that should have at least 2 objects...
consider using object { ... } instead of one slot union.

And object { object { ... is just a no-go.

Post a reply to this message

Am 13.01.2014 04:29, schrieb posfan12:
> I tried rendering the scene again last night this time with two 40GB
> swap files on different partitions (I am running out of storage space).
> It got to 30001 tokens before I went to bed. 14 hours later when I
> checked to see the render progress it was... still at 30001 tokens.
>
> It basically did absolutely nothing overnight. No errors or messages
> either.
>
>  >:(

Did we already mention that running POV-Ray with /any/ kind of swap file 
usage is /strongly/ discouraged?

Consider yourself lucky that you don't even get as far as rendering: 
Your Windows system /will/ become fatally unresponsive.

I repeat: Running POV-Ray with less physical memory than needed to 
render a scene /will/ /inevitably/ cause your /whole/ Windows system to 
come to a grinding halt during rendering.


Just to make sure you're understanding the full extent of what I am 
saying: Once it happens. You /will/ wait a minute just for the bloody 
mouse cursor to follow your mouse movement (if you're lucky). When you 
press Ctrl-Alt-Del, you /will/ wait maybe 15 minutes for the task 
manager to pop up (if you're patient). You will /not/ get any fedback on 
your keystrokes anyomre. You will /not/ be able to shut down your 
computer properly anymore unless you spend a guesstimated hour to 
systematically complete that procedure with painstaking precision and 
patience. You /will/ know why I call this "swap hell".

I am /not/ kidding, and I am /not/ exaggerating. Having been there and 
done that a couple of times during test runs, I am dead serious.


I cannot repeat it too often: /Never/ run POV-Ray for Windows with 
insufficient /physical/ memory for a scene - you /will/ regret it.


And just in case I haven't made myself clear enough:

-----------------------------------------------------------------------
Stop toying around with your swap file limits in hopes to get your scene 
to work. Abso-bloody-lutely /do/ find a way to reduce the memory 
requirements of your scene to fit inside your /physical/ memory.
-----------------------------------------------------------------------

I suspect that the LGEO geometry is CSG; note that each instance of any 
CSG object requires a full copy in memory. You could cut down 
significantly on that memory by using #declare'd meshes instead, as 
multiple instances of any such mesh share the actual mesh data.

Post a reply to this message

On 1/13/2014 1:03 PM, clipka wrote:
> -----------------------------------------------------------------------
> Stop toying around with your swap file limits in hopes to get your scene
> to work. Abso-bloody-lutely /do/ find a way to reduce the memory
> requirements of your scene to fit inside your /physical/ memory.
> -----------------------------------------------------------------------

OK, thanks for clearing up. I thought that somehow something happened to 
POV between 3.62 and 3.7.


Mike


-- 
http://isometricland.net

---
This email is free from viruses and malware because avast! Antivirus protection is
active.
http://www.avast.com

Post a reply to this message

On 1/13/2014 12:20 PM, Le_Forgeron wrote:
> Yet, lg_0975.inc is missing (not part of the downloaded zip)... it's
> spelled lg_0975.INC :-)
>
> Same story for lg_0976 and lg_0977

Did you manage to fix this? I think you just need to rename the file 
extensions to low caps.







> lg_71137.inc has a parse error at line 137, due to version.
> (that's at 27828K tokens) and it occured a bit before for lg_51011.inc
> too ;-) (but only as possible parse error, whereas lg_71137.inc is Parse
> Error.)

This file has a missing ';' after a #declare somewhere.






> It went to 29 GB of mem at that point.
>
> A lot of complain about CSG that should have at least 2 objects...
> consider using object { ... } instead of one slot union.
>
> And object { object { ... is just a no-go.
>

I've reported these to the tool's author. I'm not sure what he's going 
to do to fix them. Do you have any suggestions?




I'm sorry the scene is not working properly.

The scene requires stuff designed by multiple authors: the model itself 
(made by myself and several other people), the tool used to convert the 
model to POV (by Travis Cobbs), and the LGEO parts (by someone else who 
doesn't want to be identified by name on his website for some reason).

I'm also not really able to identify issues unless someone informs me of 
them because I don't have enough RAM to get as far in the render as 
everyone else.


Mike

---
This email is free from viruses and malware because avast! Antivirus protection is
active.
http://www.avast.com

Post a reply to this message

Am 15.01.2014 09:24, schrieb posfan12:
> On 1/13/2014 1:03 PM, clipka wrote:
>> -----------------------------------------------------------------------
>> Stop toying around with your swap file limits in hopes to get your scene
>> to work. Abso-bloody-lutely /do/ find a way to reduce the memory
>> requirements of your scene to fit inside your /physical/ memory.
>> -----------------------------------------------------------------------
>
> OK, thanks for clearing up. I thought that somehow something happened to
> POV between 3.62 and 3.7.

Well, in a sense it did: While POV-Ray 3.62 occupied only one core on a 
multicore system, POV-Ray 3.7 gets them all busy; I suspect that might 
be making things worse as far as system stability goes.

But POV-Ray 3.62, too, would take ages to render out of swap memory, and 
probably make the system quite unstable, too.

Post a reply to this message