Jump to content
The Dark Mod Forums

HMart

Member
  • Posts

    1409
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by HMart

  1. In this case for a shadow and physics mesh imo is very easy, just make two extra copies of the lowest LOD, slap the shadow material in one and the collision material on the other and make sure both occupy the same space and are on the same item mesh/layer has the main model. In blender (or any other 3D Tool) you don't need to import any TDM material or texture, you just make a basic material for the shadow and collision mesh and make sure to give each the name of the shadow and collision material respectively (not the .mtr file name the full material name, inside the file), is that easy! bear_statue_example.7z ps- here is a fast example of what I said, sorry for not making it plug&play to TDM. I add too mess with the model because I use Modo and it doesn't open ase files, I add to convert to obj using another tool and also rotate it in Modo to be able to work with it, so now is not a, one to one, to the original model and so shouldn't be used with the LOD's that were provided, this because I assume they will not match, but I didn't tested, plus the material name for the main mesh is not the correct, only for the shadow and collision mesh's are correct (follows doom 3 convention). This should be seen just as a model for anyone to know how a shadow and a collision model should be setup. (for those that don't know) I also used the second LOD counting from the last because the lowest LOD seems to not follow the main model silhouette perfectly, it could very well work at the distance but not for a shadow and collision mesh.
  2. Sorry if late but if still useful, here is a memory dump of the DR 3.0.0 crash. https://drive.google.com/file/d/1Ws7FFyG15NTp-q8GuGnWUMKTUVwkoCpY/view?usp=sharing
  3. Yes indeed but DR 3.0.0 like I said also crashs but is after, not during initialization and is random, sometimes it crashs, sometimes it works fine. Btw If other AMD users aren't getting the same behavior, it may very well be my particular PC configuration, I did some stuff to this computer that may not be desirable, like hot swapping the entire motherboard, the CPU and the GPU for new hardware without reinstalling windows, it works fine (and I've read online that windows is ok with it) in pretty much I do but it could influence DR somehow?
  4. Sorry try this one https://drive.google.com/file/d/10g0D4Ujn9V99yezEgcNPgP1gvV_MLNTe/view?usp=sharing
  5. I have a AMD 6600 XT GPU and a Ryzen 5900 CPU I confirm the bug in DR 3.0.0, red selection works on 3D view but not on 2D view, also it crashes randomly after loading to me. Unfortunately can't test DR 3.2.0, it always crashs before it opens. memory dump https://drive.google.com/file/d/10g0D4Ujn9V99yezEgcNPgP1gvV_MLNTe/view?usp=sharing
  6. Is that endorsed by Nintendo? I hope it is because Nintendo can be very protective of their IP, it has shutdown mods before, I'm cautiously optimistic.
  7. The physics on that video do look better, I still think they aren't "normal" looking, i mean not similar to Havok, PhysX or more recent physics engines but I can't deny that was way better than the older video. Btw I knew that using a faster single core CPU, would make the idtech 4 physics engine able to calculate more objects, what I didn't knew, was that you guys made it able to use multiple cores?! Is that right?
  8. Look how few boxes there's moving on that simple scene and already the performance feels so low. Next to the problems you pointed you can clearly see in the TDM video, how the physics objects move in very obvious discreet steeps, looks has if performance took a nose dive at that instant, but is that really performance going down or just how the idTech 4 physics were made to work? Instead of a continuous smooth movement they move in steeps?
  9. Indeed it would About the video I knew something like that was already possible on TDM, the problem imo is the physics objects, behavior/speed and performance. And guys don't take me wrong, TDM being a Thief homage, I don't think should go crazy on physics, I just think that with a better physics engine, some doors would open to make some cool physics based stuff, in or outside the TDM/Thief lore. Would be cool if possible but I know you can't just swap the physics engine there's a bunch of work involved, this is just a "what if" .
  10. The physics engine is open source (MIT licence) and it seems it was used on a AAA game already see here. https://github.com/jrouwe/JoltPhysics I can only dream that some day this may happen to some idtech4 based engine. So much cool physics based gameplay would be possible in that case. A small glimpse at what perhaps some TDM traps could look with a better physics engine, thou I do think some of the traps in the video bellow aren't suited for TDM and or are already possible with current TDM physics. https://www.moddb.com/games/shadwen/videos/video-2
  11. They took their sweet time, AMD has done that years ago but is better late then never.
  12. Personally, if editing original Doom 3 code, I always put my code between #ifdef macros, just like the D3xp team did and I think is a good idea, in that way, I can immediately know it is my code later (blame my self not idSoftware) or disable my edits, if necessary, for debugging or something.
  13. For TDM programmers and people that know how to edit and compile the engine.
  14. I'm not 100% sure (have not tested it) but I have read a long time ago that the material names can be any size, even a single word, like this below ivyloose06 { qer_editorimage textures/decals/ivyloose06_ed.jpg diffusemap textures/decals/ivyloose06_d.tga specularmap textures/decals/ivyloose06_s.tga bumpmap textures/decals/ivyloose06_local.tga } the name doesn't need to be a path, paths are relative anyway, (relative to the texture folder) and are only important for the textures inside the material itself. I think the material name written as a path "textures/somefolder/materialname" is used by the editor to create the folder structure in the media browser, that's all, if you don't give the editor (DR) a "path" it just puts the material in the main "textures" ones.
  15. Indeed, like Greebo more or less said, some render effects are still missing or incomplete, so performance will very probably, come down even more, but even so the bump on performance and quality, compared to the former render is fantastic, no one can deny that.
  16. Not 100% sure about TDM but this is what idSoftware said for Doom 3 and I never read that the team changed how md5 animations are handled. A community member, did revived the unused md3 animation system from quake 3, that was disabled but still on the engine and that is pure vertex animation but making the md3 play the animation, is not that user friendly and no one has ever made md5 and md3 models work together on the same character, for example md5 skeletal animations for the body and md3 vertex animations for the head, would be cool thou if possible.
  17. see in tdm_ai_humanoid_beasts01.pk4 (pk4 is just a renamed zip file, you can open it with 7zip)
  18. Hi Frank Cotton, please do what you want, but if you don't mind, I have some suggestions for you to consider, If perchance along modeling, you know how to animate, personally and I mean personally, I would love if someone would make more animations for the werewolf character, specially a better run animation and a cool roar one for when he detects the player. Also again IMO, if instead of rework existing ones (that imo are fine for the time being), a totally new character would be cool, for example, like we have the small spider like guard bot, to me would be cool, to have a relative big, biped steampunk robot, with animations, at lest walk and search animations, why, because based on Doom 3, imo is sad to me that the engine has AI AAS support (ability to navigate in a level) for big monsters but TDM has none to take advantage of that. I can imagine some missions where the player goes to some inventor guild place and has to go around a massive robot to reach some high value thing. Something like where the head is a search spot light that goes around and he makes steam boat sounds when he detects the player. I know this second one is very probably way harder to make than the one above and TDM already has a automaton character but imo is to much a obvious reskin of the builder guard. A better automaton would be cool, one that is more or less the representation of a human guard but still very different, something not like but akin to the following, world be cool Where his eyes are red and cast a spot light mood example Of course all of this new characters without animations, will be almost useless only used has static props, so again if you can't animate, reworking a existent character is obviously better. Just my two cents.
  19. IMO just Tessellating a low poly model, may help round silhouette's a little but will not magically make them look better, perhaps may even make it look worse (and unnatural) and imo is very wasteful, why, because like I said above, when doing that, many polies will very probably end on flat peace's and still look flat, have no visual impact but still make GPU's work harder.
  20. This engine doesn't support quads at all, all models need to be triangulated at export time. Don't take my word for it but IMO that limit seems to be a old recommendation for Doom 3, today is very possible to have a character with more polys (triangles), those Dragfer suggested sound reasonable but I would be surprised, if you couldn't have one or two 10 000 or more characters moving around, all depends on the amount of characters you want on view and the minimum PC you want to support. But with all respect, please make those polys mean something, don't make a high poly model, where many triangles are wasted in flat peace's, I've seen this in some games. Also it seems this engine, cares more about material complexity than raw polygon count, of course within reason, don't go crazy on polys just because, when many lights cast unto a single model, all at the same time, it is re-rendered per frame, for each light that strikes it, that can potentially mean, millions of triangles being rendered per frame (including all the rest of the scene), please have that in mind. Btw afaik for animated MD5 models the higher poly it is and the more complex the skeleton is (many bones), slower it will become, I assume because bones will have to transform (move around) more vertexes, so imo is always good to test and if necessary optimize animated md5 models and use only the strictly necessary bones. And to finish , like Dragfer said, TDM has a level of detail system, so please make LOD models. make a low poly shadow mesh (use the last LOD level for that?). Not sure if required for animated md5 models (I think those use a ragdool? "articulated figure") for that, but at lest for static level geometry, making a low poly collision mesh, is necessary (can be the shadow mesh), if not the engine will use the real mesh for collision, very slow. Not important for animated characters or static models but for dynamic rigid body models, (those moved by the physics engine) unfortunately there's a limit of 16 polys/triangles for the collision model the visual model can be higher poly. Hope this helps.
  21. haha yes that is true, is a fact of game development, is because people are writing new code, copying or moving code around and sometimes simple mistakes are made, in code, even a simple comma in the wrong place, can break a entire game. And even code that worked fine before, after some new work can stop working for some obscure reason, is called regressions, 3 steeps forward, 1 steep backward. Have patience and just wait, I'm sure that when someone in the team sees this, they will solve it and maybe, make a patch or solve it for the next TDM version but only them can decided that.
  22. Go here https://bugs.thedarkmod.com/ You need a account to be able to report bugs.
  23. I'm talking about the engine and game source code, the c++ source code. Unfortunately, unless you know how to code in c++ and how to compile the engine than you will have to wait for the TDM team to solve that bug. The best way is to make a bug report and link this thread there.
  24. I think I found the real problem on the player cpp file on UpdateConditions() function this code // DarkMod: Catch the creep modifier ... else { int creepLimit = cv_pm_creepmod.GetFloat() * 127; AI_CREEP = (usercmd.buttons & BUTTON_CREEP) || (idMath::Abs(usercmd.forwardmove) <= creepLimit && idMath::Abs(usercmd.rightmove <= creepLimit)); } Needs to be like this // DarkMod: Catch the creep modifier ... else { int creepLimit = cv_pm_creepmod.GetFloat() * 127; AI_CREEP = (usercmd.buttons & BUTTON_CREEP) | (idMath::Abs(usercmd.forwardmove) <= creepLimit && idMath::Abs(usercmd.rightmove) <= creepLimit); } The close ) for the idMath::Abs was on the wrong place. The change to bitwise OR | instead of the logic OR || was a recommendation of visual studio 2022, not something I really know if necessary, changing that didn't solved the bug nor the behavior, a better programmer may explain why VS recommended that change.
  25. I could be wrong because it was a fast look at the code but based on my debug section of the Move code, the problem seems to be that, when the player steeps to the left the "moveType" string, is set to "creep" and when moving right, is set to "walk", that causes different sound volumes to be set for the final steep sound.
×
×
  • Create New...