On 1/18/2016 7:59 PM, Ger wrote:
> Another
> indicator to that is that shortly before it crashes the memory usage goes up
> strongly.

That *could* just be an artifact.  It's parsing crap, who knows what 
objects it thinks it's creating.

Post a reply to this message

dick balaska wrote:

> On 1/18/2016 7:59 PM, Ger wrote:
>> Another
>> indicator to that is that shortly before it crashes the memory usage goes
>> up strongly.
> 
> That *could* just be an artifact.  It's parsing crap, who knows what
> objects it thinks it's creating.

Indeed, that is always a possibility, but I had a test render running this 
evening and when I came back to check on it, it was using ~30GB of memory to 
process ~28K spheres. And that's a wee bit too much.
After I stopped it and let the computer settle down a bit, I restarted it 
where it left off and memory usage was up to 2GB within minutes.
-- 

Ger

Post a reply to this message

> I have tried it in every possible way I can come up with and what I
> have found is that povray sometimes chokes on reading data while
> inside a #macro. Which indicates to me that povray does not handle
> #macros correctly. Another indicator to that is that shortly before
> it crashes the memory usage goes up strongly.

   Well, thanks to a recent question by Thomas about Parse_String(), if
you absolutely need to include code on a macro, there is a workaround
using that function from strings.inc:

   Write the include file like this:

#write(filehandle, "\"#declare CFS[",str(Count,0,0),"] = <", vstr(3,
CFS[Count], ", ", -1,-1),">;\",\n")

   Then, instead using #include "data.inc", use a call to this macro:

#macro ParseInclude(IncludeFile)
   #fopen filehandle IncludeFile read
   #while (defined(filehandle))
     #read (filehandle,IncludeLine)
     #debug IncludeLine
     #debug "\n"
     Parse_String(IncludeLine)
   #end
   #fclose filehandle
#end

   like this:

ParseInclude("data.inc")


   Hope this helps...

--
jaime

Post a reply to this message

Jaime Vives Piqueres wrote:

>    Well, thanks to a recent question by Thomas about Parse_String(), if
> you absolutely need to include code on a macro, there is a workaround
> using that function from strings.inc:
> 
>    Write the include file like this:
> 
> #write(filehandle, "\"#declare CFS[",str(Count,0,0),"] = <", vstr(3,
> CFS[Count], ", ", -1,-1),">;\",\n")
> 
>    Then, instead using #include "data.inc", use a call to this macro:
> 
> #macro ParseInclude(IncludeFile)
>    #fopen filehandle IncludeFile read
>    #while (defined(filehandle))
>      #read (filehandle,IncludeLine)
>      #debug IncludeLine
>      #debug "\n"
>      Parse_String(IncludeLine)
>    #end
>    #fclose filehandle
> #end
> 
>    like this:
> 
> ParseInclude("data.inc")
> 
> 
>    Hope this helps...
> 
> --
> jaime

It's an interesting technique to say the least, and I must say that it works 
all be it slow (I did implement it in this little animation). But the whole 
point is that an #include should work inside a #macro. 
The simplest workaround for me would be to put the #include in the main body 
of the scene. I've done it and it works fine.
So it's not like "It doesn't work" but more like "It doesn't work the way it 
should"

-- 

Ger

Post a reply to this message

> It's an interesting technique to say the least, and I must say that
> it works all be it slow (I did implement it in this little
> animation).

   Yes, it was just an interesting exercise...

> The simplest workaround for me would be to put the #include in the
> main body

   As I said, the workaround is only useful if you absolutely need to use
the include inside the macro, for whatever reason.

> So it's not like "It doesn't work" but more like "It doesn't work the
> way it should"

   I noticed that file size seems to affect it... I mean, when you run
the animation and get the error at some frame, rendering it again with
the "faulty" include will fail again and again. But if you add/remove a
single character from any file (data.inc or test.pov), then magically it
will be parseable (but not if you change the content without changing
file size).

--
jaime

Post a reply to this message

Am 19.01.2016 um 09:58 schrieb Jaime Vives Piqueres:

>   Well, thanks to a recent question by Thomas about Parse_String(), if
> you absolutely need to include code on a macro, there is a workaround
> using that function from strings.inc:

Fun fact to know, especially in this context:

Parse_String itself is nothing more than a macro that writes a temporary
file and then includes it.

So I wouldn't consider it a perfect cure for the symptoms.

Post a reply to this message

> Fun fact to know, especially in this context:
>
> Parse_String itself is nothing more than a macro that writes a temporary
> file and then includes it.
>
> So I wouldn't consider it a perfect cure for the symptoms.

   The thing is that it works without any problem... maybe it has to do 
with the fact that it only includes one line at a time?

--
jaime

Post a reply to this message

Jaime Vives Piqueres wrote:

> El 19/01/16 a las 18:26, clipka escribió:
>> Fun fact to know, especially in this context:
>>
>> Parse_String itself is nothing more than a macro that writes a temporary
>> file and then includes it.
>>
>> So I wouldn't consider it a perfect cure for the symptoms.
> 
>    The thing is that it works without any problem... maybe it has to do
> with the fact that it only includes one line at a time?
> 
> --
> jaime

Sounds kinda ridiculous and that's why I tried and it works. It runs with 50 
lines/files and even with 50K lines/files. I let it run until I had >1K 
frames.
-- 

Ger

Post a reply to this message

Am 19.01.2016 um 19:57 schrieb Jaime Vives Piqueres:

>> Fun fact to know, especially in this context:
>>
>> Parse_String itself is nothing more than a macro that writes a temporary
>> file and then includes it.
>>
>> So I wouldn't consider it a perfect cure for the symptoms.
> 
>   The thing is that it works without any problem... maybe it has to do
> with the fact that it only includes one line at a time?

I'm more inclined to suspect that it's because generation and inclusion
of the file are done in one and the same macro.

Post a reply to this message

Am 17.01.2016 um 20:43 schrieb Ger:

> Including a datafile in the main body works, but
> including it inside a #macro results in an error
> at random frames in the animation. It can be at
> frame 10 or at frame 500.

*HA!*
Got that son of a bitch!

Quick workaround: Add /anything/ anywhere before the "#end" statement of
ParseCenterOfMass(); even somewhere before the macro will do. But no
more than about 50 characters.

"WTF?!" you might ask.


Well, here's what happens in a nutshell:

- For each macro defined, POV-Ray stores some information like what file
it resides in, where it starts and, most importantly in this context,
where it ends. More specifically, it stores the position of the "#end"
that ends the macro.

- While executing a macro, to determine whether it has reached the end,
POV-Ray keeps its eyes peeled for any "#" at the position it has stored
as the macro's end.

- In your example, the 10th (give or take 1) "#declare" in "data.inc"
happens to be at the very same position as the "#end" of
ParseCenterOfMass() in your main file.


Do I need to say more? They say never to spoil a joke by explaining its
punchline, but yeah: When looking out for the end of the macro, POV-Ray
does indeed /not/ bother to test whether it is even in the right file.

*Facepalm!*

Post a reply to this message