Modular modeling – a quick example

[peter_spy]

Hi there! Since modular meshes are a thing in TDM, and I already saw some general misconceptions in the forums on how to make them, I thought I should show you one of basic techniques to make proper modular meshes, especially if you want to release them for others to use.

First off, if you're new to the concept, have some preliminary reading:
https://docs.unrealengine.com/udk/Three/rsrc/Three/ModularLevelDesign/ModularLevelDesign.pdf

The document is old, but the principles of modular design stay the same. It's always about building the game world as fast as possible, while trying to save on polygons, textures and resources in general, and making the environment look as unique as you can. These seem like polar opposites at first, but with creative use of modular meshes you will reach that middle ground.

Now, I'm not going to discuss my modeling techniques in much detail, since that's whole other topic, but we will stick to some ground rules:

1. Your wireframe has to be clean. I know this is modeling 101, but you can never stress enough how important it is. Essentially, your low-poly model has to be made with polygons (squares or rectangles) which can be divided into triangles when you convert it to a mesh. So, any piece rectangular flat surface should be divisible into 2 triangles. That doesn't mean you can't have triangles in your model. You can, they just won't be divided further.

This is very simple mesh with 3 rectangular surfaces, in other words, it has 3 polygons.



And this is how it should look like after export to mesh and in your game editor. As you see, everything is fine, there are 6 triangles.



Now, in TDM module library I often see something like this:


This is not a clean wireframe. You're looking at 14 triangles instead of 6. That's 42 edges instead of 18. While it may not be game-breaking now, it's definitely a waste of triangles. If you're going to have a whole collection of meshes built this way, you may be wasting processing power and lowering the overall game performance. Engines using lightmaps would probably have shadowing problems with this kind of wireframe. And that's how we move to rule number two, which is:

2. Save polygons whenever you can. Get rid of the faces players will never see. Use geometry only to convey believable shape of a model. Use high -> low poly model workflow and texture baking process to imitate complicated geometry with diffuse and normal textures. You don't need a thousand-polygon wall module, if you can fake it with normalmap and little visual difference. This is not only helpful in terms of performance, but it saves a lot of time at the model UVW Unwrap stage (it's easier / faster with fewer polygons to deal with). It also can be a design decision: whether it's a distant / skybox art or closer to the player, etc., etc.

Now the rule number three, which is probably the most important of them all:

3. The pivot has to be moved to a place that allows most flexible use of a model, in as many scenarios as possible, and with grid set to as high number as possible. While this is not obligatory for unique objects, decorations and clutter, architectural meshes have to be cloned, moved, rotated and snapped to grid, as fast as you can. Typically, this depends on mesh dimensions and pivot placement.

Since this all may sound very technical and abstract, let's get down to proper example. For my mission, I needed a wooden wall panel, something in the Builder's cathedral aesthetics. While browsing through many references, I found something appealing to my taste, but way above my modeling skills:



I was also taking screenshots of Dishonored. I liked the Overseers' HQ, and I wanted to have something similar in terms of modularity:


Notice that you don't need any special columns for outward corners, or to break up panels that are next to each other. I thought that the easiest way to achieve something similar would be to have a horizontal tiling texture with sections. Since I'm using 2048 textures as a base, I knew that 128 x 256 units will be enough for a wall panel, and I'll be able to divide it properly later.
I didn't want the low-poly mesh to be complex, so I thought all I need is an upper trim section, the main section with inset panels, and the ground trim section. Technically, I could probably use one trim section and overlapping UVs to save on texture space, but I thought that is a bit too far Besides, any dirt layer on that would have the same spots or scratches on both trims, and that might look weird.

This was the initial basic outline of my low-poly mesh. I thought the trim parts will be 16 u high, to fit better with overall proportions. Besides, if I'd changed my mind and decided that it's better to scale the model down to 64 x 128 u, it would have looked good as well.



Now, since my drawing skills are basically none, I decided to model parts and decoration that would end up as baked texture and normal. I started with the middle section. Since the panel would be 256 u long, it was easy to divide it into 8 sections, 32 u each.



I added thin strips between each section to make things a bit more interesting. Notice that I cut the strip by half on each end to make it tile properly later.



I made a few adjustments and started adding decoration for the insets:



Since there aren't many Builder insignia concept artworks, I tried making something on my own. It's kind of too close to hammerite stuff, but I liked it enough to leave it that way.




Now the trims. Actually, one trim for the ground that is reversed for the upper section:



The final model wasn't even high poly, medium poly at best. You're looking at 5200 polygons.



I unwrapped the initial low-poly mesh (well, a plane with 3 setions), so it was super easy to bake the medium poly mesh onto it. I was using only half of the 2048 texture space.



I could crop the texture to 1024 x 2048 and reposition UVs, but I decided that later I'd make a column, or another variation of this panel, so this space would not go to waste.
This was kind of crucial moment and time when fun began. First thing I did was to check the pivot. I aligned it with the plane, moved it to the left side, and placed it on the ground. This way the model would be much easier to manipulate, whether it's moving around, rotating, or snapping to brushes or other meshes.



Then I had to determine the final shape of the mesh and its possible uses. I applied the baked AO as bitmap to see whether the texture tiles (it did), and decided to tilt trim sections a bit, so it reflects the shape of medium poly mesh a bit more. I knew that players wouldn't see the bottom part of the mesh, but I wasn't so sure about the upper part. I decided to make the upper finish and used the trim part of the texture for it.



Then I built a few walls to see how the mesh would look placed against them. That was when I realized my mistake. The pivot was in line with the middle section now, so, when I snapped it to a wall, the middle section was z-fighting with a wall. Duh! I selected the polygon and moved it 1 unit to the front.



When I made sure that I can safely snap the mesh to walls and its clones, I proceeded to divide it to parts. As you see, this is still 128 x 256 wall panel, it's not really flexible. We need different length variations. Since I divided the medium poly into 8 even sections, I could slice the low poly mesh into chunks. Since having 8 different parts isn't that useful in the long run, I decided to clone the mesh, cut off one panel, clone the result cut another panel, etc. This way I came up with panels that are 224, 192, 160, 128, 96, 64 and 32 units long, respectively:



The question is: do you really need that many panel variations? Typically, no. Four should be more than enough. You can always have a panel going through a wall, where player will never see it, so you don't need to be that precise and have all the length variants.
Still, there was one thing even more important: corner pieces. I cloned the two-inset (64-unit) version of the panel to cut it in half. Then I rotated the "right half" 90° to the left to see the result. It was far from satisfactory.



I knew that I'd need to align the upper and lower trims to form the corner, but I completely forgot that moving the middle section 1 unit to the front (to avoid z-fighting with walls) would create half a unit gap in the corner. This is how it looked after I aligned the vertices:


This is where I could go to making textures and testing meshes in the editor, but there's also a problem of having inward corners. Many developers don't even bother with these, there will be some z-fighting of the upper part, in the small corner where meshes intersect. Not a big deal, but you can have such corners if you want as well.



I felt like I had complete package, so I made some preliminary textures and material, then I begun exporting all pieces in .ASE format. All in all, I managed to create 12 variants of one mesh to cover the whole variety of its uses.



After a few iterations of _d, _s, and _n textures, I came up with something like this:

Edit: after getting some feedback I reworked the trims to give them more depth and proper silhouette, so the final result looks like this:

 

This also demonstrates how important it is to bounce your ideas off someone or to show your work for peer review. A fresh look and healthy criticism can have very positive impact on quality of your work.

 

 

I hope you'll find this useful while designing your own modular parts, let me know if you have any questions.

Edited May 16, 2017 by Judith

[Bikerdude]

I didn't understand half of it, but the pictures speak a thousand words - very impressive Judith.

[jaredmitchell]

Great stuff! This definitely looks like what my Game Art Major classmates were up to.

 

Do you think inefficient meshes are a common problem in TDM? I only took one class in 3D modelling so I'm not the best person to pick that out. I definitely think that would contribute to a lot of the performance issues I have.

[Springheel]

You might be aware of this already, but Dark Radiant doesn't care where the pivot point/origin is. DR doesn't rotate models around their origin.

 

Something I wish I had noticed earlier on was the camera direction of the model preview window in DR, so that might be something you want to check--ideally models should be facing the camera by default for easier previewing.

 

Do you think inefficient meshes are a common problem in TDM? I only took one class in 3D modelling so I'm not the best person to pick that out. I definitely think that would contribute to a lot of the performance issues I have.

 

 

Performance in TDM has far more to do with shadow calculation and AI than it does with inefficient meshes.

[peter_spy]

Of course DR cares where the pivot is. It's highlighted as soon the model is selected and also serves as the point for snapping, movement, or rotation, as in any other engine:

 

 

 

Do you think inefficient meshes are a common problem in TDM? I only took one class in 3D modelling so I'm not the best person to pick that out. I definitely think that would contribute to a lot of the performance issues I have.

 

Just some of them are, mostly those in modules folder. Those with flat faces and weird extra edges along them, that don't contribute to an actual shape of the model, just adding triangle count (and shadow mesh triangle count, probably). It shouldn't be a major performance issue; even idtech 4 can tolerate higher triangle counts. But having many different meshes like that may be a problem, sooner or later.

Edited April 17, 2017 by Judith

[Springheel]

What rotation tool are you using? Both the rotation tool buttons and free rotate do not rotate around the model's origin, as you can see in the video below. Is there a third rotation tool that does?

 

 

 

edit: Oh, you probably have the "rotate around func_entity origin" selected. Yes, if you have that turned on, it will rotate around the origin. But there's no particular reason to have that on by default.

[peter_spy]

Wow, that was weird. I can do it both with Rotate mode and the Arbitrary Transformation dialogue. Why wouldn't I want to have that option turned on by default? It's easier to manipulate objects with pivot placed in a proper pre-designed spot, so that it facilitates rotation and alignment with other meshes. This is rather basic functionality for meshes. Turning it off is for special cases, not the other way around. This way I wouldn't be able to place those meshes easily on a grid of 16, which I did.

Edited April 17, 2017 by Judith

[Springheel]

Why wouldn't I want to have that option turned on by default?

 

 

It's up to you what you want on by default. But there will be less to complain about regarding model origins if you leave it off.

[peter_spy]

It's on by default in all game editors I've ever seen. I'm not even sure you can turn it of just from the menu. Well, except for this one I must have clicked that icon as soon as I saw the description (yes, hell yes!).

 

Even though these models are relatively simple, they need to use pre-designed pivots. Originally the pivot was aligned with the plane in 0,0,0, but I had to move it so it doesn't intersect with the wall the mesh will be aligned with. I moved it away by just 1 u, so if you're not using that pivot, you'll have to bring down the grid to 1. For architectural models, that's really bad. This way I can use the whole set with grid of 16, and they snap to walls and to each other properly.

[Bikerdude]

But there will be less to complain about regarding model origins if you leave it off.

Would this explain or fix the issue of models and prefabs not rotating inside the inspector window then..?

[Springheel]

It doesn't affect the inspector window. That rotates around the origin regardless of the other setting.

[Goldwell]

Those look really good Judith!

[Sotha]

Origin placement is important. If the model origin is greatly misplaced and ends up outside worldspawn (in the void), then dmap will fail.

 

As long as the origin is somewhere within the model and makes the module snap perfectly to the grid, all is well.

 

It is very fortunate DR does not rotate stuff around the origin, because many objects do not have the origin dead in the center, because that would compromise the grid snapping. Also, door models must have their origins at the actual in-game rotation point.

[peter_spy]

Origin placement is important. If the model origin is greatly misplaced and ends up outside worldspawn (in the void), then dmap will fail.

 

As long as the origin is somewhere within the model and makes the module snap perfectly to the grid, all is well.

 

It is very fortunate DR does not rotate stuff around the origin, because many objects do not have the origin dead in the center, because that would compromise the grid snapping. Also, door models must have their origins at the actual in-game rotation point.

 

 

You're absolutely right. Good thing is, the pivot can be placed on the edge of the brush wall that seals your level from the void, and there will be no errors.

Edited April 18, 2017 by Judith

[rich_is_bored]

The polygon count for your modules are too low. With matching textures, the scenes depicted could easily be recreated with a few brushes and the clipping tool.

 

It's important to note that TDM uses a forward renderer. For each light, for each entity, render a pass. Every module in view is going to get a separate draw call. And if you're incurring the penalty of a draw call and not throwing a considerable number of polygons at the GPU, you're not getting your money's worth.

 

I recommend beveling a few of the hard edges and making use of smooth shading.

[peter_spy]

I thought about it too, at least the middle section could have those bevels and insets left on geometry, and it still would be something like 200 triangles That was just the fastest way to make proper UVs (I really hate unwrapping in max). Making it with brushes wouldn't make sense, there would be a lot of micro-adjusting for corners and such, and all those surfaces would be treated as unique geometry, so that's even worse for performance. Here you have maximum of 12 models, all using one texture.

[rich_is_bored]

Have you used the clipper tool with brushes much? It's very easy to make mitered corners.

 

 

As far as performance, it's a tradeoff. You consume more memory with brushes. You consume more draw calls with models.

[Bikerdude]

It doesn't affect the inspector window. That rotates around the origin regardless of the other setting.

I must have some setting enabled, because a lot of models and prefabs arent rotating on the spot but around some other origin away from the model.

[peter_spy]

Have you used the clipper tool with brushes much? It's very easy to make mitered corners.

 

 

As far as performance, it's a tradeoff. You consume more memory with brushes. You consume more draw calls with models.

 

 

No, I always preferred making meshes to using brushwork, mostly because in Thief 3 the geometry tools were shitty, and anything more complex caused errors in the renderer. Also, in Unreal engines, brushes had no smoothing options whatsoever.

By the way, your example uses 2 or 3 different tiling textures, isn't it even bigger performance impact? Or at least memory consumption.

[Fingernail]

Hey guys it's me (what??!)

 

I started making a map the other day having downloaded 2.05, and using some (many) of both Springheel's modules and other models in the package, and found them pretty easy to use. That doesn't mean they're totally seamless - I ended up with various gaps and stuff because of the dimensions of the walls/buildings I wanted, and had to fill with a variety of creative trim, but that's actually often how (especially older) buildings are contstructed, repaired, added to, patched up over time. You could easily end up with a very grid-like contstruction otherwise, which would fit some aesthetics but not others.

 

I'm probably a pretty sloppy mapper, technique wise, but I guess in the end it comes down to how you prefer to work as much as anything - brushes vs models, etc. As rich says, performance is always going to be a tradeoff in some respects.

[Fingernail]

 

 

No, I always preferred making meshes to using brushwork, mostly because in Thief 3 the geometry tools were shitty, and anything more complex caused errors in the renderer. Also, in Unreal engines, brushes had no smoothing options whatsoever.

By the way, your example uses 2 or 3 different tiling textures, isn't it even bigger performance impact? Or at least memory consumption.

The reason I'm using SH's modules is because their detail is completely above what I could reasonably achieve in brushwork or patches (or doing so would be a huge waste of time and very inefficient). I'm also not saying SH's modules are perfectly constructed. But your example could easily be achieved, and actually would be more flexible in brushwork, you could do different heights of panel, more angles etc.

 

I realise modules can't easily be resized, so the attraction has to be:

 

1) I couldn't make it in brushwork or patches or

2) It looks better than brushes would do

 

That's not to denigrate what you made, which is a lovely texture! And you've used it, as you said, in the way that you personally prefer to map. We can argue till the cows come home about performance gains.

 

The much more detailed panelling, or the wooden vaulted roof in your cathedral photo above would be better candidates for modules that would appeal to other mappers, I would think. I've never been very satisfied with the look of vaulting made of patches.

[peter_spy]

Thanks, Fingernail, I'm 100% with you on this one. This was a simplistic and fast example, and probably the most efficient use of texture space ever , since modelled panelling would require exploding this mesh into smaller parts on the UV, etc. etc..

 

To be more precise, the best practice would be somewhere in between my example and stuff we already have in TDM library, where number polygons can be higher than the shape seen ingame would suggest.

 

Also the our approach might differ because of the background: in Dromed you didn't use models until it was absolutely necessary. It's kind of the other way around e.g. in Unreal engines, and in modern games in general. I can only guess that professional devs can't really choose between having an impact on CPU/GPU or memory – at least with all consoles up to X360/PS3 generation, they had to conserve memory, so their workflow is in part a result of that. Current gen consoles have a lot more memory now, so that might have changed a bit.

Edited April 18, 2017 by Judith

[Springheel]

I must have some setting enabled, because a lot of models and prefabs arent rotating on the spot but around some other origin away from the model.

 

If you rotate using the right mouse button, it rotates around the origin. If you use the left, it rotates around some abstract point behind the camera (I might have those reversed).

 

@Fingernail

 

Wow! Blast from the past. How are you doing Finger? (glad you're enjoying the modules btw. They're far from perfect but you can do pretty cool things with them).

[peter_spy]

As far as performance, it's a tradeoff. You consume more memory with brushes. You consume more draw calls with models.

 

Btw. I'll have to do a little more reading on that, since my knowledge on ins and outs of rendering pipeline is pretty fragmentary, but aren't brushes actually consuming more drawcalls than meshes? I remember reading that with CSG, every face is treated as a separate object. And also, the multi-material meshes are bad, because such mesh is split into smaller meshes, per material, before being fed to the GPU, thus more drawcalls?

[nbohr1more]

I think you're right there.

The only savings on Brushes is BSP culling which (in this engine) is very conservative.

 

 

Edit:

 

 

 

The engine will split the polygons it sends to the video driver per texture, per light, per entity, and per portal area. That means that for every light volume in the scene, a batch is sent for every group of polygons sharing a texture affected by that light volume. If the same texture appears on brushes in the world and on a func_static, even within one light volume the func_static will go to the renderer in separate batches. If a func_static with the same model keyvalue is repeated sixteen times down a hallway, each one will batch separately from the other fifteen. If you have a long, highly subdivided patch mesh with four or five chiclet lights spaced out along the curve, the curve will be split into small batches for each light.

 

 

https://www.iddevnet.com/quake4/LevelEditor_Performance

 

So it seems that all brush-work of the same texture, touched by the same light, in the same portal area should be one draw.

Of course, "same texture" is a very strict term which only applies to a texture tiled over the geometry with the same UV and scale,

hence how shifting textures ( brush carving ) can be used to split brushes at light boundaries.

 

And then, with brushes, everything is dynamically generated per PVS view which seems to make them heavier in most scenes compared

to the same scene with lots of proper func_statics or models.