Index: [thread] [date] [subject] [author]
  From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 16:28:09 -0700 (PDT)

Re: LibGGI3D RFC

On Fri, 21 Aug 1998, Rodolphe Ortalo wrote:

> On Thu, 20 Aug 1998, Jon M. Taylor wrote:
> > 
> > > Okay, drawing with textures enabled is only a particular way of shading.
> > > But it also implies a different number of parms for the function that
> > > draws triangles...
> > 
> > 	Nope.  It all goes into the particular shader_data struct, which
> > gets passed to the shader function via a void pointer.  All you need is
> > the one void pointer and the one shader_function_type pointer and you are
> > all set. 
> > 
> > > So, I don't think you can simply provide ggi3dDrawTexturedTriangle(x,y,z,u,v)
> > > through a display target, you also need the extension lib (because of the
> > > u,v parms...)
> > 
> > 	No, all you need is a different shader function.
> 
> That I don't understand.

	I *hope* I can help, but I am getting confused myself |-<.  I may 
have to defer to Teunis on some of this, the limits of my knowledge are 
fast approaching....

> How can you draw a textured triangle if you don't pass to the drawing
> function the specific texture 

	You would pass the *shader* the texture data.  Why does the
drawing function (which I will assume for the sake of argument is a
soft-rasterizer which calls the shader function for each pixel) need to
know that information?  As long as it can tell the shader about the pixel
coords/world coords/normal value/whatever other data it needs, the shader
should have all the info it needs to computer and return a shade for that
pixel.

> (well, that you could store in the graphic
> context, but it would be costly) 

	Less costly than storing it 20 times for 20 disjoint triangle sets
(I need to start calling them triangle patches).  That is a fairly extreme
example, but it could happen.  Suppose you are rendering 20 colored
spheres, each of which has the Linux penguin bitmap textured onto its
surface. 

> and, more important, the (u,v)
> coordinates of the texture inside the triangle ????

	Wouldn't you need this only once per triangle patch?  If your
patch consists of 50 triangles, presumably you want to texture over the
whole patch, no one triangle at a time.  The u,v for each triangle could
be calculated on the fly in that case, couldn't it?

> Do you mean x,y,z are in real 3D coordinates and the library itself
> computes the 2D projection (hence the u,v coordinates) ?

	That's what I had in mind.  After, all the texture is a 2D bitmap. 
Yes, you need u, v values, but only one u,v offset (and offset angle?) per
triangle patch.  Unless you want to tile more than one texture per patch
or do multitexturing, in which case you need more info.  But the info is
still per-patch, not per-triangle. 

	I learned to do texture mapping in school by projecting the 2D
texture bitmap onto a 3D projection enclosing the surface patch to be
textured, and then projecting the texture inward onto the surface.  So you
have two mapping transforms: texture [u, v] to projection [s, h] and then
projection [s, h] to surface [x, y, z].  The transform [u, v] -> [s, h] is
where you can tile, scale, rotate, correct perspective, blend textures,
etc.  That's how I know how to texture map.

	There are easer/faster methods, like creating a 2D cartesian
mapping [u', v'] over the surface patch and then transforming [u, v] ->
[u', v'], but that loses perspective correction IIRC.  I doubt not that
there are a billion other way to texture map.  I'm just going by what I
know, and with what I know you don't map [u, v] directly to the surface,
and as such you don't need per-triangle [u, v] offsets.  That's done in
the projection step.

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]