Path: chuka.playstation.co.uk!news
From: "Alex Herbert" <aherbert@ndirect.co.uk>
Newsgroups: scee.yaroze.programming.3d_graphics
Subject: Re: Efficient Object Modelling
Date: Sat, 20 Feb 1999 14:08:47 -0000
Organization: PlayStation Net Yaroze (SCEE)
Lines: 32
Message-ID: <7amg16$erp2@chuka.playstation.co.uk>
References: <7a3ea7$7op10@chuka.playstation.co.uk> <36CAFA60.C0A88FC8@ndirect.co.uk> <36CB3327.EC24F6C3@hinge.mistral.co.uk>
NNTP-Posting-Host: th-usr02-02.ndirect.co.uk
X-Newsreader: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3


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,
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?

>and avoiding having polys that go
>partially off the top or left of the screen (the clip to top-left is pig
slow on
>GPU).
>


Ah, that's handy to know.  Thanks Craig.


Herbs