Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Posts

    6739
  • Joined

  • Last visited

  • Days Won

    231

Everything posted by stgatilov

  1. Yet another breaking change, I'm afraid: 6346 Sounds have a bunch of parameters: minDistance maxDistance volume shakes soundClass The base value for each parameter is set in sound shader. However, it can be overridden with a different value in spawnargs (e.g. "s_volume" "-10") or in C++ engine code with SetSoundVolume (used extensively for footsteps). Unfortunately, Doom 3 engine has a special case: setting some parameter to zero means it will not override the base value. So there is no way to override sound volume with 0, because setting zero would mean "use value from sound shader", while setting 0.1 or -0.1 would mean "use volume = 0.1 or -0.1". This behavior causes confusion. It is especially bad when volume is set programmatically, because e.g. volume of player footsteps is computed as a sum of many modifiers (run, crouch, creep, in water, etc.) and it is hard to be sure you don't get zero sum in the end. The idea is to fix this mess and add a "don't override" special value in the system. Speaking of spawnargs, it would work like this: "s_volume" "13.4" = override with value 13.4 "s_volume" "0" or "s_volume" "0.0" = override with zero "s_volume" "" (empty string) = don't override Right now there are tons of zero values set in these spawnargs. It is not clear where the author intended to override with zero, and where he wanted to drop inherited override and use base value. I guess for compatibility reasons I'll have to replace spawnargs "s_volume" "0" with "s_volume" "" in all missions.
  2. And making it possible for the new electric lights to be broken adds a psychological problem: how will players know that they are breakable if in 99% missions they are not? Recall lootable paintings and frob-extinguishable unmoveable candles.
  3. A visually breaking change is planned for 2.13 (6354). Environment mapping is used when material contains a stage like this: { blend add cubeMap env/gen3 texgen reflect } Historically, there are two separate shaders for this case: one if the material has bumpmapping, and one if it does not. Note that if the material has diffuse or specular stage, then bumpmap is added implicitly. The shader with bumpmap was apparently "tweaked" by someone in TDM and got several major differences: it has fresnel term output color is tonemapped to [0..1] range using X / (1 + X) the color multiplier is hardcoded to (0.4, 0.4, 0.4) I'd like to delete all of these differences and restore the same behavior as in non-bumpmapped case. It is also the same behavior which is used in both cases in Doom 3 BFG (and supposedly in Doom 3 too). Speaking of points 1 and 2, nobody will notice the difference except in rare corner cases. The point 3 however is serious. It is also the main reason behind the change. Right now nobody can tweak the intensity of environment mapping: if you try to set red/green/blue/rgb, these settings are simply ignored. Now the problem is that the intensity of most environment mapping materials will change. In core files I see text like this (stainglass_saint_01) : { blend add maskalpha cubeMap env/gen3 // tone down the reflection a bit //I see no evidence that these values do anything red Parm0 * 0.2 green Parm1 * 0.2 blue Parm2 * 0.2 texgen reflect } Since the default parameter was 0.4, after the change this material will get 2x less intensity. The situation is even worse if rgb multiplier is not specified, since then it will change from 0.4 to 1.0, i.e. envmapping will become 2.5 times brighter. I can probably collect the list of all materials using environment mapping, but I'm not sure I'll be able to check them all one by one. Perhaps I can delete existing rgb settings, blindly set "rgb 0.4" and hope for the best.
  4. 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.
  5. 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.
  6. 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...
  7. 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.
  8. You can delete or ignore it I suppose you switched to some old version where the mission was called "saintlucia" ?
  9. 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
  10. 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.
  11. 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).
  12. 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?
  13. 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
  14. 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.
  15. 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...
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. It casts shadows, and it is a proper point light. Not sure what else can go wrong with a light.
  21. 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.
  22. 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
  23. 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).
  24. 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?
×
×
  • Create New...