 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I believe something is seriously wrong with the include file shapes.inc, and
particularly with the HFCreate_ () macro.
Try this code, with an image twice as long as high (i.e. a planetary map):
#include "shapes.inc"
#declare F_HF1 =
function {
pigment {
image_map {
png "my_image.png" gamma 1.0
map_type 1
interpolate 2
}
}
}
#declare F_HF2 = function (x,y,z){F_HF1(x,y,z).hf}
//HF_Sphere macro
HF_Sphere (
F_HF2, // Function,
0, // UseUVheight: 0 or 1
0, // UseUVtexture: 0 or 1
<1000, 1000>, // Resolution,
1, // Smooth, // 0 or 1
//"shapes_test.inc", // FileName or
"", //comment out one of these lines
<0,0,0>, // Center
2.0*10 , // Radius
0.08*10 // Depth
)
// end of HF_Sphere
object {
#include "shapes_test.inc"
pigment {rgb <1,1,0>}
}
1) for resolutions higher than approximately 1000, parse errors occur and
the render fails, whether a file is saved or not.
2) If you examine a save file, you will notice that the data sets are
written all on one line and without separating commas.
Typical parse error messages are:
For a saved file:
"shapes_test.inc" line 7: Parse Error: No matching } in 'face_indices', <
found instead
For a render without save file:
"C:\...\POV-Ray\v3.7\include\shapes.inc" line 967: Parse Error: bad
allocation
As said, in both cases the render failed.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 17/05/2011 14:14, Thomas de Groot nous fit lire :
> I believe something is seriously wrong with the include file shapes.inc, and
> particularly with the HFCreate_ () macro.
>
>
>
> Try this code, with an image twice as long as high (i.e. a planetary map):
> 1) for resolutions higher than approximately 1000, parse errors occur and
> the render fails, whether a file is saved or not.
>
> 2) If you examine a save file, you will notice that the data sets are
> written all on one line and without separating commas.
>
I got 8 lines in the saved file with a 2400x1200 image.
No comma between vector (but comma is traditionally optional in SDL)
I have an issue on the face_indices values: 1.996e+06 is not a good
value, as I have a bit more vectors and it complains about finding a "<"
instead of a "}".
The number should not be rounded.
You get lucky with 1000x1000 as it comes out as 1e+06
but you would be in trouble with 1001x1001, IMHO.
A few line feed would be welcome too.
(like one every 10 vector ?)
The update should be done in the #Write of HFCreate_, to replace
xRes*zRes with
xRes,"*",zRes
(and
(xRes-1)*(zRes-1)*2 with
(xRes-1),"*",(zRes-1),"*2"
) (if you get the spirit of it ?)
There already some double while-loop used to dump the vectors, so adding
a "\n" under #if(WriteFile) might already ease the output file.
(well, instead of 1 line of 1 million vectors... 1000 lines of 1000
vectors each... is that better ?)
>
>
> Typical parse error messages are:
>
> For a saved file:
>
> "shapes_test.inc" line 7: Parse Error: No matching } in 'face_indices', <
> found instead
>
>
>
> For a render without save file:
>
> "C:\...\POV-Ray\v3.7\include\shapes.inc" line 967: Parse Error: bad
> allocation
I got a full render if I comment out the last "object" from the scene.
It's just plain black. (well, no light, no ambient.. ok)
The maximum resident size was 2 161 776 kilobytes. Might be an issue for
32 bits systems. (that's a bit more than 2 Giga, usual issue for 32 bits
program)
What is your system ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Le_Forgeron" <jgr### [at] free fr> schreef in bericht
news:4dd2a7cf$1@news.povray.org...
> I got 8 lines in the saved file with a 2400x1200 image.
> No comma between vector (but comma is traditionally optional in SDL)
> I have an issue on the face_indices values: 1.996e+06 is not a good
> value, as I have a bit more vectors and it complains about finding a "<"
> instead of a "}".
The better output format would be line feed for every data value, separated
by commas, i.e. the way Poseray writes mesh2 data. That way the file is
easily readable in all circumstances.
>
> The number should not be rounded.
> You get lucky with 1000x1000 as it comes out as 1e+06
> but you would be in trouble with 1001x1001, IMHO.
> A few line feed would be welcome too.
> (like one every 10 vector ?)
>
> The update should be done in the #Write of HFCreate_, to replace
> xRes*zRes with
> xRes,"*",zRes
>
> (and
> (xRes-1)*(zRes-1)*2 with
> (xRes-1),"*",(zRes-1),"*2"
> ) (if you get the spirit of it ?)
As shall play with this, thanks!
>
> There already some double while-loop used to dump the vectors, so adding
> a "\n" under #if(WriteFile) might already ease the output file.
> (well, instead of 1 line of 1 million vectors... 1000 lines of 1000
> vectors each... is that better ?)
As said above, Poseray's lay-out is a better standard imo.
> I got a full render if I comment out the last "object" from the scene.
> It's just plain black. (well, no light, no ambient.. ok)
>
> The maximum resident size was 2 161 776 kilobytes. Might be an issue for
> 32 bits systems. (that's a bit more than 2 Giga, usual issue for 32 bits
> program)
> What is your system ?
Yes, the size of the output might be a problem indeed. In general, I want to
keep my mesh2 files well under the 100Mb.
My system is an 32 bits WinXP-SP3, 3GHz, dual core machine.
Thanks for this already!!
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18/05/2011 09:15, Thomas de Groot a écrit :
>> The maximum resident size was 2 161 776 kilobytes. Might be an issue for
>> > 32 bits systems. (that's a bit more than 2 Giga, usual issue for 32 bits
>> > program)
>> > What is your system ?
> Yes, the size of the output might be a problem indeed. In general, I want to
> keep my mesh2 files well under the 100Mb.
>
> My system is an 32 bits WinXP-SP3, 3GHz, dual core machine.
>
So the maximal address space for user data & code is 2 Giga (the 32th
bit is used on that system to reach the kernel space and other fancy zone).
No hope for that scene on that system. Sorry.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Le_Forgeron" <jgr### [at] freefr> schreef in bericht
news:4dd2a7cf$1@news.povray.org...
> The update should be done in the #Write of HFCreate_, to replace
> xRes*zRes with
> xRes,"*",zRes
>
> (and
> (xRes-1)*(zRes-1)*2 with
> (xRes-1),"*",(zRes-1),"*2"
> ) (if you get the spirit of it ?)
This is not really necessary in fact.
> There already some double while-loop used to dump the vectors, so adding
> a "\n" under #if(WriteFile) might already ease the output file.
> (well, instead of 1 line of 1 million vectors... 1000 lines of 1000
> vectors each... is that better ?)
Better is to replace:
PArr[J][K],
with:
#if(WriteFile)
PArr[J][K],"\n",
#else
PArr[J][K],
#end
And:
vnormalize(vcross(PArr[J][K+1]-PArr[J][K-1],
PArr[J+1][K]-PArr[J-1][K])),
with:
#if(WriteFile)
vnormalize(vcross(PArr[J][K+1]-PArr[J][K-1],
PArr[J+1][K]-PArr[J-1][K])),"\n",
#else
vnormalize(vcross(PArr[J][K+1]-PArr[J][K-1],
PArr[J+1][K]-PArr[J-1][K])),
#end
And:
<(J-1)/(xRes-1),(K-1)/(zRes-1)>,
with:
#if(WriteFile)
<(J-1)/(xRes-1),(K-1)/(zRes-1)>,"\n",
#else
<(J-1)/(xRes-1),(K-1)/(zRes-1)>,
#end
And finally:
F1+A, F2+A,
with:
#if(WriteFile)
F1+A, F2+A,"\n",
#else
F1+A, F2+A,
#end
This works fine.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Le_Forgeron" <lef### [at] freefr> schreef in bericht
news:4dd37e05@news.povray.org...
> No hope for that scene on that system. Sorry.
Indeed. It is to find the balance where everything still works fine....
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/18/2011 05:17 AM, Thomas de Groot wrote:
> "Le_Forgeron"<jgr### [at] freefr> schreef in bericht
> news:4dd2a7cf$1@news.povray.org...
>> The update should be done in the #Write of HFCreate_, to replace
>> xRes*zRes with
>> xRes,"*",zRes
>>
>> (and
>> (xRes-1)*(zRes-1)*2 with
>> (xRes-1),"*",(zRes-1),"*2"
>> ) (if you get the spirit of it ?)
>
> This is not really necessary in fact.
>
>> There already some double while-loop used to dump the vectors, so adding
>> a "\n" under #if(WriteFile) might already ease the output file.
>> (well, instead of 1 line of 1 million vectors... 1000 lines of 1000
>> vectors each... is that better ?)
>
> Better is to replace:
> PArr[J][K],
> with:
> #if(WriteFile)
> PArr[J][K],"\n",
> #else
> PArr[J][K],
> #end
>
> And:
> vnormalize(vcross(PArr[J][K+1]-PArr[J][K-1],
> PArr[J+1][K]-PArr[J-1][K])),
> with:
> #if(WriteFile)
> vnormalize(vcross(PArr[J][K+1]-PArr[J][K-1],
> PArr[J+1][K]-PArr[J-1][K])),"\n",
> #else
> vnormalize(vcross(PArr[J][K+1]-PArr[J][K-1],
> PArr[J+1][K]-PArr[J-1][K])),
> #end
>
> And:
> <(J-1)/(xRes-1),(K-1)/(zRes-1)>,
> with:
> #if(WriteFile)
> <(J-1)/(xRes-1),(K-1)/(zRes-1)>,"\n",
> #else
> <(J-1)/(xRes-1),(K-1)/(zRes-1)>,
> #end
>
> And finally:
> F1+A, F2+A,
> with:
> #if(WriteFile)
> F1+A, F2+A,"\n",
> #else
> F1+A, F2+A,
> #end
>
> This works fine.
>
> Thomas
>
>
I recently fixed warning messages that the Bevelled_Text macro (also in
shapes.inc) was spitting out (unnecessary bounding), so when you're
happy with the repairs you've made, attach the updated file in
p.t.scene-files and I'll make sure it gets into the distribution.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jim Holsenback" <jho### [at] povrayorg> schreef in bericht
news:4dd39438$1@news.povray.org...
> I recently fixed warning messages that the Bevelled_Text macro (also in
> shapes.inc) was spitting out (unnecessary bounding), so when you're happy
> with the repairs you've made, attach the updated file in p.t.scene-files
> and I'll make sure it gets into the distribution.
>
Excellent. I have now also added the *missing* commas. Not really necessary
of course, but it appeals to my sense of *correctness* so to speak :-)
Only for the face_indices block, have I not been able to write the last
vector without a comma.. Nonetheless, I shall put this version of shapes.inc
in p.t.scene-files. If somebody can solve this small problem, let us know.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18/05/2011 16:10, Thomas de Groot a écrit :
> "Jim Holsenback" <jho### [at] povrayorg> schreef in bericht
> news:4dd39438$1@news.povray.org...
>> I recently fixed warning messages that the Bevelled_Text macro (also in
>> shapes.inc) was spitting out (unnecessary bounding), so when you're happy
>> with the repairs you've made, attach the updated file in p.t.scene-files
>> and I'll make sure it gets into the distribution.
>>
>
> Excellent. I have now also added the *missing* commas. Not really necessary
> of course, but it appeals to my sense of *correctness* so to speak :-)
>
> Only for the face_indices block, have I not been able to write the last
> vector without a comma.. Nonetheless, I shall put this version of shapes.inc
> in p.t.scene-files. If somebody can solve this small problem, let us know.
Silly trick: the comma is not after the vector, but before it...
just my 0.02€ (Tax Not Included)
--
Software is like dirt - it costs time and money to change it and move it
around.
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Le_Forgeron" <lef### [at] freefr> schreef in bericht
news:4dd3d3c8$1@news.povray.org...
> Silly trick: the comma is not after the vector, but before it...
> just my 0.02? (Tax Not Included)
oh, right.... never thought of that trick... I shall have to try this out
first though...
Thanks for this :-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
