Path: chuka.playstation.co.uk!news From: Craig Graham Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: Efficient Object Modelling Date: Sun, 21 Feb 1999 07:44:11 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 47 Message-ID: <36CFB94B.5DB79BDD@hinge.mistral.co.uk> References: <7a3ea7$7op10@chuka.playstation.co.uk> <36CAFA60.C0A88FC8@ndirect.co.uk> <36CB3327.EC24F6C3@hinge.mistral.co.uk> <7amg16$erp2@chuka.playstation.co.uk> NNTP-Posting-Host: 195.184.231.50 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 Alex Herbert wrote: > Craig Graham wrote in message <36CB3327.EC24F6C3@hinge.mistral.co.uk>... > > > > > >Not quite - normals are pre-calculated and it's only a single matrix > multiply to > >rotate > >them (a bit quicker than doing a real product for the normal vector). > > Really? Then I appologise for the misinformation. > > So, are you saying that all normals in a model (whether used or not) are > pre-roated? Originally I had assumed that all verices were pre-calculated, Nope. Just that the actual vector of the normal is precalculated (see the TMD format for details), so you don't have to do the sum of products of the face vectors to get the normal vertex normal's as they're already in the file. And as this is fixed (unless you use RsdANIM to move vectors about within a model), the normal only has to be rotated to face the same way as the rest of the model (using the local to world matrix), libgs never actually has to calculate a normal vector at all, only rotate it. I think the reason they don't pre-calculate is so that they can generate POLY's into the TMD which use a subset of the vertices available to speed up display (I've got some code somewhere that segments a large world TMD into smaller TMD polygon sections which share a common vertex/normal pool allowing you to only display poly's which are physically close to you). > until someone pointed out that this can't be the case as GsSortObject4() > doesn't allow you to specify a temporary buffer address for storeage of the > rotated vertices. I just guessed that the same would have to apply to > normals. Can you explain? I don't think libgs does cache rotated vectors - it rotates them as they're used. If it did cache them, things would go a fair bit quicker, as in the Env mapper code I posted a while ago (where all rotated vertex normals are calculated once and the X/Y components area stored in the scratch pad so you don't re-calculate the same value for each face that uses it). > Herbs