Index:
[thread]
[date]
[subject]
[author]
From: teunis <teunis@computersupportcentre.com>
To : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
Date: Fri, 21 Aug 1998 17:56:57 -0700 (MST)
RE: LibGGI3D RFC
On Fri, 21 Aug 1998, Jon M. Taylor wrote:
> 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]..
hmmm. Actually - the allowed commands in the [BEGIN to END] section
actually fit what I'm looking for quite nicely :)
[IMHO the whole thing does]
But I'm still looking....
oh - fwiw - it looks like GGI is the -perfect- environment to develop a
OpenGL system.... what with being able to override and specialize
functions in existing extensions + adding new extensions quickly...
your split requirements (only this allowed *here*) actually fits perfectly
too...
> > > > > 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
>
>
Index:
[thread]
[date]
[subject]
[author]