Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: "Michael Hough" <mhough@stanford.edu>
Newsgroups: scee.yaroze.programming.3d_graphics
Subject: Re: 3D Sprite TMDs?
Date: Thu, 12 Feb 1998 03:33:36 -0800
Organization: SCEA News Server
Lines: 99
Message-ID: <6bum6p$4703@scea>
References: <01bce267$32a34140$0300010a@mario> <34E2C6E8.2BA8BD0F@micronetics.com>
NNTP-Posting-Host: delirium.Stanford.EDU
X-Newsreader: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4


Jim wrote in message <34E2C6E8.2BA8BD0F@micronetics.com>...
>3d sprites rears its head again.. oh that old chestnut..
>
>Has there been a solution to this problem yet?  I was up until the early
hours
>again this morning trying to
>place a sprite in three dimensions.  I have something reasonable working,
just
>a couple of glitches here and there.  My major problem is I have a roving
>camera style view and the sprite has trouble translating in relation to its
>[camera] position.
>
>Here's some pseudo code from what I can remember, am I doing anything
unusual?
>
>VECTOR v;    // coord system
>VECTOR p;    // resulting location for sprite
>MATRIX m;
>long x,y;
>
>v.vx = 0;  v.vy = 0;  v.vz = 0;
>GsInitCoordinate2 ( WORLD, &local);        // init coord system
>GsGetLS (&local, &m);                                // combine with
>GsWSMATRIX for camera
>ApplyMatrix (&m, &v, &p);                        // project coordinates
>
>// perspective calcs and display here...
>
>Now this code produces the expected result ( or at least I convinced myself
>the result was expected).
>But if I translate that point or coordinate system anywhere else, I get
nada,
>or something unexpected and a bit bizarre..
>
>I've not shown the perspective calcs because they were a hack.
>essentially.
>
>x = -p.vx;
>y = p.vz;        // not a typo with vz
>
>But this does place the sprite where it should be..
>
>Does ApplyMatrix add the translation terms as well?  I wrote my own version
of
>applymatrix to compare the
>results and I got the same as ApplyMatrix only if I neglected to do the
>translation.
>
>I also get the same result if I replace the GsGetLs with
>ApplyMatrix (&GsWSMATRIX, &v, &p);
>
>I guess as an alternative to this I would have to try a bill boarding
>approach, although not really ideal for the application I have in mind, and
>quite possibly slower.
>
>Can anyone please help me out, as I don't think I could handle many more
>sleepless nights.
>
>
>Many thanks
>Regards
>
>Jim


Here's the code I hacked together--it owes a lot to the SCEE 'flying' demo:

  setVector(&sprV,x,y,z);

  PushMatrix();

  ApplyMatrixLV(&GsWSMATRIX, &sprV, &tmpV);
  tmpV.vx += GsWSMATRIX.t[0];
  tmpV.vy += GsWSMATRIX.t[1];
  tmpV.vz += GsWSMATRIX.t[2];
  if (tmpV.vz == 0) tmpV.vz=1;  // div by zero
                                // 512 is SCR_Z
  sprV.vx = tmpV.vx * 512 / tmpV.vz;
  sprV.vy = tmpV.vy * 512 / tmpV.vz;
  sprV.vz = tmpV.vz >> 2;

  PopMatrix();

  spr.scalex=spr.scaley=512*4096/(sprV.vz);

It seems a lot like yours; you can probably use the Ls matrix rather than
the WS matrix (depending on in whose coordinate system x, y, and z are, no
doubt).  You do need to do the translation yourself.  The problem is
probably in your perspective transform; multiply by the screen distance (512
in this case) and then divide by the sprite distance.  That same number is
also scaling.  The Push- and PopMatrix() calls are voodoo left over from the
'flying' demo.

Good luck!

mike