From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : teunis <teunis@computersupportcentre.com>
  Date: Fri, 21 Aug 1998 00:03:36 -0700 (PDT)

RE: LibGGI3D RFC

On Thu, 20 Aug 1998, teunis wrote:

> On Thu, 20 Aug 1998, Jon M. Taylor wrote:
> 
> > On Thu, 20 Aug 1998, Paul Sargent wrote:
> 
> [clip]
> 
> > > Walking along the edges of a 2D triangle and filling
> > > in the raster spans from one edge to the other. You can't get any
> > > simpler.
> > > 
> > > We would be talking about implementing a handful of commands: glBegin /
> > > glEnd, glColor, glVertex2. That is what you need for rasterisation only.
> > > Simple. Can be optimised to death
> > 
> > 	Of course this kind of code will be present.  But it will be in
> > the display targets.
> 
> hmm..  The more I think about this the more I think that something like
> that -specific- commandset fits libGGI3D....
> But I could be wrong....

	It sort of does, but in a representational sense, not a command
sense. glColor = shaders, glVertex = triangle vertices or other coordinate
sets [(u, v), etc].

> > > > 	Shading and texture mapping is included with the pluggable
> > > > shaders. 
> > > 
> > > I like this pluggable shaders thing. Although I've still got to get my
> > > head around it completly. Sound like it will be a software only thing.
> > > Is that right? (I 'spose apart from the standard ones like flat, gourad,
> > > gourad + Z, gourad + Texture, etc)
> > 
> > 	The shader functions themselves will be software-only, because a
> > "shader function" for hardware shading is a meaningless concept.  What the
> > pluggable shaders concept gives you is a way to separate shading from
> > rendering.  If I call DrawTriangle() and tell it to use a phong shader, it
> > can transparently use hardware color ramps if available, or fall back to
> > the software phong shader I passed it.  And I don't need a separate
> > DrawPhongShadedTriangle() function either.
> 
> And this is where I got mixed up.
> I've been looking at -only- rendering functions.  Not shading.
> hmmm.  That does put new light on things!

	Ah, grasshopper, you have learned much.  Now it is time for you to
leave the temple!  |-> |->.  Seriously though, I think that shading should
be treated as a separate, fourth step in the tradition graphics rendering
pipeline - tesselation, geometry, rendering and shading.  Sure, shading
and rendering *can* be done as one step, but so can tesselation and
geometry or geometry and rendering.  The point is that shading involves so
many unique algorithms and principles that it can stand on its own.

> A perpixel shader is a silly thing to have in a game (IMHO) 

	Don't tell that to S3.  The Savage3D chipset supports procedural
shaders in hardware.  http://www.s3.com/products/overview/po41gx3.htm. 
They also support a lot of other advanced shaders, which leads me to the
conclusion that they have implemented a generic per-pixel shading solution
in the Savage3D chipset.

> but nice for
> high-quality rendering.  

	Have you ever seen the output of some of those advanced procedural
shaders that RenderMan has???  I saw a simple sphere with one distant
lightsource textured into an earth-like planet with oceans, fractal
continents with elevation color gradients, cirrus-like fractal clouds
which cast diffuse shadows on the planet's surface, *and* polar icecaps! 
The thing looked REAL, like a snapshot from an earth-orbiting satellite. 
My jaw was on the floor.  I think the C source and RenderMan shader
language (.sl) source combined was something like 80k.  And just by
varying some parameters, the renderer could make "planets" that looked
like Mars, or Venus, or Jupiter, or even the Moon!  A slightly modified
version of the same shader could produce a very good approximation of the
Sun!

	For those who don't know what RenderMan is, have a look at
http://rmr.spinne.com.  The FAQ will tell you everything, but in a
nutshell RenderMan is 3D Postscript.  The pluggable shader stuff is the
crown jewel of RenderMan.  Take a look a some of the textures in the
gallery on the site and tell me you don't want procedural texturing.  I
think LibGGI3D can do without the specialized shader language, but the
shader concept itself is pure gold.  If you look at RenderMan's design
principles, you will also see some of the design principles I have been
advocating for LibGGI3D - independence of shading and rendering, device
independence, algorithm independence, etc.  Good stuff.

> On the flip side, a shader that says "mix this
> fog effect into those colours and that lighting produces a gouraud-shaded
> triangle "so" for the renderer" :)
> [and where HW supports it the shader just says "do this with a direct
> renderer in HW", yes?]

	Yep.  That's the idea.

Jon


---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed