Re: To seam or not to seam...

mpolis@polbox.com.pl
Mon, 22 Apr 1996 20:35:55 +0200

From: mpolis@polbox.com.pl
Date: Mon, 22 Apr 1996 20:35:55 +0200
Message-Id: <199604221835.UAA17070@ uucp.polbox.com.pl>
To: quake-dev@gamers.org
Subject: Re: To seam or not to seam...

>>yes i thought this was in the quake specs...
> This is in the spec, indded. But that doesn't mean it's understandable for
> everyone :-) (like 50% of the .BSP description).
> Can someone take a look and propose a simpler explanation?

Well, as usually in such situations we figured it out ourselves :)
Here is a part of the source of our viewer:

if(texture[face->v1].onseam && !face->facefront)
{
tp[0].x = texture[face->v1].tx + txcor;
tp[0].y = texture[face->v1].ty;
} else
{
tp[0].x = texture[face->v1].tx;
tp[0].y = texture[face->v1].ty;
}

--------------------------------------------------------------------

>> The only difficult part is placing the texture on the object.
> And maybe generating the animation frames themselves...

Second thought is obvious, and first one is right. Working on
2D picture to wrap it around 3D object in the way Quake does it
is very difficult...

--------------------------------------------------------------------

>>there is no light info in the model files.
> I confirm. Once again, the wording of the specs (lightnormalindex)
> probably is just confusing. Someone has a better wording?

Hmmm... We are thinking if id isn't just going to fake lightining
on monsters. Using this normal we could make them Gouraud shaded,
but with so many restrictions, that we can for a sure forget
dynamic/various lights on the monsters... Guess we will have to
wait till another test release :)... Well, it's just 3 weeks till
E3.

--------------------------------------------------------------------

I new thing started to bug me. Michael Abrash said (on CGDC) that
they use z-buffer for monsters. In no way I can believe it. We used
quick-sort and there is almost no polygons glitching when displaying
monsters. They are very cleverly modelled, probably not from scratch
(we suspect they were build from thousands of polygons then some
kind of polygon-reduction process was run; all SGI programs have
such things and - otherwise than in 3D-Studio - they work fine). So
why taking so much memory and processing power for z-buffer, when
quick-sort or radix will be much better and have quality enough?...

Adrian Chmielarz
Metropolis