Warglaive of Azzinoth
Warglaive of Azzinoth
I haven't modeled for a long time, so bare with me here. I chose my favorite weapon from World of Warcraft as a model to get me prepared for bigger better things.
Here's what the ingame weapon looks like from WoW:
And here's mine so far (don't really wanna show the wireframe cause it's a lot of polys for a weapon )
(pretty sure I just gave myself Carpal Tunnel Syndrome by making this much so far)
Here's what the ingame weapon looks like from WoW:
And here's mine so far (don't really wanna show the wireframe cause it's a lot of polys for a weapon )
(pretty sure I just gave myself Carpal Tunnel Syndrome by making this much so far)
The worst part is that as you move the out-lying verts, you change the scale of the grid, so move one vert and you move them all!
But yeah, the verts are stored as 8bit on disk and in memory.
Personally I think its more to do with memory usage on an 8mb computer.
md2 has the same fault, but there the grid is sized per-frame instead of per-model, so move an outlying vert and all the unmoving ones in the middle start swimming around as the model animates.
Basically, the larger the mins/maxs coords of your model, the less accurate the vertex coords will be.
So if you start swinging it around the player's head, those notches will eventually end up looking very ugly, at least up close. You can't easily use fine detail.
Aproximations will vary as the model moves around within its grid.
md3 uses 16bit coords with fixed 1/64th precision (although q3 uses a matrix for positioning clientside, so with the q3 cgame you can rescale it if 1/64th is too awkward, but obviously needs special code to do so as that's not part of the format).
But yeah, the verts are stored as 8bit on disk and in memory.
Personally I think its more to do with memory usage on an 8mb computer.
md2 has the same fault, but there the grid is sized per-frame instead of per-model, so move an outlying vert and all the unmoving ones in the middle start swimming around as the model animates.
Basically, the larger the mins/maxs coords of your model, the less accurate the vertex coords will be.
So if you start swinging it around the player's head, those notches will eventually end up looking very ugly, at least up close. You can't easily use fine detail.
Aproximations will vary as the model moves around within its grid.
md3 uses 16bit coords with fixed 1/64th precision (although q3 uses a matrix for positioning clientside, so with the q3 cgame you can rescale it if 1/64th is too awkward, but obviously needs special code to do so as that's not part of the format).
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
I believe they were more concerned about disk space, since the verts are stored as byte but expanded to float when in memory.leileilol wrote:it was done for performance. 486s, k5s and Cyrix suck at the floating point.Willem wrote:id sort of screwed the pooch there.
EDIT: Actually, they are only expanded in rendering time, which makes sense if you're targeting a 8Mb RAM configuration.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)