Jump to content
The Dark Mod Forums

nbohr1more

Development Role
  • Posts

    10721
  • Joined

  • Last visited

  • Days Won

    117

nbohr1more last won the day on October 7

nbohr1more had the most liked content!

Reputation

2461 Deity

Profile Information

  • Gender
    Male
  • Location
    USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I am uploading this here for safe keeping: interaction.ambient.fs.glsl I have mostly ported the entirety of the fresnel shader design from our own standard lights to the ambient light. The specular response is significantly improved. Metals look like metal under ambient lighting again! This was created using the SVN build so it will probably only work for Dev builds. I will evaluate how difficult it will be to back-port to 2.09 ( probably not too much work ). To test it out, either unzip the tdm_base01.pk4 and overwrite the same file under /glprogs/stages/interaction or create a /glprogs/stages/interaction/ folder in your darkmod directory and save this file there. ( basically use any valid Doom 3 shader mod install process ).
  2. Texture lookup operations are more expensive than math on modern GPU's. Texture lookups also require lerping to smooth the brightness transitions whereas math can be set to a perfect falloff curve with no step-wise artifacts other than conversion aliasing. If we ever decide to go to a Forward+ design it is difficult to implement two texture lookups for each light ( one is hard enough ).
  3. I can reinstall it this evening if nobody else chimes in. That said, the Github page: https://github.com/id-Software/DOOM-3-BFG under base / renderprogs appears to have all the shaders ? https://github.com/id-Software/DOOM-3-BFG/tree/master/base/renderprogs
  4. What happens if you replace the "rotation hack" scaled models with models scaled in Dark Radiant ( native function )?
  5. 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 ?
  6. Ouch. I think we broke something: https://bugs.thedarkmod.com/view.php?id=5529
  7. I believe this is a symptom of a map that has brush leak to the void.
  8. 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.
  9. 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
  10. 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.
  11. 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...
  12. 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?
  13. 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:
  14. 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
×
×
  • Create New...