Broken Models
#201 posted by sock on 2012/04/06 23:43:26
I can't believe how anyone has the patience to create models for Q1. I created a model and UV mapped in LW 9 (I like the interface and tools) and cannot get it into Q1.
Qme (3.0 & 3.1)
LWO import only takes mesh, totally ignores all UV data.
DXF import, mesh only but format does not support UV.
3DS import, mesh only. I can't get the UV data to be accepted. It could be the shitty exporter in LW but I did get the 3DS file imported back into LW (not really a good proof format is right) I tried importing the 3ds file into gmax and mesh only.
So I am totally stumped how anyone can get any UV stuff into Qme. The package and pipeline seem broken to me.
Any hints on how other people create models with Qme? Is this why preach wrote the md3 route ignoring qme?
#202 posted by necros on 2012/04/06 23:57:54
ah ok, so this was the process you were talking about in your mail. :)
first, qme cannot accept standard uvw data.
what you would need to do is to split the mesh up the same way it is split up in your uvw.
if you could export a dxf with uvw and import it into gmax, then use a gmax md3 exporter to export an md3 which you can then use preach's converter on, you could create a mdl file with the single frame BUT with your uvw mapping preserved.
after this, you could export the rest of the frames as lwos and IMPORT (not open) them into your existing model.
#203 posted by necros on 2012/04/07 00:03:25
sorry, first, i forgot dxf doesn't support uvw.
so you'd use 3ds format.
the above long process is only needed for the initial frame to set up the skin mapping.
once that's done, the rest will go in fairly easily. just write a script (lightwave can do this? i'm not sure, but i am assuming so since it's a high end 3d editing suite) to export all your frames as seperate lwo files.
the only danger is that during all the importing and exporting, the vertex order could get rearranged which will prevent you from importing the rest of the frames.
Finally
#204 posted by sock on 2012/04/07 00:07:13
I did it! I got my model from LW to Q1! Now I can plan getting all the bones and animation sorted.
LW 3DS exporter
Gmax Special 3DS importer (should be default)
Save in MD3 format (special plugin again)
Use preach md3tomdl
(can't get Photoshop to save in the right PCX skin format for preach tool, have to replace in Qme)
Open in QMe and it looks good :P
FINALLY!!! :D:D
Got several options for animations, DXF import into Qme or setup bones in Gmax not sure which at this point, will have to experiment. At least I can create all the meshes and UV stuff in LW.
Without Endorsement
#205 posted by Preach on 2012/04/07 00:23:42
I don't have lightwave so I can't test it but this claims to be a md3 export plugin for lightwave. This would let you skip the gmax stages of that process.
http://members.bellatlantic.net/~mbristol/md3/index.html
PS: if you export the skin from QMe you should be able to get it into the required 8 bit format for md3tomdl.
PPS: if you can cut QMe out of the process you get to keep nice vertex normals for your model!
Yeah
#206 posted by Kinn on 2012/04/07 00:33:28
PPS: if you can cut QMe out of the process you get to keep nice vertex normals for your model!
This is what was the final nail in the coffin for QME for me.
Burning Qme
#207 posted by sock on 2012/04/07 00:38:01
Cool idea on the skin PCX format, I don't need to touch the package anymore. :)
The downside of the 3DS format is that the UV verts have to be un-welded before export. Is there an easy way in gmax to weld all UV verts together?
Well
#208 posted by Preach on 2012/04/07 00:57:51
I think the best you can do is apply the unwrap uvw modifier, select all the vertices manually and click the weld selected button. It's probably automatable with the maxscript stuff but it's not that much work by hand. Don't forget that the vertices do often get separated in the final mdl file as well, so do check if welding is helping the final output.
Too Many Verts
#209 posted by sock on 2012/04/07 01:09:05
For some reason I have 1200 skin/frame verts in my model for something that started with @160 (used the standard ogre model as a test) Not sure why, maybe it is the export 3DS process not sure.
The LW->MD3 exporter plugin is too old, won't load in the current version. (typical for LW TBH) I did find a LW to MD3 external program converter but the documentation is gone (website link dead) Might experiment with it. The 3DS route seems to be causing problems.
#210 posted by necros on 2012/04/07 01:17:03
when you are exporting, make sure you only export the mesh, and not any bones, helpers or anything else.
bones (at least in max) count as mesh objects when exported in some formats.
Ouch
#211 posted by Preach on 2012/04/07 01:17:04
That is too many vertices, 1000 is the number you need to get models down to in order for them to load in glquake...
To check if you can fix it you may want to try a weld on the mesh vertices as well as the skin vertices in gmax. Obviously though if you can pin down what's splitting the vertices and avoid it that's best in the long run.
#212 posted by necros on 2012/04/07 01:19:16
actually yeah, thinking about it... that's sounds way too high for just bones/helpers. not sure what else it could be aside from what preach just said.
Fixed
#213 posted by sock on 2012/04/07 01:40:02
http://wiki.beyondunreal.com/Legacy:Lightwave/Exporting_3DS
"The reason is a limitation of the 3ds format not supporting discontinuous uv coordinants"
Just got to weld all the stuff together in GMAX and now I have a model with 402 verts and 410 triangles :D My very first ogre, just got to test it in game, sort out animations, write ogre script and fix the skin and .. way too many things to do!
#214 posted by necros on 2012/04/07 01:53:29
have you tried importing additional frames after that first one?
#215 posted by Spirit on 2012/04/07 11:35:01
#216 posted by necros on 2012/04/07 18:56:22
i still haven't had a chance to try that out.
#217 posted by sock on 2012/04/07 20:41:43
@necros, I was planning to animate the model with bones in gmax or maybe LW. This is something I have not done before and I am curious to see the process. I have not decided yet which route to take, I need to test which is easier. I tried a couple of frame imports with Qme and the mesh was all warped. I really want to avoid using Qme at all because of the vertex problems.
#218 posted by necros on 2012/04/07 21:22:02
the nice thing about doing a model for quake is that when you animate it, you can use absolutely ANYTHING you want.
from basic IK to crazy scripted constraints/controllers.
you can use any modifiers that don't change vertex# or order (ie: you couldn't use boolean operations).
but you can use morphs (scripted morphs!), lookats, you can follow a specific vertex, etc...
or you can just use biped and get everything you need for normal animation and add onto that.
Shame Is...
#219 posted by than on 2012/04/08 01:56:08
that after you import it into Q1 all the animation will be at 10fps and the vertices will be wobbling all over the place due to them being rounded to fixed point numbers, so even if you have plenty of flexibility, it doesn't exactly allow you to go to town :)
#220 posted by necros on 2012/04/08 03:10:13
sure, but my point wasn't that you'd be making better looking animations than a AAA title, only that animating it is not a painful process at all (and, i find, quite fun).
Frame Rate
#221 posted by Preach on 2012/04/08 03:21:38
There's no reason you have to keep animations at 10fps.
Well, there are a few things you have to consider. First is that 256 frames gives you 25 seconds of animation at 10fps. Can you get an entire monster into 12 seconds of animation? Perhaps the thing to do would be to keep slow movements like standing animations at low fps and keep the higher rates for the big/fast things.
Secondly there's the QC support. There's a special instruction built into the QC instruction set for 10fps animation, with special notation and all. So to step outside that confers a minor performance penalty (though clearly it was significant in 1996) along with more verbose, messy code.
Finally I'd worry about how interpolation is handled in all the engines out there. I know that fitzquake takes a lot of care to interpolate well in a variety of situations and ought to handle high fps, but I don't know that all engines do.
Still, I'd like to see someone try!
#222 posted by necros on 2012/04/08 03:55:11
you must also halve .yaw_speed because movetogoal will be called twice as fast and so turn twice as fast.
256 Frame Limit
#223 posted by Kinn on 2012/04/09 00:18:02
probably not a huge issue if you don't mind splitting your anims over multiple models if you need more frames, and swapping the models when appropriate.
On a related note it usually makes sense to spread anims over different models if the creature varies size substantially - i've seen models where the vertex accuracy is totally trashed because of just a few frames where the dimensions of the model is large compared to the rest of the frames - moving these "large frames" into a seperate .mdl would have fixed that. The super-hell-knight thing from Nehahra is an example of how not to do it, and ironically the "large frames" that fucked the vert accuracy over in that weren't even used in the end - they were removed from the model after it had been converted to .mdl >_<
#224 posted by necros on 2012/04/09 00:23:56
yeah, that really pissed me off. :P
but tbh, i never considered splitting different bounds of a mdl into seperate files. that's a pretty good idea.
Good Point...
#225 posted by metlslime on 2012/04/09 05:12:19
I should have done that with my large and small banners in rubicon 2...
|