Conference hydra::amiga_v1

270.0. "Ray tracer now available" by COOKIE::WECKER (Dave (Cum Grano Salis) Wecker) Sat Jan 24 1987 18:23

ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT
ANNOUNCEMENT							 ANNOUNCEMENT
ANNOUNCEMENT		      DBW_RENDER			 ANNOUNCEMENT
ANNOUNCEMENT		Ray Tracer for the Amiga		 ANNOUNCEMENT
ANNOUNCEMENT		    now available!!!			 ANNOUNCEMENT
ANNOUNCEMENT							 ANNOUNCEMENT
ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT

If you liked the ray traced images previously distributed... you're
going to LOVE DBW_Render. This package is a FULL re-implementation of the Ray
Tracer that I've been using on VAXen to create all those images.

It will run on a standard Amiga (with 512k of memory (and can be configured
to run in 256k if necessary)). By adding AI-heuristics, elapsed time to
compute an image is within the same order of magnitude as a VAX-780 (even
though the Amiga doesn't have hardware floating point or virtual memory)!
For example "glass" computes in 50 hours on an Amiga without the heuristics.
With the heuristics, the image (at full resolution) can be computed in 11 hours.

 The package includes:
 ~~~ ~~~~~~~ ~~~~~~~~~
	RAY	- ray tracing program
	RAY2	- post processor to create IFF/ILBM format files
	DISPLAY	- general display program for RAY2's output
	*.DAT	- sample input files
	*.TMP	- sample RAY output files
	*.ILBM	- sample HAM encoded pictures (RAY2 output)
	*.c	- all MANX-Aztec C sources for the package
	*.h	- all MANX-Aztec C include files for the package
	RAY.DOC	- full documentation for the package
	COPYING - General License Agreement

Please read the General License Agreement (included below) for information on
how to obtain the software.

 Under Development
 ~~~~~ ~~~~~~~~~~~
Depending on the level of interest in this software, I will continue work on: 

	DBW_ED3D a full 3-dimensional graphics editor (so you don't have to
		 mathematically specify the input file to RAY you can just
		 draw it).

	DBW_FILM which creates a film loop of HAM images (so you can create
		 your own "juggler" type demos).

	----     a version of the software using increased memory and floating
		 point co-processor.

	----	 maintenance and enhancements to the current package.

 Background Information
 ~~~~~~~~~~ ~~~~~~~~~~~
The DBW_Render package uses an algorithm called Distributed Ray Tracing.
In addition to neatly solving the hidden surface problem, ray tracing
(in general) affords the opportunity for doing excellent (that is,
highly realistic) shading and illumination calculations.

This package is written in MANX-Aztec C and runs on any AMIGA system. The
RAY program knows how to create images composed of four primitive
geometric objects: spheres, parallelograms, triangles, and flat circular
rings (disks with holes in them). Some of the features of the program
are:

	Determination of correct shadows cast by arbitrarily shaped objects,
	onto arbitrarily shaped objects, due to arbitrarily placed light
	sources.

	Diffuse and specular reflections (with arbitrary levels of gloss or
	polish).  Rudimentary modeling of object-to-object diffusely reflected
	light is also implemented, that among other things accurately simulates
	color bleed effects from adjacent contrasting colored objects.

	Mirror reflections, including varying levels of mirror smoothness
	or perfection.

	Refraction and translucency (which is akin to variable microscopic
	smoothness, like the surface of etched glass).

	Two types of light sources: purely directional (parallel rays from
	infinity) of constant intensity, and spherical sources (like light
	bulbs, which cast penumbral shadows as a function of radius and
	distance) where intensity is determined by the inverse square law.

	Photographic depth-of-field.  That is, the virtual camera may be
	focused on a particular object in the scene, and the virtual
	camera's aperture can be manipulated to affect the sharpness of
	foreground and background objects.

	Solid texturing.  Normally, a particular object (say a sphere) is
	considered to have constant properties (like color) over the entire
	surface of the object, often resulting in fake looking objects.
	Solid texturing is a way to algorithmically change the surface
	properties of an object (thus the entire surface area is no longer of
	constant nature) to try and model some real world material.
	Currently the program has built in rules for modelling wood, marble,
	bricks, snow covered scenes, water (with arbitrary wave sources),
	plus more abstract things like color blend functions.

	Fractals.  The program implements what's known as recursive triangle
	subdivision, which creates all manners of natural looking surface
	shapes (like broken rock, mountains, etc.).  The character of the
	fractal surface (degree of detail, roughness, etc.) is controlled by
	parameters fed to the program.

	AI heuristics to complete computation of a scene within a user
	specified length of time.

When the RAY program runs, it reads a sort of command file, that contains a
geometric description of the scene to be rendered, plus desired global lighting
conditions, camera parameters, etc.  Then the program computes for a long
time, writing each scan line to disk as it computes it. The format of a
scanline (in the .TMP) file is:

	<line  number>	-   2 bytes long
	<red   pixels>	- 160 bytes long (4 bits per pixel)
	<green pixels>	- 160 bytes long
	<blue  pixels>  - 160 bytes long

For an entire screen (400 scan lines) this file is 192,800 bytes. A second
program is run (RAY2) to obtain one of three possible output files:

	4096 colors (HAM) encoded interlaced 320x400 resolution
	  32 colors               interlaced 320x400 resolution
	  32 colors                          320x200 resolution

All of the file formats are standard IFF/ILBM and may be displayed by the
supplied DISPLAY program. In addition, the last version (320x200) may be
edited by any standard graphic package (e.g., DPaint). Others may be
able to handle the more complex first two.

In all, the DBW_Render package represents about 4000 lines of C code. 
It is largely based on original algorithms for the VAX by Tom Dahl and
Tone Engel at Digital Equipment Corporation. The AMIGA version has taken
several months to create.

 General Public License
 ~~~~~~~ ~~~~~~ ~~~~~~~

		 DBW_RENDER GENERAL PUBLIC LICENSE
		Copyright (C) 1987 David B. Wecker

Everyone is permitted to copy and distribute verbatim copies
of this license, but changing it is not allowed.

			COPYING POLICIES

  1. 	You may copy and distribute verbatim copies of DBW_Render source
	code as you receive it, in any medium, provided that you conspicuously
	and appropriately publish on each file a valid copyright notice such
	as "Copyright (C) 1987 David B. Wecker", containing the year of last
	change and name of copyright holder for the file in question; keep
	intact the notices on all files that refer to this License Agreement
	and to the absence of any warranty; and give any other recipients of
	the DBW_Render program a copy of this License Agreement along with
 	the program.

  2. 	You may modify your copy or copies of DBW_Render source code or any
	portion of it, and copy and distribute such modifications under the
	terms of Paragraph 1 above, provided that you also do the following:

    a) 	cause the modified files to carry prominent notices stating
    	who last changed such files and the date of any change; and

    b) 	cause the whole of any work that you distribute or publish,
    	that in whole or in part contains or is a derivative of DBW_Render
    	or any part thereof, to be freely distributed and licensed to all
	third parties on terms identical to those contained in this License
	Agreement (except that you may choose to grant more extensive warranty
	protection to third parties, at your option).

    c) 	cause modified programs when started running in the simplest and
	usual way, to print an announcement including a valid copyright
	notice ("Copyright (C)", the year of authorship, and all copyright
	owners' names).

  3. 	You may copy and distribute DBW_Render or any portion of it in
	compiled, executable or object code form under the terms of Paragraphs
	1 and 2 above provided that you do the following:

    a) 	cause each such copy of DBW_Render to be accompanied by the
    	corresponding machine-readable source code; or

    b) 	cause each such copy of DBW_Render to be accompanied by all
	documentation along with a copy of this General Public License
	(which should be referred to explicitly in the documentation).

  4. 	You may not copy, sublicense, distribute or transfer DBW_Render
	except as expressly provided under this License Agreement.  Any attempt
	otherwise to copy, sublicense, distribute or transfer DBW_Render is
	void and your rights to use DBW_Render under this License agreement
	shall be automatically terminated.  However, parties who have received
	computer software programs from you with this License Agreement will
	not have their licenses terminated so long as such parties remain in
	full compliance.


			CONTRIBUITIONS

  1.	All contributions will be used for program maintenance, development
	and distribution.

  2.	Any user who sends a contribution to David B. Wecker (hereafter
	referred to as "the original author") will be added to a distribution
	list of	registered users. This distribution list will be used for
	mailings of bug fixes, enhancements and announcements of future
	software.

  3.	This package may be obtained from the original author for a
	(suggested) contribution of $18.00 (in North America), please increase
	accordingly for	over-seas orders. This will register you as a user,
	and will add you to the distribution list.

  4.	If copies are obtained from other than the original author, a
	(suggested) contribution of $10.00 should be sent to the original
	author to insure continued maintenance (and adding yourself to the
	distribution list).


			   NO WARRANTY

  BECAUSE DBW_RENDER IS LICENSED FREE OF CHARGE, WE PROVIDE ABSOLUTELY
NO WARRANTY, TO THE EXTENT PERMITTED BY APPLICABLE STATE LAW. EXCEPT
WHEN OTHERWISE STATED IN WRITING, DAVID B. WECKER AND/OR OTHER PARTIES
PROVIDE DBW_RENDER "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH
YOU. SHOULD THE DBW_RENDER PROGRAMS PROVE DEFECTIVE, YOU ASSUME THE COST
OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW WILL DAVID B. WECKER,
AND/OR ANY OTHER PARTY WHO MAY MODIFY AND REDISTRIBUTE DBW_RENDER AS
PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY LOST
PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES
SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH
PROGRAMS NOT DISTRIBUTED BY DAVID B. WECKER.) THE PROGRAM,
EVEN IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR
ANY CLAIM BY ANY OTHER PARTY.


Your comments and suggestions about the licensing policies and the
software are welcome!  Please contact:

	Dave B. Wecker
	115 Palm Springs Drive
	Colorado Springs, CO 80908

	ARPA:	wecker%[email protected]
	USENET:	decwrl.dec.com!cookie.dec.com!wecker

    Re: .0
    
    Dave, do you know if the algorithm would process faster with a 68881
    chip installed?  I have an empty slot in my MicroBotics RAM expander
    that is crying out for a multifunction board w/68881, battery clock,
    recoverable RAM, etc.  All I need is a good excuse to go buy one!
    I assume that your program is EXTREMELY math intensive with tons
    of transformations, etc.
    
    Also, any idea if the trace will go quicker with fast RAM?

Re:	.1

Yes I do LOT's of floating point operations and a 68881 would be lots of help
if:

	1)	You have a C compiler that will support the coprocessor
	2)	You can get to it efficiently.

This is why I'm waiting for Manx 3.4 which does both. The expected speed up
would be on the order of a factor of 4....

(Also: I always want a version for people who don't WANT to buy a 68881)

    Re: .0
    Very impressive lawyerese, Dave. :^)
    Sounds like you've done it again!  Thanks deeply for all the good
    stuff you've been doing for the Amiga world.  Hell, somebody's got
    to support the thing, lord knows, Commodore doesn't seem to want
    to.
    
    Already saving my lunch money,
    Gary

    
    I can't wait. You know, at 18 bucks you'll leave those guys at Caligari
    in the dust! 
    
    

    Hello Dave
    
    Do you mind if I send you a swiss check, you could send me 
    the disk by internal mail?
    
    Rgds
    E.G.

< Re: Note 270.5 by SHIRE::GANGUILLET >

I'd prefer a money-order drawn in U.S. currency (it would make cashing
on this end MUCH easier).

dave

P.S. I will NOT use internal mail for this, so please add in your
     estimate for REAL postage.

Message for Marco (CVADG1::)Pertoso....

I can't seem to find your node in any database, so I can't send you mail
directly, so here is my reply (I hope you read this notes file :-):

-> I would like to order your DWB_RENDER package. Can you please tell me where
-> to send the money. And send the package to :
-> 
-> 
-> 			PERTOSO Marco 
-> 			3, Ch du Chablais 
-> 			1226 Thonex
-> 			Geneva, Switzerland.
-> 
-> Thank again
-> Marco

Send to:

	David B. Wecker
	115 Palm Springs Drive
	Colorado Springs, CO 80908

Suggested contribution:

	$18.00 U.S. + shipping for 3oz first class (please, U.S. funds ONLY).

thanks!
dave

    re .-1
    	I believe the node name should be GVADG1 ( ie G not C)
    					  _
    Joe
   

I just posted this back to the USENET (fyi):

-> Is Dave Wecker on the net?

Right here... I just keep pretty quiet (my nature :-).

-> I just got his ray tracing program off a bbs, and I was curious to know if
-> he plans to post it here.

I'm still deciding. It's a full disk worth of code/examples, and since it is
being supported by contributions it is more likely for me to get users
registered if they have to send me a letter to get the disk. Originally I was
going to put in a clause (in the COPYING file) restricting distribution to
only personal copies (no public BBS/network postings AT ALL!) however, this
is too restrictive for shareware and I hope that people's consciences will
get to them enough to contribute (I just bought some memory, find that I
can't live without the ASDG-RRD and am sending them a contribution... let's
hope others do the same!)

When orders slow down, I may consider posting the software but right now I'm
still playing "mail-order house" (over 140 registered users so far).

-> It is one slick piece of software.

Glad you like it.

-> I'll probably blow off spring break playing with it.
-> Sean

A few suggestions (for all the DBW_Render users listening out there):

1.	Use as much STACK as you can afford. Some pictures REQUIRE stacks
	of over 100K.

2.	When you are designing a picture do the following:

	a.	no transmission (everything opaque).
	b.	no "mirrors" (use low reflection/diffusion levels).
	c.	use only 1 light source.
	d.	make the light source infinitely far away ("l" not "L").
	e.	use a small numbers of objects.

	This will allow you to prototype pictures VERY quickly (minutes not
	hours). BTW: this is why JUGGLER only took its author 1 hour/frame
	to compute it used items a,c,d and e (depending on def. of "small")

3.	If you have two (or more) highly reflective spheres (mirrored) and
	a bright light sources, you probably STILL run out of stack because
	you have to bounce the light back and forth between them for a LONG
	time (not infinite do to the inverse square law)... you can patch
	the file RAY.C changing all occurrences of:

		 max_runs = 32767;

	to a smaller number (somewhere between 30 and 300 for example). This
	will set a much smaller maximum recursion value (and thus much smaller
	stack usage).

4.	Here are some common questions that I get:

->	Would like to see the 3D scene builder...

	(So would I :-) .. it's about 30% done, expect to hear about it
	sometime this summer (spring if I get ambitious).

->	Positioning of the eye/camera...

	The easiest thing to do is to set the center of your image at
	(0,0,0). This is what is done in the GLASS.DAT example. The eye
	is positioned at:

		(30,180,200) looking in the direction of (-50,-320,-350)

	Ok.. so how does this give us (0,0,0)? Well, if you start at the
	eye and add the direction vector you get (-20,-180,-150). It turns
	out that if you go 57% of the way along the direction vector you
	get (0,0,0)!!! So you are looking down and to the left through
	the origin and then 150 units further! By adjusting this distance
	you can magnify or reduce the entire image.

	At the tip of the vector you have 256 units in X visible and 170
	units in Y visible. This defines a viewing "cone" (which you can
	draw the lines out to). But for example, in the plane of the screen
	(Z = 0), you have visible:

		x: -73 to +73		(57% of 256)
		y: -48 to +48		(57% of 170)

	You can make this calculation for any desired depth.

->	Objects are getting FUZZ even when they have 0.0 "fuzziness"...

	Remember that if you don't give the program enough time to run in,
	it will "smear" objects by using the AI algorithms to guess at pixel
	values. Try to give a small strip of the picture an infinite amount
	(999.0 hours) to run in and you should see all pseudo-fuzz go away.

->	Is there a new version yet?

	Nope, I'm just trying to keep up with orders at this point!


Hope this helps everybody out there!

Best Regards,
dave			USENET:	decwrl!cookie.dec.com!wecker
			ARPA:	wecker%[email protected]

From:	COOKIE::WECKER       "DAVE (CUM GRANO SALIS) WECKER" 25-MAR-1987 20:28
To:	LEDS::ACCIARDI
Subj:	RE: Render Quiz

-> Hi Dave....

Hi Ed.

-> I have offered to funnel questions from (hopefully registered) users of
-> 'DBW_Render' to you from PLINK Amiga users.  Here's your first quiz...

Fine with me (sorry I haven't gotten onto PLINK yet :-< )

-> Regards, Ed Acciardi
-> 
-> PS:  I will copy any answers to the VAXNotes file also.

OK, it'll save me the effort. By the way, make sure you post the
"answers" I put in the notes file (270.9) to the people on PLINK
-> --------------------------
-> Date    3/24/87 18:29
-> From   LGOLDEN
-> Subj   RENDER QUESTIONS
-> Num    8   
-> --------------------------
-> 
-> TO: EDDY*A
-> 
-> Eddy,
->        Thank you for your kind offer.  I am a registered user of RENDER and
-> have had the Amiga constantly generating new stuff.  The following are
-> questions that have arisen from my use of the program.  If you could get
-> some kind of reply from Mr. Wecker it would be appreciated.
-> 
->     1)  The docs state that you can create solid 3d objects using the
->         checkerboard texture.  I have been unable to get this to work.
->         Any insight into this would be appreciated.

The ONLY objects available are: TRIANGLES, SPHERES, QUADS and RINGS (fractals
are special types of TRIANGLES). Everything in a picture is made out of
combinations of these.

Textures apply to the SURFACES of these objects. A checkerboard pattern
(between 50 and 59) is just a coloring of the surface of one of the base
object types. The checkerboard pattern has the option of varying with either
1, 2 or 3 dimensions vary (hence the 3D comment in the docs). For example,
if you only allow the X coordinate to vary, then you will get vertical columns
(colorwise) with the width that you specify for X patterning whichever base
object this texture is on. If you allow X and Y to vary then you will get
a "constant width" checkerboard (that does NOT vary with depth), and if all
three vary you get an actual checkerboard.

->     2)  I seem to get black spots on spheres even if I let the picture
->         run to full resolution (999.0) hours.  The spots seem to appear
->         even if in bright light and with no fuzz factor set.  Is this a
->         bug?

From what I can tell this seems to come from the small (32 bit) resolution
of the MATH-FFP library. I haven't played with this on the Amiga yet with
true DOUBLEs (right now everything use FLOATs). I'll let everyone know when/if
I get a better solution running.

->     3)  If the answer to question 1 is negative, will future versions of
->         the software allow work with cubes or other solid objects?

The 3d graphics editor (no I don't have it done) lets you design YOUR OWN
3d solids (besides providing standard conic sections).

->     4)  Anxiously awaiting 3D Scene generator and movie capability!  Also

(Me too! :-)

->         please thank him for me again for all his effort.

My pleasure.

->                                        --- LGOLDEN ---

FYI... we're now up to 150 registered users (from ALL over the world).

Best regards,
dave

Guess what? I lied about the RAY software working on a VAX. Well sort of....

It compiles, and runs. However, everyone who tries to download the .TMP file
gets garbage. The reason? Simple, the VAX does numbers from low to high byte
and the 68000 does the opposite. So all of the fwrite() calls (in FIL.C) have
to be replaced with the appropriate "number flipping" routine.

FYI:	I have done this (as part of working on DBW_Render V2.0) and also
	made a version of RAY2 which runs on the VAX. These will be available
	as part of the major DBW_Render rewrite (hopefully in a few months).

BTW:	RAY2 has been changed to do a "median split" algorithm instead
	of a "poularity" based one which means that non-ham (32 color images)
	are almost indecernable from the HAM (4096 color) versions! See the
	1986 SIGRAPH proceedings for details on color compression.

    The latest issue (July/August) of "Info" magazine features a mini
    review of DBW_Render.  They gave it ***+.  For those of you who
    don't read Info, the review is reproduced here with absolutely no
    permission.
    
    "Ray-tracing produces the fantasic 3-D computer-generated shapes
    and scenes you see in music videos and sci-fi movies.  Before the
    Amiga it took a CrayII or a VAX to do it.  Commercial Amiga ray-tracing
    programs are in the works, but for now DBW_Render will let you play
    with generating 3-D HAM (4096 color) still images.  You can set
    and move light sources, point of view, type and texture of objects
    (from glass to brick) an deven produce rippling effects in water.
     Patience is required; it involves script entry of points and an
    average picture takes 8-24 hours to generate.  -MB"
    
    The picture of the brick structure in the water is featured.
    
    Gary

    Have someone .dat files on the net to share ?
    
    I'd like to experiment with them...
    
    Thanks!