rec.autos.simulators

  I believe so.  I'll have to study up on specifically how to do it, but the
file can be read in four bytes at a time.  For starters, I've opened up the
body.dof file (from the lotus at your site) using random access.  If I randomly
pick a record number, I'll get a small set of numbers read in depending on
whether I'm pulling it out as a long integer, integer, byte, etc..  Perhaps
opening in random access mode, then pulling long integers out of it will get
them 4 bytes at a time all the way through.  It returns a number, for instance,
record number 1 written to a long integer returns "826691396."  I'm not sure
record number 2 would automatically be the next four bytes in this case though,
I don't know much about this stuff.  I'll check with some folks that use my
compiler and see what they say.  

  Oops, just now, I tried pulling and storing as a four byte ASCIIZ type.
Record number one shows "DOF1" as you indicated :-)  I'll blast through and see
how many of these I find right now.  (I'm working and writing at the same time
here.)  Ok, it looks as though that's the only "DOF1" showing up.  Is that
right, or should there be more?  I might not have checked the entire file.  Are
your DOF files made entirely of 4 byte chunks?  If not, I can open it in binary
mode(I'm confused enough as it is, would rather stick to another method ;-))

  Haven't given up just yet!

  Any suggestions or thoughts?

  Thanks,

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://www.racesimcentral.net/

  Even more clever :-)

   Makes absolutely no sense to me at all :-)  If I saw some graphs of this,
it'd probably make sense though.  I'll just take your word for it for now :-)
I'll need DX8 to run Racer now and haven't downloaded it because I'm afraid it
might crash my laptop with the problems many have reported.  Too bad, with DX7a
I can drive the car, but there're no graphics (only sound and mouse control.)  

    >I need to have a function where I have a quad, that's not necessarily

  Something along the lines of an edge normal solution is what I was thinking
too.  Guess it's time for a visit to the algo newsgroup.

  About the DOF files, if they're all just a list of triangles, that's very
nice for a rookie like me :-)

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

  Ok, will do.  I won't distribute anything without giving proper
credit/payment, we know how much work this is :-)

      >If I recall some BASIC work I did in a previous life, the random

  I can read the files in binary, byte for byte, so it should work out. It'll
take me awhile to do it right, though!  I've looked through the dgeob.cpp and
dgeode.cpp files.  Too bad most of it looks greek to me.  Will have to study
them more later.

  >>  I'd really like to just get one of the cars up and running, without any

  Yes, I'm getting some wierd effects all right, although I'm sure it's because
I'm not transforming properly before calling glLightfv.  Will play around more
and pop into the OpenGL group for help.  Hope you'll be there ;-)

 Thanks for all the help,

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

...

I'd say so. It's probably the old semi-database format which some old
apps used to use. :)

You should always open it in binary mode. Probably every file in your
entire life even, but that's just my own principle. On the website is
perhaps a more verbal explanation of the DOF1 format. Only 1 DOF1
identifier should be at the top of the DOF1 file, indicating... a DOF
version 1 file.
The chunks are mostly char id[4]; int32 size; where 'size' is the
length of the upcoming chunk (though this is useful mostly to skip the
chunk if you can't handle it).
There are non-4 byte chunks, I'm sure; most of time it WILL be 4-byte
aligned but there are strings that are stored on 1-byte boundaries (I
know, it's not really cute).

Make it a parser; it's a top-down document, DOF1 being the tree root,
so to say, and when you find a material for example, you enter a
function which reads the material. You have materials and geobs that
you will encounter. These use different IDs to load/save different
things. It's all done in a way so extending it is easy (and in fact
has been done in v0.4.6, where a new flags chunk was added to the
materials).

Good luck,

Ruud van Gaal, GPL Rank +53.25
Pencil art    : http://www.marketgraph.nl/gallery/
Free car sim  : http://www.marketgraph.nl/gallery/racer/

Lol. In fact, I did a raytracing separate app yesterday to look at the
UV coordinates still, and you definitely see a sharp line running
through the separating edge, the U coordinate does very well, but the
V coordinate is really misformed. I tried another dot-product approach
assuming parallel lines, but that's quite useless at this point
(although it has less of the line's visual deformation).
I'll have to reread Eberly's approach to projective texture mapping
(which should get it right, but is quite complex).

Pick up a book on graphics, hehe, most of them explain this, with
pictures (probably available on the net too) and explain G0/G1/G2
continuity as well.

If I'm correct you don't need DX8 to run Racer v0.4.6, just DX7. On
ATI boards in Win98, the environment mapping seems to crash the
drivers and the board even. A matter of buggy drivers that is goes so
far, but turning envmapping off (gfx.ini => envmap.enable=0) seems to
work for most and gets you back the FPS again.

Ah! Well, there's the tricky bit. :)

Yes, I did that; flat tracks, but I've left it behind now since it had
some problems and the tracks were nothing like modeled (VRML) ones.
Though it would be great still as a basis to create your track model
from. But then again, you can't beat 3D model packages these days.

I tried that yesterday. Didn't really work well once the lines are not
totally parallel. And that does happen a lot here, although you could
force your way through in your generated tracks ofcourse.
There's a link, ref [153] in the book 'Real Time Rendering' which
seems to do barycentric coordinates for polygons. Somewhere in
acm.org... Haven't got the book with me though.

Even though strips may be faster, it's quite good as it is, and it's a
hassle creating strips (going through a couple of packages, supporting
it nicely). And I don't support them yet. Have no idea what the
increase would be. As new machines run Racer at 200fps (Carrera) I
don't think it should have big priority at this point too. ;-)

Ruud van Gaal, GPL Rank +53.25
Pencil art    : http://www.marketgraph.nl/gallery/
Free car sim  : http://www.marketgraph.nl/gallery/racer/

Pick up a book on C (or C++); it will definitely help, since C is
really just the same as BASIC, a 3rd generation language. Just with
some obscure writing, in the grand ole Unix style. ;-)

See you in the OpenGL lounge then. ;-)
Just move the glLightfv() command around your projection/modelview
transformations and you'll see the differences. Better to read the red
book and see how it was designed though. :)

Ruud van Gaal, GPL Rank +53.25
Pencil art    : http://www.marketgraph.nl/gallery/
Free car sim  : http://www.marketgraph.nl/gallery/racer/