Starting to Model for TDM - Revision history

Datiswous: /* Modeling Software */ added links to orbweaver's import export scripts

2026-02-12T21:03:26Z

Modeling Software: added links to orbweaver's import export scripts

← Older revision		Revision as of 21:03, 12 February 2026
Line 1:		Line 1:
	== Modeling Software ==		== Modeling Software ==

	Most modelers on the team use [http://www.lightwave3d.com/ Lightwave] or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. ~~However, there is~~ an ~~ASE exporter available~~ for Blender at ~~the~~ [~~http~~://~~www~~.~~doom3world~~.~~org~~/ ~~Doom3World~~] ~~forums,~~ and [~~http~~://www.katsbits.com/tools/ katsbits.com] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.		Most modelers on the team use [http://www.lightwave3d.com/ Lightwave] or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. There are ase and lwo exporters and an lwo importer for Blender at [https://gitlab.com/orbweaver/darkblender gitlab.com/orbweaver/darkblender] (up to Blender 5.0.1) and [https://www.katsbits.com/site/category/tools/ katsbits.com] has some import/export scripts for Blender (2.49 or below), otherwise ask somebody in the Dark Mod Forums.
	[http://www.autodesk.com/products/autodesk-3ds-max/overview/ 3ds Max] can be used to model and import/export .ase files.		[http://www.autodesk.com/products/autodesk-3ds-max/overview/ 3ds Max] can be used to model and import/export .ase files.

Thebigh: /* Collision Meshes */ -copyedit

2023-10-04T00:14:03Z

Collision Meshes: -copyedit

← Older revision		Revision as of 00:14, 4 October 2023
Line 76:		Line 76:
	== Collision Meshes ==		== Collision Meshes ==

	Collision models should be used on most objects for several reasons. They can help simplify pathfinding databases for AI and weapons, they also simplify the shape of the object so it can be moveable. If an object is going to be static and not move, like a pillar, ~~it's~~ collision model can be as complex as you want, however this defeats the purpose of a collision mesh. Generally you want to make the collision mesh as simple as possible while retaining the basic shape of the model. This will guaranty that arrows will bounce off of it, or stick to it in a realistic way. If the mesh doesn't match the original object close enough you will get things like arrows bouncing off the air next to the model, or arrows that go through the model.		Collision models should be used on most objects for several reasons. They can help simplify pathfinding databases for AI and weapons, they also simplify the shape of the object so it can be moveable. If an object is going to be static and not move, like a pillar, its collision model can be as complex as you want, however this defeats the purpose of a collision mesh. Generally you want to make the collision mesh as simple as possible while retaining the basic shape of the model. This will guaranty that arrows will bounce off of it, or stick to it in a realistic way. If the mesh doesn't match the original object close enough you will get things like arrows bouncing off the air next to the model, or arrows that go through the model.

	Collision models must be exported with the original object mesh. This makes them hard to see in the editor, but the collision surface can be toggled so it's not a problem. Collision meshes won't be seen in game, nor will their effects if done properly.		Collision models must be exported with the original object mesh. This makes them hard to see in the editor, but the collision surface can be toggled so it's not a problem. Collision meshes won't be seen in game, nor will their effects if done properly.

AluminumHaste: /* Naming Conventions */

2013-05-20T15:12:56Z

Naming Conventions

← Older revision		Revision as of 15:12, 20 May 2013
Line 30:		Line 30:
	The following convention should be used for naming all new model additions to TDM (many existing models do not follow this convention, and over time effort will be made to update them). Following this convention will make it easier for mappers to find the models they want in a long list--if they are looking for a chest, they want to look under "c" for chest, not "w" for wooden_chest.		The following convention should be used for naming all new model additions to TDM (many existing models do not follow this convention, and over time effort will be made to update them). Following this convention will make it easier for mappers to find the models they want in a long list--if they are looking for a chest, they want to look under "c" for chest, not "w" for wooden_chest.

	# '''Object Type''' descriptor first. Mappers are generally going to search by object, so they will want to find all objects of a similar type grouped together. It's a window, a plate, a chest, etc. Don't bother duplicating the name of the folder, however. If your ~~ojbect~~ is inside the "lights" folder, then you don't need to call it "light_torch_wood".		# '''Object Type''' descriptor first. Mappers are generally going to search by object, so they will want to find all objects of a similar type grouped together. It's a window, a plate, a chest, etc. Don't bother duplicating the name of the folder, however. If your object is inside the "lights" folder, then you don't need to call it "light_torch_wood".
	# '''Material''' descriptor next. This may be appropriate, but remember that different textures can be used on the same model, so calling something "statue_marble" could be misleading if it also has a metal texture.		# '''Material''' descriptor next. This may be appropriate, but remember that different textures can be used on the same model, so calling something "statue_marble" could be misleading if it also has a metal texture.
	# '''Size''' descriptor next. This is primarily useful if there are multiple versions of the same mesh, like "statue_lion_large" and "statue_lion_small".		# '''Size''' descriptor next. This is primarily useful if there are multiple versions of the same mesh, like "statue_lion_large" and "statue_lion_small".

AluminumHaste: /* Modeling Software */

2013-05-20T15:10:45Z

Modeling Software

← Older revision		Revision as of 15:10, 20 May 2013
Line 2:		Line 2:

	Most modelers on the team use [http://www.lightwave3d.com/ Lightwave] or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. However, there is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/ katsbits.com] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.		Most modelers on the team use [http://www.lightwave3d.com/ Lightwave] or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. However, there is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/ katsbits.com] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.
	~~3dsMax~~ can be used to model and import/export .ase files.		[http://www.autodesk.com/products/autodesk-3ds-max/overview/ 3ds Max] can be used to model and import/export .ase files.

	== Making the Model ==		== Making the Model ==

AluminumHaste: /* Modeling Software */

2013-05-20T15:09:54Z

Modeling Software

← Older revision		Revision as of 15:09, 20 May 2013
Line 1:		Line 1:
	== Modeling Software ==		== Modeling Software ==

	Most modelers on the team use Lightwave or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. However, there is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/ katsbits.com] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.		Most modelers on the team use [http://www.lightwave3d.com/ Lightwave] or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. However, there is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/ katsbits.com] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.
	3dsMax can be used to model and import/export .ase files.		3dsMax can be used to model and import/export .ase files.

AluminumHaste: /* Modeling Software */

2013-05-20T15:08:56Z

Modeling Software

← Older revision		Revision as of 15:08, 20 May 2013
Line 1:		Line 1:
	== Modeling Software ==		== Modeling Software ==

	Most modelers on the team use Lightwave or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. However, there is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.		Most modelers on the team use Lightwave or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. However, there is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/ katsbits.com] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.
	3dsMax can be used to model and import/export .ase files.		3dsMax can be used to model and import/export .ase files.

AluminumHaste: /* Modeling Software */

2013-05-20T15:08:07Z

Modeling Software

← Older revision		Revision as of 15:08, 20 May 2013
Line 1:		Line 1:
	== Modeling Software ==		== Modeling Software ==

	Most modelers on the team use Lightwave or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable, ~~however. There~~ is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.		Most modelers on the team use Lightwave or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable. However, there is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.
	3dsMax can be used to model and import/export .ase files.		3dsMax can be used to model and import/export .ase files.

Demagogue: /* Modeling Software */

2012-03-28T14:17:18Z

Modeling Software

← Older revision		Revision as of 14:17, 28 March 2012
Line 1:		Line 1:
	== Modeling Software ==		== Modeling Software ==

	Most modelers on the team use Lightwave or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable, however. There is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, otherwise ask somebody in the Dark Mod Forums.		Most modelers on the team use Lightwave or [http://www.blender.org/ Blender]. Anything that can save in either .lwo (prefered) or .ase format is acceptable, however. There is an ASE exporter available for Blender at the [http://www.doom3world.org/ Doom3World] forums, and [http://www.katsbits.com/tools/] has some import/export scripts for Blender, otherwise ask somebody in the Dark Mod Forums.
	3dsMax can be used to model and import/export .ase files.		3dsMax can be used to model and import/export .ase files.

Springheel: /* Shadow Meshes */

2008-09-20T11:45:50Z

Shadow Meshes

← Older revision		Revision as of 11:45, 20 September 2008
Line 102:		Line 102:
	Shadow meshes must be exported with objects and their collision models. Unlike collision shaders the shadow shaders do ''not'' override the objects shadows. So when making a model that uses a shadow mesh you need to use material shaders for the object with noshadows on it, this has to be set in the material file (materials/.mtr). However do not go and start adding ''noshadows'' to all the materials as some objects or terrain might need shadows. Instead copy/paste the shader deffinition into a new .mtr file, give it a new name and add noshadows to it, that way the original material doesn't change. You should also use ''NoSelfShadow'' which will stop the material from casting shadows on itself.		Shadow meshes must be exported with objects and their collision models. Unlike collision shaders the shadow shaders do ''not'' override the objects shadows. So when making a model that uses a shadow mesh you need to use material shaders for the object with noshadows on it, this has to be set in the material file (materials/.mtr). However do not go and start adding ''noshadows'' to all the materials as some objects or terrain might need shadows. Instead copy/paste the shader deffinition into a new .mtr file, give it a new name and add noshadows to it, that way the original material doesn't change. You should also use ''NoSelfShadow'' which will stop the material from casting shadows on itself.

	There are 2 material shaders for shadow meshes, they can be combined and both used for one model at the same time. They are '''/~~/base~~/shadow''' and '''/~~/base~~/shadow2'''. ''Shadow'' material casts shadows and self shadows (on the object the mesh is exported with, it is all considered one object although the collision and shadow meshes are not seen in game). Shadow2 casts shadows (on terrain and other objects) but does not cast shadows on itself. This is very handy for things like apples where the player really won't notice if the stem casts a shadow on the apple. Remember, this is one of the most important considerations for performance so if an object can live without shadows, or without casting shadows on itself then use that option first.		There are 2 material shaders for shadow meshes, they can be combined and both used for one model at the same time. They are '''textures/common/shadow''' and '''textures/common/shadow2'''. ''Shadow'' material casts shadows and self shadows (on the object the mesh is exported with, it is all considered one object although the collision and shadow meshes are not seen in game). Shadow2 casts shadows (on terrain and other objects) but does not cast shadows on itself. This is very handy for things like apples where the player really won't notice if the stem casts a shadow on the apple. Remember, this is one of the most important considerations for performance so if an object can live without shadows, or without casting shadows on itself then use that option first.

	Weird lighting issues due to shadow meshes. .Ase files from 3ds max have an issue with shadow meshes clipping outside of an objects mesh which can cause weird shadow fragments on the objects they belong to. The cure for this is to make sure that the shadow mesh is entirely inside the objects mesh. If it sticks out anywhere you will get a weird shadow. A workaround I have found that works good is to model large parts of a shadow mesh that are easy to hide, this can cut down alot of shadow casting polys on an object. Then I will split small details off of the object and give them a material that has shadows, then I don't have to mess with the very hard areas but have still done some good. (example: a small pot with tiny handles, the pot will cast no shadows but will have a shadow mesh to do that, The tiny handles will themselves cast shadows so there is no weird shadow mesh clippling - both use the same base material, but the noshadows and noself shadow lines are removed from a copy of the original shader).		Weird lighting issues due to shadow meshes. .Ase files from 3ds max have an issue with shadow meshes clipping outside of an objects mesh which can cause weird shadow fragments on the objects they belong to. The cure for this is to make sure that the shadow mesh is entirely inside the objects mesh. If it sticks out anywhere you will get a weird shadow. A workaround I have found that works good is to model large parts of a shadow mesh that are easy to hide, this can cut down alot of shadow casting polys on an object. Then I will split small details off of the object and give them a material that has shadows, then I don't have to mess with the very hard areas but have still done some good. (example: a small pot with tiny handles, the pot will cast no shadows but will have a shadow mesh to do that, The tiny handles will themselves cast shadows so there is no weird shadow mesh clippling - both use the same base material, but the noshadows and noself shadow lines are removed from a copy of the original shader).

Springheel: /* Grid Alignment and Origin */

2008-02-08T18:10:31Z

Grid Alignment and Origin

← Older revision		Revision as of 18:10, 8 February 2008
Line 57:		Line 57:
	== Grid Alignment and Origin ==		== Grid Alignment and Origin ==

	Please make sure your models are grid-aligned (the bottom of the object rests on a grid line in your modelling software). If they don't, it can be difficult to get the model to sit on the floor or other surfaces in the editor.		Please make sure your models are grid-aligned (the bottom of the object rests on a grid line in your modelling software). If they don't, it can be difficult to get the model to sit on the floor or other surfaces in the editor. If the object is likely to have other things placed on top of it (tables, shelves, etc) then it is also helpful if the top surface is grid-aligned as well.
	~~Grid alignment~~ is ~~easy~~ if ~~you place~~ the ~~bottom~~ of the ~~object at 0 in~~ the ~~Z plane which is fine for most static~~ objects~~. However if you~~ are ~~creating~~ a ~~moveable object~~ the ~~origin~~ needs to be ~~as close~~ to ~~center as possible~~ and ~~this complicates~~ grid ~~alignment~~.
			Keep this in mind for all objects. The back of a door handle should sit very close to flush with the grid so it'll align well with doors. The back of a torch should be right on the grid so it doesn't sink into or float away from a wall. objects like chests are made of three different models; A chest, a lid and a lockbar. The chest can be flush to the floor, but the top might not align to the grid, it's best to move the verts to the closest grid line in this case. The lid's pivot needs to be at 0 in the z plane, so the bottom of the lid also needs to hit a grid line so it can sit flush with the top of the chest and not leave a gap. The lock bars pivot also need to be flush with 0 in the z plane (for rotation pivot) but it need sto also align on the grid so it'll match up closely to the lockbox.


	Re:'''Grid size''', testing in your 3d program:		Re:'''Grid size''', testing in your 3d program:
Line 66:		Line 68:
	Now any verts placed on a grid line will match the grid in DR.		Now any verts placed on a grid line will match the grid in DR.

	Re: '''Origins'''. D3 uses the origin of the model to determine physics for movement--moveable objects will rotate around the origin when they are bouncing around. Any model that will likely be made into a moveable object (basically any unattached object smaller than a chair) should have its origin where its center of gravity would be. Typically a player will look at the center of an object, not the bottom ~~to frob it~~, so having the origin in the center of moveables makes them easier/more realistic to frob.		Re: '''Origins'''. D3 uses the origin of the model to determine physics for movement--moveable objects will rotate around the origin when they are bouncing around. Any model that will likely be made into a moveable object (basically any unattached object smaller than a chair) should have its origin where its center of gravity would be. The frob trace is also done to an object's origin. Typically a player will look at the center of an object to frob it, not the bottom, so having the origin in the center of moveables makes them easier/more realistic to frob.

	When centering a moveable on the grid be aware of other factors. If you build an object and it doesn't fit the grid precisely then the bottom won't be grid aligned and will be hard to place on a table without it floating or using an extremely low grid setting in DR.

	A workaround is to center your object, then fudge it just off center so that it's bottom (top or side) is aligned to the closest grid line. At a grid spacing of 1 in Max this will generally only move the origin slightly off center and the effects won't be noticable when frobbing or during collision detections, but it will make you objects sit flush to surrounding terrain and other objects better, a major plus.

	Keep this in mind for all objects. The back of a door handle should sit very close to flush with the grid so it'll align well with doors. The back of a torch should be right on the grid so it doesn't sink into or float away from a wall. objects like chests are made of three different models; A chest, a lid and a lockbar. The chest can be flush to the floor, but the top might not align to the grid, it's best to move the verts to the closest grid line in this case. The lid's pivot needs to be at 0 in the z plane, so the bottom of the lid also needs to hit a grid line so it can sit flush with the top of the chest and not leave a gap. The lock bars pivot also need to be flush with 0 in the z plane (for rotation pivot) but it need sto also align on the grid so it'll match up closely to the lockbox.

	Large objects that are not likely to be moveables, like desks or wardrobes, can have their origin at the bottom of the object, for easy placement on the floor.		Large objects that are not likely to be moveables, like desks or wardrobes, can have their origin at the bottom of the object, for easy placement on the floor. An exception would be something like trees that an author might possibly sink into the ground far enough to reach outside the world. In this case have a centered origin would be best so the origin stays inside world.
	An exception would be something like trees that an author might possibly sink into the ground far enough to reach outside the world. In this case have a centered origin would be best so the origin stays inside world.

	Objects that might be designed to swing or rotate (like a hanging sign) should have their origin at the point of rotation.		Objects that might be designed to swing or rotate (like a hanging sign) should have their origin at the point of rotation.