 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
