#349 posted by JneeraZ on 2012/05/04 21:54:09
Interpolation?
Could Be
#350 posted by madfox on 2012/05/04 22:06:57
This example shows the effect, now the solution if there is.
http://members.home.nl/gimli/celbox.wmv
#351 posted by JneeraZ on 2012/05/04 22:10:05
That looks like interpolation. :) Try turning interpolation off in your Quake engine and see what it looks like.
#352 posted by necros on 2012/05/04 22:33:07
looks fine to me? what am i missing? it picks the box up and moves it over, then drops it again. also looks cool.
Lerping From Last Frame To First Frame
#353 posted by metlslime on 2012/05/04 22:41:11
i see it in the video. How to fix it depends on how this animation will be integrated into the level -- obviously right now you have one box vanishing an another magically appearing, so this isn't a complete thing yet.
#354 posted by necros on 2012/05/04 22:43:29
oh the playback must be broken as it freezes half way for me.
you could try adding two frames, one at the end of the sequence where the boxes shrinks into itself into a single point, and one at the start where it grows from a single point. this way, it would lerp the movement of an invisible single point.
it'll still look goofy because you'll see the box grow and shrink really fast though.
My Silly Perfectionist
#355 posted by madfox on 2012/05/04 22:58:29
The animation is a 30 frame static entity, that is a part of two combining conveyor belts.
In the middle there would be another one with an injector uploading the cellboxes.
For one animation the frames are too complicated so I make them in three parts.
The bad point is that I have to make them fit to eachother in place and time.
So the interpolation willem directed to is the cause. I tried to add interpolation 0 at the console but that's wrong ofcourse.
I keep hearing the word lerping.
In the gif file the last frame is the cellbox at the end.
There will be a counterpoint both boxes are on the same place, but I thought I could catch that by letting them drop down into a solid brush while they are moving backwards.
Frame Counts
#356 posted by madfox on 2012/05/08 08:42:10
I found the fitzhack version to temper my intention to make the interpolation for the static entity. I just didn't knew it was the engine that had this limit.
The animation rolls much more shaky, but fills in the exact rotation.
The original fitzquake rolls much smoother, but then I keep the hazy frameshades.
I think I keep on to original Fitzquake, as for now only the wheels get creepy.
http://members.home.nl/gimli/vey00.jpg
http://members.home.nl/gimli/vey01.jpg
Cellbox
#357 posted by madfox on 2012/05/08 08:48:52
Jack In The Box
#358 posted by madfox on 2012/05/11 08:14:53
It soon became clear to me that tuning two static entities is a real framejerk, so I combined them.
Reduced the interpolation effect of the conveybelt to the wheels, and then noticed the swing in the middle.
It had become a jolly cellbox.
In Qmle it won't show but in game it's hardly a count.
http://members.home.nl/gimli/conveyc.gif
http://youtu.be/OAi_Sj74BP4
#359 posted by necros on 2012/05/15 00:41:33
So is it 1000 verts, 2048 tris? I have a model with ~1700 verts loading just fine.
Verts
#360 posted by Preach on 2012/05/15 01:08:30
The limits for verts is 2000 almost everywhere, including dos/winquake. The original glquake binary had a reduced vertex limit of 1000, but the released glquake source had this limit restored to 2000. Consequently every source-port has a limit of at least 2000, and there's no reason at all to keep models at 1000.
#361 posted by necros on 2012/05/15 01:10:35
Ah ok, I got confused by the first post in this thread.
Btw...
#362 posted by necros on 2012/05/16 03:28:43
Just thought I'd mention this: preach's md3 converter is awesome. Thanks for making that thing. :)
In The Background
#363 posted by sock on 2012/05/16 19:30:01
I am sure most new content would never see the light of day without the various coder utilities that work away in the background. I am sure preach would love to see what you have been up to with his model converter! :P
Well...
#364 posted by Preach on 2012/05/16 22:05:20
I'm glad it's proving useful, and I'm sure you'll be glad to hear that the next generation of the md3 converter is almost half-done! By which I mean that I've written a module in python which loads and saves mdl format models. I'm just working on a few example models to go with it and then I'll put it out here.
Once that's done, all that remains is to clone the code, adapt it to load md3 files instead, then make the glue code for the conversion. The purpose of all this reinventing-the-wheel is that the glue code will hopefully be clear and easy to adapt, allowing for finer control of the md3 to mdl conversion. For example, if you're making a map object which needs to be aligned on the grid to meet the geometry in the map, you might want to specify the scale used in the conversion of the model coordinates.
Features
#365 posted by sock on 2012/05/16 22:32:19
I was wondering if you don't mind adding some more features:
* BMP skin support (8 bit) I can't get Photoshop to save in that wacky PCX format you use.
* Multiple skins (via the normal text file)
* Update special mdl keys (rotate etc)
* specify names and groups to animation sets (via the normal text file, a comma delimited list) It is awkward viewing stuff in Qme with just a huge list of numbers for frame names.
In Order
#366 posted by Preach on 2012/05/17 00:37:04
Yes
Yes
Yes and
Yes
The first one will come from using another python library. The pcx thing was largely chosen because I didn't want the md3tomdl source to have any dependencies on external code, and 8bit pcx was just easy enough to hand-parse. I'll make sure that the examples include some that use the library.
Multiple skins and proper group frames are things that are easy to manipulate with a script and the module that I have now. It's the kind of thing that you'd have to write a whole difficult-to-parse syntax in the "config file" method of the existing tool, so I hope the omission thus far is understandable.
As an example, to set the rotate flag on a model would require the following line added to the script:
����mymdl.flags = 8
If the requirement to know the numerical values of the flags is considered too taxing I might be persuaded to include them as constants!
Md3tomdl
#367 posted by sock on 2012/05/17 01:58:38
@preach, that would be awesome to have those features. It is the last things I use Qme for (multiple skins and model flags) and not having Qme in the pipeline will be awesome.
The config file flag of mymdl.flags is fine with me, is this parameter available in the current version?
I totally understand why the skin / animation names option is missing from the current version. Writing a config file parser is always time consuming.
Prerelease
#368 posted by Preach on 2012/05/17 09:56:50
There seems no point keeping the module back when it would already be useful to you, so here it is:
http://www.btinternet.com/~chapterhonour/qmdl.zip
Pop the qmdl folder in your python "Lib" folder. You can then put the following lines in a file called flag.py to add the flag to the mdl file md3tomdl produces.
��from qmdl.mdl import Mdl
��mymdl = Mdl()
��infile = open(r"input.mdl", "rb")
��mymdl.read(infile)
��infile.close()
��mymdl.flags = 8
��outfile = open(r"output.mdl", "wb")
��mymdl.write(outfile)
��outfile.close()
I'd suggest having a short batch file that calls md3tomdl followed by this python script.
Let me know how it works, I've tested with python 3.2, but if you have an earlier version installed it might still work...
Supplimental
#369 posted by Preach on 2012/05/17 10:39:13
Some helpful code for renaming frames:
def rename_range(frames, start, name, length):
����for i in range(length):
��������frames[i + start].name = (name + str(i + 1)).encode("ascii")
def rename_frames(mdl, names):
����i = 0
����for name in names:
��������rename_range(mdl.frames, i, *(name))
��������i += name[1]
rename_frames(mymdl, [("walk", 8), ("run", 6), ("stand", 9)])
Essentially you write a list of tuples, where each tuple is the sequence name and length.
Snakeless
#370 posted by sock on 2012/05/17 23:32:40
@Preach, unfortunately I don't have python installed, but I can wait, honestly there is no hurry. :) Plus I am busy creating new skins at the moment, so it will be a while before I am back to exporting models again.
#371 posted by necros on 2012/05/18 03:28:41
rawr
Sock's mesh, uv and skin and I rigged and posed it.
Thanks again for the converter, preach. Wouldn't have bothered with this stuff without it.
Another Angle
#372 posted by sock on 2012/05/18 03:45:57
Nice!
#373 posted by ijed on 2012/05/18 04:00:08
|