Path: chuka.playstation.co.uk!news From: Alex Herbert Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: What's up with fog? Date: Mon, 03 Aug 1998 19:14:58 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 38 Message-ID: <35C5FE22.C5A8645E@ndirect.co.uk> References: <35C2BFAD.5EF8@funnytown.com> <35C59A49.5164@mdx.ac.uk> Reply-To: aherbert@ndirect.co.uk NNTP-Posting-Host: dialin2-02.ndirect.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 [en] (Win95; I) Robert Swan wrote: > Fogging is a bit dodgy, and as (from memory) I dont think you can spread > the fogging out by subdividing a polygon (which makes sense as light > calculations are only carried out once per polygon, regardless of > subdivision and I assume the fogging component of light on a poly is > calculated then). Yep, sounds right. I started making a tiled floor out of flat shaded quads, and the "stepping" of intensity was quite visible. I changed the quads to Gouraud shading (using the same normal for each corner), switched the dithering on and now the fogging is silky smooth. Although I had shared the normals (so GsSortObject4 didn't have to rotate any more data), I was still surprised that there was little impact on the processing time. Ok, so the GPU has to do more work this way, but my code was overrunning the GPU anyway, so no problem. > What you can do is mess around with the fogging > attenuation coefficients (dqa and dqb). In the manual it doesn't really > imply that you can mess around with dqb, which affects the 'spread' of > the fogging. This leads onto several points - > > 1) make your polygons smaller, so that there are more steps of colours > 2) mess around with dqb (1.25 * 4096 * 4096 is given in manual). Try 1.0 > * 4096 * 4096 or 1.5 * 4096 * 4096 (cant remember which one) and you > should find you can smooth out the fogging > Hmm, I was puzzled by dqb and how to set it right. In my code I set it as (5*4096*4096)/4, but then I noticed that in the CW Dino code it was set up as (5/4)*4096*4096. Should give the same result, but because of the integer maths of CW, (5/4) = 1. So, I have a question. Does the GNU compiler equate that expression correctly? Will this lead to more incompatibility between CW and GNU? Herbs