-
Posts
8726 -
Joined
-
Last visited
-
Days Won
81
Everything posted by OrbWeaver
-
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).
-
Wishlist For Darkradiant
OrbWeaver replied to sparhawk's topic in DarkRadiant Feedback and Development
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.
-
Light frustums different in DR and TDM
OrbWeaver replied to duzenko's topic in DarkRadiant Feedback and Development
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.
-
Light frustums different in DR and TDM
OrbWeaver replied to duzenko's topic in DarkRadiant Feedback and Development
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. -
Light frustums different in DR and TDM
OrbWeaver replied to duzenko's topic in DarkRadiant Feedback and Development
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. -
Light frustums different in DR and TDM
OrbWeaver replied to duzenko's topic in DarkRadiant Feedback and Development
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). -
Light frustums different in DR and TDM
OrbWeaver replied to duzenko's topic in DarkRadiant Feedback and Development
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. -
Light frustums different in DR and TDM
OrbWeaver replied to duzenko's topic in DarkRadiant Feedback and Development
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".
-
Light frustums different in DR and TDM
OrbWeaver replied to duzenko's topic in DarkRadiant Feedback and Development
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. -
Light frustums different in DR and TDM
OrbWeaver replied to duzenko's topic in DarkRadiant Feedback and Development
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.
-
Christmas "Connections" Contest 2021 - [ Winner "Iris" ]
OrbWeaver replied to nbohr1more's topic in Fan Missions
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. -
Christmas "Connections" Contest 2021 - [ Winner "Iris" ]
OrbWeaver replied to nbohr1more's topic in Fan Missions
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.
-
DarkRadiant 2.13.0 released
OrbWeaver replied to greebo's topic in DarkRadiant Feedback and Development
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.
-
Can't compile latest GIT version
OrbWeaver replied to AluminumHaste's topic in DarkRadiant Feedback and Development
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.