Path: chuka.playstation.co.uk!news From: "Alex Herbert" Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: Efficient Object Modelling Date: Sun, 21 Feb 1999 13:12:50 -0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 73 Message-ID: <7ap14o$erp15@chuka.playstation.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> <36CFB94B.5DB79BDD@hinge.mistral.co.uk> NNTP-Posting-Host: th-usr02-57.ndirect.co.uk X-Newsreader: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sorry Craig, I think I misunderstood what you were originally saying. When I said that the normals had to be recalculated, I meant that the normal vectors would have to be re-rotated each time they are used within the model. I wasn't suggesting that the normal vectors would have to be re-built, as like you say, they are in the model data already. I was just pointing out how inefficient GsSortObject4() is in it's GTE usage. Thanks anyway, Herbs Craig Graham wrote in message <36CFB94B.5DB79BDD@hinge.mistral.co.uk>... >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 >