"Tom Plunket" <gamedev@[EMAIL PROTECTED]
> wrote in message
news:vih9d3hjn6nqg4anb9g3590iqqvbujpbim@[EMAIL PROTECTED]
> Jim Langston wrote:
>
>> > Isn't Z typically defined as the dotproduct between the view
direction
>> > and the difference between the point-in-space and the POV? (Not a
>> > graphics guy, but that's my naive understanding.)
>>
>> When you state a z coordinate, it is fairly im****tant to express if you
>> mean
>> before translation, or after. From your questions, it seems you mean
>> after.
>
> Heh, ok, yeah I thought we were talking post-transformation, since the
> OP was asking about what to do with vertices behind the camera.
>
>> >> For most programs (such as games) there should never be a large
enough
>> >> triangle close enough to the clipping plane to have to shear.
>> >
>> > I'd think this really depends on the application, unless you're
>> > suggesting that "close" polygons should be tesselated as a matter of
>> > course? I know on the PS1 games I worked on, the balance between the
>> > memory a model took and how small we could make the polygons meant
that
>> > ground polys would shear (if I understand the definition correctly)
all
>> > over the place since the PolySize:CameraHeight ratio was very large.
>>
>> Well, I mentioned games specifically because in games it is program
logic
>> that dictates your POV. A proper game will not allow your POV to move
>> somewhere where shearing could take place. A game with bugs/poorly
>> written
>> program may allow it, where artifacts can take place.
>
> Should Be Land, I'd say. Actual Games have constraints beyond being
> Properly Engineered, and shearing polygons is not necessarily a "program
> bug" if the act of scissoring pushes you over your frame time. :)
As long as the program recognizes that the POV may move into an object and
do something about it, whatever it is. I've always found games where you
can look outside the world (POV inside the side of a mountain) as not
properly adressing the situation.
|
