|
Only Way
#8252 posted by necros on 2009/01/31 23:28:23
is to set:
'wait' '-1'
'toggle' '1'
and manually retrigger to close after opening.
#8253 posted by metlslime on 2009/02/01 02:45:57
isn't there a "crusher" flag that prevents doors from reopening on impact?
Not For Normal Quake?
#8254 posted by necros on 2009/02/01 02:52:31
#8255 posted by negke on 2009/02/01 10:00:06
The crusher flag is called "dmg" and should prevent the door from reopening if the value is high enough. And if not, give both doors the same "team" field.
#8256 posted by JneeraZ on 2009/02/01 12:00:36
The "team" field didn't seem to work. The "dmg" is set at 10,000 so that should be high enough.
I dunno, I added a new spawnflag (SF_CRUSHER) and added a quick IF condition to the "door_blocked" function. That seemed to do it.
Crusherflag
#8257 posted by Preach on 2009/02/01 15:01:35
Necros had it right first time about the crushing behaviour, it comes from setting wait to a negative number. Quoth the source(door_blocked):
// if a door has a negative wait, it would never come back if blocked,
// so let it just squash the object to death real fast
if (self.wait >= 0)
{
if (self.state == STATE_DOWN)
door_go_up ();
else
door_go_down ();
}
So as long as self.wait is less that 0 the door doesn't change direction.
QMLE
#8258 posted by anonymous user on 2009/02/05 18:20:15
After several bumps in Quake modelling I won't get used to the fact a modelframe exported to dxf has a unique vertice and trianglecount.
It may be my poor knowledge of triangles and vertices but when I import this file in another editor and try to export them back to Qmle the vertices turn out higher and triangles are doubled.
I know it has something to do with triangles turned into quads and vice versa, but why doesn't these counts stay the same?
I don't add anything so that can't be the reason.
Is it the 8bit configuration, and nowadays 3Dstudio's 16 or 32bit?
Don't Think So
#8259 posted by ijed on 2009/02/05 18:28:05
I've never had the issue, to be honest, but many do.
If you're working with editable poly then the 7 key isn't showing you a valid vertice / face count - change to mesh while working and the number practically doubles.
As a typical safety thing I'd export the model, open it, select all verts and do a weld within a distance of 0 then export and see if it opens.
If not then the model is bad from the start - having a vertex spike, multiple vertices in the same position etc.
No Clue
#8260 posted by necros on 2009/02/05 19:46:26
you're using 3ds max? make sure when you export that you only export the mesh.
3dsmax will export your bones as geometry without telling you. these may not show up if you import the frame alone into qme3.1 (ie: when they're inside the character mesh), but they will change the vertex/face count preventing you from combining the frame with the original model.
it's important to note that the reason it does this is because bones actually are just geometry. in fact, you can make your own bones out of boxes, spheres, splines, etc. the bones that max makes just have a premade shape to make it easier.
this also means that adding bones will increase the polycount in max's built in counter, so you should completely ignore that counter.
i've successfully used both custom rigs and biped in quake, so keep at it and check everything because it is possible.
Paradigm Shift
#8261 posted by Preach on 2009/02/05 19:47:32
&startI'd really suggest that you start by not thinking of the .mdl format as the best container for your model. mdl format is not a robust way to store information about a 3D model, so you're always going to run into problems with this kind of thing. Repeated saving to .mdl while making changes can make the vertices wobble more than they need to, etc, although we love them because they render in quake engines we must accept mdl is bad.
(see also: http://www.celephais.net/board/view_thread.php?id=60097=155&end=180 onwards)
The way I think of it now is that you make your model in another editor, in a better format like .max (substitute a format of choice for the rest of this post), and then EXPORT to .mdl right at the end of the editing process. If I then decide that I want to add another animation to that model, I chuck out the .mdl format copy that currently exists, make the changes in the .max version, then export the .mdl again.
It's usually helpful if your pipeline to convert from .max format to .mdl is short and hands-off, you don't want to have to rotate/reflect/move the model at all during this process, in case you need to do it many times. Adding stuff like skins is a bit of a hassle, and you certainly don't want to be changing animations! Ideally, you don't even need to open the mdl during the conversion process, just export and then drop it in your progs directory. This might require a bit of trial and error in your main editor to get the model correctly scaled and rotate in game, which again is easier once the pipeline is short.
The problem often arises at the starting point, if you're trying to modify an existing .mdl file. It can be tempting to just keep working with the .mdl format, because it's "practically there" already. Even so, I think it's best to just import the model into .max format right at the start of the project, and make sure it matches up when you export it again. From there you can edit as normal.
(This post brought to you by 3DMax Studio, a piece of software Preach doesn't even own...)
Mdl
#8262 posted by madfox on 2009/02/06 20:01:07
Ijed - I supose you're working in Max3d? As long as I use Qmle and Quark4.07 nothing goes wrong, but I'm tightened to only use manupulating tools like vetice change and rotating. Every output like the Qmle's dxf, or Milkshape's 3ds are the only way to keep the model clear. If I import to Max3D I haven't got the knowhow yet to even ad bones.
Necros - As I said I'm using the Am2000 studio I bought because it is the one that uses mdl files. Bad enough it is an other extentions then Ol'Quake uses. But it can import the dxf/3DS files. If it would be the creepy bone addon count I can't imagine 12 bones with 5 counterparts would end up in a double vertice count.
There the thing goes wrong and I can't get a grip on it.
Exporting them to one poly by count brings me the same model in QMLE, but I cant get up to the double verticecount.
http://members.home.nl/gimli/am2005.jpg
Preach - I'm trying in the Max3D studio, but as I have hardly experience with it I can't make a thing of it. Max3D can't import mdl files I thought? I tried most extentions for in and export but I don't know how that double layer triangles appears.
Pathway
#8263 posted by Preach on 2009/02/06 20:58:06
Ok, here's the pipeline I work with in gmax, and I'm pretty sure that it can be replicated in max3d.
Import:
MDL
use QMe to save it as
MD2
import into 3dsmax ( http://host-a.net/getfile.php?usern=Game_Genius&file=md2Importer.ms is a plugin for this step, which I haven't tried out)
MAX
I'm pretty sure that the mdl->md2 conversion doesn't do any harm, since in theory this conversion can be done exactly. If it turns out I'm wrong and it does wobble the vertices more, I'll probably write a quick program to do the conversion in this direction without the wobble. (*)
Export
MAX
export to MD3(there are loads of plugins which do this)
MD3
convert to MDL(I used to use quark for this, but since it's a pain to get working, I wrote http://www.btinternet.com/~chapterhonour/md3tomdl.zip for this step)
MDL
And the job is done.
_________________________
(*) I've moved the whole technical discussion from this post into a footnote. Ok, here's the deal with MD2. It still compresses vertex coordinates into a single byte like MDL, but the scale factor is slightly different. Instead of having one scale factor for the entire model, like quake 1 does, MD2 has a scale vector per frame. This gives you more control, but is often counterproductive.
For example, you might look at your source model, calculate the bounding box of the vertices in each frame, and then use the corresponding scale per frame. This affords you as fine a grain resolution as one byte can carry in each frame. The problem is that it can create much greater "floaty vertex syndrome", because the grid that all of your vertices snap to is changing every frame. If you had a sequence where the arm of your character waves, but the body remains mostly still, then the body ends up wobbling as the extent of the arm is changing the size of the bounding box.
It could be argued that the MDL method has an equally bad problem, that vertices can end up not moving at all from one frame to the next if the movements are slight. But I'd disagree on two points there. One is that the motion is more regular in time for MDL, stop-starts is compensated for by the brain better than random noise is. The other is that MDL motion is more controlled in space - if the head is just bobbing up and down during this wave animation, the vertices won't move left to right in the MDL. However, if the arm is changing the width of the bounding box in MD2 then the head might wobble from side to side, and the rounding effect might even make vertices go in opposite directions as the grid changes, some left, so right (or worse, some up and some down!)
If you agreed with me, then you might try and write a more sophisticated MD2 exporter. It could first look through all the frames in a sequence, and try to create groups of frames where the bounding box stays within 10% of the max in the group. Then it would use the same bounding box for that whole group. You might even relate bounding box changes to the amount of movement in the whole model, rather than just changes in the limits.
In any case, I've been a bit dishonest there contrasting MDL to MD2 because you can exactly replicate MDL behaviour with an MD2. Just set the same scale in every frame in the model! This is why during the import, it should be safe to convert from MDL to MD2, no information should be lost. Of course, going the other way you can't get an exact replica of every MD2 as a MDL, which is why we have MD3 as the intermediate format in that direction.
Typo
#8264 posted by Preach on 2009/02/06 21:00:29
I've moved the whole technical discussion from this post into a footnote.
should in fact read:
I've moved the whole technical discussion from this post into Appendix A.
Interesting,
#8265 posted by necros on 2009/02/06 21:56:44
my approach is:
MDL
QME3.1 -> export .dxf frame.
Import .dxf into MAX
*animation stuff here*
Export all frames as .dxf
QME3.1 -> batch import frames
Pac
#8266 posted by madfox on 2009/02/07 00:18:49
thanks for the mdl importer, Preach. I'm not familiar with max as I'm just learning the basic lessons. I'll try them out!
I never had the idea to make the files mdl2 or mdl3. I do use the old q2mdlr9b which can import and export Q1 /2 files.
Hmm
#8267 posted by Preach on 2009/02/07 01:13:32
I seem to remember that, but it brings back memories of the mdl exporting not being 100% reliable, and it isn't an ideal tool for creating animations in either.
I also remember the first times I was trying to make models like this, and I also got frustrated with the exact same pifalls: tools changing triangle orders, messing me about, declaring the conversion to mdl impossible all of a sudden. Things got much easier once I had some reliable tools to import and export models around, and a good editor like gmax to do all the editing. One thing that it really takes experience to know is exactly what kind of models you can make which will still convert to quake format. Once you have that down, it's much easier to do everything in a high-end editor and leave the conversion to the end.
And...
#8268 posted by Preach on 2009/02/07 01:24:00
And I really have to add that the most valuable thing I learnt is MD3 format is really your friend when it comes to exporting time.
As long as your MD3 is a single mesh*, then it can be converted to quake with only a loss of accuracy in the animations, the skinmap, smoothing and frames can all be converted. So seriously, find an editor which can export to MD3(blender, gmax, 3dsmax, maya all do), give it a try, and I'll bet you won't go back.
* "A single mesh" here doesn't mean that all the triangles have to be connected in a continuous object. It's a technical thing about MD3s, you can have multiple "meshes" making up a single MD3, which then get joined together with tags. Each of these meshes can have it's own skinmap, but MDL format will only accept 1 skin, and can't do anything with the tags. I'm not saying that it would be impossible to combine the skinmaps side by side and line up the tags, but it would be a bit hard for an automated tool to do well...
Hugh
#8269 posted by madfox on 2009/02/07 17:33:47
That makes things a bit clearer. So it seems that mdl2 and md3 are the extentions I have to look for.
The qmld2r9b seems a good programm as it comes to exporting 3DS. I have never come further then in and exporting extentions in it, as the skinpainter is weird with the pal format and I never knew how to add bones.
The only trick i do is importing in AM2000 so I can attach bones to make the animation. While exporting back to QMLE the verticecount doubles, but as I'm making a new model from base that won't matter.
I surely need more knowhow of Max or Blender.
But as I bought AM2000 I have the import ext:
dxf lit seg mdl(own to program) ply 3ds av2
which are quiet a lot.
Export extentions are only four:
ply 3DS av2 mdl (own to program ie not the quake mdl).
Counts
#8270 posted by madfox on 2009/02/08 09:01:44
Had a quick steamup with max3d and now I've managed to import an enforcer into max with a 3ds file.
I'm on the point that I have bones which are roughly devided over the model. But before going further I decided to check if my model still is on the same count.
Then I see I can only export 3ds and it has one vertice less?
So I import an enforcer
222 vertices 424 triangles
and it comes out as
221 vertices 424 triangles
#8271 posted by necros on 2009/02/08 09:13:32
have you tried importing the enforcer and then exporting it again without doing anything at all in a completely fresh document?
if you're still losing a vertex then i'm not quite sure what's up... it shouldn't merge vertices on it's own. :S
Yeah
#8272 posted by ijed on 2009/02/08 15:07:34
That's wierd.
The safe, but tedious, option is to export all frames to max then create a new .mdl - treating it as a completely new model.
Well
#8273 posted by madfox on 2009/02/08 19:57:28
Here are some screenies to fill in the case...
I import an enf.3DS in Max3D and export it unchanged back to QMLE:
http://members.home.nl/gimli/max3.jpg
http://members.home.nl/gimli/max4.jpg
Nothing wrong.
Then I import the model and make my animations, export it to 3DS:
http://members.home.nl/gimli/max1.jpg
http://members.home.nl/gimli/max2.jpg
Max3D shows the right count but Qmle seem to import it different.(?!)
Triangles
#8274 posted by Preach on 2009/02/08 20:08:20
You've actually gained some triangles there too. I wouldn't expect the import/export process to actually create an identical model though. If I followed my pattern of import cia MD2, then export via MD3, I'd expect the vertex count of a regular quake model to increase quite a bit, because you'd lose all the onseam information, as no other format supports that.
It's just another advantage of recreating the .mdl file from scratch each time, rather than trying to import new frames into an existing one: You don't have to worry if there's an extra vertex or if the triangle count has changed, you just start with a blank slate each time.
Skyboxes And Water In Quake (darkplaces Client)
#8275 posted by Zylyx_ on 2009/02/16 22:49:13
hey just two questions.
How do I add custom skyboxes to my quake maps? I'm using WC 3.3 and the Darkplaces client for my Quake maps. I have a sky texture in my dev.wad called "sky", and I added the "sky" key in the worldspawn entity with the name of my sky texture as the value.
I have 6 sky texture files in my quakedir/mymod/textures dir with the names followed by the recommended HL mapping suffixes of bk, ft, rt, lt, up and dn.
However, when I test my map, I get a black box around my test level.
Also, I have a water texture in my wad with the name "!water", and it's 64x64 (as recommended), but in the game it shows it as one solid tiled chunk, and I cant swim in it.
Any help is appreciated. Thnx.
#8276 posted by anonymous user on 2009/02/16 23:03:05
The skybox images have to be in /mymod/gfx/env and liquid textures require "*" in front of the name (not "!").
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|