 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I noticed someone mentionned this in the newsgroups a few years ago, I
guess it's still the same? #read only supports 3D vectors, not 2,4 or 5?
Unless I'm doing something wrong? (Yeah, I know, just use four seperate
floats and reassign the 4D vector with them... just not as elegant)
Example:
//[...]
#declare CurColor = <1,1,1,0.8>;
#if (clock > 0)
#fopen ColorFile "curcolor.dat" read
#read (ColorFile,CurColor) // <- Error
#fclose ColorFile
#end
//[...]
#macro V4strC(V)
concat("<",vstr(4,V,",",10,7),">, ")
#end
#fopen ColorFile "curcolor.dat" write
#write (ColorFile,V4strC(CurColor),"\n")
#fclose ColorFile
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not sure, but what is the error message POV spits out when trying to
load?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: tim.nikias (@) gmx.de
> I noticed someone mentionned this in the newsgroups a few years ago, I
> guess it's still the same? #read only supports 3D vectors, not 2,4 or 5?
> Unless I'm doing something wrong? (Yeah, I know, just use four seperate
> floats and reassign the 4D vector with them... just not as elegant)
>
> Example:
> //[...]
> #declare CurColor = <1,1,1,0.8>;
> #if (clock > 0)
> #fopen ColorFile "curcolor.dat" read
> #read (ColorFile,CurColor) // <- Error
> #fclose ColorFile
> #end
>
> //[...]
>
> #macro V4strC(V)
> concat("<",vstr(4,V,",",10,7),">, ")
> #end
>
> #fopen ColorFile "curcolor.dat" write
> #write (ColorFile,V4strC(CurColor),"\n")
> #fclose ColorFile
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 23.09.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Aside of that, your text looks strange to me: Just using
#write (SomeOutputFile, FourD_Vector)
suffices, no need to concat it to string first.
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: tim.nikias (@) gmx.de
> I'm not sure, but what is the error message POV spits out when trying to
> load?
>
> --
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
> Email: tim.nikias (@) gmx.de
>
>
> > I noticed someone mentionned this in the newsgroups a few years ago, I
> > guess it's still the same? #read only supports 3D vectors, not 2,4 or
5?
> > Unless I'm doing something wrong? (Yeah, I know, just use four seperate
> > floats and reassign the 4D vector with them... just not as elegant)
> >
> > Example:
> > //[...]
> > #declare CurColor = <1,1,1,0.8>;
> > #if (clock > 0)
> > #fopen ColorFile "curcolor.dat" read
> > #read (ColorFile,CurColor) // <- Error
> > #fclose ColorFile
> > #end
> >
> > //[...]
> >
> > #macro V4strC(V)
> > concat("<",vstr(4,V,",",10,7),">, ")
> > #end
> >
> > #fopen ColorFile "curcolor.dat" write
> > #write (ColorFile,V4strC(CurColor),"\n")
> > #fclose ColorFile
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.521 / Virus Database: 319 - Release Date: 23.09.2003
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 23.09.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias v2.0" <tim.nikias (@) gmx.de> wrote in news:3f7eed13$1
@news.povray.org:
> Aside of that, your text looks strange to me: Just using
>
> #write (SomeOutputFile, FourD_Vector)
>
> suffices, no need to concat it to string first.
>
Error is: 4D vector unexpected.
That was just an example. Control of precision and the comma is useful
with many data elements, might not be with a single colour, but with
something like quaternions higher precison than the default might be
desired. "\n" is useful for human readability. Isn't so strange to me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I never use the #read primitive, it's usually much easier to save in a
POV-script format (objects declarations, array definitions and
initialisations, etc.) and to load using the very basic #include
primitive that has all the parsing functionalities already implemented
(including 4D and 5D vectors).
JC
None wrote:
> I noticed someone mentionned this in the newsgroups a few years ago, I
> guess it's still the same? #read only supports 3D vectors, not 2,4 or 5?
> Unless I'm doing something wrong? (Yeah, I know, just use four seperate
> floats and reassign the 4D vector with them... just not as elegant)
>
> Example:
> //[...]
> #declare CurColor = <1,1,1,0.8>;
> #if (clock > 0)
> #fopen ColorFile "curcolor.dat" read
> #read (ColorFile,CurColor) // <- Error
> #fclose ColorFile
> #end
>
> //[...]
>
> #macro V4strC(V)
> concat("<",vstr(4,V,",",10,7),">, ")
> #end
>
> #fopen ColorFile "curcolor.dat" write
> #write (ColorFile,V4strC(CurColor),"\n")
> #fclose ColorFile
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've never noticed that the default isn't proper. E.g. for floats, it will
just put 0.2 for 0.2, but it will use .21342 if that's the number. AFAIK,
that's the same for vectors, so what you're doing is forcing it to round to
a certain precision.
Have you looked at the output-file to see if the vector is written
correctly? And I'm not too sure, but isn't the variable you're loading a
value to (CurColor in this case) supposed to be undefined before loading?
I've never had problems using my I/O-Macs, and they support all kinds of
vectors and floats, so I'm not sure where you're problem originates...
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: tim.nikias (@) gmx.de
> @news.povray.org:
>
> > Aside of that, your text looks strange to me: Just using
> >
> > #write (SomeOutputFile, FourD_Vector)
> >
> > suffices, no need to concat it to string first.
> >
>
> Error is: 4D vector unexpected.
>
> That was just an example. Control of precision and the comma is useful
> with many data elements, might not be with a single colour, but with
> something like quaternions higher precison than the default might be
> desired. "\n" is useful for human readability. Isn't so strange to me.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 23.09.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias v2.0" <tim.nikias (@) gmx.de> wrote in
news:3f81417f@news.povray.org:
> I've never noticed that the default isn't proper. E.g. for floats, it
> will just put 0.2 for 0.2, but it will use .21342 if that's the
> number. AFAIK, that's the same for vectors, so what you're doing is
> forcing it to round to a certain precision.
No, Povray uses default precision, try it. If one of the numbers is
really small, Povray's default will write out something like: "1.22461e-
032", which might be rounding errors I don't want to carry forward. On
the other hand, if one of the numbers is 1.0000005, Povray will write out
"1", which is precision I don't want to lose. (I'm using the Windows
version).
> Have you looked at the output-file to see if the vector is written
> correctly? And I'm not too sure, but isn't the variable you're loading
> a value to (CurColor in this case) supposed to be undefined before
> loading?
Yes, it's written correctly in the file, and... EUREKA! That's the
problem, because I had already initialized the vector. Hehehe, from the
Help on #read: "A DATA_IDENTIFIER is any undeclared identifier or any
previously declared string identifier, float identifier, or vector
identifier.". I guess that doesn't apply to non 3D vectors. I've
initialized all of my other variables and 3D vectors before reading them
without any issues, so I didn't think about that for a 4D.
Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"JC (Exether)" <no### [at] spam fr> wrote in news:3f810ed9@news.povray.org:
> I never use the #read primitive, it's usually much easier to save in a
> POV-script format (objects declarations, array definitions and
> initialisations, etc.) and to load using the very basic #include
> primitive that has all the parsing functionalities already implemented
> (including 4D and 5D vectors).
Good idea! Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
