Path: chuka.playstation.co.uk!news From: Craig Graham Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: Poly Intersections Date: Wed, 06 Jan 1999 01:06:25 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 81 Message-ID: <3692B711.E94081A4@hinge.mistral.co.uk> References: <3689671E.AA01BBAB@hinge.mistral.co.uk> <36908BCA.F33C961E@hinge.mistral.co.uk> NNTP-Posting-Host: d1-s7-39-telehouse.mistral.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Toby Sargeant wrote: > Another thing you might like to consider for RSDAnim is presplitting > pathological polygons that are guaranteed to cause incorrect overlaps when > z-sorted. Interesting idea - I may well take this one further. I was intending to do it just for polys that actually intersected, but I can see the case where you're gonna get Z-sort problems using libgs: Top view: Z distant / / / / ---------------B / / / / A Z near --------------VIEW PLANE---------------- Two poly's drawn here (A and B) - they don't intersect. A's average Z is less than B's, so libgs (libps) draws B first then A. But in reality B is supposed to hide part of A. You can subdivide A into two polys: Top view: Z distant / / / A1 ---------------B / / / / A2 Z near A1 sorts behind, A2 sorts in front, B sorts in the middle - problem solved. Unfortunately, you cann't pre-calculate this as it depends on which direction you're looking at. Rotate the model and what hides what changes, and the ordering of the Z overlapping polys changes. > Maybe it's feasible to sort polygons into groups such that each polygon in the > group sorts neatly, and each group also sorts neatly, and then use many > different OTs to sort and merge. In the limit (1 polygon per group), this is > BSP, which I have no doubt would be very slow, given that you have to go > through the ordering tables to draw polygons, but it might prove to be a > reasonable tradeoff for reasonably large groups of polygons. If you were going to BSP tree, you'd have to generate a TMD with multiple objects in it, one object for each 'safe' group of polys which can be classed as a 'polygon' for the purposes of the BSP. Sort each convex solid (safe polygroup object) into a seperate OT, then sort the OT's via the BSP tree.... > Has anyone considered alternatives to ordering tables? I know they're > reasonably fast, but they need a lot of memory to be accurate, and they're > always going to handle inconvex solids badly. You can reduce the amount of memory used and up the accuracy a bit by either using huge models, or using larger values for the shift value when sorting. You've just got to be careful your largest magnitude coordinate shifted left by N is less than 1< Toby. Craig.