Jump to content
The Dark Mod Forums

motorsep

Member
  • Posts

    913
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by motorsep

  1. Do you know if it's possible to have 2 normal maps per surface (material) ? For example, I want to have a large rock with one normal map defining general shape details (non-tiling, fits the model) and second normal map defining smaller details, tiling over the surface. I recall there was something like adding normal maps or adding normal and heightmap in Doom 3, but I am not sure how (if possible at all) to make one texture just fit the model as if it was just a regular func_static with regular material, and have "detail" normal map being added to the original one, but having it tiling, as if it was like a wall textures. Thanks.
  2. Widget is a must, since scaling/rotation is done in place where model is kitbashed. We'll haven to look into the matrix stuff. Not everyone feels comfortable working with matrices :-) As for collisions, it's the engine's thing. Should be easy to fix. EDIT: I am guessing it would be nice to simply do this [1 0 0 0 1 0 0 0 1]*2.5 in the transformations spawnarg to scale up model uniformly, until scaling widget becomes a reality (or have an extra field for scale). DR would do rotations first, then scaling. This way it's easy to position the model, then scale it up/down, reposition it, adjust scale.
  3. You save scale in the spawn argument on the entity. For example, if you scaled you model 2.5 times larger, you would get "scale" "2.5" spawnarg set on the entity. Next time DR load the map, it parses the spawnarg and scales up your model in the view.
  4. Proper way is, like I said, to have "scale" spawn arg (vector) that scales model internally in the DR, without messing with the file itself. On the engine side "scale" will let engine know that the model needs to be rendered in scale, and collision model would be generated accordingly. Again, source ASE/LWO file will remain as-is. I guess what I am asking is for OrbWeaver to point me to the code where scale spawn arg can be introduced (reading/writing/updating) and where render model can be updated, based on the scale spawn argument. Also would be interested to know where in the code we would be able to enable scaling (Rotate and Scale UI) and where in the code rotation widget is handled (would be nice to add scaling widget).
  5. You don't need to save / edit anything. DR would render scaled model from RAM. Physical copy stays as is. Same thing with rotations - models on HDD aren't rotated. They are only rotated in the viewports.
  6. We'll fix it in the engine. I am more concerned about the Editor.
  7. Models. And as you can see "important" note says rotation hack is not recommended. So I want to see if we can implement proper scaling.
  8. Would it be hard to implement scaling of func_statics in DR ? Besides visual uniform/non-uniform scaling, "scale" spawn arg should be created and modified on the func_static entity. This would allow building maps like in UE4 / Unity using kitbashing technique.
  9. We experienced interesting issue - on Win10 with AMD GPU, 32-bit build of our Doom 3 BFG derived engine crashes randomly, but 64-bit build works fine. Do you have similar issues with TDM ?
  10. Simply because Win7/8 is technically still WinXP. Windows 10 suppose to be redesigned, and when redesign happens, incompatibility happens. Whether it's flawed or not, we'll see next year, when MS fixes it up and updates it. Since it's the last version of Windows, I am sure they will keep refining it until it's better than Win 7.
  11. I assume T2 and T3 are Thief games from more than a decade ago ? How can you expect those games to just work on modern hardware and OS without devs updating them ? Plus, it's most likely related to video drivers, which doesn't have much to do with Win10 per se. Some Linux apps built with older libs and core won't run on current Linux builds. It's expected. Software needs to be adjusted and recompiled with/under new OS.
  12. Nah, I would like to be able to search references, have hints for functions/variables when hovering over them, peek definition, etc. Just like when you code in C++. Highlighting can work (somewhat) by default if you use C++ highlighting.
  13. There used to be this app for scripting: http://d3raptor.tripod.com/screenshots.html, but it's gone now. So having MSVC extension as IDE for DoomScript (and flexible/configurable enough to accommodate not only stock Doom 3, but any standalone game made with idTech 4, like TDM) would be awesome and quite useful!
  14. Has anyone ever tried making an extension for MSVC to allow coding in DoomScript inside MSVC, utilizing all it's power when it comes to search, highlights, hints, going to declarations and definition, etc. ? Is it possible?
  15. @NagaHuntress: Why is the fix you already implemented is not enough? It seems to be working fine (I am still testing large 120k x 120k terrain, but so far so good)
  16. I don't use patches a lot and I never made terrain with patches. However, player was getting stuck in the mesh made terrain. So I am guessing it's safe to say patches would have same issues as mesh/model.
  17. From what I understood, renderer uses same math classes as the rest of the code. If you would switch everything to doubles, there will be issues with rendering. But perhaps I misunderstood that.
  18. Would you only need to increase precision for collisions part of the code or for the entire codebase ?
  19. @NagaHuntress: I recall we tried a few years back (with Doom 3 engine) to move to double floats and performance penalty was very harsh (and I don't recall if it solved the issue of getting stuck) I wonder how CryEngine solves that issue with its massive outdoor levels. I've heard of a trick where player is always at 0 0 0 of the world, and the world moves around, unlike in conventional game engines, where the world is static, and player moves across the world.
  20. Yeah, but I meant interactively dragging bounds and having the volume to resize uniformly ?
  21. Is it possible to resize a light volume in DarkRadiant uniformly ? Thanks.
  22. Tested and indeed, it all works like a charm! Great job you've done, NagaHuntress, thank you! I am gonna see about trying to test AI/NPC and physics objects on that edge. Hopefully none will get stuck
  23. Is the direction of movement method in second (disabled in your patch) #elif block ? I also wonder if this fix affects non-player characters and AI (I haven't tested Doom 3 AI against that test case ).
×
×
  • Create New...