Page 2 of 3
Re: 16 bit MDL models?
Posted: Mon Jun 29, 2015 3:19 pm
by 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).
Re: 16 bit MDL models?
Posted: Tue Jun 30, 2015 2:28 pm
by drm_wayne
Maybe, but i dont know much about the model stuff, especially MD3.
I think i just give up on this :/
Re: 16 bit MDL models?
Posted: Tue Jun 30, 2015 5:22 pm
by frag.machine
mh wrote: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).
From what I read, things are a bit simpler: normals are stored as bytes, so lookup tables to replace atan2() and acos() calls would be really inexpensive, even in constrained platforms.
Re: 16 bit MDL models?
Posted: Tue Jun 30, 2015 5:32 pm
by drm_wayne
Well i searched google a few months ago and i found this:
http://pastebin.com/s42Ku6KX
But this doesnt seems to work (it outputs the normals to a file on the first load).
Re: 16 bit MDL models?
Posted: Tue Jun 30, 2015 8:14 pm
by mh
frag.machine wrote:mh wrote: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).
From what I read, things are a bit simpler: normals are stored as bytes, so lookup tables to replace atan2() and acos() calls would be really inexpensive, even in constrained platforms.
They're definitely shorts:
https://github.com/id-Software/Quake-II ... del.c#L357
But runtime decoding does use a lookup:
https://github.com/id-Software/Quake-II ... ace.c#L701
Re: 16 bit MDL models?
Posted: Tue Jun 30, 2015 9:41 pm
by frag.machine
mh wrote:frag.machine wrote:mh wrote: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).
From what I read, things are a bit simpler: normals are stored as bytes, so lookup tables to replace atan2() and acos() calls would be really inexpensive, even in constrained platforms.
They're definitely shorts:
https://github.com/id-Software/Quake-II ... del.c#L357
But runtime decoding does use a lookup:
https://github.com/id-Software/Quake-II ... ace.c#L701
Sorry, I should've expressed myself in a more clear way. They are indeed stored as shorts, but actually holding 2 components (latitude, longitude) according to this:
Code: Select all
The encoded normal vector uses a spherical coordinate system. Since the normal vector is, by definition, a length of one, only the angles need to be recorded. Each angle is constrained within [0, 255], so as to fit in one octet. A normal vector encodes into 16 bits.
Therefore, a lookup table of 256 floats (assuming no fancy translation tricks applied to reduce even more the used memory) ought be enough.
Re: 16 bit MDL models?
Posted: Wed Jul 01, 2015 8:02 am
by mh
frag.machine wrote:Therefore, a lookup table of 256 floats (assuming no fancy translation tricks applied to reduce even more the used memory) ought be enough.
Understood, yes.
You'd still have to do some extra load-time or run-time computations in exchange for the memory saving though, but they should be fast enough (no trig). If it was me I'd burn the extra memory and go for a lookup of 65536 vec3_t, but on balance it's worth profiling both.
Re: 16 bit MDL models?
Posted: Wed Jul 01, 2015 3:06 pm
by 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
...
Re: 16 bit MDL models?
Posted: Thu Jul 02, 2015 1:17 pm
by 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?
Re: 16 bit MDL models?
Posted: Thu Jul 02, 2015 2:14 pm
by mh
drm_wayne wrote: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?
If it was sourced as an 8-bit model but just upconverted to 16-bit then it's still gonna have vertex wobble.
Re: 16 bit MDL models?
Posted: Thu Jul 02, 2015 9:24 pm
by frag.machine
mh wrote:drm_wayne wrote: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?
If it was sourced as an 8-bit model but just upconverted to 16-bit then it's still gonna have vertex wobble.
^^^ This.
Try creating a new model on Blender from scratch and then exporting directly to MD16.
Re: 16 bit MDL models?
Posted: Fri Jul 03, 2015 5:14 am
by drm_wayne
who said its an "upscaled" model?
It IS a fresh model from blender, nothing upscaled :/
Re: 16 bit MDL models?
Posted: Sun Jul 12, 2015 6:24 am
by drm_wayne
ok, as usual... thx for nothing..
Re: 16 bit MDL models?
Posted: Sun Jul 12, 2015 6:21 pm
by 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 ?
Re: 16 bit MDL models?
Posted: Sun Jul 12, 2015 8:07 pm
by 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?