16 bit MDL models?

[mh]

I think this is more an issue with the code than it is with the format itself.

The actual Q3A source code doesn't compute normals at load-time, so it's just a LittleShort call.

At runtime it just does a lookup in tr.sinTable for the normal values.

Even if you really must decode normals at load-time, since it encodes them as shorts you could just make a short-to-float[3] lookup and get the values that way (or use the same tr.sinTable lookup that Q3A uses).

[drm_wayne]

Maybe, but i dont know much about the model stuff, especially MD3.
I think i just give up on this :/

[frag.machine]

[drm_wayne]

Well i searched google a few months ago and i found this:



But this doesnt seems to work (it outputs the normals to a file on the first load).

[mh]

[frag.machine]

[mh]

[drm_wayne]

My goal was just to get a better modelformat without wobbling for the viewmodels, i would be already happy with the MD16
feature (because i dont need all the MD3 features), somebody should write a tutorial ...

[drm_wayne]

The Quakeforge devs are not answering my mails so i started porting it myself.
Actually the model gets loaded, BUT it still looks like an 8 bit vertex model (it is indeed an MD16, correctly exported).
What do i need to pay to get this format?

[mh]

[frag.machine]

[drm_wayne]

who said its an "upscaled" model?
It IS a fresh model from blender, nothing upscaled :/

[drm_wayne]

ok, as usual... thx for nothing..

[frag.machine]

Well, sorry if we can't help you with an obscure, non-standard, undocumented model format supported only by one engine. Have you at least bothered to check the QuakeOne.com thread I found or directly the QuakeForge source or asked help to taniwha, who seems to know it better than all of us ?

[Dr. Shadowborg]

1. Screenshot or it didn't happen.

2. If you've loaded a model into blender from a quake .mdl, you're still going to have vertex swim. Period. Make sure that you've loaded your model from a less precision lossy format. If model has been made from scratch in blender, and stored in a non-lossy format, disregard.

3. If problem persists, try it in the quakeforge engine and see if it does the same there.

4. If problem is not present in quakeforge engine, then you've obviously done something wrong in porting. Note that this is a fairly complicated thing, loading extra data from the model file is one thing, getting the render to use all that extra data is another.

5. If problem appears in quakeforge engine...then perhaps the format is not yet ready for primetime, and you should look at other options?