OrbWeaver

It doesn't have to be symmetric, but all of the shaders I've seen so far are symmetric in their Z falloff, including the commonly-used ones like biground1. If the projected Z coordinate goes from 0 to 1 then these textures will give surprising results when applied to projected lights, which (I assume) most users will expect to be brightest near the light origin, not halfway along the target vector. But of course DR should mimic what the game does, so if the game uses the full 0-1 range of the Z falloff texture then DR should as well, even if it doesn't really make sense for most light shaders (and changing this in game would be a bad idea because it would affect the lighting in existing maps). I can't speak to the original game design, but in terms of DR, there is no restriction on where you can drag the right and up points, so it's quite possible to set up a projected light with non-orthogonal vectors (the frustum in this case becomes a sort of weird rhomboid shape). I guess the game is just taking this possibility into account by not assuming that the vectors are orthogonal when calculating the matrix.

I was confused when I was looking at this code (to see if I could integrate it into DR to fix projected light rendering). I wasn't sure why there were "old" and "new" conventions, but if some of this code came from BFG and some from Doom 3, this would explain the distinction. Our shaders use W for the divider as per normal expectations, and use projective texture lookups for S and T (i.e. S/W and T/W are what gets rendered) but not for Z, which is undivided. As you say it would be possible to put the divider in Z if the shader was updated but I can't really see the point of it. In DR the Z coordinate is used for the falloff texture, so the light will become dimmer as you move further from the origin. Is this not what the game does too? Do D3 projected lights have the same brightness along the whole target vector, or do they dim based on distance? Our (DR) Z goes from 0 to 1, but this is actually wrong: the falloff texture is symmetric about the 0.5 position, so our lights are actually dim near the origin, brightest halfway along the target vector, and then dim to black. I'm trying to fix this using my limited math skills so that Z goes from 0.5 to 1, resulting in maximum brightness near the "light bulb" which dims to 0 as you reach the end of the target vector. But if the game doesn't do this, DR shouldn't either.

Actually it doesn't — you can use rectangular images if needed, although it's best to keep to sensible (preferably powers of two, but at least multiples of four) dimensions: 128x64, 1024x256, 1024x768 if you must, but not 357x299. Alpha doesn't "just work" by default in the engine, you need to set up the material to use it. Probably the alphaTest keyword is what you want (e.g. "alphaTest 0.5" to show transparency anywhere the alpha value is less than 50%.)

You don't need to do that. The scripts work fine with 2.93 — I always check and update them with new official Blender releases although I do not do any tests with alpha or beta builds. I guess I should consider renaming the Git branch since it seems a few people assume that blender-2.80 means "Blender 2.80 exactly and no newer versions".

http://orbweaver.gitlab.io/DarkRadiant/#CreatingLights TLDR summary: press the L key to bring up the light inspector, and adjust all the properties in there rather than in the spawnarg list.

Be aware that the light projection texture calculation in DR is horribly broken, in particular if you "shear" the light by sliding the light_target point parallel to the target plane, the texture projection does not update at all and the light preview no longer matches the rendered frustum. If any of our maths wizards want to dive into the code and fix this, it would certainly be welcomed.

That's a potential copyright issue, isn't it? Or were there particular textures included with Doom 3 which were released under an open license when the D3 engine itself became open source?

I actually like those new sounds. They seem detailed and realistic, and sound like you are actually walking around on real surfaces with fairly heavy boots. The only one which doesn't work for me is the stone jumping — to me it sounds more like a kitchen cabinet being shut rather than an actual jump, and seems to have no consistency with the stone walking footsteps (which are very good).

By "rotate the building", do you mean adjusting the brushes and patches so that they lie at an angle while still being snapped to grid, or do you literally mean selecting the whole building and rotating it some number of degrees using the rotation tools? Because you almost certainly don't want to do the second one. Geometry which isn't snapped to the grid will cause all sorts of problems with map compilation and optimisation.

I'm referring to the first post in the thread, not the poll itself. Is it really supposed to look like this: Perhaps it's just a problem on my particular browser/OS combination.

Good luck with the contest, but I think the first post could do with some formatting. It looks like it was copy-pasted from a text document with hard line-breaks and multiple empty lines, making it somewhat difficult to read.

The Sword makes me think of its closest real-life counterpart: Winchester Mystery House. It was weird, but also attractive, interesting, memorable and atmospheric. Thieves' Guild was like the unfinished deleted scenes you sometimes get on DVDs: you can see exactly why they were deleted, and adding them back improves nothing.

The changelog is generated from the bugtracker, so only issues which have bugs logged will be in the changelog. Sometimes for really trivial changes like a single colour or icon tweak, I don't bother making a bugtracker entry (although really I should, it's just laziness on my part).

That's a very good start. One thing I would suggest paying attention to is the alignment between textures and brush edges. Having a thin sliver of bricks along the top of a wall or above a door is quite unrealistic, because walls are not generally built like that — the builders would need to cut loads of bricks to the right height to fit them in, which would be extremely time-consuming. Instead, you could use the "fit texture" controls in the Surface Inspector to ensure that an exact number of brick rows is fitted to the wall height, which is how it is typically done in real life.

Would it work to have a top level "meta project" which doesn't build anything itself but just depends on everything that is needed (including both UI and Core module projects), and have this meta project as the default? This would presumably ensure that by default you build everything, but if you choose to build just the UI it doesn't require the core module (since there is no actual build-time dependency). I'm not an expert on Visual Studio projects of course so this may be a completely daft or unachievable idea.

Sorry if I came across as snarky. I do not take any pleasure in the fact that you've lost work. It just seems so incomprehensible to me that people spend so much time working on something which is important to them, but not take basic precautions to protect their work against data loss, which is so easy to do. It's not like you need a professional automated tape backup system; just copying each day's work onto a thumb drive at the end of the day (or into a Dropbox folder) would be better than nothing. I certainly wouldn't physically kick a homeless person, but if the reason they were homeless is that they willingly spent all of their money on game consoles and SUVs and didn't pay their mortgage, I would be far less sympathetic than if they lost their home due to reasons entirely outside their control.

I would ask you the same question: how can you do this? Pour 4-6 hours per day for 3 weeks of your life into something and not make a single backup at any time? Do you just assume that disks and computers are 100% reliable and data never gets lost for any reason? It takes literally seconds to make a copy of your FM directory somewhere else, even if you are just manually doing it with Explorer rather than using one of the many available backup solutions, Dropbox, SpiderOak, Google Drive or whatever. Regardless of whether TDM has a bug with deleting FM directories (one of the core devs would need to investigate that; I don't know the answer) I'm afraid I have no sympathy for people who store an important ongoing work in a single place and never bother to make any backups.

Well you're entitled to your opinion, but I still don't get it. Recording reverb inside a sound effect is an obsolete technique which pre-dates (and conflicts with) reverb generated by the game (EAX, EFX etc), which is why our sound effects do not have their own reverb. I suppose our stone footsteps are indeed a little "clumpier" than Thief's and the tile footsteps are less high-pitched, but it certainly doesn't sound "off" to me. You're welcome to produce your own versions and then distribute this as a separate PK4 which people can download. I know at least one other forum member has done this in the past. If enough people like the alternatives better than the versions currently in the mod, they could even be integrated by default at some point.

Manipulating already-compressed OGG files is a bad idea since it introduces generation loss (and unfortunately the original uncompressed files were not all retained for subsequent editing). Although to be honest I really have no idea what you are talking about regarding the footsteps. Both stone and tile sound (to me) very similar to the original Thief stone and tile, and are clearly distinguishable in both tone and volume (although I suppose the tile could be made a bit louder to make it clear that it is a "loud" surface). I have no idea how the stone footsteps sound like "two bricks rubbing against each other" — are we even playing the same game? I agree that the water sounds are rubbish though; it is clear that these were made by somebody swishing their hand around in a container of water, and do not sound anything like footsteps.

There is already a better way of deprecating assets such that they do not appear at all in DarkRadiant browsers. So far I don't think this feature has been used at all by the mod assets.

I have noticed that some of the door opening sounds seem way too loud. One problem is that certain double-door prefabs (e.g. cabinets) actually play the same opening sound from both doors simultaneously, making the sound twice as loud as it should be.

Reducing the player footsteps is not going to happen — not only is this core Thief-like gameplay, but the volume that the player hears is designed to allow the player to determine what surface they are walking on. If the footsteps were too quiet, it would be much harder to tell. If you want the footsteps to be less noticeable to guards, you can accomplish this by adjusting the AI sensitivity slider (I believe you can still make them "Almost deaf" if you really want to). Having player footsteps masked by multiple guards walking around is something I would support actually (there is a similar mechanic in Sniper Elite games where ambient sounds mask your gunshots), but would require more AI programming.

That would be an option too, and I think it could be achieved with the existing interface. We already show available skins as children of model nodes, so we could show entities using the model as children too.

I actually like the idea of a combined Model/Entity browser. They may be doing different things at the map level, but from a user perspective their purpose, appearance and functionality is very similar: choose an object in a tree, look at the preview, add it to the map if you like it. The fact that some of those objects are just "static models" while others are "entities which do things" aren't necessarily important for a mapper, especially if some entities are literally just a few models with LOD swapping. It does raise the question of how to populate the trees though. Entities exist in a completely different virtual tree from models, which are just shown in filesystem layout. Presumably the two different trees would need two different root notes, at which point the distinction between models and entities is effectively re-introduced within the single dialog.

There is no quick and easy way to determine if an object is visible at all to the player. In order to accomplish this, you need to render the object with full occlusion by other objects, then determine how many pixels from the object make it into the final render. What I'm suggesting is that once this screen-space render is done, the resulting image is then used for the highlight processing, so only the visible parts of the frobbed object become highlighted. As a consequence, an object which wasn't visible at all would not be highlighted at all. That's just a consequence of the way the highlight is rendered (it brightens the object's own texture then renders it in 3D space as normal). As far as I know there is no specific test for whether a frobbed object is visible. Most likely the invisible frobbed objects are being highlighted, but you can't see it because brightening the texture of an occluded object does not make it shine through other objects.