Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Posts

    8629
  • Joined

  • Last visited

  • Days Won

    65

Everything posted by OrbWeaver

  1. This looks like the relevant documentation from iddevnet: So time is just the current game time in seconds, and using this to lookup into a table of values (using wrap-around indexing obviously, so the table gets "played" again and again as time increases) gives you a brightness which can flicker, pulse or do whatever is defined in the lookup table. The blamplight_cv material is doing this independently for each channel (hence the separate red, green and blue declarations), so that it can multiply in the parameters which contain the red/green/blue channel of the _color spawnarg. This is what allows it to be colour-variable while still using the sintable (which I assume contains a sine wave) to animate the brightness.
  2. I've never seen an SVN client on Linux that wasn't junk. Just use the command-line client; it might not have the most super-modern interface (even by command-line standards) but it works.
  3. Yes, I believe so. rgb means "set the RGB colours to this specific value", and the value in this case comes directly from the lookup table, not the spawnargs. colored is short for color parm0, parm1, parm2, parm3 which means "take the RGB values directly from the spawnargs", but this is overridden by the rgb declaration which I believe means that colored does nothing in this case. The difference with the blamplight_cv shader is that the spawnarg values are explicitly multiplied by the value from the lookup table, so the resulting colour should take both into account (again, there is a colored declaration which I think is doing nothing).
  4. If I understand correctly, there is a specific light shader which does not respond to colour or brightness adjustments? This is something light shaders can do, for example there are certain shaders which use a fixed colour or texture (possibly animated) which are not intended to be controlled via the color spawnargs. Definitely not a DR problem as Greebo says, and it may not even be a "bug" as such, since it is up to the shader author whether a particular shader responds to colour (I wonder if the "_cv" suffix means "colour variable" or something, but that's a wild guess). One could argue that this is a usability issue however. Perhaps we need some better organisation of light shaders, to distinguish the generic shaders which respond to colour and can be used anywhere, and special-purpose shaders which may have fixed colours or textures and are designed for specific purposes like association with a particular entity?
  5. For my screenshot earlier I just did it the dumb way: duplicate the projected light several times, move each one up or down by some amount, and view all of the lights simultaneously projected onto a single surface.
  6. Having a single matrix definitely sounds sensible to me, both from a Don't Repeat Yourself (DRY) principle and for easier compatibility with the DR renderer which only has a single matrix per light (although the renderable frustum is derived via different code).
  7. Looks like a mistake in RGBAImage — the mipmap generation code has been modified, but the setting of GL_LINEAR_MIPMAP_LINEAR is completely missing, which means (I believe) that the generated mipmaps do nothing and there is only basic nearest-neighbour filtering
  8. I guess that needs testing by examining the setting on a clean install (or after removing local settings). I assumed it was 100% because in my experience that's how most games behave — all sounds play at full volume unless you specifically choose to make certain channels quieter. But it's quite possible we have a default of 75% or something. Whatever the default is, that's what you should balance the ambients against. That's kind of my point. If ambients are too loud, they should be reduced with default spawnargs so they sound reasonable without having to adjust the ambient slider. This takes careful, manual work — volume balancing is not as easy as it sounds, because it's very common to hear a "cool" sound you like and want it to play loudly, even though it might be drowning out other things or completely unbalanced with the ambient in the next room.
  9. If you are thinking of making ambient sounds louder, I would double check to make sure you have your own ambient music slider at 100%, so you get a feel for the "real volume" rather than the possibly-lowered ambient volume in your game settings. It might sound obvious, but I've played commercial games where the background music was absolutely deafening (to the point you couldn't hear anything else going on), which I'm fairly sure was caused by some content creator adjusting the level's sound volume with their own music slider turned down (or maybe they were just deaf and/or incompetent... who knows). Although it would be fairly simple to implement, I think it would actually be useless. The volume of an ambient sound played via DarkRadiant through your system sound mixer doesn't tell you anything about how loud that ambient will be in comparison to other sounds going on in the game; not just other ambients (which it needs to volume match) but also footsteps, guard barks etc. Having a volume slider in the entity inspector might be useful rather than setting numeric values directly, particularly if combined with the "hot reload" feature which would allow you to have another game window open playing the sound in realtime as you adjust the entity properties. But playing the sound in isolation within DR isn't going to help with volume matching.
  10. 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.
  11. 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.
  12. 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).
  13. 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).
  14. 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.
  15. 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.
  16. 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.
  17. @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.
  18. 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).
  19. 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.
  20. 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.
  21. 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?
  22. 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.
  23. 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.
  24. 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.
×
×
  • Create New...