Dec 122017
 
Microsoft C 5.1 source code for a ray tracer.
File MTVSRC.ZIP from The Programmer’s Corner in
Category C Source Code
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


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


 December 12, 2017  Add comments

Leave a Reply