Jump to content
The Dark Mod Forums

HMart

Member
  • Posts

    1545
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by HMart

  1. Seems to be OpenGL I tested right now. 

    See how light cyan is top, the middle two small lines, look like they come out of the surface, like they should, the left circle, should also look like it is coming out and the right one going in, like the two big vertical line on the sides.

    Btw the normal map was something I just made on a hurry on paint.net so quality is not good but did it's job. :) 

    tdm_norm_test.gif

    norm_test_ex.gif

  2. 46 minutes ago, Amadeus said:

    I just learned this recently too, it should be Direct X

    Is that really correct? Unless TDM team changed stuff from Doom 3 times, if you use Doom 3 as example, normal maps that represent outward surfaces, use OpenGL system, those that represent inward surfaces, aka holes, use D3D system. 

    On real DirectX renders, outward surfaces, use the D3D system instead and the OGL one for inward, is inverted.

    And to reinforce this the original example by idSoftware, looks to use the OpenGL system see here

    bumpmaps_b.png

    cyan for top, purple for the bottom, in d3d is inverted.

    Thou like I said maybe the TDM team changed all of this by now...

  3. 37 minutes ago, MirceaKitsune said:

    Oh, some implementations might work a little differently from what I remember the term megatexture referring to. From what I used to know, it meant turning the entire level into a single model or set that uses a single enormous texture.

    R: The level does use a single enormous texture but is not a texture in the usual sense per se, afaik a MT is a buffer of pixels arranged and optimized in a way to be streamed in fast possible.  

    While the concept may have its upsides, there are two major issues that negate any benefit in my view: The first is system resources, you don't benefit from any reuse as every pixel is unique, the only way to do it at scale is with a gigantic image thus a huge performance drop in pretty much every department.

    R: Where do you got that idea? Afaik performance is exactly the same as for normal textures?! You only render the necessary tiles, for the scene you see on screen at any giving time as use the necessary vram, you can even see on the video I posted that a Nintendo 64 can handled it fine!

    If you are talking of the blurriness when moving fast, that IMO is not performance, is more speed of streaming in the textures, it only affects visuals not movement performance, but this was worse on the HDD days thou, today with SSD's and M2 drives, IMO things have improved a ton. 

    Also I played most of all modern Wolfenstein games, Dishonored 2 and the first modern Doom game, all of them use MT and are imo, very performant games. 

    The second issue is that level design becomes far harder and more specialized...

    R: This is true indeed.

    while here in TDM we only need to draw a bunch of brushes and place some modules to make a level, an engine based on megatextures would require level designers to sculpt and paint the entire world in software like Blender which is far more difficult and we likely wouldn't have even half of the FM creators we do today, even for those that know how to do it imagine the task of manually painting every brick on every home and so on.

    R: Yes you are right but IdSoftware remade their own editor to be able to paint in real time unto surfaces and slap overlays/decals very easily all around, they add no need to force artists to do it on other tools like Blender, thou based on what I know about Seneca (one of the id's artists) for example he wouldn't mind working on a external tool, he already did it for Rage. 

    But anyway in reality, this tech was made for pros, for big teams, not single developers like TDM mission makers, even John Carmack (the guy that invented MT) said that when Rage 1 came out, he said it would be very hard to mod Rage, if not impossible, because of MT.

    Btw you can slap repeated textures unto surfaces with MT, there's nothing preventing that, it just gave artist's the option to make every surface unique, by being able to easily paint detail all over with no fear of texture limits, if they wanted too, and in some ways they did that in other games and engines as well, even without MT, for example Fallout 3 world, was "painted" all over using a special decal system. 

    I concede that there's problems with MT, but IMO the real problem with it, is not on the user side, or was performance, quality or being a bad made tech, it was just speed of streaming in, size and was hard to handle. Specially for indie developers but later even for AAA teams, it was found to hard to handle for PBR and real time lighting.

    Spoiler

    MT was good for games with baked lighting, because most surface data/info could be baked into a single huge texture, but modern games, more and more require real time lighting and also require, a bunch of more texture data, the data to make a single surface looks, on many modern AAA games, is mind blowing, there's the diffuse/albedo map, the normal map, the metal/specular map, the roughness map, the AO map, the height map, the gloss map, the subsurface map, the reflection/cube map, etc, etc, with MT, many of this textures, would need their own separate MT, this to work with real time lighting. This would be extra GB of texture data on top of GB and so, even more compression needed. And baking a Rage 1 MT, was already a time consuming process and needed a PC farm to do it, imagine today.

    This is why even idSoftware ended abandoning some of the MT ideas, like the baking huge textures workflow but not all of it, the virtual texturing itself and texture streaming the most important part of the tech anyway, is still used, afaik UE5 still uses VT and texture streaming as well, and this can work with individual textures as well.

    But just saying that MT was a horrible idea because its limitations, is also imo not fare or true, because it also brought some good ideas to the table, it was a evolution process and like all such things the final incarnation can end very different but it needed the initial state to start somewhere. Enough said.

    Ps. sorry for the huge wall of text.... :P

    • Like 1
  4. 1 hour ago, MirceaKitsune said:

    Megatextures were a horrible idea ...

    Completely disagree it was a very good idea that unfortunately came too early with idSoftware RAGE 1 because hardware was still and is not truly ready for it. 

    Megatexture is for textures, what UE5 nanite is for geometry, it permits huge amounts of texture data in a level and even totally unique textures per each surface, no repetition unlike older methods.

    MT isn't simple a giant texture slapped unto a level, it is a type of virtual texturing system, the MT is a huge "texture" but it's data, is not all drawn on a level at the same time, like a normal one is, it is broken into smaller squared peace's and those peace's into even smaller ones for LOD aka mipmapping, then those peace's are streamed in, in real time has the player moves around. 

    Again IMO It is a very cool idea and if the hardware was fast enough, to stream it fast and it was possible to compress the MT data, to very small amounts and still keep good quality, it would be a fantastic system for very unique levels. Rage 1 world may look bad at close distance, but at medium to large distances imo it looks fantastic and totally unique.

     

  5. 19 hours ago, Petike the Taffer said:

    I wonder whether you can resize and reshape a speaker from a spherical shape into a rectangular shape that could fit in a room.

    I couldn't find a clear tutorial on resizing the speaker and altering its shape from the default sphere/orb shape. Odd.

    Maybe it's just a dumb pipe dream by me, but I'd find a rectangular sort of configuration for a speaker much better to work with.

     

    Why do you want a square visualization for sounds? If is because you are afraid, that because of the fact the sound shape goes through walls, in a squared like room, that sound may go as well, then don't be, afaik unless there's zero portals in a scene, sound will be blocked by "walls" automatically. It uses the portals to know where it can "flow" into other rooms.

    So only the size not the shape of the visualization, is what matters, like OrbWeaver said, the shape is only a visualization for the inner and outer radius of a sound.  In other words the area or "field of influence" of a sound and that "field" afaik, expands equally in a 3D volume, in a sphere like manner (to be more precise two spheres, a smaller inner one and a larger outer one), so a sphere shape, IMO is the best approximation for it.

    I also assume, a cube would be misleading because on the current system, if the player parked at the corners of the cube, he/she wouldn't hear the sound, thou I never tested it.

  6. It detected my CPU core count correctly, 12 physical 24 virtual. :)  

    Btw just curious but what's the reason, for the cpu core data to not be printed at the top? Next to the cpu name and features like AVX and SSE stuff. 

    Not complaining, critiquing or anything, if is like that, it most be because of a good reason.  I just found it odd that's all, because I add to travel down a bit on the console before I saw the cpu core count and thought "why? when there's CPU info already at the top?". 

     

  7. 4 hours ago, Dragofer said:

    Nice - did you find a solution for how to avoid it clipping into walls or other solid objects when coming too close? Off the top of my head there was also a need to handle its behaviour in case the player gets submerged, and various other ToDo's.

    There's a cool trick that is making what you have on your "hand", very small, or at lest smaller enough to not get out of the player collision mesh, so it can never reach a wall, the player collider prevents it. And then move the object very near the camera "lens" and it will look big and normal despite the small size, is a nice trick that I learned a few fps games use. 

    But I don't think is the one idTech 4 uses... 

    3 hours ago, snatcher said:

    No, I didn't. According to @HMart it needs a hack of some kind? I don't know.

    ...

    Unfortunately I don't recall what that trick/hack is anymore, I just remember something about the engine code having what idSoftware called "weapon hack", probably just looking at the engine code and searching for weapon hack, will give some results, thou like I said, right now, I don't recall how it is used. :( 

    • Like 1
  8. 27 minutes ago, stgatilov said:

    ... (and are not even self-sufficient).

    What do you mean?   Btw I don't want to continue with my "complaint" or push the subject further, I've said enough already and is your guys decision.  I'm just genuinely curious what do you mean by that. 

  9. On 3/9/2024 at 12:45 PM, Frost_Salamander said:

    both maps and stencils can produce a pixelated shadow if you look close enough.

    Not to start a discussion on this but just for correctness, that is not true at all, unless you are using a really low polygon shadow mesh, if you see a pixelated shadow with stencil, then that is a shadow map or a mix of both stencil and shadow maps. 

    Stencil shadows are crisp and well defined, they have no resolution setting or quality setting (besides turning off shadows), because they are literally geometry (triangles) being projected unto surfaces, while shadow maps are pixels (textures) so you can control how sharp they are.

    Comparison.jpg.996d2187d435fc237435d4ba5

    TDM has a mix shadow system, where some effects even in stencil shadow mode, will use shadow maps, for example volumetric lights shadows, are shadow maps.

     

    Stencil shadows

    500px-Shadow_volume_illustration.png

     

    Shadow maps

    GUID-48D90406-3DCC-4CF6-9A20-6EEC0DD2FBB

  10. And btw I'm not against using both shadow systems, I just think that supporting two systems, is more work, but if the TDM engine team is okay with that, then go for it they have my full support, for what is worth.

    I just personally don't like that shadow maps are being pushed back is all. :(

    But you guys do what you want, this should be a mission makers decision, I'm just a "customer" I will have no choice but accept what you guys decide. :)  

  11. And those pics that Daft Mugi posted do show the problem with TDM maps, but I also have to say, that is a problem with TDM shadow maps, not with maps in general, I never seen such ugly issues in Stalker for example or Call of Juarez and many other games. 

    Perhaps those shadow maps issues arise from people not thinking of shadow maps at all, when creating their lights, shadow maps do require a little more tweaking to look good, specially at grazing angles, because they are literally textures, so perhaps moving the lights a little solves those problems or even increasing the shadow map res.

    Just think about this, if shadow maps where that ugly, the gaming industry would never deprecate stencil shadows and we would still be seeing a ton of games using them, but is totally the contrary, games with stencil shadows, are the minority, even idSoftware removed them, I think since Rage (i'm not totally sure about Rage...) and up (besides obviously Doom 3 BFG). 

    For example: 

    Wolfenstein II

    Wolfenstein II: The New Colossus Laptop And Desktop Benchmarks ...

    Dishonored 2 

    ds2_10.jpg&f=1&nofb=1&ipt=04a2871572b21a

    Evil within 2

    the-evil-within-2-5.jpg&f=1&nofb=1&ipt=8

    (this particular shot is impossible with stencil shadows, because of the blood that is a particle effect with alpha)

    etc.

    For obvious reasons TDM fans have a good opinion of stencil shadows and I comprehend that, they do look very good, TDM and Wolfenstein 2009 are the games with the best soft stencil shadows that I haver seen, but maps can also look good, if given the chance and used to their full potencial. 

    another game with good stencil soft shadows

    MV5BOWI2NjZiMmUtMzhhYS00Y2VhLTg2ODktMWU2

    Thou tree shadows on this game seem to use something else or literally stencil shadows because sometimes they look like a blob on the floor instead of seeing the individual leaf. 

    &f=1&nofb=1&ipt=7f065c436427bd2e205d75d4

     

  12. 1 hour ago, datiswous said:

    If shadow maps would look good I would agree, but they just don't.

    ok fair enough but you have still not seen TDM using shadow maps to the full potencial, so I would wait until then before making a final decision but ok. Also unlike stencil that looks crisp at any quality level shadow maps only look good at res beyond 1024 and up and also dependes on the tech used, some have noisy edges by nature, because of low res penumbra effects.    

    But to me today they look good enough and the fact they may look less than equal to stencil, maybe the particular TDM implementation, with all respect for those that implemented them. 

    I have played a ton of games with shadow maps that look good at lest to me.

    Stalker for example: 

    stalker-clear-sky-2_1831073.jpg

    Metro 2033

    Metro2033%25202010-03-19%252021-14-57-68

    Dead Space

    windowslivewriterdeadspacepcreview-a57dd

    Call of Juarez

    call-of-juarez-20070511022543484-1988556

    Arkane Prey made on Cryengine

    New Games: PREY (2017) - PC, PS4, Xbox One | The Entertainment Factor

    and many many more. 

  13. I know you didn't asked for non TDM mappers opinion but man this decision makes me really sad, :(  imo after so many years, with both shadow systems and still deciding to hard limit shadow maps, to only stencil can do, is like cutting the wings of a bird.

    Has a player, I can't wait for the day you guys finally decide to remove stencil shadows from this engine.

    EDIT: Ups I didn't saw the poll at first so my comment was a tad precipitated sorry about that. 

     

    Spoiler

    For example, we could have add trees leaf's casting shadows by now, in many missions, making for some cool and moody shadow casting scenes, like for example, a courtyard with a big tree in the middle, casting a big shadow unto everyone and everything passing beneath, or a volumetric light casting thought the leaf's of a big tree and throwing a cool spooky volumetric shadow unto the scene, etc. We don't have such scenes in any mission, imo only because stencil shadows are the default. And if they, even if not removed from the engine, were just not thought has the default shadow system anymore, I believe things would change fast.

    Every time I play a TDM mission and see a cool tree but only the trunk cast shadows, I get really disappointed, because I know is a artificial limitation now, not a impossibility of the tech like it was before.

    The majority of the gaming industry has changed to shadow maps, ages ago. And I would bet money that if you guys, did the same, no one will miss the stencil shadows, not when they finally realize, what they have been missing out.

    Enough said, you guys decide.

     

  14. Could it be anything to do with the shape of the geometry? Is a curved staircase looking at the images. 

    Or the thickness? Thou by that image those stairs are anything but thin.  Is just that I have seen thin walls leak light, while ticker ones do not and I have seen this, in more than one engine even in lightmapped ones.

    Also is that brush geometry or a imported triangle mesh? You will correct me if wrong but afaik the engine treats triangle mesh's, a tad differently from brush geometry, like it doesn't automatically inline the triangle mesh geometry, into the overall baked brush geometry (unless your force it), so it leaves a invisible "gap" there where the mesh connects with the brush wall? 

    Could be floating point accuracy problems, like you recently talked about?

  15. 3 hours ago, nbohr1more said:

    BFG has no Dmap source code... checking RBDoom3BFG.

    RBDoom3BFG uses the same as vanilla

    Ah yes all of that makes sense, I just forgot that BFG didn't came with dmap and people add to transfer the original tools to the new engine.

  16. Perhaps id didn't cared for that loss on accuracy, at lest for Doom 3, is hard for me to believe they did that for lack of knowledge or something but who knows.  Is this code still in BFG?

  17. 7 hours ago, OrbWeaver said:

    I'm surprised to hear anyone is using Hungarian notation these days. It's one of the most derided, disliked, obsolete and useless naming conventions in programming. I don't think I've ever seen a modern programming guide or tutorial which advocates it (except perhaps in very limited situations like using "mSomething" to indicate a member variable).

    First I need to say sorry for keeping this of topic subject going, I promise this is the last comment from me on this. 

    Now I also got surprised but Frictional Games still does, at lest in HPL1 and HPL2 engines they do, I assume they still do it on their latest engine as well, only them know why.

  18. Orbweaver said all what I thought, I also hardly always follow programing "rules", mostly because "basic naming conventions in programming" change with times and as the languages evolve and change. So imo no one should get to much hung up on those, specially when some rules aren't even evidence based but some famous coder thought it made the code "cleaner" and people just followed.

    For example Hungarian notation, so many coders use it but to me it can crash and burn. I played around with Penumbra HPL engine for a time and it is riddled with such notation and not once, I felt it helped me understand better the code, for the contrary.

  19. 11 hours ago, peter_spy said:

    I'd say "writeFloat" method that returns void is bigger cringe here.

    Why? Can you explain?

    Personally I see nothing wrong with that, looking at that function is obvious that they made it to not return anything, it just writes a float value to a file, and in C any function that doesn't return anything returns void.

    And those inner write functions may have error handling of some kind, so no need to return a bool for success or failure by the main function.

    The only potencial problem I see with it is they pass the file handle by pointer and there's no guard there for a eventual null pointer being passed to the function and it will crash if that happens but the fact this worked for years tells me they made sure that never happens.

  20. 2 hours ago, Fiver said:

    ...updating other creators' missions, even OMs, was frowned upon or appreciated.

    Doing that without permission from the author/s is frowned upon, saying this because if I'm remembering correctly, caused some stir in this community in the past, including a ban.

    And telling the truth, if I was a mission maker (that I'm not), I personally wouldn't want anyone to mess with my mission without my permission. 

    • Like 3
  21. 16 hours ago, Baal said:

    It actually is possible to override single declarations without touching the core files. I just got it to work with a footstep sound replacement. At least I think so, I am not a hundred percent sure yet.

    It is possible to override "core" files in TDM, without messing with the original files, from the beginning. This is a feature of the Doom 3 engine and obviously transitioned into TDM.  In Doom 3 and TDM, you just make a copy of a def, mtr or any other file inside your mod or mission folder, respect the same virtual file path from the originals and the modified files will take precedence over the files inside the .pk4's.

    This could be used by mission makers to for example override the "noshadows" from some alpha materials, for example to permit trees, grass, banners, etc, in their mission to cast shadow maps, something the core materials can't do because they are limited by the need to support the old stencil shadows.  But a brave mission maker, could recommend players to only use shadow maps on their mission and say, if a player wants stencil shadows they will have to accept that trees will cast ugly shadows.

    (I'm sure there's ways to automatically disable shadows for trees and such, when a user sets stencil shadows on, but it may take a bit of scripting madness...)  

×
×
  • Create New...