I wish that the documentation better explained the syntax for #read and
#write.

I have created a file of the positions and velocities of a number of
particles, (34 particles at 350 time periods).  I have pasted the first
four records from my file.

0,0,2.82488,1.88872,1.28931,-0.528847,-0.0413402,-0.84771
0,1,4.52083,2,3.26511,0.180401,-0.87059,-0.457743
0,2,2.46931,-1.21869,-0.8285,-0.187654,-0.372504,-0.90886
0,3,-2.75538,0.609548,-1.23555,-0.440196,-0.39602,-0.805851

The text file has the carriage returns already in it, as you can see. I
successfully used the following command to write this file:


#write
(MyFile2,tt,",",n,",",actorp[n][0].x,",",actorp[n][0].y,",",actorp[n][0].z,",",actorv[n][0].x,",",actorv[n][0].y,",",actorv[n][0].z,"\n"

)

But when I try to read the file, either superpatch for 3.1a crashes, or
it says something about expecting a variable but seeing a comma
instead.  I want to load this huge file into memory into two different
arrays, each with two subscripts.

According to my interpretation of the debug stream, when the program
gets into the second line of variables, it hangs up on about the third
variable. I am trying the following commands to read the file:

#fopen MyFile2 "c:\pov31\include\traillist.txt" read
#declare tt=0    ;
#while (tt<350*clock+1)
#declare n=0    ;
#while (n<num)
#debug "yeehah"
#read (MyFile2,l,m,px,py,pz,vx,vy,vz)
 #debug str(l,2,2)
 #debug str(m,2,2)
 #debug str(px,2,2)
 #debug str(py,2,2)
 #debug str(pz,2,2)
 #debug str(vx,2,2)
 #debug str(vy,2,2)
 #debug str(vz,2,2)
#declare actorp[tt][n]=<px,py,pz>;
#declare actorv[tt][n]=<vx,vy,vz>;
#declare n=n+1   ;
#end

#declare tt=tt+1;
#end

#fclose Myfile2

Thanks for any possible help.   This "one hour" doofy project turned
into a twelve hour battle with the software! I suspect the problem is
in the use of two-dimensional arrays, as a much simpler,
one-dimenstional array "reading" project works great.   If I may
politely state so,  the 3.1a documentation preaches to the choir too
often on syntax and rarely gives enough examples of how to actually use
the terms. In this case, I don't know how to read my file.

Post a reply to this message

Look in the "fileio" folder in the demonstration scenes for some
examples.

Post a reply to this message

NOPE. Simplistic one-liner data files. I need to understand how to read
a larger number of variables.  Should there be a carriage return/ how do
you accomodate for it/  CAN you put into a 2-D array?

Anyone else?

Chris Huff wrote:

> Look in the "fileio" folder in the demonstration scenes for some
> examples.

Post a reply to this message

Greg M. Johnson wrote:
> 
> I wish that the documentation better explained the syntax for #read and
> #write.
> 

it took me some time to understand this, but you need commas between 
*all* data file entries for #read to work correctly. That includes
commas 
at the ends of lines, too. 

I hope this helps

Post a reply to this message

That was the trick!  Will name next animation submission in honor of you!

 Was I negligent in not seeing this important detail in the documentation?

edna dornblazer wrote:

> Greg M. Johnson wrote:
> >
> > I wish that the documentation better explained the syntax for #read and
> > #write.
> >
>
> it took me some time to understand this, but you need commas between
> *all* data file entries for #read to work correctly. That includes
> commas
> at the ends of lines, too.
>
> I hope this helps

Post a reply to this message

Greg M. Johnson wrote:
> 
> I wish that the documentation better explained the syntax for #read
> and #write.
> 
> I have created a file of the positions and velocities of a number of
> particles, (34 particles at 350 time periods).  I have pasted the
> first four records from my file.

Generally, when I have an outside program generate data for POV-Ray,
I have the same program output a standard .INC file, with all of the
#declares, #locals, etc., needed for POV-Ray to parse the file directly.
This requires very little extra effort in the program that generates the
data, and the results parse a lot faster.

For instance, in my last IRTC entry, the insect parts were made of
bicubic patches, which I converted to meshes using a bit of macro
code.  I got tired of waiting for the macro to parse, so I modified the
macro to write the triangles to a file, in full POV syntax.  From then
on I merely #included the generated files, in place of the original
generating code.  Things parsed much more quickly.

Regards,
John

Post a reply to this message

John VanSickle <van### [at] erolscom> wrote:
: For instance, in my last IRTC entry, the insect parts were made of
: bicubic patches, which I converted to meshes

  I wonder why.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Greg M. Johnson" wrote:
> 
> That was the trick!  Will name next animation submission in honor of you!
> 
>  Was I negligent in not seeing this important detail in the documentation?

	A better question, why in the world would the interpreter
require a comma and CR/LF at the end of a line? I can't say I've
seen everything in my time but that is not a rational data set
requirement.

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Matt Giwer <mgi### [at] giwersworldorg> wrote:
: 	A better question, why in the world would the interpreter
: require a comma and CR/LF at the end of a line? I can't say I've
: seen everything in my time but that is not a rational data set
: requirement.

  It doesn't require a comma and a CR/LF. It just requires a comma between
values. It couldn't care less about CR/LF's. It just ingores them.

: begin:vcard 

  Please don't post this vcard crap here.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

So, like how would you make your inc if you had two variables which were
[350][34] each?

Would your file generator literally say:

#declare position.x[1][1]=1;
#declare position.y[1][1]=2;
#declare position.z[1][1]=3;
#declare position.x[1][2]=4;
#declare position.y[1][2]=5;
#declare position.z[1][2]=6;

I know how to write such a file, but wouldn't this make it a huge INC?  Are
you sure this is faster than reading with a #while loop the following data:

 1,2,3,4,5,6,


John VanSickle wrote:

> Greg M. Johnson wrote:
> >
> > I wish that the documentation better explained the syntax for #read
> > and #write.
> >
> > I have created a file of the positions and velocities of a number of
> > particles, (34 particles at 350 time periods).  I have pasted the
> > first four records from my file.
>
> Generally, when I have an outside program generate data for POV-Ray,
> I have the same program output a standard .INC file, with all of the
> #declares, #locals, etc., needed for POV-Ray to parse the file directly.
> This requires very little extra effort in the program that generates the
> data, and the results parse a lot faster.
>
> For instance, in my last IRTC entry, the insect parts were made of
> bicubic patches, which I converted to meshes using a bit of macro
> code.  I got tired of waiting for the macro to parse, so I modified the
> macro to write the triangles to a file, in full POV syntax.  From then
> on I merely #included the generated files, in place of the original
> generating code.  Things parsed much more quickly.
>
> Regards,
> John

Post a reply to this message