Path: chuka.playstation.co.uk!news From: James Russell Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: OT's - how do they work? Date: Tue, 21 Oct 1997 17:05:08 +1300 Organization: Peace Computers NZ Ltd Lines: 128 Message-ID: <344C29F4.1E4D@peace.co.nz> References: <3446DC9D.BB81C6EE@ibm.net> <344b4014.300721@news.playstation.co.uk> <344AB445.6113@peace.co.nz> <344d734b.5610332@news.playstation.co.uk> NNTP-Posting-Host: 202.37.70.35 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (X11; I; IRIX 6.2 IP22) CC: jruss@ibm.net Alex Amsel wrote: > > >Now the PSX OT_TAG's have a pointer to the next OT_TAG (p) but > >don't have an associated Z value or a pointer to the GPU commands > >to be executed. > > If the polygon is at Z = 100, it will look up the 100th entry in the > above table, and will insert it before the existing polygons there. > The GPU command immediately follows the OT_TAG so no pointer is > needed. OK, let's see if I've got this straight: Say I want a Z resolution of 0 to 511 (a Z granularity of 512). That doesn't mean to say that Z doesn't have a higher granularity when calculating positions in 3D space, it just means that when it gets plonked in the OT some of the lower bits will be chopped off (every 'real' Z value will be plonked into one of 512 'slots'). That means a OT of size 9 (2^9 = 512); There are 512 OT_TAGs in the OT, one for every 'granule' of Z. Each of the 512 OT_TAGs begins a linked list of GPU commands to execute for that 'Z granule'. These 512 OT_TAGs are either blank (nothing in that 'slot') or point to ANOTHER OT_TAG *within the PACKET WORK AREA*. An OT_TAG within the packet work area has packet data directly following it, AND a pointer to ANOTHER OT_TAG, again, within the packet area. This list continues in this fashion until the 'pointer to next OT_TAG' is NULL. When I insert a 3D object into the list, the program effectively: Transforms all vertices into Screen Space (Xs,Ys,Zs) For each polygon 'P' in the 3D object Average of the 'Zs' component of P's vertices -> Zaverage Work out which of the 512 'slots' Zaverage fits into. Work out the commands to draw this polygon. Puts these commands into some free space in the packet work area. Sets the OT_TAG at the beginning of these commands to point to wherever the slot pointed originally. Insert a pointer to this new command into the above slot. When I draw the OT, the program effectively: For Z = 511 to 0 Step -1 // (Back to Front - Painters algorithm) Current_OT_Tag = OT[z]; while(Current_OT_TAG.p is NOT NULL) Send packets at Current_OT_TAG.p to GPU. Current_OT_TAG = Current_OT_TAG.p Maybe this graphic example helps - turn on fixed width font! ORDERING TABLE after all polygons inserted: (9 bit) --------------------------------------------------- [0] [1] [2] ..................... [509] [510] [511] | | | | | | NUL NUL 345 236 NULL NULL PACKET AREA: ------------ Offset: 000 001 ... ... 186 187 (pointed to by TAG at 345) -> NULL (End of list) 188 -\ 189 | 190 |--- GPU packet data for this TAGs polygon. 192 | 193 -/ 194 ... 235 236 (point to by TAG in slot 509) -> NULL (End of list) 237 -\ 238 |--- GPU packet data for this TAG's polygon 239 -/ ... 344 345 (pointed to by Slot 2) OT_TAG -> (Offset 187) 346 -\ 347 |--- GPU packet data for this TAG's polygon 348 -/ 349 ... Right, now assuming all the slots in the ordering table are NULL except for the ones specified above, we can see that the painters algorithm: Starts at the 'back' (slot 511) and work it's way to the front (slot 0). Does nothing for 511 and 510 (they're both NULL). Hits 509 and sees that it points to offset 236. It goes to offset 236 in the packet area and draws a polygon using the GPU packet data it finds at 237-239 (it determines the length of the packet data from the 'num' field of the OT_TAG). The OT_TAG at 236 points to NULL, so it ends there and goes to the next slot (508). For slots 508 to 3 it does nothing (since they're all NULL). For slot 2 (which point to offset 345): It goes to offset 345 in the packet area and draws a polygon using the GPU packet data it finds at 346-348 (deducing the size of GPU data from the OT_TAG 'num' field. It sees the OT_TAG at 345 points to another OT_TAG at 187. It goes to offset 187 in the packet area and draws a polygon using the GPU packet data it finds at 188-193 (it determines the length of the packet data from the 'num' field of the OT_TAG). The OT_TAG at 187 points to NULL, so it ends there and goes to the next slot. There are no more slots with non-NULL pointers, to it finishes there and the screen is drawn! Is this correct? I sure hope so! Cheers, J -- ==PEACE COMPUTERS ==James.Russell@peace.co.nz - 64(9)3730400 -Fax 64(9)3730401