Jump to content
The Dark Mod Forums

nbohr1more

Development Role
  • Posts

    10714
  • Joined

  • Last visited

  • Days Won

    117

nbohr1more last won the day on October 7

nbohr1more had the most liked content!

Reputation

2451 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 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.
  2. 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
  3. 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.
  4. 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...
  5. 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?
  6. 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:
  7. 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
  8. Bikerdude intends to join! He is planning a story addition to "The Elixir".
  9. 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.
  10. Try deleting "DarkmodKeybinds.cfg" and see if the default values work as expected.
  11. 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
  12. 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
  13. 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.
  14. 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.
×
×
  • Create New...