Path: chuka.playstation.co.uk!chuka.playstation.co.uk!chuka.playstation.co.uk!not-for-mail From: Lewis_Evans@Playstation.sony.com Newsgroups: scee.yaroze.programming.3d_graphics Subject: HELP:small planar quads Date: 14 Jan 1998 15:30:51 -0000 Organization: Sony Computer Entertainment Europe - 119.SS5 Lines: 121 Sender: news@chuka.playstation.co.uk Message-ID: <69ilnb$c4e1@emeka.playstation.co.uk> Reply-To: Lewis_Evans@Playstation.sony.com NNTP-Posting-Host: emeka.playstation.co.uk 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. If it's about planar quads, it sounds like you're saying that they're not being displayed when they should be. 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]; (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); (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. (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. 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. Lewis To: Lewis Evans cc: From: news @ playstation.co.uk Subject: HELP:small planar quads:scee.yaroze.programming.3d_graphics From: Andreas Schrattenecker Newsgroups: scee.yaroze.programming.3d_graphics Subject: HELP:small planar quads Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have following BIG problem: Aktualy my scene only contains quads, for performance reasons. I worked really hard to find a technique for non-planar(vertices dont lie on same plane) quads, without missing polygons (quads normally have to be planar). And it works!, but: there are missing planar-quads, which _have_to_ work. What i have found out is: 1) This happens if quads get small a: they are far away b: the angle between view-vector and quads gets small 2) No GPU-error -> for missing quads no packets are created. 3) It seems not to be a "to-screen-transformation-error" because if increasing projection distance->quads gets bigger->problem disappears. Perspective conversion is after transformation -> no transformation error. 4) if 1) there are quads displayed although they should be hidden (also if negative angle between viewvector and quad gets really big) in the same areas where quads disappear (when i change angle) ???? 5) useing frontfaced and backfaced quads -> also errors (would anyway not be a solution-> to slow) 6) triangles are displayed correct (no solution -> to slow, and i would have wasted lots of time for looking on quads). 7) happens with all types of quads: textured,non textured, gouraud, gradation (i am not sure for flat-quads now) 8) errors change when define vertices-order different -> but no way to define without errors. 9) The only solution i have found is to pull(in realtime) vertices in a direction that angle gets bigger or quad gets bigger. Possibly missing quads are simply overpainten -> but needs also much time. I really like the playstation-architecture (also GsLib) a lot. And it is possible to write quality-games also with GsLib which can compete with n64-games. I have now implemented an improved uniform mipmapping, which is also faster than non-mipmaping (smaller textures when polys gets smaller) and my polygon-count is ca. at 2500 displayed-triangles with 64x64 textures near viewpoint. I really try hard to make a high quality game on Net Yaroze, but this Library-bug makes me crazy. I have worked ca 500 h (without exaggeration) to solve this problem, but now i NEED HELP. It would be fine if someone could help me with this problem, or if Sony could bring out patches for GsLib to solve such bugs. Andreas Schrattenecker