Path: chuka.playstation.co.uk!news From: Andreas Schrattenecker <"Andreas Schrattenecker"> Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: HELP:small planar quads Date: Wed, 14 Jan 1998 17:49:23 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 264 Message-ID: <34BCEC93.4581@jk.uni-linz.ac.at> References: <69ilnb$c4e1@emeka.playstation.co.uk> Reply-To: andreas.schrattenecker@jk.uni-linz.ac.at NNTP-Posting-Host: ried-remote07.ivnet.co.at Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 [de] (OS/2; I) Lewis_Evans@Playstation.sony.com wrote: > > From: Lewis_Evans@Playstation.sony.com > To: news@playstation.co.uk > > Firstly, is your problem with planar or non-planar quads? The latter type > are never going to consistently > work properly, unless you employ some serious trickery. > small planar quads dont work, and there is a lot trickery for non-planar quads > If it's about planar quads, it sounds like you're saying that they're not > being displayed when they should be. yes > There are many possibilities here: > > (1) check the total number of things that you register into your ordering > table each frame; > sprites, GsBOXFs, TMDs (for each, sum the polys), created polygons, etc. > Make certain that the > PACKET area is large enough for this: > > #define MAX_SIZEOF_PRIMITIVE 24 > #define MAX_PRIMITIVES 2048 > > PACKET packetArea[2][MAX_PRIMITIVES * MAX_SIZEOF_PRIMITIVE]; no such error. i have tested last with a tmd, generated with rsdlink (not own created tmd) to ensure there is no error in my tmd-generation, and took tut0 from NetYaroze Solution Code. the tmd file rsdlink created contained only 2 quads( to ensure there is no memory problem with packetArea. tmd contained one quad near viewpoint one far away (although not so far away z ca 5000). same problem -> no coding error (i am sure) > > (2) check that there's no fogging involved; GsSetLightMode(0) will ensure > this. > > (3) make the ambient lighting bright, eg GsSetAmbient (4*ONE, 4*ONE, > 4*ONE); > i now use Textured,Gradation quads with own precalculated lighting -> no fogging(gradation), no lighting error (because used also all vertices-colors set to 255 -> same error. > (4) point number 4 on your list below seems to suggest that the order of > vertices might be involved. > Whether a poly is displayed or not depends, not on the > normal-to-camera-vector angle, > but on the order of vertices on screen; when looking at polygon head on, > where it should be visible, > the order of vertices should be top left, top right, bottom left, bottom > right. > However, this may not be it, since you only get it with small polys. same errors with rsdlink -> no vertices-ordering problem also tested all possibilities of ordering > > (5) at some point of being far away, the polys will disappear, due to sheer > perspective; > ensure that you can move the camera fluidly at runtime, to make sure this > isn't the cause of it. dont really understand this (my bad english, or simply dont understand this) but i can move camera fluidly -> small polygongs appear and disappear depending on camera position and viewvector-direction. It seems that quads have problems when: after world-screen-transformation and after perspective conversion, calculated "screen-2d-polys" are only 1 pixel high ,or vertices fall together -> then there is no packet generated. lastly used folowing .ply to test @PLY940102 # 8 1 2 # 0 0 1280 256 0 1280 0 0 1536 256 0 1536 0 0 5120 256 0 5120 0 0 5376 256 0 5376 # 0 -1.0 0 # 1 2 3 0 1 0 0 0 0 1 6 7 4 5 0 0 0 0 > > If none of this works, consider the fact that drawing 2 triangles is > only 15-20% slower than > drawing one quad; this would be a temporary workaround, enabling you to > carry on working on > other things, while we and other members try to sort out the problem. > triangles need lot of GTE time blocking cpu, and i need cpu time. i have seen ca 60% performance-increase with quads. Aktually i go on with the calculate-problem-areas-and-pull-vertices-down trick -> is faster. Thank you alot for looking at this problem Andreas Schrattenecker Lewis_Evans@Playstation.sony.com wrote: > > From: Lewis_Evans@Playstation.sony.com > To: news@playstation.co.uk > > Firstly, is your problem with planar or non-planar quads? The latter type > are never going to consistently > work properly, unless you employ some serious trickery. > small planar quads dont work, and there is a lot trickery for non-planar quads > If it's about planar quads, it sounds like you're saying that they're not > being displayed when they should be. yes > There are many possibilities here: > > (1) check the total number of things that you register into your ordering > table each frame; > sprites, GsBOXFs, TMDs (for each, sum the polys), created polygons, etc. > Make certain that the > PACKET area is large enough for this: > > #define MAX_SIZEOF_PRIMITIVE 24 > #define MAX_PRIMITIVES 2048 > > PACKET packetArea[2][MAX_PRIMITIVES * MAX_SIZEOF_PRIMITIVE]; no such error. i have tested last with a tmd, generated with rsdlink (not own created tmd) to ensure there is no error in my tmd-generation, and took tut0 from NetYaroze Solution Code. the tmd file rsdlink created contained only 2 quads( to ensure there is no memory problem with packetArea. tmd contained one quad near viewpoint one far away (although not so far away z ca 5000). same problem -> no coding error (i am sure) > > (2) check that there's no fogging involved; GsSetLightMode(0) will ensure > this. > > (3) make the ambient lighting bright, eg GsSetAmbient (4*ONE, 4*ONE, > 4*ONE); > i now use Textured,Gradation quads with own precalculated lighting -> no fogging(gradation), no lighting error (because used also all vertices-colors set to 255 -> same error. > (4) point number 4 on your list below seems to suggest that the order of > vertices might be involved. > Whether a poly is displayed or not depends, not on the > normal-to-camera-vector angle, > but on the order of vertices on screen; when looking at polygon head on, > where it should be visible, > the order of vertices should be top left, top right, bottom left, bottom > right. > However, this may not be it, since you only get it with small polys. same errors with rsdlink -> no vertices-ordering problem also tested all possibilities of ordering > > (5) at some point of being far away, the polys will disappear, due to sheer > perspective; > ensure that you can move the camera fluidly at runtime, to make sure this > isn't the cause of it. dont really understand this (my bad english, or simply dont understand this) but i can move camera fluidly -> small polygongs appear and disappear depending on camera position and viewvector-direction. It seems that quads have problems when: after world-screen-transformation and after perspective conversion, calculated "screen-2d-polys" are only 1 pixel high ,or vertices fall together -> then there is no packet generated. lastly used folowing .ply to test @PLY940102 # 8 1 2 # 0 0 1280 256 0 1280 0 0 1536 256 0 1536 0 0 5120 256 0 5120 0 0 5376 256 0 5376 # 0 -1.0 0 # 1 2 3 0 1 0 0 0 0 1 6 7 4 5 0 0 0 0 > > If none of this works, consider the fact that drawing 2 triangles is > only 15-20% slower than > drawing one quad; this would be a temporary workaround, enabling you to > carry on working on > other things, while we and other members try to sort out the problem. > triangles need lot of GTE time blocking cpu, and i need cpu time. i have seen ca 60% performance-increase with quads. Aktually i go on with the calculate-problem-areas-and-pull-vertices-down trick -> is faster (but also slow). Thank you alot for looking at this problem Andreas Schrattenecker