Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Content Count

    8090
  • Joined

  • Last visited

  • Days Won

    36

Everything posted by OrbWeaver

  1. I see the problem. This was actually working when I first switched to CMake because PKGLIBDIR wasn't defined, so it would default to the runtime data path (/usr/share/darkradiant) + scripts using the same logic as on Windows. I've fixed this to always use ApplicationContext::getRuntimeDataPath which should work correctly on both Windows and Linux, and already takes into account whether it is a relocatable build or one using hard-coded absolute paths.
  2. I'm happy to work on this one assuming @greebo hasn't started on it himself. I also preferred the single-colour light volumes so I would definitely like an option to disable the per-light colouring, and this ought to be pretty easy to implement.
  3. Sure, I don't run whatever distro uses PKGBUILD so I never touch it myself, but I'll accept patches.
  4. Blender doesn't. I can make a cube or a sphere, move the camera inside, and still see all of the geometry from the inside even though the normals are facing outwards. And I'll bet that even modelling apps that hide back-facing polygons by default will still allow you to see those polygons in wireframe mode, but even this option isn't available with the current DR renderer. If you are behind a patch, you can't see it at all no matter what rendering options you select, which is really poor usability. Maybe in the lighting preview mode (which most people don't use) it's fine to show the patc
  5. Yes, that looks pretty conclusive, and suggests that @stgatilov's theory is correct. The engine is indeed dividing the map into disconnected regions separated by opaque volumes, and culling everything not reachable from the current room, without any need for visportals.
  6. Me too. I rarely bother to customise colours (I trash my preferences far too often to make lots of changes), but other than Maya/Max and Super Mal all of our themes are basically variants of hideous white. It would be great to have a wider selection of attractive themes that are actually being used by mappers.
  7. Right, but my point is that the distant room appearing to disappear behind a wall doesn't prove that it is being culled by the engine. It might still be sent to the GPU and rendered, but hidden from the final output image because something else (the wall) is drawn in front. That's why you need r_showTris 2, which shows all triangles that are being rendered, even those which are behind other objects and not visible in the final image.
  8. I know the flood fill can start with any entity, but does it actually do a separate flood fill for every entity and divide the map into visleafs if the map sections are disconnected? If so, then I guess what HMart wants to do will work perfectly.
  9. Sorry, I can't see what's happening from that video. All I see is a distant room flickering on a completely black background; I can't see what is being rendered or sent to the GPU (since r_showTris is turned off, noclip doesn't provide any information about render culling, and I can't even see if you are behind or in front of another wall since everything else is completely dark). If you want to definitively see what geometry is being sent to the GPU, you need to use r_showTris 2. Without this option, there is no way to tell the difference between something not being rendered at all, and
  10. I'm 99% sure that they won't, and that the "opaque nodes" reference only refers to the flood-filling algorithm, not the division of the map into visleafs. What it means is that the inside of a sealed box will be completely optimised away by the flood-filling algorithm, because the walls are opaque and they stop the flood-filling (which only covers parts of the map reachable from the player start). This also suggests that with HMart's unconnected rooms idea, the problem will be that most of the rooms will be considered unreachable (opaque) and optimised out by the dmap compiler. Nothing in
  11. No. If there are no visportals, there are no visleafs. The whole map is a single visleaf, and the whole thing will be rendered as long as it is in front of the camera (I assume the engines culls everything behind the camera or out of view, regardless of visportals). I think you're getting confused by the name "visportal", since the "portal" part suggests it's just a gateway between two things. From this it might follow that a map full of completely unconnected rooms wouldn't need any portals (because there are no doors or gateways between them). But the engine does not work this way. Visp
  12. This is implemented in e649657d774fc05b. I actually removed Light::intersectsAABB entirely; now all of the intersectsLight methods just do a simple AABB intersection test between Light::lightAABB and Node::worldAABB, which is much cheaper than the complex long-winded code in Light::intersectsAABB. I now see relatively little time spent in the lighting intersection calculation, and a much larger amount of time spent in the backend render method of Winding. I suspect this could be improved by the use of OpenGL VBOs to store the winding data, rather than submitting it repeatedly using s
  13. Maybe not, it was just a guess after all. Nevertheless, I don't know how to change this. I cannot find anything in the wxWidgets documentation relating to the visibility of shortcuts in menus, nor can I find any discussion of this issue.
  14. Technically it's never required to make visportals, but if you don't, everything in front of the camera will be rendered regardless of whether it is in the same "room" or hidden behind other objects. There is no automatic culling of geometry based on "connectedness", or anything other than the manual dividing up of map geometry by placing visportals. If you want to see what is happening at the render level you can use the r_showTris cvar to enable drawing of triangle outlines.
  15. On Ubuntu I use the gnome-tweaks tool to adjust this. It's not installed by default but is available in the repository.
  16. Indeed it has. I've updated the README.md in the source tree but not the wiki.
  17. Yes, that seems plausible. We need to be careful though because there are at least two different situations where AABBs are needed — lighting calculations and the selection system — and the AABBs they need are not identical. But I'm sure there is a bit of redundancy from the legacy code that we could simplify. Also a good suggestion. We could default initialise it with a "sensible" initial light count like 16, or even try std::list which should have constant time insertions at the expense of slow random access (which is not needed). In any case, as of a8a19bec7bce6 I have disabled
  18. No, it shouldn't be necessary at all. That seems like an oversight on my part. We only need to calculate the light intersections in the lighting preview mode. Even when we are in lighting mode, that 35% worries me (since it happens in every frame). I did do some performance testing with the new lighting code, but didn't see any significant regressions. Maybe the performance characteristics are very different on Windows vs Linux.
  19. I'm pretty sure there have never been any textures shown in the 2D ortho views. Texturing simply isn't enabled in those views. I agree that patches disappearing when you look at them from behind in the 3D view is annoying. Perhaps I'll look into it; there might be some simple OpenGL state that can be set to show the patches from behind (maybe in wireframe).
  20. Something weird happened when I tested the patch welding (which overall looks like a great feature). I made two rectangular patches in the top view, welded them together and the patch seemed to disappear from the 3D view. It turns out the orientation was flipped, so I had to move the camera down and look up at it to see the texture. Is it possible that the welding code is either flipping or ignoring (resulting in undefined behaviour) the patch normals?
  21. I too am rather skeptical of an ongoing need for per-material frob customisation, but ultimately I am not a mapper and if experienced mappers say they have needed it, I can't really contradict them. Nevertheless, for the main bulk of materials which do not need per-material customisation, I don't understand what benefit a macro (which the material author must remember to manually include in every material he creates) provides over simply doing what the macro would do in the C++ code, automatically, for every material. This would not even prevent the use of customisations: the behaviour co
  22. My mistake, I thought your idea was for some kind of floating LED widget in the ortho views. Still, even custom-drawn GUIs using wxWidgets would be an additional maintenance burden, so I wouldn't recommend this unless it was really important. A regular dialog using toggle buttons with appropriate icons would be fine, I think. It's also important to remember that some users may be colour blind, so GUIs should never use only colour to distinguish important information. It's fine to use colour as an additional highlight provided there is some other change of shape/icon/text which doesn't rel
  23. As a UI programmer I'd say that stgatlov's LED idea looks nice, but I'd rather not go down the route of implementing our own custom GUIs in the OpenGL windows. Just rationalising the menu items into appropriate toggles (rather than separate Enable X and Disable X menu items) would be a big improvement, then perhaps pulling out a couple of major options into toolbar buttons so mappers could quickly enable or disable the sync with a single click.
  24. I think this might be a GTK theming issue. Clicking around through various core GNOME apps (I tried Files, Disks, Videos, Terminal and gEdit) I see no menus with shortcuts listed. All the apps have moved to the new "header bar" style where you don't actually have the regular File/Edit menu bar, just various buttons and a "Menu" button which brings down a speech bubble-style menu which does not contain any shortcuts. If this is implemented at the GTK 3 level rather than with GNOME-specific code, then I guess it applies to wxWidgets too which uses GTK 3 as a backend. In which case, I'm not
  25. Other things I particularly like about CMake in no particular order: It keeps all CPU cores occupied for the entire build, and will happily build different submodules in parallel. Automake would only ever parallelise compilation of CPP files within a single module, with each module needing to be linked before it would move on to the next one. If you adjust a compiler or linker option in a CMakeLists.txt, it automatically rebuilds whatever might be affected by that compiler option. With autoconf the configure script would be regenerated automatically but you would have to manually
×
×
  • Create New...