peter_spy

I thought about something similar just for randomising purposes, but it would be easier to achieve it just with switching visibility of meshes, walls for doorways or unfrobable/frobable doors. I wouldn't worry about splitting map into parts if the design allows for having transition zones reached only by player, i.e. with ladders. If you'd use the same textures, materials and models across your maps, loading time should be relatively short.

Looks good, you might want to put it on Sketchfab to show off the materials a bit more

A small update: slightly reworked trims made big difference without raising triangle count too much. Straight modules have 26 triangles, corners are joint together now to decrease unnecessary extra drawcall for left and right side, so they have a bit more, but still, 127 triangles is nothing these days

Healthy criticism is fine. You just need to know when to stop refining your work, because at some point it's diminishing returns. It's important to take breaks or ask for feedback, because that really contributes to quality of your work. I see that especially with textures and materials, the first version is rarely good. 3rd, 4th iteration is where I can say: "now we're talking!". I don't think speed should be a relevant factor in modelling until you're confident with your skills, when you know your workflow is solid, but could be improved. Actually, speed and ease of use is more important while placing models in your map, so it's better to spend a few extra hours on careful planing in that department, especially if you want to release your models to the public.

Oh, so there's a reason for it, like e.g. in Dark Souls, where catacombs could go completely dark to scare the shit out of you? I just started playing, so I didn't see a point to it yet. Maybe it would be better to use zones and change ambient for interior locations, while leaving it a bit brighter for locations where you can see the sky then.

Thanks for the kind words. You're right about the model, of course. At first I was thinking about giving the middle section some more depth, while it's the trims that will look better with some more polygons and variety in angles. Also, it's the fastest and easiest way to improve the look of the model, while it still will be very low-poly. There's no need to keep the higher-poly version of those trims, especially that this shape has polygons that are 1 or 2 units wide. Without proper texture they'd look almost invisible anyway. And, you can easily fake it with proper diffuse and normal textures, and just get something in-between on geometry level. The goal is to keep a healthy relationship between mesh shape and final (possibly just one) material, so the overhead can go for other uses, like AI, physics and such. I've been using the r_showtris command a lot lately, it's been very useful for studying both meshes and brushes. Also, I have my autoexec.cfg with seta image_downSize command ready, so I can see how the artwork holds up when scaled down for optimisation. I must say I'm quite pleased with the results Well, that's not the worst thing I've seen lately, take a look at this: "You think anyone will notice?" "Nah, leave it."

My only complaint atm is the ambient brightness setting. It's almost pitch black. I had to crank up gamma all the way up to see anything.

On somewhat related note, the way this engine handles parallel mesh surfaces is amazing. Typically you need two adjacent mesh walls to use some kind of angle, because you'd see dots or shadowing problems where the two mesh edges meet. Not in idtech4: Meanwhile in UDK:

Good find, I also just found this: https://simonschreibt.de/gat/renderhell/ but that requires a longer reading session. All in all, industry moved away from brushes almost completely, using it only in prototyping stages. In UE3/UDK and later engines you can have your level geometry built entirely out of static meshes.

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?

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.

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.

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.

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.

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.

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.

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: 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.

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.

Thanks Biker, I already added it to my notes, this will be written huge block letters To illustrate it better: This is what you typically do before export. Notice the actual pivot (big arrows) aligned with the move gizmo in 3dsmax. This is what you should not be doing, even though you do that for all other game engines: If you export your mesh and load your map, the lightning will look like this: Don't mind the mesh distortion, I added it to see whether subdivisions help anything (they make it even worse). There are two lights here, btw. and it looks like there are many more. And see this weird stuff at the top? Now, this is mesh with a pivot that didn't have any rotation/scene alignment. As you can see, axes are not aligned. And for idtech4 this is alright. In other game engines this piece would be imported horizontally. And finally, everything is works as it should. The disaster has been averted

After several hours wasted, I finally found the source of the problem. Typically before exporting, you adjust mesh pivot for proper snapping, and you Align the pivot to the world (i.e. to current scene in 3smax), so the mesh isn't e.g. turned on one of the sides after importing it in game engine. YOU MUSN'T DO THIS IN DARKMOD. Looks like the initial rotation of the pivot is used by the idtech4 as a reference to calculate specularity and cubemaps for the polygons. When you align it to your scene in 3dsmax, you'll mess it up. You can still move the pivot, just don't rotate it. This is for ASE files btw., not sure how it works with LWO.

Alright, box mesh works well with this material, while the plane mesh does not. That doesn't make much sense to me, since I already made objects like columns with open edges and some of their polygons deleted, as they're never visible. They work okay and cast proper shadows.

Also, it's not that today's economy is only about giving customers what they want. Otherwise companies wouldn't rely on psychology of addiction and its studies to make consumers "love" brands from the earliest age possible, so any purchase is as emotional as possible. Food industry pours tons of sugar, fats, and salt to everything they make, to get "optimal ratio" of those ingredients for every kind of food, because that makes your brain scream with delight with every bite or sip. The general idea is to make children consumers and decision makers as early as possible, and to make adults as childish and irresponsible in their spendings. This has been going on since 1950s-60s. Our brains are simply not ready for that kind of addictive properties of, well, everything. There are corporate R&D departments and science teams basically making people's lives more difficult or miserable like that, just because their boss needs to see 10-30% YTY growth in his Excel spreadsheet.

That shouldn't be a problem. There's something wrong with that meshes, because the same material put on brushes looks fine: At first I thought the planes might be too big for proper specularity, so I might need to more subdivisions, but then this happened

I just had a few hours this month for editing, so I probably won't be able to solve this right away, but is it just me or IDTech4 doesn't like using overlapping UVs? The lightning looks pretty weird and the material looks metallic, even with proper specular. I'm guessing that's what's causing problems and those IES-like lights. After I fix this, I'm planning to write quick guide on how to design a basic flexible tileset for this wall panel. This is one texture and one mesh by the way, just split in sections and variants, to cover as many uses as possible. All with properly placed pivots, so you can place it in seconds. This was made with grid of 16.

It's not that good, I mean definitely not as good as Dis1. It has its moments, but it falls apart as a whole. What about some mindless fun in new Doom?