Jump to content
The Dark Mod Forums

MirceaKitsune

Member
 View Profile  See their activity

  • Posts

    2271

  • Joined

  • Last visited

  • Days Won

    36

 Content Type 

Everything posted by MirceaKitsune

  1. MirceaKitsune
    Just for clarification: The screenshots I posted were before I added the normal and specular maps. Final versions include the normal texture for fur depth and other details, specular images that make the fur and hair slightly shiny, and I even put in cubemap reflections for the eyes. The models just made it to GIT last night, and more info will come during the course of today. I find them realistic enough for now, but in any case this is as good as it gets (unless we add realtime fur simulation to idTech 4 ). Here's some screenshots for those curious until then:
  2. MirceaKitsune
    The model and texture are almost finished, I don't plan on making major changes. I am however happy(ish) with their realism! Especially now that normal and specular maps were done, after the last screenshots last night. I'm hoping to publicize the mod on GIT soon, after the final touches are executed. The character set does aim for equal quality to other TDM NPC's, though I doubt they will ever be accepted over thematic reasons.
  3. MirceaKitsune
    Next up, kitties!
  4. MirceaKitsune
    Guess what I'm back to working on
  5. MirceaKitsune
    I'd advice a honest but technically understandable term for everyone in their descriptions. Something like: "Notice: Oscillating lights can't make use of light caching, and are more performance intensive than static lights".
  6. MirceaKitsune
    Ah... I see. I didn't know of this difference until today... I'd imagine many mappers wouldn't either until being around for long enough. Maybe having a clearer distinction between the two can help, so mappers are aware and can be encouraged to use non-oscillating lights in most cases? I'm still curious about a few things however: - Was light caching tested and working for torch entities that don't use oscillating lights, as well as electrical lamps? Or does it only work for the classic light entities, which there's pretty much no point to using in TDM nowadays? - Would it be possible to cache movable light sources as well (like candles) as long as they aren't being moved? Since they can be repositioned by the player, I imagine dmap can't handle this kind of caching. - What do the devs think about my LOD idea for oscillating lights? Could the effect be distance based, so even lights that use it can have a lighter performance decrease on larger maps?
  7. MirceaKitsune
    The problem is that as far as I'm aware, it's used by all of the torch entities. Radiant encourages mappers to go ahead and place those all the time, since they're the easiest solution... I attempted to make a map some time ago, and they were definitely the first and only option that jumped to my attention! So ultimately, maps end up using oscillating lights everywhere. There might be a better solution however: Oscillation could be distance based instead. This could rely on a multiplier, ideally cvar controlled... which let's say is 1.0 when the player is 5 meters away or closer, 0.5 when they're 7.5 meters away, 0.0 when 10 meters away or farther. This gradually decreases oscillation, then makes sure that lights farther than 10 meters disable it entirely and can make use of caching! At that distance you probably don't notice it anyway, so this would maintain the effect while improving performance for large maps. Perhaps this solution is more worth considering?
  8. MirceaKitsune
    I didn't check the names specifically, but I am indeed referring to that oscillation. It's a nice effect, but if the light's origin moves all the time you can't make use of this important optimization. Couldn't movable light sources be cached in realtime somehow? As long as a candle is sitting still on a table, and of course nothing within the light's radius animates, this should theoretically be possible! Same for dropped torches (that have stopped rolling around) and even the player's lantern (as long as they're standing perfectly still). But this might be less of a problem for starters, since most maps don't have a lot of movable lights from what I've seen (like candles). Most lights are torches mounted on walls, and not the type guards can pick up and run around with. If even those could be cached, the performance improvements might be huge! I assume what you mentioned only works for classic light entities though, not lights that are part of any entity definition (which would include all types of torches).
  9. MirceaKitsune
    I recently saw a post about the functionality of the idTech 6 engine, which brought this suggestion to my attention. It's actually a simple and trivial improvement, although I can imagine people missing it and not thinking about its absence. Also keep in mind I don't know the lighting code of TDM, and everything I say is purely out of observation. Like most engines that use dynamic lighting, TDM tends to have considerable performance issues when a lot of lights are rendered at once. This is often because of shadows and possibly other calculations. A common way to prevent extra computation in the renderer is caching all lights, and only updating each one when necessary. Meaning either the light itself has moved, or something is moving in front of the light. If both the light and the geometry it affects are static, there is nothing to recalculate, which offers a significant performance boost. TDM has a serious problem here: Even if the engine already knows how to cache lights, every torch has a moving light source! If you look closely at a torch, you'll notice its shadows constantly bob around. While this makes sense aesthetically, it also means that light will be recalculated each frame... even if the torch is mounted on a wall and no physical object or NPC is currently moving within its radius. Since most maps use torches and have areas where characters don't walk in front of them, I see a notable performance improvement being lost here. My personal suggestion: First of all, does idTech 4 support light caching for static lights + geometry to begin with? If somehow the original engine didn't have that, I definitely think it should be patched in! Once that's solved, I believe moving light sources for flame based lights should be controlled by a cvar; If people are okay with the performance loss, they can enable that to get bobbing shadows... if not, disable to allow torch lights to be cached and improve overall FPS. An idea to compensate for the visual loss: Can't we use an animated light texture to simulate moving flames altogether, as well as pulsating brightness? The light bobbing looks pretty extreme anyway: In real life, candles have a smooth flame that casts a neat shadow, and shadows don't always move that chaotically even when it's a noisier flame like a campfire.
  10. MirceaKitsune
    They probably would with a few new shaders or tweaks to the renderer. Depends on whether any devs willing to do add such around. We are still waiting on Ambient Occlusion and other visual improvements.
  11. MirceaKitsune
    The evidence is clear: He was visited by the crazed buttstabber.
  12. MirceaKitsune
    That's by far the type of TDM map I love seeing, wonderful work so far. Please finish this, I am very curious to play it once it's out!
  13. MirceaKitsune
    I am interested about that as well. I was following a few threads about the 64bit engine, but they haven't been active in many months...
  14. MirceaKitsune
    I hope this isn't going a bit off-topic. But can we expect more work on new features and modernization for 2.05, now that the most crucial bugs were fixed? I'm especially hoping that further visual improvements could be considered... such as a simple shader for SSAO (screen space ambient occlusion), and why not Depth of Field and Motion Blur for those of us who want ultra modern visuals? Soft shadows (ideally distance based) are also a popular request which I'm totally backing! I'm also eager for the 64bit engine, which is probably the most important modernization still pending. Not trying to beg for features... just wanted to bring up those aspects with this occasion, since I humbly believe they should be future targets.
  15. MirceaKitsune
    Also, I noticed a note about "AI scooting themselves out into the void": I should have reported that there was this one map once, which had a few diagonal walls (almost fully vertical but slightly tilted). Sometimes, when guards would patrol too close to it and stepped on the surface, they suddenly rocketed into the air then their bodies fell from the sky. It gave me a few scares at the time
  16. MirceaKitsune
    I was pretty surprised to hear there's someone maintaining a Romanian translation in the dev team, since I haven't even met any other TDM players from Romania here. It's nice if others from my country are around too I'm curious about this as well; If I remember correctly, EAX makes audio effects like echoes in rooms possible. But because of proprietary mumbo-jumbo, it doesn't work out of the box any more... especially on Linux which I use. There was talk of an open-source alternative being considered for replacing it in the engine, but I don't know where to follow the progress on that.
  17. MirceaKitsune
    Beautiful and much needed improvement. Thank you developers, for putting so much work into making this game so great! This is definitely a notable and wonderful release. I'm especially hyped about the new inventory system, which is something I've been wanting to see for a while. Though to be honest, it isn't entirely what I was hoping for either: I would have opted for a real grid-based inventory... where all objects take up space and can be moved to any hotkey, together with being able to visually hold any item in your hand. Pretty much like Minecraft, or the first of the DeusEx games. Maybe something to hope for in 2.05?
  18. MirceaKitsune
    Especially considering the FOSS nature of TheDarkMod, I'd suggest adding support for OSVR instead. I understand it aims to become an open common architecture for VR headsets, so it sounds like the right way to go! If the Vive and Oculus will refuse to support it because their proprietary modes are too fancy, that shall be their loss. https://en.wikipedia.org/wiki/Open_Source_Virtual_Reality
  19. MirceaKitsune
    OpenGL 4.3 support is still kind of a luxury, I don't think the engine should require more than 3.x for years to come. Especially since Mesa just recently got support for 4.1... and yes, many of us do play high-end games on the free video drivers
  20. MirceaKitsune
    I can see why SSAO would need to be tweaked carefully, especially considering TDM's already dark atmosphere. I believe it still has its place though, as it's an effect having to do with accurate light physics. SSAO exists during night time all the same, even if it's a small lamp lighting an area. It should however be noted that SSAO can be used in two ways: Brightening or darkening. Usually it's used to darken tight spaces... however it can also be used to give an inaccurate but good looking simulation of light bounces, which if good enough could be used to replace fancy GI altogether! Here's an idea that pops to mind which might look pretty good, though it's just to exemplify: Say you have a corner, and half of it is being lit by a lamp while the other half is covered in pitch blackness. The AO could darken the space in the area of the light, in order to to simulate occlusion... but also gradually lighten the dark corner outside the radius of the light, to simulate the light bouncing around (the exact reverse). Using SSAO intelligently to both darken bright areas and lighten dark areas near lights could achieve a good middle ground, by looking good and also not affecting the gameplay
  21. MirceaKitsune
    Interesting... didn't notice the effect in fireplaces, though I never looked closely. For whole entities (model + light) this can be easily achieved by just texturing the light bounces. But yeah, I was thinking of calculating bounces for models and lights placed independently. Doing this fully might be a challenge no one will take... since it would require the engine understanding light as a volume, rather than just a 3D projection of a 2D texture. Or some form of compact ray tracing, though doing that in realtime is a crazy idea. SSAO is the most obvious and important effect though. I understand that in comparison, it's easy to do with the Z-buffer and shaders... so hopefully it can be achieved a lot more easily in comparison. If brightness based occlusion could account the colors or lights and textures though, that could perhaps fake bounces too as a bonus!
  22. MirceaKitsune
    My only objection is that I don't think developers should have to implement support for specific headsets, but a generic implementation for all VR devices. At least to my ears, saying "implement support for the HTC Vive" is the same as saying "implement support for this model of A4Tech keyboard" or "implement support for that LG monitor". Ideally VR headsets are be detected by the OS as a monitor + an input device like mice and tablets (the head tracking), which should mean that side-by-side stereoscopic rendering and proper mapping of the head rotation should do the trick for any headset type.
  23. MirceaKitsune
    As most players will surely agree, one of the things that make TDM great are its visual capabilities, which come from idTech 4 having been so well designed. As I've been playing more with rendering and game engines during the last period, I realized this is something worth bringing up in the graphics department. I dare suggest it since frankly, TDM has some of the best graphics in the world of open-source games today... the idea of adding a common effect that would rocket its visual quality even higher sounds acceptable enough to post about. Typically there are two light occlusion effects, though I can imagine them combined in one by a smart renderer: Ambient Occlusion to simulate darkening in tight spaces, and Global Illumination to simulate light reflecting off surfaces. They're often costly to calculate for realtime lights, but there are engines that do it right... Tesseract (FPS based on Cube 2) offers a great example of doing FPS-cheap GI! A more serious problem specific to TDM is that this would affect the brightness of areas, and in turn the gameplay on existing maps... it would need to be an user option for this reason. I'm mostly curious on the opinions of the devs; Could at least SSAO be considered at some point, if not an implementation for radiosity? Some examples of why this is so awesome.
  24. MirceaKitsune
    Coal powered motorcycles existed in real life?! Who would have thought TDM would teach me things I never knew about history.
  25. MirceaKitsune
    I know, and I am using LWO for now. I want to try ASE as well for some things, but for some reason can't find any working exported on the internet.
×
×
  • Create New...