InsideQC Forums

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)

if this is going to end up as an MDL may I suggest you keep the polys down, it's going to get ugly when it starts moving.

what's the deal with the model "moving" anyways? why does it do it? when does it do it? can you prevent it?

Error wrote:can you prevent it?

Vertex precision is integer in MDL. You can only prevent it by not using MDL or MD2. MD3 doesn't do this as much (but it still does it if you zoom in like fov set to 1 to notice)

doesn't qme save additional crap for the model so this doesn't happen?

It can't be prevented in Quake 1, it's an engine thing. The MDL file format is precision limited. id sort of screwed the pooch there but it was their first shot at a 3D format so it's hard to really blame them.

Yep, the mdl format only saves a low precision vertex location, so it's like the vertices are snapped to a grid the whole time.

Willem wrote:id sort of screwed the pooch there.

it was done for performance. 486s, k5s and Cyrix suck at the floating point.

it was done for performance. 486s, k5s and Cyrix suck at the floating point.

Are you sure about that? Those verts are expanded to floating point once the MDL is loaded I believe. The integer stuff is only for disk storage AFAIK.

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).

I don't plan to animate this... would that help? I plan to use daemon's idea of animating it in game like he did on Feral

leileilol wrote:

Willem wrote:id sort of screwed the pooch there.

it was done for performance. 486s, k5s and Cyrix suck at the floating point.

I believe they were more concerned about disk space, since the verts are stored as byte but expanded to float when in memory.
EDIT: Actually, they are only expanded in rendering time, which makes sense if you're targeting a 8Mb RAM configuration.