|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres wrote:
> Well... I'm puzzled. After some more tests, my only conclusion is that
> the #include inside the macro sometimes fails to load correctly the
> included file contents, leaving there "unparseable" code.
>
> --
> jaime
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.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Jaime Vives Piqueres
Subject: Re: Is this a bug? : WORKAROUND
Date: 19 Jan 2016 03:58:48
Message: <569dfac8@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
From: Jaime Vives Piqueres
Subject: Re: Is this a bug? : WORKAROUND
Date: 19 Jan 2016 06:23:46
Message: <569e1cc2@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |