Jump to content
The Dark Mod Forums

Search the Community

Showing results for tags 'engine'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 10 results

  1. Hi there! Glad to see forum is active I just saw in Gameranx video info about darkmod and as thief series fan I start to think that I might do something even by my own. Im 3D artist with photogrammetry specialization (I work for Indie studio almost a year now ) so I thought it might be refreshing and interesting portfolio piece. Problem is, I watching right now second video of tutorial and there is information about lagy levels if you not use portals. My background is photogrammetry and HP modeling in zbrush so Ideally I would sculpt and decimate models with nice textures (2k or 4k), buuut; that might be not an option as far as I see. Game engines are topic that I not explore at all, because use of decimated photogrammetry assets is not a problem in UE. So, in summary, what polycount and texture size limitations we have per model. Let say custom item like candle. 2k poly and 512 texture or it must be under 200 poly or something ? Cheers and huge thanks to everybody who started and keep that project alive Cant wait to find some free time and play something new so close to Thief 3 game.
  2. This was discussed briefly on Discord some time ago, I wanted to bring it up here as well for consistency. I don't believe it's an emergency but do consider it an important change especially later down the road, as Linux is slowly moving away from x11 with many distros already going full Wayland by default. In my case I'm pretty much waiting for KDE Plasma to fix a few bugs left with the DE before permanently switching from X11 to wayland too, I might be able to make use of it rather soon if they do. With the new input and rendering system introduced after 2.09 and available for testing in the dev builds (GLFW) we're on our way to having a Wayland compatible build of our engine. Meaning the engine is able to render natively to the WL pipeline, without having to go through the fake x11 server simulated by the Wayland session for compatibility with X exclusive apps. This not only offers proper compatibility for Wayland users, but may improve performance on various fronts which was one of the goals of the new rendering framework. From what I remember @cabalistic telling me, we can't have the same engine for both x11 and Wayland: It must be compiled against different system packages to produce one version or the other. For Linux users the installer may need to offer two engine binaries in this case, or an option to pick which version you'd like to install if that's better. Other than that I understand it should be able to produce in theory, as SDL2 and GLFW both offer Wayland compatible libraries to compile the engine against. I'm not familiar with the C++ code in the slightest so I'll let the experienced developers complete this with the proper technical additions.
  3. https://bugs.thedarkmod.com/view.php?id=5068 Sometimes, when going underwater, the shader responsible for blurring the view will shrink the image to roughly 1/4 of the screen (1/2 both horizontally and vertically) and position it in the lower-left corner, while leaving a jumble of textures to display in the background. This only seems to happen on rare occasions; My latest test suggest it occurs if the player has taken any damage and the health bar is showing up on the HUD. I'm running TDM 2.07 x64 on Linux (openSUSE Tumbleweed) with the free video drivers (amdgpu).
  4. I've recently posted this into another thread, but I thought I might as well make a thread about it. Regarding engine upgrading, I was wondering, it would perhaps be best to create a separate webpage dedicated to the TDM Engine, chiefly to document new features and updates that separate it from idtech4, but also to attract potential developers that can help improve it. Is there a github page for the code, or something like it?
  5. https://bugs.thedarkmod.com/view.php?id=5055 There seems to be an issue with shadow rendering in the engine: When enabling both Stencil Shadows and Soft Shadows, shadows get incorrectly mapped and are stretched across the screen in front of the camera. I have no issues when using Stencil Shadows without shadow softness, nor when using Map Shadows both with and without soft shadows. I'm running TDM 2.07 x64. My operating system is Linux openSUSE Tumbleweed x64. Kernel 5.2.14. Mesa 19.1.7 (amdgpu module). My video card is an AMD Radeon XFX R9 390. I attached two screenshots from the FM Full Moon Fever: The first shows stencil shadows without softness (normal results) and the second is stencil shadows with softness (corrupt shadows).
  6. Ok so we are having a lot of talk surrounding TDM's engine, and its amazing that we are having so much done in the way of improvements to it, lately. I thought it could be fun to have a (yet another) place where we as fans could post things we would like to see added to the game, more specifically to its mechanics. Just suggestions for things that we feel would reinforce the game's strengths and design choices. Obviously, its up to the team and coders to know where to best place the resources and what needs to be prioritised. But a man can dream... Having said that, lets start with something simple and easy... Physics overhaul Ok, maybe not an overhaul, but if theres one thing I always wanted to see improved in TDM (idtech4), before any graphical enhancement, was actually the physics. Not just the sort of fixing that has been taking place on specific points (like being able to KO guards with thrown or fallen objects, which was implemented back in the day). In my dream scenario, TDM would be going closer to a true "physics simulation" type of plataform (keeping gameplay needs at the front, of course). Why do I say that? The potential for a slow, deliberate stealth game in a trully responsive world are immense. Lets remember some of the possibilities to gameplay coming from great physics, as seen in Half Life 2 (I use it because its from the same generation as Doom3): (In the second video) The moment where the player accidentally pushes the pc monitor and it falls down (at 2:02) making a mess, or the whole section from 2:50 to around 4:50 are great examples of things that would be so fun to have in TDM with a more advanced physics system: - responsive chain reactions between objects, rewarding the use of moveables in maps because they can play a crucial role (you dont wanna accidentaly drop a bunch of bottles by bumping clumsily into the table holding them); - pushing objects into place to create obstacles and have their combined weight slow down enemies; - destructable geometry, based on their material (this is so amazing, as you can see in the first video with the wood structures - they seem to be true breakable shapes, organically reacting to impacts or pressure). - being able to throw or cause the movement of heavy bodies that take out enemies and damage other bodies upon impact, even objects with so much mass that they can crush anything on their path; HL2 is a prime example because they used physics masterfully to create all sorts of interesting interactions between the player and the storyline, like puzzles you had to solve using objects and force, or using physics to set traps and take people out, etc. Unfortunately, our engine, although I think many of the principles are there, seems a lot more limited overall. So I wonder how realistic it is for TDM to eventually improve its physics mechanics, either by enhancing doom3's own physics, or by implementing parts of external engines like Bullet or something. Im no expert and have absolutely no idea how hard any of this would be. But I do feel this could be something really interesting for future gameplay.
  7. I hope this isn't a useless thread, just thought it would be constructive to let everyone know about it. I was looking up some TDM related concerns, and accidentally stumbled across another fork of the idTech4 engine. It's called fhDOOM, and it seems to have a lot of neat graphical improvements over the stock engine. eXistence/fhDOOM There are definitely things in there that TDM could consider grabbing! Some important ones highlighted on their front page: Modern renderer based on OpenGL 3.3 core profile. Any up-to-date engine should have this as a norm.Parallax mapping. Not sure if we have this already... I only know the original engine had simple bump mapping.Soft shadows. A heavily desired and long awaited feature.Alpha textures affecting shadows. This allows light to shine through textured grates, which is a very beautiful improvement.Soft particles. This one we already have now however.An example of the old lighting system (ours) versus lighting with shadow mapping (fhDOOM): As the obstacle to new features is almost always finding someone willing to code them, discovering those improvements for our engine is a goldmine... since unless they conflict with any of our changes, I assume they should be easy to just plug into the code. Can any of this good stuff please be considered for inclusion in TDM's version of the engine?
  8. 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.
  9. I am trying to compile the latest SVN engine, on openSUSE Tumbleweed (via gcc 4.8). Compilation goes well until the end, when the process mysteriously fails for an unexplained reason. The only thing that seems to be printed is the name of the file and something called "Error 1". Anyone else running across this, and knows of a solution? Thanks. cm/CollisionModel_load.cpp: At global scope: cm/CollisionModel_load.cpp:42:13: warning: ‘versioned’ defined but not used [-Wunused-variable] static bool versioned = RegisterVersionedFile("$Id: CollisionModel_load.cpp 6551 2015-10-15 18:48:23Z stevel $"); ^ In file included from include/boost/filesystem/path_traits.hpp:23:0, from include/boost/filesystem/path.hpp:25, from include/boost/filesystem.hpp:16, from framework/../idlib/../idlib/Image.h:29, from framework/../idlib/../idlib/Lib.h:230, from framework/../idlib/precompiled.h:106, from framework/precompiled_engine.h:28: include/boost/system/error_code.hpp:221:36: warning: ‘boost::system::posix_category’ defined but not used [-Wunused-variable] static const error_category & posix_category = generic_category(); ^ include/boost/system/error_code.hpp:222:36: warning: ‘boost::system::errno_ecat’ defined but not used [-Wunused-variable] static const error_category & errno_ecat = generic_category(); ^ include/boost/system/error_code.hpp:223:36: warning: ‘boost::system::native_ecat’ defined but not used [-Wunused-variable] static const error_category & native_ecat = system_category(); ^ scons: *** [build/release/core/cm/CollisionModel_load.o] Error 1 scons: building terminated because of errors.
  10. I am wondering why can't entities limit to be expanded beyond 8192 entities ? (I am sure it's plenty, but still)
×
×
  • Create New...