16 bit MDL models?

Discuss programming topics for the various GPL'd game engine sources.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: 16 bit MDL models?

Post 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).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: 16 bit MDL models?

Post by drm_wayne »

Maybe, but i dont know much about the model stuff, especially MD3.
I think i just give up on this :/
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: 16 bit MDL models?

Post 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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: 16 bit MDL models?

Post 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).
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: 16 bit MDL models?

Post 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
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: 16 bit MDL models?

Post 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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: 16 bit MDL models?

Post 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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: 16 bit MDL models?

Post 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 :P ...
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: 16 bit MDL models?

Post 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? :cry:
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: 16 bit MDL models?

Post 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? :cry:
If it was sourced as an 8-bit model but just upconverted to 16-bit then it's still gonna have vertex wobble.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: 16 bit MDL models?

Post 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? :cry:
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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: 16 bit MDL models?

Post by drm_wayne »

who said its an "upscaled" model?
It IS a fresh model from blender, nothing upscaled :/
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: 16 bit MDL models?

Post by drm_wayne »

ok, as usual... thx for nothing.. :(
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: 16 bit MDL models?

Post 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 ?
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
Dr. Shadowborg
InsideQC Staff
Posts: 1120
Joined: Sat Oct 16, 2004 3:34 pm

Re: 16 bit MDL models?

Post 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?
Post Reply