Path: chuka.playstation.co.uk!scea!peter_alau@playstation.sony.com From: Gerrit Goossen Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: gteMIMefunc & me: One of us is wrong Date: Fri, 13 Nov 1998 00:43:52 -0500 Organization: SCEA News Server Lines: 61 Message-ID: <364BC70E.75A7@funnytown.com> NNTP-Posting-Host: 38.165.241.13 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01-C-MACOS8 (Macintosh; I; PPC) James wrote: >Gerrit Goossen wrote: >> >> gteMIMefunc(theAnimation->workVertexArray, theData->mimeArray, >> theData->vertexCount, ONE); > >The first argument is both input and output. It is the 'origin' of the >vertex, and the second arg is the difference between the origin and the >destination. The function multiplies the difference by the last arg, >divides by ONE and adds it to the origin. Those assumptions are *exactly* why I expected my code to work! If I'm adding 1/4 of a vector to each vertex, and I do it four times, it should be the same as adding the full vector once. Craig wrote: >I reckon that Gerrit using ONE as a p scaler is far to big and accounts >for the problem >- there's some math error going on in what should be the fractional >part of the delta information (the GTE is prone to errors in the >fractional component). So what he actually should do is scale his delta >array up as far as possible without overflowing the +/- 32767 >that you can get in a signed short and reduce the p scaler accordingly >(multipy all delta's by 10, divide p scaler by 10 seems a good starting >point). As I read this I began to remember what hope felt like... The problem really does look like a math error (vertices that don't move much, move to far and vice versa), so I quickly whipped in a "multiply by 8" to the tool I'm using to generate the MIMe and tried it out: No luck. The results look exactly the same as before! (It animates correctly with a single gteMIMefunc, but "mutates" with multiple calls in a row.) Just for thoroughness I tried scaling the vectors by 16 and had the same results as well... James later wrote: >Why not just use gteMIMEfunc with a variable 'p'? Of course, this means >that you have to copy the original input verts every time, which is >less than efficient, but it would mean that you don't lose the >accuracy. It's what I'll end up doing if I can't figure this out, but curiosity has kicked in: I don't believe I'm doing anything wrong, but I'm getting the wrong results... These kinda things bug me! >But I don't know if this is compatible with RSDAnimlib, which >I haven't used before. I'm not using RSDAnim or RSDAnimlib... It's hard to gauge if I had more or less trouble when I was trying to though ;^) Anyway, just a long-shot idea on where the problem might be: Is there any chance that making repeated requests to the GTE to perform operations on the same data could be the problem? (Does the GTE que requests like the GPU?) - Gerrit