Jump to content
The Dark Mod Forums
peter_spy

Builder Compound Asset Pack – v0.46 (tweaks / new content)

Recommended Posts

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

  • Like 2

I always assumed I'd taste like boot leather.

 

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

obraz.png
obraz.pngobraz.png

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

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 by Judith
  • Like 4

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 2

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Share this post


Link to post
Share on other sites

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 by Judith
  • Like 3

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.


Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Share this post


Link to post
Share on other sites

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

  • Like 1

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Share this post


Link to post
Share on other sites

Version 0.41 is up. (edited the first post as well)

 

Download link (69 mb)

 

|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 by Judith
  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...