The Builder Compound

[Guest]

Builder Compound Pack will help you create better environments for your Builder-themed map sections! The aim of this experimental package is to provide high-quality models, materials, and other assets that don't put a big strain on the idtech4 engine. This early version is slightly more bare-bones than I wished for, as some modular sets (e.g. the roof) proved to be too complex and unfit for general use. Don't worry though, the set will be updated and expanded in future releases.

 

Tweaks

– Arch door and arch with hinges models have been removed. They were just static models, not actual door entities, and they weren't super useful, e.g. hey couldn't act as visportal closing entity due to gaps and transparent parts.

– Detail texture stage added to selected materials (mostly those you can get very close to). As you approach a surface, you should see a slightly grainy layer that enhances the details.

New content

– Door01 and door01_frame have been added to both models and entities. This is a basic door for this corridor section. By default, it's locked (with easy lock) and AI will notice if it's left ajar. You may want to disable the latter (set ShouldBeClosed to 0) if you have a section with many AIs and doors, as it will probably disrupt AI patrolling too much.
The frame will work with walls that are 16 units thick. Both door and the frame will work with grid of 8 and smaller. You can use the grid of 4 to change the  door position within the frame. Look for grooves in the frame model.

 

First of all, launch the map to see a simple section that was made with these assets. Use the menu or type map bc in the console to start the map. Noclip though the north wall, if you want to get to the staging area and see all pieces used to make this section.

 

General info and tips:

Make sure you have Rotate func_* entities around origin (Ctrl+R) enabled (Dark Radiant top icons) to use models efficiently. All models have custom pivot / origin point placement to make them snap to grid and geometry really fast. If you have keyboard shortcuts configured for RotateSelectionX/Y/Z and FloorSelection, placing these models around the map will be a breeze. I also recommend having shortcuts for SelectNudgeUp/Down/Left/Right, so you can move models in ortho views without using a mouse. DR detects models in a weird way, e.g. if your model is one-sided, or has some faces turned back to the camera in ortho view, selecting and moving it around will be difficult. Using keyboard is often more seamless and precise. You can select a model in perspective view, and then move it around in X/Y/Z plane using keyboard.

Optimal scale for tileable materials is 0.125. This provides good pixel density vs repetition. Materials are optimized to be used both with and without post-processing, and the default gamma of 1.2. In some cases, specular hotspot might look slightly overblown with post-processing enabled. Correct look without post-processing was the first priority. Same principles apply to using lamp.

The main idea behind this set is that you can use simple brushes for walls and floors, and wall panels have proper offset, so you don't need to use special surrounding BSP behind them. You can place panels right where your walls are, and there will be no z-fighting or clipping.

Assumed basic measure for a corridor is 192 x 192 (length / width), but you can go lower if you don't plan to use arches and metal doors. The smallest wall panel piece is 24 units long. Use brushes to create basic space, then adjust it to what you can make with wall panels (combinations of 24, 48, 96, 192 etc.). DR's measurement tool is your friend.

Default grid for placing most pieces is 8, but it goes down with smaller / more complex models and setups. One special case is matching metal doors to arch with hinges, this needs grid of 2. That's a mistake on my part. I didn't think of better pivot placement until it was too late. The example map contains a "staging area" where you'll find grouped arch, hinges, and doors, so you can use that as a template.

As per The Dark Mod license, you may modify this pack's contents, although I'd advise against it. Most textures are compressed in lossy DDS format and compressing them again will result in loss of image quality. If you want to make changes, need alternative versions of a model or material contact me first. I'll see what I can do.

Last but not least, I hope you'll find this pack useful and fun to work with, as I had plenty of fun while making it I already have a long list of models and features to include in subsequent releases, but I'm always open to feedback and suggestions. Thanks!

Credits:

Springheel, Obsttorte, Spooks, nbohr1more, STiFU, Destined and other TDM Forum members: guidance, encouragement, and fruitful discussions

Epifire: asset feedback and critique

The Black Arrow: inscription texts

Plans for upcoming releases:

Corridor:

- Fixing the wall panel collision model, so strafing along it isn't wobbly Done.

- Roof modular set Done.

- Making metal door an entity with proper sounds and open/close times. Done, made proper door instead.

- Floor switch model/entity for metal doors

- Window set Done.

 

Roadmap:

All work is on hold for now. I'm working on a small FM that will use some of these assets plus many more. Some of existing assets will get reworked too. All links are taken down, and I have no release date yet, sorry.

Edited December 30, 2023 by Guest
Update

[New Horizon]

Congrats on the release!

[Goldwell]

Congratulations Judith!

[grayman]

Yipes! Getting this one.

[jaxa]

Your example screenshot looks gorgeous.

[AluminumHaste]

Very very nice work man, thanks for contributing to the game!

[Guest]

Thank you!

 

Sorry for somewhat rushed description, I wanted to have this released before I went to sleep yesterday. Readme has some more details. I'll try to make it more clear later on.

[Bienie]

Oh man, right on! I will definitely take a good look at this set once I'm finished with my current FM. Looks amazing! We sorely needed a good builder themed module set, thank you so much for taking the time to create it!

[Guest]

Thank you! This is still an early stage though, there are no windows, or roof, I have to rework some of the models like the wireless generator, candles, wall panels will need a clip/collision model, because moving nearby them is wonky, etc. The list grows

But I wanted to expand a bit on why I tried to make something like that. During my first months with TDM, I was getting to know the editor and the engine, and testing their capabilities. My knowledge about engines, editors, and making content is related to Unreal engines, but most techniques are rather versatile and engine-agnostic.

While I was browsing TDM model/material/entity folders, there were a few things that looked like instant red flags to me (at least from what I know about gamedev and content creation workflow). Materials often had many stages, and the number of materials per model was often very high (here you can read why this is bad). At the same time, most materials didn't use specular workflow (here you can read why everything is shiny and how to achieve it in a non-PBR engine). I think I understand some of these decisions, like using simple projection mapping and multiple tiling materials everywhere allows the mod to be a 3 GB download instead of 8.

At the same time, I was curious if by using "standard gamedev approach" to asset creation and optimization I could both yield better performance and have higher quality of assets. By that I mean using 0-1 UV space for texturing, unwrapping more than one model per texture space, and using as few (and as simple) materials per model as possible. The example map is a bit barren at the moment, but I think the answer to that question is a cautious "yes". These are the longest views / highest drawcall counts I could find.




So, even if this environment was more complex and DC count was doubled, this would still be a pretty good result. What's also important, the CPU and GPU load looks like this:


37% GPU is probably due to factors like 2k textures everywhere, FXAA, and 1440p. These are stencil soft shadows btw, not shadowmaps. I think in that regard 10% CPU use looks promising here.

So "the standard approach" seems to be working well with the engine, graphics pipeline looks less disrupted. The only downsides are larger file sizes and less flexible model/material editing options (although you shouldn't edit and re-save compressed DDS textures anyway, you need source files for that). Gamers are used to everything between 15 to 50 gig downloads these days, and GPUs with 2 gigs of VRAM are considered quite old. So, I think this is rather safe concession to make. If the model library is comprehensive enough and uses skins for variation, mappers will find ways to kitbash geometry to keep things fresh for a long time without editing textures or models much.

 

There's also one important problem, the asset creation time. Using full specular workflow, making 2k textures, baking normalmaps, designing modular sets, all that takes a lot of time. Sometimes, and especially for one-man projects, it's easier to switch to something less complex and faster to deliver. But it's also hard not to love how the engine handles all the good stuff you're making for it

Edited February 20, 2019 by Judith

[Bienie]

Wow, those modules look great! I'm very impressed particularly by the low drawcalls and CPU load. That's usually the "limiting reagent" when I'm mapping, quite often having to cull things to bring DCs down, and I feel like the game is pretty CPU heavy in general. Great work!

[VanishedOne]

This will be really useful.

 

A couple of minor concerns (aside from whether the inscriptions read well; that's a matter from the other thread): (1) the open grilles at the bottom of the doors: I can see how a player would use them to his/her advantage, or be disadvantaged by light passing through, so for gameplay and aesthetics it's an interesting feature (and I expect it might cast some dramatic shadows), but as a mapper you'd have to treat such a door as a door containing a window and set it up not to close visportals.

 

(2) I see the banners have ladder surfaces built in. That's good for consistency in that all banners sharing that appearance will be climbable, but bad for consistency in that the banners in the core mod aren't set up to be climbed, and I'm not sure how one would convey to players that these are climbable banners. (There's a T2 mission that expects players to realise they can climb a banner near the start, and it caused a lot of confusion.)

[Guest]

Open grilles were frobable in previous iteration, and you could go under the door. But the whole set looked oversized, so I had to abandon the whole idea after scaling all the models down. Even when fully closed, the door don't cover the whole arch space, so you can't use them to close visportal. You can use a func_portal to make it a proximity-based occluder, or do the same for particular entities behind doors with LOD system. I find func_portal and LOD system very useful, and I think it should be used more often, as it gives you almost direct control over what appears in player's visleaf and when. It does take additional time to set up, but performance benefits are great.

 

I want all my banners to be climbable, as this enables more interesting traversal options. I had an invisible tutorial in mind to include with example map, but that would have prolonged the release. Now that you brought it up, I think I should include it in the next release, so mappers have an idea how to teach players that rule.

 

Thanks for the feedback, it's really useful!

Edited February 21, 2019 by Judith

[Springheel]

Kind of a tangent, but how would someone climb a banner in real life? There's literally nothing to hang on to.

[RPGista]

Congrats on the release. Im sure the community will use these a lot. You have to appreciate the methodical approach taken on planning and creating the assets, the attempt to use the engine to its full capacity in terms of shader design. The result is very expressive. I also noticed that your textures have a slightly stylised look to them, it appears that they are made in a procedural way, instead of based on real life photos. This gives the scenes a unique feel. Great work.

[Obsttorte]

Very nice work.

 

Regarding the climbable banners: there isn't much consistancy in what and what not should be climbable in FM's anyway, so if you want it like that it's fine imho. What may cause issues though is that if you are planning other mission authors to use those models, then it may happen that they don't realize they are climbable, as typically most if not all models aren't climbable by default and a specifically textured brush needs to be added to allow for climbing. As your approach with having them climbable by default goes in a different direction, you may note this in the comment section of the specific entities.

[Guest]

Thanks. Textures are indeed not based on photos. I mix patterns, colors, and dirt to have better control over the final look.

 

Banners will always show their yellow ladder hull when placed in DR, so mappers will notice that right away – you can't turn it off with filters. I was thinking about making two versions, but I want these banners to be systemic, so if player notices it, their first instinct will be to use it. Having both climbable and not climbable version would probably cause confusion among players going from mission to mission.

[Springheel]

You included the ladder texture right into the model itself? That's interesting. I thought those textures were like monsterclip, and wouldn't process properly if they weren't worldspawn.

[RPGista]

Yeah, cool to know, its probably the material that counts, not the mesh/brush.

[Guest]

You included the ladder texture right into the model itself? That's interesting. I thought those textures were like monsterclip, and wouldn't process properly if they weren't worldspawn.

 

Yeah, for some reason it works perfectly fine, in similar way to collision hulls. Have you tried adding clip or monsterclip as additional material to a model too see whether it works?

[Springheel]

Yeah, I've tried adding monsterclip, but that texture doesn't seem to work on models. Regular clip textures work for collision, but not for pathfinding.

[VanishedOne]

Ladder surfaces don't even have to be static: see the stepladder prefabs.

 

Banners will always show their yellow ladder hull when placed in DR, so mappers will notice that right away – you can't turn it off with filters.

Actually you can make a custom filter that hides textures/common/ladder(.*) -- I just tested and it works. You're right that there's no such built-in filter though.

[Guest]

Next release will feature modular roof parts and truss. While it's typically meant for corridors linking two locations, you will be able to use it for more complex structures:

 

Edited March 5, 2019 by Judith

[VanishedOne]

Bug report: lamp01_blue isn't blue. (I found the intended colour by examining the sample map.)

[Guest]

You mean the light entity. I'll put proper _color values in the in the next update (it should be 0.282 0.533 0.784).

[Guest]

|Fixes|

- Fixed lamp01_blue light source entity which was actually orange (thanks VanishedOne).

|Tweaks|

- Material type for floor01 is now surftype15 "tile".

- Fixed collision for woodpanel01 pieces. You can now strafe along it while crouching, without collision issues.

- Fixed collision for carpet pieces. Walking on folded parts is now smooth for both player and AI.

|New content|

- Additional length variants for woodpanel01 pieces. Now you don't have to combine pieces to have intermediary length values like 168, 144, 72, etc. This way you can use fewer models and lower the drawcall count even further.

- Modular roof parts and roof truss.

Edited December 30, 2023 by Guest