Task: Set Up Moveables

[Ishtvan]

We have a lot of items that could and should be moveable, but aren't quite set up yet. Chairs, crates, etc.

 

It would be great if a modeler/mapper could go thru and do this. What we need is:

 

For each model we have that could be turned into a moveable item:

 

Step 0.

Make sure the model is solid when viewed from all directions, since we don't know how it will rotate when it's moving. Some of our models for small, moveable objects have missing faces (on the bottom of the chalice, for example), so this will need to be fixed in a modeling app.

 

Step 1.

Make the collision model for the moveable following this tutorial:

http://forums.thedarkmod.com/index.php?showt...opid=74416&

(Note that for moveables with very simple visual models, like a crate we can skip this step, because it will be used automatically)

 

Step 2.

Add the moveable to the def file /defs/tdm_moveables.def

 

Make sure you put in the correct:

-name ( It should be named atdm:moveable_<name of the moveable> )

-model name

-mass

 

Regarding the mass:

Do NOT worry about setting the mass, friction, density, etc, so it behaves correct right now. This will be a final tweaking task. However, DO guesstimate the mass in the follwoing cases: Some of our models have names like candle1 and candle2. One of these is a smaller candle than the other. We can't tell immediately which one is which from the model name. So, when you are putting it in to the def file, remember which is which, and assign a smaller mass to the smaller object. Now we know which is which when we tweak the def file later.

 

Step 3. - Testing

Make a note of the new moveable names you added.

 

3.a Launch TDM and go to some wide open, well lit map ( I was using test_water ).

 

3.b Noclip up until you're high off the floor.

 

3.c Open up the console and type "spawn atdm:moveable_<your moveable name>"

 

3.d You should now see the moveable spawn in its default orientation. Go back to the ground, exit noclip, and push the moveable over. Pick it up and throw/drop it, shoot it with arrows etc, making sure that the clipmodel prevents it from falling thru the floor and also that it fits well. Don't worry about the other physics properties for now (it might be too light/heavy, too bouncy, not enough friction when sliding along the floor, etc).

 

NOTE: If you don't go high enough off the floor before you spawn something, it can sometimes spawn partially inside the ground, and then it will clip thru the ground when you push it. This is not a problem with the clipmodel, it's just what happens when you spawn things inside of other things, so make sure you noclip up high enough off the ground before you spawn it.

 

Anyway, that's it. It would be really helpful if someone could do this.

[SneaksieDave]

So Doom3 will generate a CM dynamically for some items? Any idea what the criteria is? I guess we could just test them out first, and see if D3 barfs.

 

I'll throw my hat into the ring and do some of these as I can. It's a simple task, anyone could help out really.

[Ishtvan]

Yeah, it will automatically generate it if it has few enough faces, like a box.

 

I just added some objects, the wood planks (short, long and longer). D3 loaded the collision models automatically for these planks, since they were just boxes (6 faces).

 

I tried this with the crates, thinking they would have 6 faces as well, but for some reason this did not work. Possibly they have more than 6 faces (why??) or multiple submeshes. I don't have a model editor to look at them. Anyway, we'll have to either simplify the crate model so it's 6 faces, or make a CM for it.

 

Also, I forgot to add the all important "test what you just added" step to the process. I'll add that in.

[Ishtvan]

Does anyone have time to help with this? It would be nice to give the beta mappers some moveable crates to play with puzzles and stuff.

 

I tried to put in the crates, but D3 did not like loading the collision model from the visual model. It worked fine with the planks models/darkmod/props/junk/plank_short, but it can't load a collision model from the crates: models/darkmod/props/containers/crate01.lwo

 

This indicates to me that our crates have more than 6 faces for some reason. If this is true, my next question is: Why on earth would a wooden crate model need more than 6 faces?

 

[EDIT: Hmm, looks like our crates have some extra polies around the edges. I guess that's up to the modelers, but it still means we have to make a simple clipmodel brush for them]

[SneaksieDave]

Yes, I will be trying to do some as possible. Hrm, I think I need a reminders list, too; things I keep meaning to do are coming from multiple directions.

[Springheel]

I followed these steps and got a small rock ingame as a moveable. But it doesn't seem to work entirely. I can't pick it up, shooting it with a regular arrow doesn't do anything, though a fire arrow will blast it all over the map. Somehow after shooting one it came to rest about ten feet up in the air, not touching anything. Also, the rock doesn't seem to rest on the ground. Is it the collision mesh that determines how it rests on the ground? If so a simple box probably won't work for a rock.

[OrbWeaver]

Is it the collision mesh that determines how it rests on the ground? If so a simple box probably won't work for a rock.

 

Yes. Yes.

 

If you zoom in small you should be able to fit the brush to the size of the model fairly well. You can also shave off parts of the brush with the clipper tool before exporting, as long as it remains a single convex brush.

[Ishtvan]

It also has to fit within the face/vertex/edge limits though, so you have to be careful about making it too highpoly or it will fail to import.

[Springheel]

You can also shave off parts of the brush with the clipper tool before exporting,

 

That puts me out of the running then. My knowledge of brush making is limited to cubes.

 

The rocks are already on CVS, but someone else will have to tackle the collision mesh.

[Dram]

I think it may be better to just have the collision mesh as part of the actual model - you can get them to fit the model better. I could do this I guess, but only once I'm happily ahead of schedule on the alpha map, which I currently am not.

[Ishtvan]

Well, it would be nice to have moveable crates in the alpha map too...

[Dram]

Well, it would be nice to have moveable crates in the alpha map too...

 

Hmm good point. Well I guess it should'nt take long to open each up and add collision boxes and the sort. I guess I'll do that during making the map (if I get bored I'll do these to uber bore myself so that going back to the map will not be borig again. Repeat)

[SneaksieDave]

I might suggest we list the ones we've done/are doing here, so that we don't do the same thing twice. Not terribly necessary, but it could help.

 

Both candles are done (have been).

Fireplace logs will be re-done, as I only did that as a learning exercise.

[Dram]

I might suggest we list the ones we've done/are doing here, so that we don't do the same thing twice. Not terribly necessary, but it could help.

 

Both candles are done (have been).

Fireplace logs will be re-done, as I only did that as a learning exercise.

 

Done as in the model itself has a collision model or you mean a CM file to go with it? I'd say to keep things fluid every model made should have a collision model inside the model itself. They only take about a minute each and means we won't have even more files in the folders. But if it's all the same whatever, I guess we can just have external cm files. Just as I said before, doing it in the model itslef will yield more accurate results imo.

[Ishtvan]

I think it's all the same in terms of the final file format, but you do have a good point that a CM in the model is more accurate than the brush->export method since it doesn't have to be grid-aligned.

[SneaksieDave]

I'm fine with either way, but if those unskilled with modelling tools are to lend a helping hand, the DoomEd method will be the only way.

 

So what's the bottom line, separate files or no? If not, I won't waste any time on it. But ultimately, they're going to come that way from the community too, without a doubt. Might as well "support" (include) it.

[Dram]

I'm fine with either way, but if those unskilled with modelling tools are to lend a helping hand, the DoomEd method will be the only way.

 

I think for small object at least it's a better idea to use in-model collision file rather then external cm. For things like couches etc a cm file would do imo.

 

But ultimately, they're going to come that way from the community too, without a doubt. Might as well "support" (include) it.

 

Well if they already make a model I would'nt expect it to be too hard to just make a collision model in it. They'd have to do it through doomed and I believe it's easier in the modelling app.

[OrbWeaver]

Do we know for sure that an in-model CM will work? I have never actually tested this but if it works it would certainly give better results than chopping up a brush.

[Ishtvan]

That was how Brian @ Id suggested doing the CMs, so he at least thinks it works. Haven't tried it personally, but I'm pretty sure BT has tried it and said it worked. I'd say see how accurate you can get with a brush, and if it's not a tight enough fit around the model, go for the modeling method.

[Dram]

Well the broken arrow model I made uses this and works fine

[SneaksieDave]

All I'm saying is that if it's going to be done in-model as procedure, then they're all going to fall on one person pretty much (unless everyone becomes a modeller). Since the DoomEd method exists though, people will use it, so there will be no 'purifying' it out. Anyway, I'll hold off on adding any CMs to game then, pending the decision here...

 

Ironically, we couldn't use a CM for a couch, because it would have to be concave.

 

Edit: oops, missed this:

I'd say see how accurate you can get with a brush, and if it's not a tight enough fit around the model, go for the modeling method.

So we will have a mix then, and go with whatever comes first for "accurate enough" objects, and otherwise use modelling for less suited items, unless there are objections.

[Dram]

I know what you mean aargh. Hmm, well it's a pretty simple task. I have'nt tried to do it with d3ed but I guess for most items larger then a coin it should be ok.

 

Well whatever you guys choose, I'd do it but I'd rather do the alpha map. And any specific moveables I'd set up for the alpha map atm. Hell that means most mansion items lol. Whatever, I'm just babbling, 2am here almost and I only slept 4 hours last night (mapping too long lol)

[Domarius]

Ironically, we couldn't use a CM for a couch, because it would have to be concave.

Then what does it use - the visible mesh, which is still concave? I don't understand.

The other physics engines I know of, can let you specify multiple CMs and attatch them together.

[SneaksieDave]

We might be able to do that, I'm not sure. I don't fully get it either.

[Ishtvan]

If the couch is a static, there's no limit on how complicate the CM can be (right now it's using every tri on the couch rendermodel as a tri in the CM).

 

Doom3 has specific limitations on collision models for moveable items, not all collision models. Maybe it can be concave, I'm not sure, but it does deinitely have to obey the limit of 16(?) faces, and we can't change that. Doom3 physics is all collision based, so every time you move around a moveable, it has to take the clipmodel for the moveable and mathematically solve for when any part of the clipmodel will collide with anything else in the physical world. That's probably why they have that limit, but who knows.

 

Again, these are the limitations (from the CM tutorial thread) :

"max vertices = 32"

"max edges = 32"

"max polygons = 16"

""max edges per polygon = 16"

"The collision model must be an enclosed hull. Dangling polygons or"

"edges are not allowed."

 

 

You can have multi-clipmodel static entities in Doom3, but I don't know if it would work for moveables. You might have to bind two moveables together and make a prefab to get that effect.

 

So a valid question might be : Do we want people to be able to move the couch, or shoot between the legs of the couch? We might have to choose.