Jump to content
The Dark Mod Forums


Development Role
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by nbohr1more

  1. What happens if you replace the "rotation hack" scaled models with models scaled in Dark Radiant ( native function )?
  2. While I concede that very few if any mappers use falloff images in projected lights... ...and also will offer that the idea of a falloff image itself ( instead of mathematical falloff ) is rather silly... If anyone from a Doom 3 mapping background is currently toiling away on an old TDM version or Doom 3 to create a TDM mission then suddenly find that this feature no longer exists ( and they will need to relight their mission... ) there will be considerable frustration. If we at least had a falloff <value> keyword then it might be easier to convert the light materials. Also, we may have accidentally broken a few maps where the falloff image was used to grant the player a little more shadow (etc). @stgatilov @cabalistic ?
  3. Ouch. I think we broke something: https://bugs.thedarkmod.com/view.php?id=5529
  4. I believe this is a symptom of a map that has brush leak to the void.
  5. I think the answer to this comes from answering these questions: 1) Is there more work to make shadow rendering efficient that can benefit from BFG code migration? 2) If so, will retaining the BFG matrix make porting BFG code easier? 3) Likewise, will the BFG matrix design make it easier to port GPU skinning code? 4) Likewise, is any portal \ light culling done in BFG more efficient and would it be easier to port? If the BFG matrix does not assist with any code porting efforts, does not assist with any rendering efficiency designs, and causes problems with Dark Radiant compatibility then it should be reverted.
  6. I moved this discussion out of the 2.08 Beta thread Related bug trackers: https://bugs.thedarkmod.com/view.php?id=5044 https://bugs.thedarkmod.com/view.php?id=5325
  7. I think this is a general issue with our bloom implementation. I created a water material that also exhibited these types of artifacts. I believe we need to ensure either input or output values are clamped so they do not go out-of-range. We probably should cure this sooner than later because if I bump into artifacts with my own water material chances are other mappers (etc) may bump into this issue as well.
  8. Yes, it seems that either specular of itself or in combination with surface normals is changed enough since 2.05 that this texture is very prone to z-fighting. It should be possible to fix with a high polygonOffset or privatePolygonOffset value but it doesn't seem to work in my tests. Perhaps these keywords require a dmap? (Not eager to do a bunch of dmap iterations to find out.) Hmm... maybe I need to disable bindless textures...
  9. The DDS uses an alternate image that does not exactly match the Doom 3 original. I guess the only concern might be the name of the texture but it is so generic that I somehow doubt we would be in trouble?
  10. Here is our limits wiki: https://wiki.thedarkmod.com/index.php?title=Limits,_Max,_Min,_Stats,_etc 2.10 is going to allow an extremely large number of entities so the entity limit listed there is not applicable for future TDM versions. Dev build thread where you may test it out:
  11. Yep, the wiki entry there has a few links from before our FM database migration. The official download links are here: https://www.thedarkmod.com/missiondetails/?internalName=phrase_book
  12. Bikerdude intends to join! He is planning a story addition to "The Elixir".
  13. stain01b_s.tga Both of these are Doom 3 textures from pak004.pk4 I don't see any SVN history where we committed a TGA version only the DDS version. I guess we can convert it to TGA and upscale it a little. Here is a converted file: stain01b_s.tga Heh! That would explain why makeIntensity would cure the flicker. It just kills the specular texture.
  14. Try deleting "DarkmodKeybinds.cfg" and see if the default values work as expected.
  15. Sounds reasonable enough... I guess the snag for this is that good looking lights have long falloff patterns... thus you will find that the radius check will almost always hit the portal unless you have: * Ultra tiny lights * Huge rooms * Ugly short falloff images
  16. A completely "sealed" room will not render outside geometry. ( Sealed with brushes, either caulk or world spawn ) Performance problems happen when: 1) The statue intersects with the room 2) A light whose origin is outside the room has a radius that goes inside the room 3) The room has open portals leading to the statue or light(s) The biggest hurdle is understanding that portal closure is not necessarily line-of-sight. Portal culling typically happens only when the object is behind two portals. https://iddevnet.dhewm3.org/doom3/visportals.html The areaLocked keyword is meant to help in scenarios where it is not fully possible to: 1) Prevent lights from rendering to parts of a model that are outside of your room ( normally only brushes split at the room boundary ) 2) Prevent lights from outside the room from traversing into it 3) Fully close portals in a way that would cause geometry culling for a light inside your room
  17. A little further pondering... The areaLock keyword is mainly meant to handle unexpected light performance impact by making it easier to keep part of the light radius outside the area from rendering. Before this keyword, mappers would need to tediously adjust the light radius of lights near walls to keep performance acceptable. What strikes me is a common denominator for this thread and some common complaints about light radius management is that mappers may like noshadows lights but not when they pass through walls and floors. A material flag that says, "this is a wall" might be the most mapper friendly way to address most of these issues including the one in this thread. I will see if I can devise a flag like this.
  18. Now that I think of it, one way to keep a light from bleeding to unwanted surfaces is to use the "spectrum" keyword. It pairs light materials to surface materials or entities. As of 2.08 and newer, there are two new spectrum options: lightspectrum = acts like standard spectrum for entities except it allows ambient lights to render nospectrum = entity ignores the spectrum attributes of all lights ( probably should be applied to AI depending on the scene ) ( see interaction.cpp ) It may be worthwhile to design something like spectrum for shadows.
  19. Tough call with this one. There is a no_efx keyword we could add to the sound shader: lockpick_pin_00 { description "Made by phide" //sound/sfx/tools/lockpick/lockpick_pin_00.ogg sound/sfx/tools/lockpick/lock_pick_chain_short_1a.ogg no_efx } but that will make take away awareness of the environment. I guess the solution is to lower the lockpick sound? lockpick_pin_00 { description "Made by phide" //sound/sfx/tools/lockpick/lockpick_pin_00.ogg sound/sfx/tools/lockpick/lock_pick_chain_short_1a.ogg volume -12 } If you want to try either of these, create a sound subfolder in your "darkmod/fms/nhat3" and copy tdm_sfx_tools_lockpick.sndshd into it then edit the definitions as above. tdm_sfx_tools_lockpick.sndshd ( same file exists in your tdm_base01.pk4 I believe )
  20. You cannot mix ambient light and standard light defs. ambientLight is a global property and so is noshadows. You can add multiple projection images but doing so is more expensive than simply merging them in photoshop. Adding this capability would offer some performance advantages though since you could re-use geometry cache.
  21. If that 2nd stage even worked (Hint AMD drivers have never allowed it in the past and the current backend does not blindly execute shader operations the way that Doom 3 native did), the programs would execute against the 2D inputs without respect to the surface position and projection direction. Also, sort postProcess is something you do when you are forcing the whole scene to render before you perform your own render operation. It is meant for things like bloom, toon shaders, and some transparency effects where you are using a full screen overlay. Also, if this is for the ambient world then you are running on some sort of assumption that the ambient world can possibly know anything about other lights in the map. Currently, it cannot. There was a proposal to have the dynamic location script query the lights in an area and generate an average color for the local ambient but nobody has worked on it yet. https://bugs.thedarkmod.com/view.php?id=2354 Though this won't magically improve visuals. Mappers can already tune the location based ambient to match the expected ambient color for the lights in an area. The only additional benefit besides being an "easy button" for choosing the right ambient color is that it could be dynamic so that extinguished lights would alter the ambient baseline. I guess one approach would be to blend a blurred output of the fullscreen ( _currentRender ) to the final ambient light result since it would at least provide some color matching and might give some localization to the lighting too but it would probably not look too hot without artist tuning ( it would aggravate Duzenko ...)
  22. Small tweak to the kitchen reverb. This should be the final version. kiss.efx
  23. TDM ambient lights do calculate normal and specular shading. The only performance you save is shadows. ( no free lunch ) There are multiple ways to simulate bounce lighting. The most popular being the use of no-shadows lights with ai_see set to 0 ( see "Sir Talbot's Collateral" ). Spooks showed how to use cubemaps for GI / ambientCubicLight ( We hope to extend that approach with probes in the future. ) Finally, if you have very good spacial reasoning, you can use the "Strombine" method: http://www.lunaran.com/maps/quake4/strombine/
  24. Updated the unofficial EFX version a bit: https://www.moddb.com/mods/the-dark-mod/addons/unofficial-thieves-efx
  • Create New...