OrbWeaver

I'm in the UK and it's the same for me. The "Get started" link takes you straight to a login page before you can do anything else.

There is no "risk" per se in setting the spawnarg in your map — if the result sounds good, it is good. The only way this could present a problem in future is if the underlying sound file had its volume changed in the mod assets, and the default volume spawnarg was updated to compensate. In this situation your map would get the changed volume file but not the updated spawnarg. However this situation is exceptionally unlikely, not least because we don't have the uncompressed originals for most music files, and any volume adjustments in future would be made purely on the default spawnargs, not the file itself. What that paragraph means (I think I probably wrote it, based on the wording) is that ideally you shouldn't have to set spawnargs on ambient music, because the ambient volumes should be consistent throughout the mod. If there is a significant difference in volume between two different ambients, this ought to be considered a bug in the core assets. But if the core asset can't or won't be changed, and you need to override it in your mission to make it sound correct, then you should do so.

This is what I have so far; it looks good on Linux, but obviously I haven't confirmed that the #ifdefs work correctly on Windows. If you have time, perhaps check if it is still looking good on Windows and does not expand the dialog and attract complaints? I'd be interested in how the pixel sizes interact with Windows' own DPI scaling functionality too — if you set your scale factor to 200%, does Windows/wxWidgets take this into account automatically or do you get cut off widgets there too? Don't worry about it, I can trace that in about 2 minutes in Inkscape. I agree. I've been gradually refreshing them where I can — although I don't claim to be the most talented artist, some of the existing icons are barely legible on a large screen with their small details and 1-pixel lines. Colour is still a challenge, since we don't have any way to switch between icons sets for light and dark mode, so I've generally been hacking it by using colours around 50% brightness which hopefully show up on most themes (but of course this isn't guaranteed).

I have some UI suggestions for the new Surface Inspector, which I will discuss here rather than changing unilaterally myself since you've obviously done a lot of work on this and might have more changes planned. We're going to need to #ifdef the pixel-based widget minimum sizes, since unfortunately these result in crushed/unreadable widgets on Linux with certain GTK themes. In general we can't use fixed pixel sizes on GTK because the combination of user-selectable themes and variable DPI (mine is 110%) make the relationship between widgets and pixels unpredictable. The new icons look good. I suggest removing the light blue ellipse in between the arrows in the horizontal and vertical scale buttons, since from a distance this makes the arrows slightly harder to read (it just looks like blur). I don't recommend using the exact same icons for buttons which do different things (vert shift buttons and h/v scale assignment buttons), since this is potentially confusing. They should be distinguished in some way, even if it's just a different colour and a square at the base of the arrow or something. The large vertical gap between H and V scale (to fit the buttons in) makes things a little odd: H and V scale are actually the most "tightly bound" parameters because of the new transfer buttons, but the layout makes them look like they are in completely different sections! However, I can't immediately think of a easy way to improve this — the buttons need to go somewhere, and placing them off to one side isn't obviously ideal either (and would widen the dialog further).

Not that I can think of — assuming no unexpected bugs of course. All my recent work has been minor tweaks which stand on their own, plus internal refactoring (covered by unit tests so hopefully not breaking anything) and adding a few new tests for the projected light calculations.

Looks good to me.

An 11-year-old Blender tutorial is probably so outdated that it would be unhelpful, given how rapidly Blender develops. For example, Blender gained the Cycles renderer in 2011 which allows you to bake normal maps entirely within the software, and there have been massive improvements to the sculpting tools in the last decade. You could probably achieve the result of this tutorial in Blender 2.93 without using any other software.

On the Unix side it's trivial, because it's already handled as part of the CMake build process. Of course this does not help on Windows. The actual command is: ${ASCIIDOCTOR} -a stylesheet=manual.css -D ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/manual.adoc The important part is the -a argument which allows the stylesheet to be overridden, whereas -D just specifies the output directory for the HTML file. Asciidoctor itself appears to be Ruby-based and is installed via the Gem process.

@greebo I notice that the online manual on the official website (https://www.darkradiant.net/userguide/) is using the default AsciiDoc style, which is different from the asciidoctor style which I use on my Gitlab page (http://orbweaver.gitlab.io/DarkRadiant/). Is that a deliberate design choice, or just a consequence of the way the CI system is working? Although the default style is perfectly readable, I feel it looks a bit like a 1998 GNU manual page, which is one of the reasons I switched to the more flexible asciidoctor for generating my Gitlab site. I also think that having the left-hand contents panel is useful for navigation in a large document. Of course styles are very personal and others may disagree on what looks best.

Since AO primarily affects brightness, baking it into the diffuse map would be the simplest approach. You could do this as a separate material stage as per @nbohr1more's example, or you could bake it directly into the diffusemap itself (either within Blender via image compositing or in your image editing tool of choice). I've done this myself with model-based textures (e.g. making the grooves between stone tiles look darker using baked AO).

If someone wants to write such a script they're welcome to do so, and submit it for inclusion as a user-contributed script. Note that brush and patch primitives are not represented as triangles, so any algorithm related to triangles alone will not work.

Alpha channel has nothing to do with smoothing, and will just waste space in your image file. For smoothing problems, I would check that all of the face normals are pointing in the correct direction in your chosen modelling app, and make sure you choose the correct smoothing options on export (if any). For example with the Blender->LWO export script, you can choose full smoothing, no smoothing, or smoothing based on the material Autosmooth settings.

Makes you wonder why the original code is using full vectors for all the parameters, given that these can be combined in ways which don't make sense. Surely start and end would be better as scalar values, representing "distance along the target vector", rather than arbitrary vectors in 3D space which might point in completely different direction to the target vector?

That would be my advice too. The engine does a good job of opening or closing portals according to well-defined rules; it is extremely unlikely that trying to override this manually with scripts is going to lead to any improvement. At best it would achieve nothing, at worst it would be slower and possibly result in portals being open when they should be closed or vice versa. The case for adjusting portals manually would be if there was some condition that made a portal invisible to the player but which the engine could not detect, e.g. it is obscured by fog or a large moveable object.

In DR terms I'd vote to keep falloff in Z and perspective divisor in W, for consistency with omni lights. Otherwise we'd need to add special handling in the shader to deal with projected lights using a different texture coordinate for the falloff texture. Note that we don't force mappers to use start/end (they have to tick another box to enable it), so rendering code needs to handle the situation where these values are unset. I think we currently assume no start means light origin, and no end means the same as the target vector. We don't explicitly support it and I haven't done any testing myself. It might happen to work by accident though.

Like what? I really have no idea what you're saying here. I'm not sure why you think a single numerical value is somehow better than a falloff image. A falloff image can represent any falloff pattern (linear, quadratic, full brightness, whatever), not just whatever hard-coded formula is programmed in by the developers. I suppose there would be no harm in also offering a math-based falloff as an option for mappers, e.g where "falloff <power>" represents a power of Z: 0 for no falloff, 1 for linear, 2 for quadratic, 3 for cubic etc. But this is a separate issue from making the existing approach work correctly. Only if you divide the Z component by W, which DarkRadiant certainly doesn't and from @stgatilov's analysis it seems the game doesn't either (or at least shouldn't). That does at least suggest that the DR code isn't broken with regard to Z falloff. Although DR's code is hardly an authority on the correct way to render lights, as an additional data point we definitely do not divide the Z coordinate by W — only X and Y are divided.

Well here's a surprising result. I did a test of Z falloff in DR and in game, by duplicating a projected light (with the default shader) and shifting each copy vertically. The DR renderer does indeed not match the game, but not quite in the way I expected: the game appears to have no falloff whatsoever! On the plus side, this would be really easy to fix in DR (just ignore the Z component entirely). But surely this behaviour is not correct? Are projected lights really expected to have full brightness all the way along the target vector, then cut to black immediately? I wonder if this was always the behaviour with Doom 3 or if something has changed in our/BFG's code. If this is the correct behaviour, I guess in maths terms this means that the Z coordinate must always end up as 0.5, since this is the brightest part of most falloff textures (including the default light shader).

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