Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Posts

    6731
  • Joined

  • Last visited

  • Days Won

    230

Everything posted by stgatilov

  1. It would be great if you attach all the tdm_installer_NNNNNNNNNN.log files, maybe I'll see something interesting there. You can try to enable "Advanced Settings \ No multipart byteranges", maybe something in your networks breaks them. But yes, getting the full download is the easier solution if you don't intend to switch between various versions.
  2. I think yes. The root of the issue is always an opaque wall (in terms of areas/visportals) which does not cast shadows (in terms of lighting). Shadowcaulk is both opaque and casts shadows, so there is no contradiction.
  3. Right now core count is printed by job system, and features are printed by SIMD processing system. From the implementation point, vectorization and multithreading are orthogonal...
  4. dev17008-10685 is available. Speaking of the new parallelization, it would be great to check that the new version does not get slower than the older ones The only different there is number of threads used in jobs system. Previously it was always 2 threads, now it is (NumberOfPhysicalCores - 1). However, detection of physical cores number might be buggy --- the numbers are reported near the beginning of game console.
  5. You can delete or ignore it I suppose you switched to some old version where the mission was called "saintlucia" ?
  6. Another leak in Written in Stone near start (230 -1820 65): This case is more interesting because it is not just light leaking vs not leaking through a wall. Here we see view-dependent scissoring rectangle which limits the light effect. The light source is in the farthest area behind a wall (on the middle of the two far visportals). There is no way to cast a ray from the light source through visportals that would reach the viewer area: if you hit one of the far portals, then you surely don't hit the near portals. So the frontend decides that the light is not active in the viewer's area. Then the light scissor is bounding rectangle around all the visportals. Normally, the wall in between should occlude the light, but apparently it was set to noshadows. This wall seals the areas, so this is the same kind of bad input as usual. But the resulting behavior is indeed interesting. So I wonder how should we fix it @Amadeus @Dragofer
  7. You can't make trees/grass cast proper shadows with stencil buffers, because they are rendered as bulky quads with alpha-tested texture. Imagine shadows falling on the surface of water, or on the glass. You will never see it with stencil shadows: the shadows are computed only on single solid surface closest to viewer at each pixel.
  8. I'd like to remind that the core question is: what should we do now? Stencil shadows don't support a lot of things, but they are pixel-perfect in exchange. Indeed, stencil shadows won't be removed while shadow maps look like crap here and there (and are not even self-sufficient).
  9. As everyone know, right now we have both stencil shadows and shadow maps in the engine, and the player is mostly free to choose whichever he likes more. Due to the reasons I provide below, stencil shadows will most likely be dropped in some future, but that future is definitely not here yet. Unlike shadow maps, stencil shadows do not support: Alpha-tested shadow occluders. Shadows on translucent surfaces. Volumetric lights with account for shadows. Soft shadows with contact hardening. Point 4 can be ignored, point 3 has an automatic workaround by forcing lights with volumetrics to shadow maps. Points 1 and 2 result in major difference in behavior between the two modes. For the reference, we have one more technical difference: Front faces cast shadows in shadow maps mode, but don't cast them in stencil shadows mode. I recall how initially volumetric lights had their shadows disabled in stencil shadows mode, and mappers were not happy because that's a big difference in behavior. One issue was that every mission has to be beta-tested in both modes. That's why right now I mostly follow the same strategy: Alpha-testing is disabled when rendering shadow maps (since 2.12), unless you enable r_shadowMapAlphaTested. Shadows are disabled on translucent objects (since today's 2.13 dev build), unless you enable r_shadowMapOnTranslucent. I wonder if this is still what majority of the mappers think is best?
  10. dev16996-10665 is available! This includes everything that we could not help but commit to trunk during beta, and some of the stuff which we wanted to commit back then but did not
  11. That's because these counters are updated by calling special wrappers around draw calls. I think the new backend does not call it everywhere --- maybe I changed something here. So I'm afraid the performance counters are as reliable as we care about them when doing changed to the renderer... which is not great at this moment.
  12. For easier inspection of various culling algorithms, I created a new debug cvar. It fixes the camera position that renderer frontend uses for culling, but allows player to fly around and see the same objects from different view point. Don't expect perfectly valid/sane picture, but I think it reliably shows which objects are sent to OpenGL for rendering. Here is the demonstration (bottom-left is clipped away in this video, but I hope it is clear anyway): It will be available in the next dev build. Maybe someone will find it useful for analyzing overdraw? P.S. Aside from that, "r_showtris 2" + "r_useScissor 0" should be useful for overdraw analysis too. It is questionable though whether you should disable r_useScissor in this case...
  13. Changelog of 2.13 development: dev17008-10685 * Enabled shadow features specific to maps implementation (poll). * Auto-detect number of parallel threads to use in jobs system (6503). * Improved parallel images loading, parallelized sounds loading, optimized EAS (6503). * Major improvements in mission loading progress bar (6503). * Core missions are now stored uncompressed in assets SVN (6498). * Deleted a lot of old rendering code under useNewRenderPasses + some cleanup (6271). dev16996-10665 * Environment mapping supports texcoord transforms on bumpmap (6500). * Fully disabled shadows on translucent objects (6490). * Fixed dmap making almost axis-aligned visportals buggy (6480). * com_maxFps no longer quantizes by milliseconds on Windows 8+. * Now Uncapped FPS and Vsync are ON by default. * Supported Vsync control on Linux. * Added set of prototype materials (thread). * Fixes to Stone font to remove stray pixels (post). * Loot candlestick no longer toggle the candle when taken. * Optimized volumetric lights and shadows in the new Training Mission (4352). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. * Now combination lock supports non-door entities by activating them. * Added low-poly version of hedge model (6481). * Added tiling version of distant_cityscape_01 texture (6487). * Added missing editor image for geometric02_red_end_HD (6492). * Added building_facades/city_district decal material. * Fixed rendering with "r_useScissor 0" (6349). * Added r_lockView debug rendering cvar (thread). * Fixed regression in polygon trace model (5887). * Added a set of lampion light entityDefs.
  14. Remember that installer works with old versions too. You install 2.11 and installer will overwrite your newer training mission with the one from 2.11. Switch back to 2.12 and training mission will be deleted. Also, there is no proper concept as "mission version". There are various things like version, some of them don't exist for core missions. It is easy to say "just check condition here, then condition here, then here". Such hacking will cause confusion, and the support for these conditions will have to stay with us forever, despite everyone forgetting about it in a few years.
  15. Some parts are managed by tdm_installer, some parts are managed by in-game downloader. You mix the two, and you get endless stream of issues and confusion. As simple as that.
  16. This is surely because of volumetric shadows. I get 200 FPS without them and 100-120 FPS with them (that's not fullscreen). Point lights in this room also have volumetrics enabled, not just the projected lights --- I believe they should not. But even if it gets fixed, performance will still be lower when volumetric shadows are involved. Since @Fiver has extremely low-end machine, it would probably make sense to tweak r_volumetric* cvars. Maybe "r_volumetricLowres 2", maybe "r_shadowMapSize 512". Maybe simply disable them.
  17. It casts shadows, and it is a proper point light. Not sure what else can go wrong with a light.
  18. This one has nothing to do with the change. It happens in 2.11 too. I have no idea what is wrong here, and why one patch casts shadow while the other similar one does not. There is even auxilliary surface with "shadow" material inside the stairs, which should also cast shadow but it does not.
  19. You can try msbuild command to build from command line. Perhaps it won't ask you for updated MSVC license. It should be like: msbuild DarkRadiant.sln /p:Configuration=Release
  20. beta212-07 is available. This one is considered release candidate, meaning that most likely it will be turned into official release soon. For this reason, here are the deprecated 32-bit binaries. It would be great if someone briefly checks the 32-bit Linux executable (cannot do it myself).
  21. It seems that you redmapped the mission. It means some visportals could be broken... and consequently some locations could be broken... Was it required? Did you change any brushes or patches?
  22. Maybe you can provide a savefile?
  23. It turns out we have many people who enjoy discussing code My complaint about that code is that all floating point numbers are snapped to integers with same tolerance. The .proc file contains a lot of different data: models, shadow models, BSP tree, visportals. They contain in different combinations: positions, texcoords, normals, distances. Snapping or comparing all of these quantities with same tolerance is a really bad idea. Some data is more sensitive to changes than other. They even have different measurement units, i.e. you position is measures in something like meter-units, while texcoords are usually measured in something like tex-units, and they are as incomparable as meters and seconds. Some data should not be snapped at all because that could break its internal invariants. If you snap coordinates of normal vector, it is no longer normalized, and the receiver has all the fun of dealing with extremely rare cases which normally should not happen. As for Hungarian notation... I do some mesh processing with halfedge data structures. When you have 10 local variables being halfedge handles, 5 local variables being face handles, and 5 local variables being vertex handles, it becomes much easier to understand what's going on if they start with "he" / "f" / "v" respectively. But this is very situational of course. Just starting pointers with 'p' and array-like stuff with 'a' is usually unnecessary, unless you have 3-4 levels (triple pointer or triple arrays), although in that case the code is smelly regardless or how you name variables
  24. When I actually meant pseudographics, I did not mean some specific line/dots/crosses. I simply meant the cases when people add spaces until the text gets the exact alignment they want. You can't search for such cases, because the only offending character is space, which is present everywhere. The only way to proceed to just change spacing and listen for feedback afterwards. And it sounds like an OK solution for me in general, but definitely not a good idea for 2.12.
  25. Since briefing is completely redefined by you, you need to add subtitles GUI for them to show up. See stock mainmenu_briefing.gui.
×
×
  • Create New...