#207 posted by JneeraZ on 2009/01/27 21:08:07
"You must at least make sure that you don't alter the order in which the frames occur without giving the user control over it. The actual names given to the frames in the .mdl aren't used by the engine/qc. It relies entirely on the enumeration of them in the order that they occur. "
Beautiful. OK, that settles that then! Thanks.
Hmm
#208 posted by nonentity on 2009/01/28 07:38:41
Hey coding thread.
Very sorry about this, never post in here since I'm not a coder, so tend to skim read and leave you guys to your scary quote text fun ;p
Just wanted to bump stuff above the flame thread again (I suggest anyone else reading this does same and avoids bumping again pls ;)
Kiss
MDL Hell...
#209 posted by JneeraZ on 2009/02/05 14:08:57
Man, this file format is fairly jacked up.
Anyway... Quick question:
Is the "onseam" stuff entirely necessary for texture coordinates or is that some sort of concession that was made to allow for easy skin creation back in the day? If I store all texture coordinates as full 0-1 values and set onseam to zero for them all, will Quake throw a fit?
Onseam Bowling
#210 posted by Preach on 2009/02/05 17:39:00
When making new skins, it's no longer really necessary. If you're trying to do anything more complicated that 2-sided planar then you pretty much have to ignore it, and just eat the extra vertices on the model. The md3tomdl converter does exactly this.
However, it's very important that you keep them for existing models, as it tells you which vertices need to be duplicated on the skin. I think if your program didn't preserve the original quake models like that, people would get confused to say the least.
If you changed models to duplicate vertices which were onseam, and then removed the onseam flag, there could problems in other editors. For example, if you saved one like that, then loaded it and saved it with QMe, then the vertex normals along the seams would be altered compared to the original, which might make the seam more obvious.
#211 posted by JneeraZ on 2009/02/05 18:18:16
Wow, so the whole purpose behind it was to save a vert or three in the mdl file?
Hmm
#212 posted by nonentity on 2009/02/05 18:21:39
Bear in mind we're talking the first full 3D fps here.
What we now view as insane levels of optimisation was fairly necessary back then...
#213 posted by JneeraZ on 2009/02/05 18:25:21
I question some of the stuff, actually. Carmack did some crazy machinations in places to save very minimal amounts of space.
Ijed
#214 posted by gb on 2009/02/05 19:13:49
We need to think about skin animations. Blinking lights on enforcers are neat, and I have a couple other cases where this could be useful.
Apart from that. Do the additional mouth/face textures often seen on id skins have something to do with this?
Were they meant for animation purposes?
#215 posted by JneeraZ on 2009/02/05 19:17:13
I think those are for the head gibs.
Gib Faces
Would be a perfect addition for death skins (if they get implemented somewhere)
Maybe
#217 posted by Preach on 2009/02/05 20:00:32
I'd guess the whole onseam system was created because at the time it seemed like an unintuitive system to have vertices occupying the same position in the model, but connected to different triangles - when they are supposed to be part of the same surface in the model. The onseam method was a fix to the problem "how do I display the same vertex in two places on the skin?". It's just unfortunate that the solution pretty much ties you to the front/back skins that quake used.
Although I usually advocate the detached vertex solution, detaching things like that can cause problems. For example when calculating the vertex normals at that vertex, you probably want to average all the surfaces meeting at the split vertices, and give that same vector to all the vertices. This is a lot harder to do once you've split the vertices. In fact, if an unrelated vertex just happens to collide then you're scuppered...
Thankfully, .mdl uses precomputed vertex normals, so as long as you're converting from a format that supports merged vertices with split UVs then you can probably get sensible smoothing groups. Also, worrying about smoothing groups isn't the most pressing concern with quake models.
Interestingly enough, I don't know that onseam actually saves memory over all, when you consider how much wasted texture space there is as a result of using it. On models with lots of frames it's probably beneficial as the extra vertices would be recorded on all those frames. But for weapon models and other simple models, onseam probably doesn't make up for the waste.
#218 posted by gb on 2009/02/05 20:19:43
I think headgibs use their own models, which use their own skins.
I'm Aware Of That
How difficult would it be to copypaste the faces from the head gib skins onto body skins? (I'm no modeller so I can't tell)
Yeah
#220 posted by ijed on 2009/02/06 00:14:34
I want blinking lights for the enforcers, that was a good suggestion, whoever made it.
It looks from the models that the head gib was originally going to come from inside the main model, but it didn't work out.
Simple as export c+p import to put the pain head onto the normal guy for a dead skin.
#221 posted by gb on 2009/02/06 00:24:48
I was replying to Willem about the additional face parts etc. on id1 skins. Those are pretty weird.
So Was I
#222 posted by ijed on 2009/02/06 02:03:42
It seems the extra faces are there because the head and model were originally going to be combined, until they realised that hiding the entire body inside a copied head would be more wasteful.
Just Think....
#223 posted by metlslime on 2009/02/06 05:09:37
how awesome it would look if they did hide the body inside the head gib, now that we have engines that do model interpolation?
Vampires!
#224 posted by Preach on 2009/02/06 10:07:26
Back in the day before I worked on mods that people would play, I made a quake mod where you fought vampires - aping Buffy and that kind of thing. One of the driving things behind it was to make the death sequences look cool (by quake standards), so when you staked a vampire through the heart they'd look agonised for a beat, then explode into a puff of dust.
Coming back towards relevance, when you killed them with fire the flames burnt upwards from their feet while their arms flailed. In order to make their legs disappear, the polygons were just folded up into the upper legs, then the torso, with the flame graphic concealing the interpolation which arose. I imagine the final effect is not too dissimilar to what metl's thinking of.
(ps: the head gibs are probably separate for the more mundane reason of giving them a blood trail, which is a per model effect...)
Railgun In Quake
#225 posted by spy on 2009/02/06 10:43:02
is it possible?
i'd appreciate any help
#226 posted by Spirit on 2009/02/06 12:20:07
Sure, there were some mods with railguns I think.
Ahem
#227 posted by Spirit on 2009/02/06 12:21:03
And I just remembered I once successfully completed this tutorial: http://www.inside3d.com/showtutorial.php?id=167
#228 posted by Trinca on 2009/02/06 12:28:32
Spy Parboil once change the qwprogs.dat to railmod i think... since u are russian is easy to ask in is forum :)
http://parboil.quakeworld.ru
#229 posted by Trinca on 2009/02/06 12:47:58
zomggg are you the spy from the old Parboil board?
hehe
Quakec Question...
#230 posted by metlslime on 2009/02/06 12:57:59
what is the proper way to make an entity toggle between visible/solid and invisible/nonsolid?
So far, what i have tried is calling self.modelindex = 0, self.solid= SOLID_NOT to make it invisible, then doing SetModel(self, self.model), self.solid=SOLID_BBOX again to make it visible.
Visually, it works. But, once it's been invisible, it can never turn solid again.
So, is there a better way?
Trinca
#231 posted by spy on 2009/02/06 13:18:01
what are you talking about?
psssst. trinca don't tell anybody that i'm russian it's a secret :))
p.s. thanks spirit for the link.......
|