R Soul

Could someone explain the cause of this problem, and suggest the best solution? Here I have a path with a slight bend: The curved part of the wall is a mesh, with a simple set of Caulked brushes behind it. You can see that the triangles looks unpleasant. Long thin triangles don't seem like a good thing. Here's a DarkRadiant screenshot with the func_statics turned off, and the brushes selected: All the vertices are snapped to the grid (I think I had to go down to 1 to get the path texture lined up nicely at the corner). If I turn the pathway brushes into func_statics (with Caulk underneath to seal), the in game result is much nicer: It works, and the AI have no trouble walking over it, but is there a better solution? I can live with this for one part of the map, but if it occurs elsewhere I'd prefer a more elegant solution.

I've recently been working on a set of intersecting arches using meshes made in Blender, but I don't have much of a feel for how good or bad performance is. Here's a video of me looking around a section of my map: Do those numbers look okay for the sort of detail you can see? Bear in mind there's another set of arches on the level above, and I'd like to have another level with some more pillars, but a flat roof. And one or two archways at ground level. Can someone with more experience tell me if that's wise, or if it's likely to cause performance problems? The wiki page says the drawcall limit should be 4000, and the shadows limit 80000, but those numbers might be intended for a large outdoor area. Values of 3000 and 60000 for a small bedroom would clearly be ridiculous, so I'm not sure I should just be comparing my scene to those standards.

A nice set of drawings of old London: http://spitalfieldslife.com/2015/12/27/a-walk-through-walter-thornburys-london/ "old cramped streets" is a good search term edit: A few questions, which may require speculation to answer: These images all have show thick wooden beams: http://spitalfieldslife.com/wp-content/uploads/2014/03/forgotten.jpg http://spitalfieldslife.com/wp-content/uploads/2014/03/forgotten_0017_2.jpg http://spitalfieldslife.com/wp-content/uploads/2014/03/forgotten_0017.jpg Would they be structural? I can imagine in the last two images those beams being used to brace the walls. In the first image I can imagine clothes lines, but those beams are much too thick for that purpose. It's nice to provide climbing opportunities, but it's also satisfying to know that those things are perfectly valid, and not just for gameplay.

Here's some nice architecture, and best of all, some ghost legs: https://www.google.co.uk/maps/@48.6358574,-1.5115812,3a,82.3y,47.98h,92.81t/data=!3m8!1e1!3m6!1sAF1QipMajabCre2_ak7kJuaXP00Xjpf2o8phHZ6CDoTJ!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipMajabCre2_ak7kJuaXP00Xjpf2o8phHZ6CDoTJ%3Dw203-h100-k-no-pi-0-ya75.31492-ro-0-fo100!7i8704!8i4352?dcr=0

Thanks for the tip. http://bugs.thedarkmod.com/view.php?id=4764

At the moment the materials browser shows a list of material names, but only when clicking on each one do we see the editor image. It would be nice if each time we selected a category, we then saw a grid of thumbnails, like the texture browser, so we could see them all.

A set of houses which used to be a childrens' home: Google Maps link The buildings have some nice architectural features. edit: Those staircases are nice, Arcturus, but we could do with some way of stopping an AI using them if another is going in the opposite direction.

Since there was some disagreement, I did a test with a blatantly wrong collision model, and can confirm that when a model uses materials from tdm_collision.mtr (tdm_collision_metal, tdm_collision_stone etc), their polys are the only ones that affect collision. A comment in the .mtr file also states that they take over AI vision blocking too, instead of the visual model, which is a bonus.

If a model has a collision material, does the engine only use that for collision? I.e. does it disregard all other polys when collision detecting? If so, how does it know what material sounds to use? Does it perform some kind of hit testing to the nearest real poly? I looked at a barrel model and noticed there's nothing in the material def that disabled collisions. Edit: I just noticed (or re-noticed, since I saw this ages ago) that there are materials for collision stone, collision wood etc, which happen to share the same texture, so that answers the surface type question.

Hi all. While browsing the textures I found that there's a 2d tiling cement texture that has no material. stone/flat/cement_002 This is from a set made by Gleeful. There are some tiling 1d versions which seem to be all present and correct. I made a material file, normal map and editor image for the 2d tiling version. See the attached file: cement_002_tiling_2d.txt (rename to .zip)

Thanks, that's good to know, though I can't even imagine making a model with 5000 triangles.

It's working now. The distance property name should be lod_1_distance, not lod_distance_1. I appreciate the advice, and I've learned a bit about entities. : thumbs up smiley: def file: entityDef atdm:stone_arch_01 // 3d stone bevelled arch { "inherit" "atdm:lod_base" "editor_displayFolder" "LOD/architecture/arches" "editor_usage" "Stone arch with 3D bevelled edges. ~800 polys. LOD 1 model ~500 polys." "model" "models/darkmod/architecture/arches/stone_arch_128.lwo" // high poly model "model_lod_1" "models/darkmod/architecture/arches/stone_arch_128_lp1.lwo" // lower poly version "lod_1_distance" "600" // distance setting } edit: Note to self and anyone reading this: don't use hyphens in filenames. Other things may get messed up.

Can the LOD posts be split in to a separate thread please? I think it'll make it easier to follow than if we have two people's questions running simultaneously. edit: Thanks, that was quick. I've tested with other LOD entities and they all switch models just fine (even when I use my two models), so I think the problem is related to the 'def' being in my FM folder rather than the TDM installation. The hide distance works properly.

Still no success. In my FM folder I have 'def/architecture.def' with the following: entityDef atdm:stone_arch_01 // 3d stone bevelled arch { "inherit" "atdm:lod_base" "editor_displayFolder" "LOD/architecture/arches" "model" "models/darkmod/architecture/arches/stone-arch-128.lwo" // high poly model "model_lod_1" "models/darkmod/lights/non-extinguishable/streetlamps/roundstreetlamp_02.lwo" // lower poly version "lod_distance_1" "600" // distance setting } Notice that I'm using a completely different model for lod 1 so I can be absolutely sure that I'll notice a change (LOD changes are meant to be subtle, after all). It appears in the entity class tree as fms/atdm:entity_base/func_static/atdm:lod_base/atdm:stone_arch_01. The other four key-values set in the file are present in the properties pane. The entity is created correctly in the 2d view and I can see its properties, which all match the above. The high poly model shows up in game but it doesn't change no matter what distance I try.

That didn't work, but what did work was to use atdm:lod_base as the classname instead of func_static. I'm aware of the possibility that something may work, but with consequences, so do you think that solution is okay or will something explode?

Is there something I have to do to enable the LOD system for an ordinary object (i.e a func_static)? I created a model (the higher poly version), then added an lod_1_distance of 300 and a model_lod_1 referring to the lower poly version, but in game I only see the higher poly version. I've also placed a "atdm:brazier_large01" entity which confirms that LODs are working when set up correctly. Do I have to use an entity or use some other class? I've tested the lod 1 version as an ordinary model and it shows up correctly in game. Properties:

Thanks again Bikerdude. Your feedback is most appreciated, which is why, between 5:55 and 14:20, I was willing you to spot that you'd filtered out clip textures. The brushes in that area aren't new, but I extended two of the buildings to make the street less wide. I fixed the error near the start of the map, and removed the 'overkill' visportal. The big diagonal VP actually is sealing, but you put the camera inside of of the brushes (the one with the brown blocks) My reasoning for that angle was to hide what could be seen from the other end of the nearby tunnel: Even as the player gets to the end, the VP is still closed: I'll try out your alternative suggestion for that area to see what it's like. It may end up being about the same in terms of visible area. On the subject of reducing the thickness of visportals and blocking caulk brushes, is that just because it's easier to see through them to the other brushes, or is there some other reason? I also appreciate your offer to make the modified map available, but I think it's best to work on these brushes myself. It gives me a better feel for what's going on. Thanks again.

Many thanks for the advice Bikerdude, and I appreciate the effort of making a video. I've made some changes which anyone interested in can view here: tut.txt (pk4/zip file) I've doubled some of the visportals as Springheel suggests in this New Mappers Workshop video: https://youtu.be/RmKjmt7IJr8?t=389. If we don't have a name for that arrangement, I suggest "airlocks" because of how close they are to each other.

Hi all. I've had a few goes at building (mainly streets) but after coming up with very basic and small sections, I find myself reluctant to go further in case I've made some fundamental design error that's going to make things very hard later on. E.g. I know that visportals are essential, and that we can seal outside areas using PortalSky brushes, but do I really understand them? With previous building attempts, I've used one huge set of PotalSky brushes to allow me to make brush changes without the hassle of inadvertently creating leaks, but it's occurred to me that I may then end up with architecture that makes it very hard to create more localised sealing and good visportals. For my current attempt I've tried to keep things tighter - sealing areas locally and making visportals rather than just thinking about adding them later. Adding a new street is more of a hassle because keep creating leaks, but I'd be interested to know if that's preferable, for a noob, to leaving it to the end when it may prove impossible. Please see this attachment for my very small set of streets: tut.txt I've be interested to know if it seems like I have the right idea with visportals and PoralSky brushes. To me the latter look a bit messy, but it might be the only way when there are buildings with multiple heights (and I'd like to add pointed rooftops eventually). I'd also be interested to know if the street layout looks okay to work with, e.g. do you see any problems with adding more detail, and interiors for some buildings?

My condolences.

The background mesh is useful but it can get in the way as brushes are created. Obviously it can be hidden by filtering func_statics, but that hides all meshes. It can be hidden with 'H' but I don't know if there's a way to unhide a specific object. It's useful to have a layer just for the background mesh(es), but at the moment I prefer a custom filter. Set the name of the mesh and define a custom filter: Type: entitykeyvalue, entitykey: name, match: bg\w*, action: hide bg\w* means the name must begin with bg and can be followed by any number of things, which allows multiple background meshes to be hidden or shown. I decided I didn't like having no material applied, so I set up a basic one before exporting the mesh. In DR it has the property 'hide' set to 1 so it doesn't show up in game.

Perhaps those marks could be escaped with a preceding \ in front of each of them.

On reflection I think that '03' name would be better. Some people may be relying on the original plain yellow. Renamed files: new win glow.txt It's still using the normal map from the '02' version.

I only enhanced the glow of the editor image. The diffuse texture is less bright. I've removed the outdated material code, although a quick scan of the TDM mtr files suggests it's still present in many files.

Here's a good base for a glowing glass texture: https://upload.wikimedia.org/wikipedia/commons/b/bd/Snow_Glow.jpg A bit of blurring and a grimy overlay are recommended. Using that, I changed the original diffuse texture for textures/darkmod/window/largesquare02_lit, so now it looks like this: The files are attached in this post: http://forums.thedarkmod.com/topic/8991-nominate-poor-textures/?p=417482 (includes a missing specular map for the unlit version) Here's roughly how I edited the original texture: Opened the original dark glass version. Split the frame and glass into two layers. Made the glass greyscale (and maybe tweaked brighness/contrast etc) for more use later. Found this photo: https://upload.wikimedia.org/wikipedia/commons/b/bd/Snow_Glow.jpg Scaled and pasted into image. Copied to duplicate layer and blurred. Changed transparency to finely control the blur/sharpness. Duplicated the frame layer and made it darker to cancel out excess brightening from mtr 'addition' stage.