Dec 122017
Microsoft C 5.1 source code for a ray tracer. | |||
---|---|---|---|
File Name | File Size | Zip Size | Zip Type |
ALGORITH | 1679 | 839 | deflated |
ANTIALIA.C | 839 | 345 | deflated |
BALLS.NFF | 558 | 229 | deflated |
BIBLIO | 9230 | 3678 | deflated |
BOUND.C | 3900 | 1508 | deflated |
COLOR.C | 7191 | 1776 | deflated |
COLOR.DOC | 2788 | 892 | deflated |
CONE.C | 7030 | 1991 | deflated |
CONFIG.H | 1758 | 663 | deflated |
COPYING | 590 | 351 | deflated |
DATA.C | 1447 | 587 | deflated |
DEFS.H | 4480 | 1574 | deflated |
ERROR.C | 923 | 341 | deflated |
EXTERN.H | 1858 | 647 | deflated |
GETOPT.C | 1536 | 669 | deflated |
INSTALL | 1198 | 664 | deflated |
INTERSEC.C | 5201 | 1873 | deflated |
LEXYY.C | 14534 | 3167 | deflated |
MAIN.C | 4277 | 1392 | deflated |
MAKEFILE | 1139 | 557 | deflated |
MAKEFILE.ORG | 2306 | 923 | deflated |
MATHERR.C | 554 | 290 | deflated |
MJSMAIN.C | 4507 | 1525 | deflated |
MTV_FIX.1 | 2509 | 1015 | deflated |
MTV_FIX.2 | 1713 | 891 | deflated |
NFF.DOC | 8101 | 3118 | deflated |
NFF.Y | 4098 | 1562 | deflated |
PIC.C | 3874 | 1218 | deflated |
PIC.H | 390 | 161 | deflated |
PICTGA.C | 3250 | 1134 | deflated |
POLY.C | 6016 | 1976 | deflated |
PQUEUE.C | 1931 | 734 | deflated |
RAY.1 | 2196 | 1083 | deflated |
RAY.DOC | 2446 | 1050 | deflated |
README | 3272 | 1583 | deflated |
README.1ST | 3204 | 1621 | deflated |
SCREEN.C | 8060 | 1895 | deflated |
SHADE.C | 4981 | 1671 | deflated |
SPHERE.C | 2511 | 892 | deflated |
TOKENS.L | 811 | 379 | deflated |
TRACE.C | 1168 | 519 | deflated |
TRI.C | 6528 | 2153 | deflated |
VECTOR.C | 1998 | 711 | deflated |
YTAB.C | 18583 | 5459 | deflated |
YTAB.H | 421 | 234 | deflated |
Download File MTVSRC.ZIP Here
Contents of the README file
########################################################################
MTV RAYTRACER*
written by Mark Terrence VandeWettering
[email protected]
########################################################################
* Well, I have had the initials since 1964, Music Television can't say
that 🙂
This represents the second formal release of the MTV Raytracer.
It was written to help me understand how raytracing works, to
generate cute images, and generally because I like to program.
Feel free to use it for any purpose, I am releasing it into the
public domain.
The input format to this ray tracer is called "NFF" or Neutral File
Format, which was invented by Eric Haines' for his Standard Procedural
Database. The SPD was designed to allow programmers to test their
raytracers on databases of varying sizes. While not the end-all to
object file formats, it has served me well. If you wish to change the
input file to something else, you probably only need to change the
parser in "parse.y", not any of the other code.
NFF supports the following primitives:
spheres
cylinders
cones
polygons
polygonal patches (normals are interpolated from corner points)
The MTV raytracer supports all of these primitives, with the minor
limitation that polygonal patches must be triangles (have only three
vertices). I am sure some clever person can convert patches with more
sides to triangles, I haven't found the need yet.
The output from the raytracer is very simple, and not directly tied to
any specific device. It consists of a single line, with format in
C scanf style of "%d %d\n", which gives the resolution of the image.
It is then followed by x*y sets of (red green blue) bytes. We have
pretty unstandard hardware here, (I convert these to Utah Raster
Toolkit form and then filter that to display on a Tek4115) but I do
maintain an archive of source which has been sent to me for this
purpose. More below--
By the time you read this, this raytracer should be available via
anonymous ftp from drizzle.cs.uoregon.edu. I will try to archive
source code for displaying the ".pic" files, as well as interesting
objects that I run accross. Filters already exist to display images on
suns, to convert to PostScript and Impress, as well as X bitmaps Also
available is Eric Haines' SPD source code, so you can generate your own
fractal spheres, mountains, gears etc.
By placing this in the comp.sources.unix, I hope to get this to more of
the people who have requested it. I will entertain e-mail with
questions, and even requests for the source code, but remember that I am
a grad student only, and have limited time. If it takes me a long time
to reply, send mail to me again.
Thanks must go to Eric Haines especially, whose e-mail conversations
have been interesting and fruitful. Also thanks to the numerous
authors whose research into raytracing has seen implementation in this
raytracer, and have provided a host of ideas about image synthesis.
Also thanks to Jeff Eaton and David Koblas, whose criticism and sense of
competition drove this poor hacker to write a better program than he
could have without them.
Ta Ta For Now...
Mark VandeWettering
MTV RAYTRACER*
written by Mark Terrence VandeWettering
[email protected]
########################################################################
* Well, I have had the initials since 1964, Music Television can't say
that 🙂
This represents the second formal release of the MTV Raytracer.
It was written to help me understand how raytracing works, to
generate cute images, and generally because I like to program.
Feel free to use it for any purpose, I am releasing it into the
public domain.
The input format to this ray tracer is called "NFF" or Neutral File
Format, which was invented by Eric Haines' for his Standard Procedural
Database. The SPD was designed to allow programmers to test their
raytracers on databases of varying sizes. While not the end-all to
object file formats, it has served me well. If you wish to change the
input file to something else, you probably only need to change the
parser in "parse.y", not any of the other code.
NFF supports the following primitives:
spheres
cylinders
cones
polygons
polygonal patches (normals are interpolated from corner points)
The MTV raytracer supports all of these primitives, with the minor
limitation that polygonal patches must be triangles (have only three
vertices). I am sure some clever person can convert patches with more
sides to triangles, I haven't found the need yet.
The output from the raytracer is very simple, and not directly tied to
any specific device. It consists of a single line, with format in
C scanf style of "%d %d\n", which gives the resolution of the image.
It is then followed by x*y sets of (red green blue) bytes. We have
pretty unstandard hardware here, (I convert these to Utah Raster
Toolkit form and then filter that to display on a Tek4115) but I do
maintain an archive of source which has been sent to me for this
purpose. More below--
By the time you read this, this raytracer should be available via
anonymous ftp from drizzle.cs.uoregon.edu. I will try to archive
source code for displaying the ".pic" files, as well as interesting
objects that I run accross. Filters already exist to display images on
suns, to convert to PostScript and Impress, as well as X bitmaps Also
available is Eric Haines' SPD source code, so you can generate your own
fractal spheres, mountains, gears etc.
By placing this in the comp.sources.unix, I hope to get this to more of
the people who have requested it. I will entertain e-mail with
questions, and even requests for the source code, but remember that I am
a grad student only, and have limited time. If it takes me a long time
to reply, send mail to me again.
Thanks must go to Eric Haines especially, whose e-mail conversations
have been interesting and fruitful. Also thanks to the numerous
authors whose research into raytracing has seen implementation in this
raytracer, and have provided a host of ideas about image synthesis.
Also thanks to Jeff Eaton and David Koblas, whose criticism and sense of
competition drove this poor hacker to write a better program than he
could have without them.
Ta Ta For Now...
Mark VandeWettering
Contents of the README.1ST file
########################################################################
MTV RAYTRACER*
written by Mark Terrence VandeWettering
[email protected]
########################################################################
* Well, I have had the initials since 1964, Music Television can't say
that 🙂
This represents the second formal release of the MTV Raytracer.
It was written to help me understand how raytracing works, to
generate cute images, and generally because I like to program.
Feel free to use it for any purpose, I am releasing it into the
public domain.
The input format to this ray tracer is called "NFF" or Neutral File
Format, which was invented by Eric Haines' for his Standard Procedural
Database. The SPD was designed to allow programmers to test their
raytracers on databases of varying sizes. While not the end-all to
object file formats, it has served me well. If you wish to change the
input file to something else, you probably only need to change the
parser in "parse.y", not any of the other code.
NFF supports the following primitives:
spheres
cylinders
cones
polygons
polygonal patches (normals are interpolated from corner points)
The MTV raytracer supports all of these primitives, with the minor
limitation that polygonal patches must be triangles (have only three
vertices). I am sure some clever person can convert patches with more
sides to triangles, I haven't found the need yet.
The output from the raytracer is very simple, and not directly tied to
any specific device. It consists of a single line, with format in
C scanf style of "%d %d\n", which gives the resolution of the image.
It is then followed by x*y sets of (red green blue) bytes. We have
pretty unstandard hardware here, (I convert these to Utah Raster
Toolkit form and then filter that to display on a Tek4115) but I do
maintain an archive of source which has been sent to me for this
purpose. More below--
By the time you read this, this raytracer should be available via
anonymous ftp from drizzle.cs.uoregon.edu. I will try to archive
source code for displaying the ".pic" files, as well as interesting
objects that I run accross. Filters already exist to display images on
suns, to convert to PostScript and Impress, as well as X bitmaps Also
available is Eric Haines' SPD source code, so you can generate your own
fractal spheres, mountains, gears etc.
By placing this in the comp.sources.unix, I hope to get this to more of
the people who have requested it. I will entertain e-mail with
questions, and even requests for the source code, but remember that I am
a grad student only, and have limited time. If it takes me a long time
to reply, send mail to me again.
Thanks must go to Eric Haines especially, whose e-mail conversations
have been interesting and fruitful. Also thanks to the numerous
authors whose research into raytracing has seen implementation in this
raytracer, and have provided a host of ideas about image synthesis.
Also thanks to Jeff Eaton and David Koblas, whose criticism and sense of
competition drove this poor hacker to write a better program than he
could have without them.
Ta Ta For Now...
Mark VandeWettering
Misc notes
mjs
ray.docOutput of the unix "nroff -man ray.1 >ray.doc"; a readable
version of ray.1, the "manual" page for the package
ytab.cThe unix command "yacc -d nff.y" produces y.tab.c and y.tab.h
ytab.hwhich have renamed here to ytab.c and ytab.h
lexyy.cThe unix command "lex tokens.l" produces "lex.yy.c", which has
been renamed here to lexyy.c
makefile.orgOriginal makefile that came with the usenet posting
Official Patches...
The patch from Mark T. VandeWettering in mtv_fix.2 has been applied.
The patch from Eric Haines in mtv_fix.1 has been applied...pretty much...
On or about line 79 of screen.c
VecCross(viewvec, leftvec, upvec);
has been commented out since it ever so slightly fouls up a sequence of images
I'm in the process of tracing. (I think it is fixing something which, for this
particular input, isn't broken, thus breaking it (?!)
Jim Prior's patches for MSDOS ([email protected])...
The "divide()" kludge (matherr.c) seems to help with the "divide by zero"
errors that show up under MSDOS (this problem never appeared on the UnixPC
with it's 68010). The value of HUGE under MSC is DBL_MAX, but causes the
system to die an early death. Jim redefined this to MAXFLOAT (from Borland's
values.h), I've changed it to FLT_MAX (from MSC's float.h). My feeling is that
DBL_MAX is really the right value to use, but I haven't time to track down the
crash. It seems to work with FLT_MAX, so that's how it sits.
The "RESUME" equate enables a "start where you left off" feature for those
times when the computer crashes 3 days into a 4 day trace. When "-R" is given
on the command line, the program will search for an output file of the same
name given with "-o", and if found, calculate where to resume tracing. This
works dandy on the UnixPC, but under MSDOS if the system crashes (or power
blinks, like it does all the time at my place) the output file is 0 bytes
long. Perhaps the file should be closed and reopend after each scan line.
Jim also changed the unix time keeping routines in main.c to work under
MSDOS.
Lee Crocker's patches...
Lee changed the "-t" option a bit so that instead of "happy dots" being
displayed at the end of each scan line, it prints the scan line number.
Lee also supplied a version of pic.c to output Targa format files. Since
many of my routines are built to handle the original output format of mtv,
I've renamed his file pictga.c. It's a "drop in" replacement, so just
rename it or fiddle the makefile to suit.
"Real Soon Now"...
Rather than use Lee's pictga, it might be more in the spirit to write a
simple filter to convert from the "native" output format to Targa.
Some more work has to be done on the output statistics report; I still get
negative numbers in there from time to time. The mjsmain.c file changes some
of the printf format strings, but it still isn't 100%.
Some speedup ideas I haven't messed with yet...
cl: /G2 (80286) /FPi87 ("smallest & fastest")
(specify mLIBC7.LIB at link time)
Link: /F[arcalltranslation] /P[ackcode]
--- eof ----------------------------------------------------------------
MTV RAYTRACER*
written by Mark Terrence VandeWettering
[email protected]
########################################################################
* Well, I have had the initials since 1964, Music Television can't say
that 🙂
This represents the second formal release of the MTV Raytracer.
It was written to help me understand how raytracing works, to
generate cute images, and generally because I like to program.
Feel free to use it for any purpose, I am releasing it into the
public domain.
The input format to this ray tracer is called "NFF" or Neutral File
Format, which was invented by Eric Haines' for his Standard Procedural
Database. The SPD was designed to allow programmers to test their
raytracers on databases of varying sizes. While not the end-all to
object file formats, it has served me well. If you wish to change the
input file to something else, you probably only need to change the
parser in "parse.y", not any of the other code.
NFF supports the following primitives:
spheres
cylinders
cones
polygons
polygonal patches (normals are interpolated from corner points)
The MTV raytracer supports all of these primitives, with the minor
limitation that polygonal patches must be triangles (have only three
vertices). I am sure some clever person can convert patches with more
sides to triangles, I haven't found the need yet.
The output from the raytracer is very simple, and not directly tied to
any specific device. It consists of a single line, with format in
C scanf style of "%d %d\n", which gives the resolution of the image.
It is then followed by x*y sets of (red green blue) bytes. We have
pretty unstandard hardware here, (I convert these to Utah Raster
Toolkit form and then filter that to display on a Tek4115) but I do
maintain an archive of source which has been sent to me for this
purpose. More below--
By the time you read this, this raytracer should be available via
anonymous ftp from drizzle.cs.uoregon.edu. I will try to archive
source code for displaying the ".pic" files, as well as interesting
objects that I run accross. Filters already exist to display images on
suns, to convert to PostScript and Impress, as well as X bitmaps Also
available is Eric Haines' SPD source code, so you can generate your own
fractal spheres, mountains, gears etc.
By placing this in the comp.sources.unix, I hope to get this to more of
the people who have requested it. I will entertain e-mail with
questions, and even requests for the source code, but remember that I am
a grad student only, and have limited time. If it takes me a long time
to reply, send mail to me again.
Thanks must go to Eric Haines especially, whose e-mail conversations
have been interesting and fruitful. Also thanks to the numerous
authors whose research into raytracing has seen implementation in this
raytracer, and have provided a host of ideas about image synthesis.
Also thanks to Jeff Eaton and David Koblas, whose criticism and sense of
competition drove this poor hacker to write a better program than he
could have without them.
Ta Ta For Now...
Mark VandeWettering
Misc notes
mjs
ray.docOutput of the unix "nroff -man ray.1 >ray.doc"; a readable
version of ray.1, the "manual" page for the package
ytab.cThe unix command "yacc -d nff.y" produces y.tab.c and y.tab.h
ytab.hwhich have renamed here to ytab.c and ytab.h
lexyy.cThe unix command "lex tokens.l" produces "lex.yy.c", which has
been renamed here to lexyy.c
makefile.orgOriginal makefile that came with the usenet posting
Official Patches...
The patch from Mark T. VandeWettering in mtv_fix.2 has been applied.
The patch from Eric Haines in mtv_fix.1 has been applied...pretty much...
On or about line 79 of screen.c
VecCross(viewvec, leftvec, upvec);
has been commented out since it ever so slightly fouls up a sequence of images
I'm in the process of tracing. (I think it is fixing something which, for this
particular input, isn't broken, thus breaking it (?!)
Jim Prior's patches for MSDOS ([email protected])...
The "divide()" kludge (matherr.c) seems to help with the "divide by zero"
errors that show up under MSDOS (this problem never appeared on the UnixPC
with it's 68010). The value of HUGE under MSC is DBL_MAX, but causes the
system to die an early death. Jim redefined this to MAXFLOAT (from Borland's
values.h), I've changed it to FLT_MAX (from MSC's float.h). My feeling is that
DBL_MAX is really the right value to use, but I haven't time to track down the
crash. It seems to work with FLT_MAX, so that's how it sits.
The "RESUME" equate enables a "start where you left off" feature for those
times when the computer crashes 3 days into a 4 day trace. When "-R" is given
on the command line, the program will search for an output file of the same
name given with "-o", and if found, calculate where to resume tracing. This
works dandy on the UnixPC, but under MSDOS if the system crashes (or power
blinks, like it does all the time at my place) the output file is 0 bytes
long. Perhaps the file should be closed and reopend after each scan line.
Jim also changed the unix time keeping routines in main.c to work under
MSDOS.
Lee Crocker's patches...
Lee changed the "-t" option a bit so that instead of "happy dots" being
displayed at the end of each scan line, it prints the scan line number.
Lee also supplied a version of pic.c to output Targa format files. Since
many of my routines are built to handle the original output format of mtv,
I've renamed his file pictga.c. It's a "drop in" replacement, so just
rename it or fiddle the makefile to suit.
"Real Soon Now"...
Rather than use Lee's pictga, it might be more in the spirit to write a
simple filter to convert from the "native" output format to Targa.
Some more work has to be done on the output statistics report; I still get
negative numbers in there from time to time. The mjsmain.c file changes some
of the printf format strings, but it still isn't 100%.
Some speedup ideas I haven't messed with yet...
cl: /G2 (80286) /FPi87 ("smallest & fastest")
(specify mLIBC7.LIB at link time)
Link: /F[arcalltranslation] /P[ackcode]
--- eof ----------------------------------------------------------------
December 12, 2017
Add comments