Magnesius' Meshes

[Magnesius]

Thanks, Spring. It is already optimized and consists of roughly 300 triangles. The other meshes are also tweaked and should be ready for ingame use, apart from the wooden chest. I saw that there is a darkmod_door entity which is frobbable, therefore I will seperate the wooden chest into the main part and the doors.

[Magnesius]

Something to add to our project's fauna:

Nothing spectacular, but it might make a nice addition. Currently, these snails are still static; surely they can somehow inserted as 'trains' or 'movers' which follow a given path.

[Dram]

whoa! you're going friggin fast! great work Mag, welcome to the Team btw... yeah I only noticed now

[Magnesius]

 

The wooden chest has now MD5 animations for opening & closing:

(Video taken from Blender without any textures)

 

Can I set up such a MD5 mesh to be frobbable? Right now, I am using a custom .def-file for creating a new entity based upon func_animate. It is quite a hassle to accomplish this in Radiant with 3 parts of the chest (main, left/right door), because the grid is not fine enough for placing the point of origin precisely of each model. So MD5 meshes should be the way to go...

[Ishtvan]

You're saying you tried it with our frobable door class but can't place the origins in the right place? Can't you use the 3DS to place the origins of the doors at their pivot points? Or you can't get the 3 pieces to fit together in Radiant?

 

I think we should use the frobable door/mover system if possible. It might be that we have to create a prefab where we take the one-time trouble to place the coordinates of the doors more finely than is possible in Radiant (i.e., fit them together in some other 3d program and copy down the regular coordinates and enter that into the "origin" key by hand) and then import that prefab for all chests once it's done.

[Magnesius]

You're saying you tried it with our frobable door class but can't place the origins in the right place? Can't you use the 3DS to place the origins of the doors at their pivot points? Or you can't get the 3 pieces to fit together in Radiant?

I actually have only the old Dark Mod release from the FTP server (/Darkmod/TheMod), which crashes upon starting (I am using XP-SP2 with an intentionally restricted user account + ATI 9500pro). I did not try working with it in the editor, though. But after all, it is a Radiant thing: I can get the pieces together, but there remains always a small visible gap. Guess I should start working with a Doom grid size in Blender!

 

I think we should use the frobable door/mover system if possible. It might be that we have to create a prefab where we take the one-time trouble to place the coordinates of the doors more finely than is possible in Radiant (i.e., fit them together in some other 3d program and copy down the regular coordinates and enter that into the "origin" key by hand) and then import that prefab for all chests once it's done.

So, only for verification: We are using only static meshes / brushes for frobbable doors, aren't we? It would be quite handy to implement usable and therefore frobbable objects with animations, though. Isn't this possible (I am not only thinking of chests and boxes, but also of usable gears, clocks etc)?

[Gildoran]

We can implement entities that play animations when frobbed, but that's not really applicable to your wooden chest: We need to make sure that the doors stop if blocked, which I'm doubtful would occur if we used an animation for the doors opening/closing. (to be honest, I'm not 100% sure, though)

[Magnesius]

Well, frobbable entities that play animations have certain advantages over prefabs (rotation, single mesh instead of a bunch of small models, complex opening mechanisms). However, it would be pleasant if both is possible. I did not think of obstacles in the door's way, though.

[Ishtvan]

Yeah, we can call whatever script we want when you frob something, so it is quite easy to play an animation. We can do this in the case of buttons, gears, etc, but I agree with Gildoran in thinking the MD5 method for doors probably wouldn't check collisions with physics. The player expects all doors to behave more or less the same way, including those on chests. For the door entity, they get stopped by physics (or push things aside if they're light enough), they can frob them again in mid-swing to stop them, they effect sound propagation (if you had a really big chest you could get in and hide), that sort of thing.

 

How do people usually fit door models in doorways or putting lamps on tables? Isn't this kind've a similar problem? You might want to ask some of the other mappers how they go about fitting things together. Maybe it's the gridsize as you say, or maybe there's some trick, who knows.

[gleeful]

Wow, those are some fantastic models, Magnesius!

 

I wasn't even aware of your existence up until now I must admit. Edit: Ok, that's because you're brandnew!

 

Keep it up, please!

 

Kind Regards

gleeful

[Dram]

Yeah, great stuff dude

[Magnesius]

I wasn't even aware of your existence

Uhm.. that's the Keeper training, you know. We have got carpets in these boards

 

I have mailed all the finished meshes to Springheel, so eventually the mappers can put snails into their missions! Dram, can you make some sort of 'train' with a static mesh and waypoints in D3Ed?

[Gildoran]

Magnesius: Yep, that's possible with splines in D3ed.

 

Heh, that'd be great if Snails ended up being a signature of TDM, much like how burricks and the word "taffer" are for Thief.

 

PS, I swear it looks like those two snails are ... Well, I guess we know why there's so many snails on that table.

[gleeful]

Uhm.. that's the Keeper training, you know. We have got carpets in these boards

 

Hehe!

 

Again, really excellent work!

 

Kind Regards

gleeful

[Magnesius]

Magnesius: Yep, that's possible with splines in D3ed.

Great thing!

Heh, that'd be great if Snails ended up being a signature of TDM, much like how burricks and the word "taffer" are for Thief.

Just imagine! We should also have glowing escargots, though... just for the case we won't use glowing fungi for some reasons, as we certainly do not wish to copy Thief in a 1:1 manner.

 

I saw that the window section of the model gallery is still empty - although windows are quite important! How should the snails otherwise be able to come inside a mansion? Here is one solution:

[SneaksieDave]

Magnesius, damn! Those shots just made me wet myself. They look great.

 

A related but OT question for those in the know - what are the ramifications for using models as architecture, specifically with regard to portals and sound occlusion? I'm guessing no problem - open a hole, pop the window model in, and place a portal - but how will the model, the glass window, trigger the portal to open/close? I guess the same holds true for doors, but I'm still not clear if we're going with models or movers for doors (or if it even matters). Also will such windows prevent breakable-ness?

[Magnesius]

Hey, thanks. I'll make some variations of it.

 

open a hole, pop the window model in, and place a portal - but how will the model, the glass window, trigger the portal to open/close?

Ah, yes. The original Doom door is able to trigger portals, and it can consist of a model. I suppose our frobbable rotating door is some sort of modification which can do that as well; although I have to admit that I did not try to actually use TDM entities in the editor. Guess I have to ask Sparhawk for CVS read access. Another interesting point would be the implementation of door knobs, which should of course move before opening the door!

 

but I'm still not clear if we're going with models or movers for doors

Having only movers would certainly be a big limitation. I do not remember any door in D3 which consisted soley of brush geometry, even the simple ones were modeled.

 

Also will such windows prevent breakable-ness?

Hm, these windows seem to be a new invention. With the steam powered production process of these windows, even a sword cannot break them! They are, thanks to the Builder, indestructible - as he is himself! Well, I should stop being a Hammerite salesman for now. I could imagine that the whole mesh with one window in it can be destroyed (the window pictured above consists of 3 different meshes - the frame, left and right window). While that is certainly possible, it would alert nearly all guards in the flanking rooms, and is therefore out of question for a master thief.

[Springheel]

I'm trying to add your models to CVS, but I've run into a problem with the antique vase. The texture isn't showing up for some reason. Is this path supposed to have two 'vase's?

 

*MATERIAL_NAME "vasevaseantique_d.tga"

 

Also, is there no material for the spectacles?

[Magnesius]

Concerning the vase: Yes, it should be "vasevaseantique_d.tga". This material name in the ASE file will not be read, all what matters is solely the *BITMAP string.

*BITMAP "//base/models/darkmod/props/textures/vaseantique"

There is no other texture declaration which is important for Doom. However, I don't see any problem with it at all (I just checked it in Radiant); did you change my 'material'-file?

 

The spectacles-mesh has 2 textures:

- the standard Doom glass texture

- the trumpet texture

 

So there is no need for another texture. Even if you don't wish to include the trumpet, simply insert the "trumpet"-texture. Basically, it's a generic golden shiny surface and could receive another name, such as "shineygolden".

 

Edit: I thought that I used the correct texture path for my meshes (//base/models/darkmod/props/textures). Did you change it?

[Springheel]

The spectacles-mesh has 2 textures:

 

I know it's using the same textures, but is it using the same material entry?

[Magnesius]

Yes, it does.

[Magnesius]

I suppose I will ask Sparhawk for CVS read access so that I am able to check my model paths against the most recent folder structure. I could send you 100% valid meshes then, which only need to be moved to the server.

[Springheel]

When you're doing material entries in the future, we're trying to avoid the overly long pathnames. Just use the name of the model, or magnesius_model if you think there's likely to be a conflict.

 

edit: Ok, the spectacles are in. Still can't figure out why the antique vase isn't working. I changed the material path to:

 

*BITMAP "//base/vaseantique"

 

and the material entry to:

 

vaseantique

{

qer_editorimage models/darkmod/props/textures/vaseantique_d.tga

diffusemap models/darkmod/props/textures/vaseantique_d.tga

specularmap models/darkmod/props/textures/vaseantique_s.tga

bumpmap models/darkmod/props/textures/vaseantique_local.tga

}

 

I don't see anything amiss. I'm starting to think the decorative.mtr file is cursed somehow.

 

edit: aha! I copied the text to a new file and saved it as decorative2.mtr, and now they all work. Bizarre.

[sparhawk]

I suppose I will ask Sparhawk for CVS read access so that I am able to check my model paths against the most recent folder structure. I could send you 100% valid meshes then, which only need to be moved to the server.

 

If there are no objections we can also give you full access to CVS. Since you seem to contribute regularly it would be ok for me.

[Magnesius]

Huh? Bizarre indeed. Well, it seems settled now. I will use the new material declarations from now on.

 

If there are no objections we can also give you full access to CVS. Since you seem to contribute regularly it would be ok for me.

That would be helpful. Also, I would like to try out the TDM entities in D3ed, the old FTP version somehow refuses to work with my system.