Jump to content
The Dark Mod Forums

cabalistic

Development Role
  • Content Count

    681
  • Joined

  • Last visited

  • Days Won

    16

cabalistic last won the day on September 1 2018

cabalistic had the most liked content!

Community Reputation

414 Legendary

1 Follower

About cabalistic

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Germany, Munich

Recent Profile Visitors

263 profile views
  1. Yes, Vulkan would need porting shaders, too. Actually, the porting itself has been completed in the meantime, but Vulkan would need more - Vulkan requires compiled shaders in the SPIR-V format, so the entire pipeline for shaders would have to change somewhat. The problem is, with Vulkan you'd basically have to completely reimplement the entire rendering pipeline and properly decouple some additional parts of the engine, all of which is a massive undertaking (though very educational, I'm sure). Modern OpenGL techniques, on the other hand, can be integrated piece by piece and coexist with the existing pipeline, so much more manageable. It's also doubtful that Vulkan would deliver significant improvements over modern OpenGL, because the engine has more glaring bottlenecks. So, given the effort required and the expected negligible gains just make a Vulkan port rather impractical. Not saying that it wouldn't be fun to do, just not practical
  2. It does not, currently. I'm working on it, and there's an older alpha of VR support. Hopefully, after the upcoming 2.08 release, I'll be able to update the alpha version again
  3. Phew, key mapping on Linux looks quite broken in the code. Doom3 is using a very limited mapping table on possibly the wrong input. I added a new mapper for standard special keys that should at least improve the situation, starting from 2.08. In the long term, we may need to look into a rewrite, possibly using a sensible input library.
  4. You're right, the shadow geometry can be cached. Rendering it to the stencil buffer, however, cannot, because it's done from the camera's point of view (unlike shadow maps), and that typically changes between frames. But of course, the geometry is the more significant cost
  5. At least for classical stencil shadows, yes. You can't really implement a forward+ renderer with stencil shadows. Technically, TDM uses a trick for soft stencil shadows that would allow it, but it is detrimental to performance. And even then, stencil shadows would have the disadvantage that they need to be rerendered on every frame, whereas shadow maps can potentially be cached as long as the light itself or the shadow casters in its vicinity don't move. As for putting shadow volume generation to the GPU: that's possible, in principle. However, my experience with geometry shaders has been poor, they usually tank GPU performance quite significantly if you use them for anything other than a few simple objects. I'm not sure it's a good trade-off, and personally at least I think the kind of effort needed to implement it is better spent on improving shadow mapping. But that's just my personal opinion
  6. The performance comparison is not that simple. Yes, the GPU side is fairly cheap, but even there it has drawbacks. In particular, it requires to render each (shadow-casting) light separately, which is not ideal in modern rendering architectures and does not scale particularly well with many lights. And while the rendering itself is cheap, creating the necessary shadow geometry is not. That's traditionally done on the CPU, and it's one of several reasons why TDM is currently heavily CPU-bottlenecked. There are a couple of reasons why it's currently not the case, but I'm willing to wager that shadow maps will eventually outperform stencil in TDM
  7. This is a question for @duzenko, but I think the fullscreen resolution handling was changed such that the render window is always at full desktop resolution, but the internal render resolution is set according to your choice. So even if the app runs at 4k, rendering should not. Can you see a quality / performance difference ingame between different resolution settings?
  8. That's the dynamic index/vertex buffer running out of memory. This is fine, though, they are automatically resized. Basically, to not waste GPU memory, they start at fairly modest sizes. But the more demanding your map is, the more memory you need. If the current value is not sufficient, the buffers are resized automatically. The messages are informative only.
  9. Perhaps it's not texture-related, but rather the vertex/index buffers. That might suggest memory corruption or possibly missing/incorrect GPU fences.
  10. You people keep missing each other's points, I think. Context matters Alberto, while I agree with your practices in principle, even "universal" concepts don't apply universally to every problem. I would recommend trying to find a recording of John Romero talking about id Software's history and how they approached game design. He specifically mentions why missing assets are not treated as hard errors, and - surprise - it was specifically to enable fast iteration and getting products shipped Like I said, context matters. Missions and assets are not quite the same thing as writing code.
  11. This would basically require to develop a "new" renderer in WebGL, and possibly some other significant platform porting. I'm not stopping anyone from doing it, but this is going to be a significant amount of work. If I'm writing a new renderer, I'd rather learn Vulkan in the process than another variant of GL
  12. Well, I did get VR rendering working in my PoC, but it turned out that performance is too bad in many maps. That's why I abandoned the effort until perhaps one day enough performance bottlenecks are solved to make it more feasible. A basic stereoscopic rendering would not be as performance critical and is not terribly difficult, but there are some gotchas. In particular, some optimizations in the engine do not play nicely with stereoscopic rendering, so it's still some effort to put in. GIven that the renderer is undergoing some major changes at the moment, I don't think the time is right to add this, as TDM has enough to do for 2.08. Also, as long as that work is ongoing, the renderer is fairly unstable codewise, so that makes adding (and maintaining) stereo support more work.
  13. Stereoscopic support was only added with Doom3 BFG, but TDM is based on the older Doom3 engine. Therefore, there is no stereoscopic support whatsoever.
  14. Capture frame should just work. If it's not, I'm afraid I don't know how to help you with that. You could try the standalone version of nSight, it worked better for me than the Visual Studio integrated one.
×
×
  • Create New...