Page 2 of 2
Posted: Mon May 10, 2010 6:55 pm
by mh
Sajt wrote:Probably. Anyway, I don't think that model works in even DarkPlaces. I did manage to figure out how to decode the skin. If you want the code I could post it. In any case, the code for FixMDL will go up on the QShed SVN one of these days.
The model that I thought you were going to look at was not nofix.mdl, but bomb.mdl. This model was run through QWalk, which resulted in some duplication of vertices (since QWalk doesn't support the old facesfront/onseam Quake texcoord system). I think QWalk must have recalculated the normals after that, which results in hard lighting seams along where the vertices were duplicated. But it looked fine in DarkPlaces for some reason.
The bomb.mdl link is gone to 404-land.
Any possibility of one normal facing inwards and another facing outwards for a vert that has been duplicated?
I've been looking over the DP MDL loader and render setup and think it's likely a case of DP doing better blending on the normals resulting in a smoother transition. It also uses proper normals rather than a precalculated dotproduct.
Posted: Mon May 10, 2010 7:14 pm
by Sajt
I believe the problem was simply that the normals were being calculated based on the split up edges, and it was happening in a "stair-step" pattern causing the edges of some of those "stairs" to go black. I suspect that DarkPlaces recalculates normals on load and even looks for co-locating vertices that aren't attached to the same triangle. Or something.
Here's a screenshot that sort of shows the funny stairstep:
http://www.icculus.org/~sajt/uglybomb.jpg
And here's bomb.mdl:
http://www.icculus.org/~sajt/bomb.mdl
Posted: Mon May 10, 2010 9:34 pm
by mh
Nice one, cheers. DP doesn't recalculate normals by the way, but it does use a lookup table containing the normal vector itself (rather than a precomputed DotProduct) and blends normal vectors at render time (rather than light * (dp1 * blend + dp2 * (1 - blend)).
It does remove duplicate verts at load, but so does DirectQ.
From the looks of the bomb in-game, the ugliness seems to occur on backfacing triangles. I think QWalk's loading code is good (it's almost the same as DirectQ's, but that's irrelevant), but I'm not too certain about that compress_normal function during the saving.
