16 bit MDL models?
Re: 16 bit MDL models?
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).
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
We knew the words, we knew the score, we knew what we were fighting for
Re: 16 bit MDL models?
Maybe, but i dont know much about the model stuff, especially MD3.
I think i just give up on this :/
I think i just give up on this :/
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: 16 bit MDL models?
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.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).
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: 16 bit MDL models?
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).
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?
They're definitely shorts: https://github.com/id-Software/Quake-II ... del.c#L357frag.machine wrote: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.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).
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
We knew the words, we knew the score, we knew what we were fighting for
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: 16 bit MDL models?
mh wrote:They're definitely shorts: https://github.com/id-Software/Quake-II ... del.c#L357frag.machine wrote: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.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).
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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: 16 bit MDL models?
Understood, yes.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.
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
We knew the words, we knew the score, we knew what we were fighting for
Re: 16 bit MDL models?
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 ...
feature (because i dont need all the MD3 features), somebody should write a tutorial ...
Re: 16 bit MDL models?
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?
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?
If it was sourced as an 8-bit model but just upconverted to 16-bit then it's still gonna have vertex wobble.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?
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
We knew the words, we knew the score, we knew what we were fighting for
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: 16 bit MDL models?
^^^ This.mh wrote:If it was sourced as an 8-bit model but just upconverted to 16-bit then it's still gonna have vertex wobble.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?
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)
Re: 16 bit MDL models?
who said its an "upscaled" model?
It IS a fresh model from blender, nothing upscaled :/
It IS a fresh model from blender, nothing upscaled :/
Re: 16 bit MDL models?
ok, as usual... thx for nothing..
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: 16 bit MDL models?
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)
-
- InsideQC Staff
- Posts: 1120
- Joined: Sat Oct 16, 2004 3:34 pm
Re: 16 bit MDL models?
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?
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?