Blender Request

[Baddcog]

Arghh, this stuff is just frustrating to me anymore.

 

I was gonna fix that 'gap' in the doorframe. But I modelled that stuff purposely a little rough so it would have more character. Now I gotta redo the entire thing to fix it and void the whole reason I made it that way.

 

I'm just not feeling it at all. Then the whole pain in the ass of loading it up and making sure all the tex are right, etc...

 

Sorry. If you guys want so obj files or something let me know. But I really just don't feel like redoing all this stuff again.

[Springheel]

Sorry. If you guys want so obj files or something let me know. .

 

Will the uvmap be intact if you save it as an .obj file? If so, that would be great.

[greebo]

I'm a bit lost - should I still go ahead and convert the models to LWO?

[Springheel]

Sure.

[greebo]

Um, I guess I'm a bit late, but I finally got around to import them into Blender. It didn't go as smoothly as I expected (the door scale was off so I had to resize them to match, and some vertices had wrong U/V coordinates, I had to unwrap them again). And the LWO exporter wrote each material to a separate layer, so I had to flatten them in Lightwave.

 

Anyway, the LWOs are in SVN now, I'll commit my Blender files to the model_src repository.

[Springheel]

Ok, thanks. I'll try to get to that next week.

[Springheel]

Huh, it just occurred to me that the .lwo doors won't automatically replace the .ase ones in maps, will they. I guess in order to fix the current maps we'll need to do a search/replace script.

 

There is actually a pretty big list of models that have never been updated, so perhaps it can all be done at once.

[Tels]

Huh, it just occurred to me that the .lwo doors won't automatically replace the .ase ones in maps, will they. I guess in order to fix the current maps we'll need to do a search/replace script.

 

There is actually a pretty big list of models that have never been updated, so perhaps it can all be done at once.

 

Ah,yes, I forgot. But if you add the list of files (blah.ase => blah.lwo) into devel/manifests/fixup.txt running the script is easy.

[Springheel]

All the other models should already be listed there. I'll add the doors when I get to them next week.

[greebo]

Concerning the "moveables missing clipmodels list":

 

models/darkmod/decorative/vases/pot_large.ase

models/darkmod/decorative/vases/pot_medium.ase

models/darkmod/decorative/vases/pot_small.ase

models/darkmod/decorative/vases/vaseantique.ase

 

These 4 models are vases with a large opening, so you basically can put things into them. They already have a collision mesh, but it is too complex to be used as clipmodel for moveables. I can trim down the collisionmesh to 16 polys, but I promise it will look awkward when you try to put things into such a moveable vase (a small item will just hover in mid-air, players will not be able to put things inside the model - projectiles will also bounce off before actually touching the bottom of the inside).

 

What do we want to do here? I vote for removing them as moveables and leaving them static for the sake of believability.

[Springheel]

This is an issue with many existing models, like buckets (I'm pretty sure I raised this about buckets in the past). There is no perfect solution that I can think of. What I've been doing is going ahead and making the movable version, and allowing for the fact that mappers can always include the static mesh if they want players to be able to drop things in it.

 

I don't like the idea of just removing them as movables. After all, we actually used one of those pots for the key in St. Lucia, didn't we?

[greebo]

But if the collision mesh is "closed" at the top, this would also affect the model as func_static, wouldn't it? The clipmodel would still be loaded for calculating projectile collisions, from what I recall. Maybe I'm wrong.

[Springheel]

Come to think of it, you're right. I remember testing that too.

 

Well, I don't know. This issue with simplified CMs affects a LOT of models (all vases, pots, hats, helmets, chairs, buckets, etc). Do we want to eliminate all those as movables?

 

Either option is going to have moments where it appears unrealistic. Unless we make two versions of each model.

[greebo]

Having two versions of these questionable models was also what I was thinking about - after all this might give us the best of both worlds, if a "closed" moveable vase can be called "best".

[Springheel]

It does unfortunately rely on mapper knowledge to get right--they would have to be aware of the limitation of movable models and then select the right static one for their map. But I guess that's the best of the bad options we're stuck with, unless we can later find a way to have more complex CMs.

 

What kind of naming convention should we use? "*_open"?

[greebo]

Wait, I've got the solution. Quite obvious if I think about it.

 

We just need to save the moveable clipmodels to separate files and let the moveable entityDefs refer to them with the "clipmodel" spawnarg. That way you can use the models as func_statics just fine (using the built-in collision mesh if there is one or the visual mesh otherwise) and use the moveable entityDefs, which will override the built-in clipmodel via the spawnarg.

 

The only decision is whether we want the clipmodels saved as .cm or .ase/.lwo (the latter will show up in the model viewer).

[Springheel]

We just need to save the moveable clipmodels to separate files and let the moveable entityDefs refer to them with the "clipmodel" spawnarg

 

Hey, that's perfect. Well, as perfect as we're going to get.

 

The only decision is whether we want the clipmodels saved as .cm or .ase/.lwo (the latter will show up in the model viewer).

 

Obviously I'd prefer .lwo for the ones I'm doing.

 

So basically I should go through all the .lwos with clipmodels, and any time the clipmodel is significantly different than the visible mesh (vases, chairs), I should cut out the cm, save it as a new name ([model]_cm?) and then save the model without the cm?

[greebo]

Hey, that's perfect. Well, as perfect as we're going to get.

After experimenting, I need to refine the suggestion above, as using .cm files won't cut it. The "clipmodel" spawnarg cannot refer to actual .cm files, only .ase and .lwo files are allowed. Hence we only have one option left, namely using separate .ase and .lwo files for as clipmodel for moveables.

 

So basically I should go through all the .lwos with clipmodels, and any time the clipmodel is significantly different than the visible mesh (vases, chairs), I should cut out the cm, save it as a new name ([model]_cm?) and then save the model without the cm?

Basically, yes. Although I'm wondering whether it was better to save these *_cm.lwo files somewhere else, because they will clutter the model selector in DarkRadiant otherwise. Maybe save them to models/darkmod/misc/clipmodels?

[Springheel]

Although I'm wondering whether it was better to save these *_cm.lwo files somewhere else, because they will clutter the model selector in DarkRadiant otherwise. Maybe save them to models/darkmod/misc/clipmodels?

 

Yes, that probably makes sense.

[greebo]

Ok, I'll create that folder then as models/darkmod/misc/clipmodels. The process is much faster for me now too, because I don't have to remap the textures of the ASE-imported models.