cs87fmc@cc.brunel.ac.uk (F M Cargill) (05/09/91)
In article <8787@crash.cts.com> jcs@crash.cts.com (John Schultz) writes: >...The 34020 >board (still in design phase) will sport a 34082, spec'd out at 40 MFLOPS. It's >got built in matrix operations as well. Serious real-time simulation will be >possible with this board. Will it let you use the 40MFLOPS to do 3D projections? Hardware Z-buffering would be even better - it would let us render scenes using the Radiosity model rather than using Ray-Tracing; for animations the former has the advantage that you only calculate the scene once (to work out light reflections) and you can produce an image of the scene in a matter of seconds, from whatever viewpoint you like - Real Time Virtual Reality! Fletch. cs87fmc@cc.brunel.ac.uk
jleonard@pica.army.mil (05/09/91)
I am unfamiliar with Z-buffering and the Radiosity model ( but interested ). Could some kind soul explain what these are and/or point me to some good literature on the subjects. ___________________________________________________________________________ |Jeff Leonard Usenet: jleonard@pica.army.mil | | My strength is as the strength of ten because my code is pure. | ---------------------------------------------------------------------------
mark@calvin..westford.ccur.com (Mark Thompson) (05/11/91)
In article <53121@nigel.ee.udel.edu> jleonard@pica.army.mil writes: >I am unfamiliar with Z-buffering and the Radiosity model ( but interested ). >Could some kind soul explain what these are and/or point me to some good >literature on the subjects. The first is easy. Z-buffering is perhaps the simplest of all hidden surface algorithms but did not become popular until the past several years because off its memory cost. It invovles a dedicating a chunk of memory the size of your frame buffer with a depth of at least 16bits (depending on the possible range of Z values). The idea is, when scan converting the graphics primitve to color values for each pixel, a z-value is also calculated (the distance from the view plane to the object surface at that location). This value is compared to the value previously stored at that location and if the new value is closer to the viewer, then the z-value at that location is updated and the pixel color is written to the frame buffer. If not, the calculated z-value is discarded and the rasterizer moves on to the next pixel. Ofcourse this requires that the Z-buffer be initialized before rasterization begins. Because the depth of the Z-buffer determines the precision to which the comparison can be done, the bigger the better. 32bits is not uncommon and some have gone to floating point. A typical problem case for a Z-buffer would be runway markings in a flight simulator. Although the distance from the viewer to the runway may be 1 mile, the polygon that describes the runway marking may be only 1/2 inch off the ground. This case is beyond the capabilities of a 16bit Z-buffer. The other problem with the Z-buffer is it does not handle transparency properly. Consequently, algorithms such as Carpenter's A-buffer have been implemented. For further reading on the Z-buffer, A-buffer, and other hidden surface techniques, check out "Computer Graphics, Principles and Practice" by Foley, van Dam, Feiner, & Hughes. Radiosity is a more complex topic. It basically is a method for modeling diffuse interobject light reflection using procedures based on thermal engineering models. While ray tracing yields very hard edges and specular highlights, radiosity produces more subtle lighting effects and soft lighting & shadowing that is typical of the real world. While the above mentioned text does a good job of describing a few radiosity methods, a more thorough text is the Siggraph "Radiosity" course notes as well as papers from Siggraph proceedings from the past 3 to 5 years. The course notes can only be bought at Siggraph but are available at some larger libraries. Hope this helps. %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~% % ` ' Mark Thompson CONCURRENT COMPUTER % % --==* RADIANT *==-- mark@westford.ccur.com Principal Graphics % % ' Image ` ...!uunet!masscomp!mark Hardware Architect % % Productions (508)392-2480 (603)424-1829 & General Nuisance % % % ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jcs@crash.cts.com (John Schultz) (05/11/91)
In <2102@Terra.cc.brunel.ac.uk> cs87fmc@cc.brunel.ac.uk (F M Cargill) writes: >In article <8787@crash.cts.com> jcs@crash.cts.com (John Schultz) writes: >>...The 34020 >>board (still in design phase) will sport a 34082, spec'd out at 40 MFLOPS. It's >>got built in matrix operations as well. Serious real-time simulation will be >>possible with this board. >Will it let you use the 40MFLOPS to do 3D projections? Hardware Z-buffering >would be even better - it would let us render scenes using the Radiosity >model rather than using Ray-Tracing; for animations the former has the >advantage that you only calculate the scene once (to work out light >reflections) and you can produce an image of the scene in a matter of seconds, >from whatever viewpoint you like - Real Time Virtual Reality! You can use the 40MFLOPS to do whatever floating point operations you wish. Z-buffering in hardware? You'll have to wait for the i860 board. Not only will you get hardware z-buffering, but Gouraud shaded polygons at about 40,000/sec (33Mhz part). 25Mhz i860s are down to about $250... I saw a demo at HP/Apollo with a 68030 machine with an i860 coprocessor doing real-time radiosity and texture mapping in a window (about four frames/sec [real-time is relative]). Still no big deal compared to an SGI VGX, but a great deal cheaper. John