 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay, I've probably made another stupid mistake that I'll figure out fifteen
minutes after I post this, but at the moment I am utterly baffled and
clueless.
I'm trying to read from a file that looks like this:
//----
<3.630000,6.150000>,
<2.590000,5.280000>,
<1.880000,3.690000>,
<2.400000,1.720000>,
<3.370000,1.050000>,
<4.850000,0.690000>,
<6.370000,0.880000>,
<7.490001,1.920000>,
<7.410001,2.700000>,
<6.860000,3.320000>,
<6.170000,3.080000>,
<5.330000,3.680000>,
<5.120000,4.530000>,
<5.620000,4.950000>
//-----
// I wound up with, in part, the following code and I get an error saying:
// "Parse error: Expected 'Undeclared identifier', uv vector found instead"
#declare Rv = array[210]
#declare cnt = 1;
#fopen SplnFile Fname read
// -- #while (cnt < 210) <--- this was commented out to check problem
#if (defined(SplnFile))
#read (SplnFile, tempz) // this part works
#declare Rv[0] = tempz;
#declare cnt = cnt + 1;
//#end
#end
#read (SplnFile, shit)
#declare Rv[1] = shit;
text
{ ttf "crystal.ttf", vstr(2, Rv[0], ", ", 0, 5), 0.02, 0 //
texture { pigment {rgb 1} finish {ambient 1} }
scale y*0.7
translate z*3.2
translate x*-3.2
}
text
{ ttf "crystal.ttf", vstr(2, Rv[1], ", ", 0, 5), 0.02, 0 //
texture { pigment {rgb 1} finish {ambient 1} }
scale y*0.7
translate z*3.2
translate x*-3.2
translate y*3
}
//---- > failure happens when I try to read into the array as here:
#while (defined(SplnFile))
#read (SplnFile, Rv[cnt-1]) //*<-- fail point, read into an array fails
#declare cnt = cnt + 1; // why must it be undeclared?
// how do I fix it so the #while statement
#end // reads it?
#fclose SplnFile
//=====================
If anyone can figure out what I've done wrong -- or is it some weird bug --
let me know.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> #while (defined(SplnFile))
> #read (SplnFile, Rv[cnt-1]) //*<-- fail point, read into an array fails
> #declare cnt = cnt + 1; // why must it be undeclared?
> // how do I fix it so the #while statement
> #end // reads it?
i had the same problem a couple of times. when i remember right something
like this should work:
#while (defined(SplnFile))
#read (SplnFile, value)
#declare Rv[cnt-1] = value;
#declare cnt = cnt + 1;
#end
where value is an undefined identifier.
can't test it in the moment. rendering... ;-)
Hope that helps
Regards Roman
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Zarkoff" <zar### [at] yahoo com> wrote:
> Okay, I've probably made another stupid mistake that I'll figure out fifteen
> minutes after I post this, but at the moment I am utterly baffled and
> clueless.
>
>....
> #declare Rv = array[210]
>
> #declare cnt = 1;
>
> #fopen SplnFile Fname read
>
> // -- #while (cnt < 210) <--- this was commented out to check problem
> #if (defined(SplnFile))
> #read (SplnFile, tempz) // this part works
> #declare Rv[0] = tempz;
> #declare cnt = cnt + 1;
> //#end
> #end
>
Just like I said, minutes later a soultion occured to me:
#while (defined(SplnFile)) // I still don't know why POV
#read (SplnFile, tempz) // expects an undeclared identifier here.
#declare Rv[cnt-1] = tempz;
#declare cnt = cnt + 1;
#undef tempz // <------ that makes it work
#end
I'd still like to know why the #read statement requires an undeclared
indentifier in this case. I've seen others use declared identifiers -- I
think.
I'm working around a problem I don't understand yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'd still like to know why the #read statement requires an undeclared
> indentifier in this case. I've seen others use declared identifiers -- I
> think.
>
> I'm working around a problem I don't understand yet.
Though I'm no expert on the source, an educated guess would conclude this:
An application needs to define what type the information is, e.g. a float or
a vector, to allocate the appropriate amount of space. POV-Ray probably does
it by reading the information and finding it's type along the way (or
something like reading it into a buffer, finding the type, casting it and
handing it back to the POV-SDL environment).
If you've set the type before, POV-Ray doesn't have the flexibility to
adjust the type by itself, as clean and proper programming would disallow
such behaviour (who has ever heard of a programming language which recasts
types as it sees fit?!).
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (who has ever heard of a programming language which recasts
> types as it sees fit?!).
Ever seen programs written in C? ;-)
*hides*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Ever seen programs written in C? ;-)
>
> *hides*
Hey, upcasting because it is needed for a calculation is one thing, but
simply changing a type doesn't happen by itself. And such behaviour is
usually documented somewhere and has a reason (how annoying would it be if
you want to do some math, and C keeps on annoying with "int not compatible
with double", when all you want is "2.5312e63 * 2"?
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote:
> > Ever seen programs written in C? ;-)
> >
> > *hides*
>
> Hey, upcasting because it is needed for a calculation is one thing, but
> simply changing a type doesn't happen by itself. And such behaviour is
> usually documented somewhere and has a reason (how annoying would it be if
> you want to do some math, and C keeps on annoying with "int not compatible
> with double", when all you want is "2.5312e63 * 2"?
>
> Regards,
> Tim
>
> --
> aka "Tim Nikias v2.0"
> Homepage: <http://www.nolights.de>
The manual I get when I click on help says I should be able too.
It says under "#read":
"A DATA_IDENTIFIER is any undeclared identifier or any previously declared
string identifier, float identifier, or vector identifier. Undefined
identifiers will be turned into global identifiers of the type determined
by the data which is read. Previously defined identifiers remain at
whatever global/local status they had when originally created. Type
checking is performed to insure that the proper type data is read into
these identifiers."
Doesn't saying "or any previously declared string identifier, float
identifier, or vector identifier" mean I should be able to use declared
identifiers?
Is the manual wrong? Or did I read that wrong?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>Ever seen programs written in C? ;-)
>>
>>*hides*
>
>
> Hey, upcasting because it is needed for a calculation is one thing, but
> simply changing a type doesn't happen by itself. And such behaviour is
> usually documented somewhere and has a reason (how annoying would it be if
> you want to do some math, and C keeps on annoying with "int not compatible
> with double", when all you want is "2.5312e63 * 2"?
...now go and play with pointers. (And remember, if you need strings in
C, you are *forced* to use pointers.)
If I see the words "suspecious pointer conversion" one more time I'm
going to go mad... [But hey, this is why I don't use C any more.]
But anyway, enough of that...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v2 <voi### [at] devnull> wrote:
>...[snipped]...
>
> If I see the words "suspecious pointer conversion" one more time I'm
> going to go mad... [But hey, this is why I don't use C any more.]
I wish POV-ray were more like C.
What I'm trying to do is read a file output by a Spline Editor that looks
like this:
---->
// File generated by SpilinEditor v1.2
// POV-Ray v3.0 syntax
#declare testSpln =
lathe{
cubic_spline
14,
<3.630000,6.150000>,
<2.590000,5.280000>,
<1.880000,3.690000>,
<2.400000,1.720000>,
<3.370000,1.050000>,
<4.850000,0.690000>,
<6.370000,0.880000>,
<7.490001,1.920000>,
<7.410001,2.700000>,
<6.860000,3.320000>,
<6.170000,3.080000>,
<5.330000,3.680000>,
<5.120000,4.530000>,
<5.620000,4.950000>
}
// end of file
<-----
I want to tell POV to read the top part as a string, the "File generated by
SpilinEditor v1.2 ... #declare testSpln = lathe{ cubic_spline...", as
strings.
Given an undefined variable I don't know what POV is making of that and I
don't know how to tell it to make what I want of it.
It seems to ignore comments and then not treat what looks like a string to
me as a string.
When I assume that top part is a string and write:
#read (SplnFile, tempz) // what is read exactly?
text { ttf "crystal.ttf", tempz, 1, 0 // <--- fails here --*
texture { pigment {rgb 1} finish {ambient 1} }
scale y*0.7
tranlate y*2
}
It fails to treat it like one.
What the hell does POV make of that data when it reads it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What the hell does POV make of that data when it reads it?
It reads comma-separated values. Strings have to be in quotation marks,
vectors use the < and >, and floats are just plain numbers. I'm not sure
about comments starting with double-slash (//), but I think they are
ignored.
POV-Ray's reading capabilities aren't meant to read "ordinary" files. Just
stuff like this.
"string", <1,1,1>, 321.514, "another_string", 4.2333, <3,6>
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What he said.
It allows you to (for example) do a bunch of calculations, save the
result to a file, and load it back in during the next frame of the
animation.
POV-Ray doesn't have the ability to read arbitrary files. Nor to write
them, really. (It can write arbitrary text files. But it can't read them
back.)
If you wanted, I suppose you could write some kind of preprocessor which
sticks quote marks round everything first...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zarkoff nous apporta ses lumieres en ce 29/01/2006 05:51:
> // File generated by SpilinEditor v1.2
> // POV-Ray v3.0 syntax
> #declare testSpln =
> lathe{
> cubic_spline
> 14,
> <3.630000,6.150000>,
> <2.590000,5.280000>,
> <1.880000,3.690000>,
> <2.400000,1.720000>,
> <3.370000,1.050000>,
> <4.850000,0.690000>,
> <6.370000,0.880000>,
> <7.490001,1.920000>,
> <7.410001,2.700000>,
> <6.860000,3.320000>,
> <6.170000,3.080000>,
> <5.330000,3.680000>,
> <5.120000,4.530000>,
> <5.620000,4.950000>
> }
> // end of file
>
> <-----
>
If that's the full content of the file, just #include it.
The lines starting by "//" are comments and will be ignored.
The rest is correct syntax for a lathe object. If the identifier name don't suit you,
just change it
in your editor.
--
Alain
-------------------------------------------------
Zoroastrianism: Shit happens half on the time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
.....
>
> POV-Ray's reading capabilities aren't meant to read "ordinary" files. Just
> stuff like this.
>
> "string", <1,1,1>, 321.514, "another_string", 4.2333, <3,6>
>
Why did they limit it? That means I have to go into all the Spline Editor
files I'm using and chop all that unreadable data off myself -- or write a
C program to do it... Which means I'd have been better off using an old DOS
type C program.
If they would have done what seems the simpler programming thing and let the
POV user format how data is read then POV-ray would soon be reading files
from Maya, Lightwave and 3D-max.
Why did they rob us of that power?
If you're going to have file reading - why not go all the way... fseek, user
formatting, etc..
fseek and file positioning and char by char reading would make the whole
file reading and writing operations more powerful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If they would have done what seems the simpler programming thing and let the
> POV user format how data is read then POV-ray would soon be reading files
> from Maya, Lightwave and 3D-max.
>
> Why did they rob us of that power?
I agree with you.
However, they did not. The end.
As I said in my other post, it's really ment for saving variables
between frames of an animation so you can load them back in the next frame.
Notice also that POV-Ray can *write* arbitrary text into an output file.
Just not *read* it. (Odd, but true.)
Also note the other reply; you can read this particular file just with
#include, since it's already in POV-Ray SDL format...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Why did they limit it? That means I have to go into all the Spline Editor
> files I'm using and chop all that unreadable data off myself -- or write a
> C program to do it... Which means I'd have been better off using an old
DOS
> type C program.
Design decision? After all, POV-Ray is supposed to be a script-based
raytracer. It does come with this nice and handy SDL, but it's a bonus,
POV-Ray, after all, is just a raytracer. You're not supposed to be
programming with it, you're supposed to describe a scene and let it
raytrace.
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have another strange "read" issue. Indeed I only want to transfer
variables from one frame to another, but A LOT of them. My file goes like
this:
-0.00164469
-0.0512107
0
-0.612596
-0.609269
-0.605894
-0.602472
When I read that in, by using a simple
#read (DATA, newVar)
the line with the "0" is simply ignored - instead of the 0 being saved in
"newVar". I have to convert the lines with "0" to "-0.0" ("0.0" isn't
enough) to prevent that. Is this a feature or...?
Regards,
Viktor.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Try separating the values with commas.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Viktor" <vik### [at] spamfencenet> wrote:
> -0.00164469
> -0.0512107
> 0
> -0.612596
> -0.609269
> -0.605894
> -0.602472
>
> When I read that in, by using a simple
> #read (DATA, newVar)
> the line with the "0" is simply ignored - instead of the 0 being saved in
> "newVar". I have to convert the lines with "0" to "-0.0" ("0.0" isn't
> enough) to prevent that. Is this a feature or...?
It is a RTFM!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Viktor nous apporta ses lumieres en ce 23/06/2006 13:22:
> I have another strange "read" issue. Indeed I only want to transfer
> variables from one frame to another, but A LOT of them. My file goes like
> this:
>
> -0.00164469
> -0.0512107
> 0
> -0.612596
> -0.609269
> -0.605894
> -0.602472
>
> When I read that in, by using a simple
> #read (DATA, newVar)
> the line with the "0" is simply ignored - instead of the 0 being saved in
> "newVar". I have to convert the lines with "0" to "-0.0" ("0.0" isn't
> enough) to prevent that. Is this a feature or...?
>
> Regards,
> Viktor.
>
>
>
>
It reads the data as: -0.00164469, -0.05121070 (note the extra zero), -0.612596,
-0.609269,
-0.605894, -0.602472
The lone 0 is treated as the last digit of the preceding value. Another integer would
have been
treated the same way, but would have been easier to spot as it would have altered the
preceding value.
Put a comma after each value but the last.
--
Alain
-------------------------------------------------
A short cut is the longest distance between two points.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
