Jump to content
The Dark Mod Forums

peter_spy

Member
  • Posts

    3201
  • Joined

  • Last visited

  • Days Won

    109

Posts posted by peter_spy

  1. There is something in English/American manner of speaking that looks like tons of sugarcoating and beating around the bush, at least when you come from some other country. In other cultures, e.g. Polish or German, people are much more blunt. When they see shit, they call it shit, not "unfortunate bowel byproduct" :D There is such a thing as being too polite, and it's regarded as contrived or superficial. It can also be an easy way to disarm any criticism or discussion, regardless of their substance. I've seen it bumped to absurd levels on TTLG, where I saw responses like "you're not our friend, you can't criticize us", or "since you don't like it like we do, maybe Thief isn't a game for you". Fortunately TDM forums are nowhere near that level.

  2. 10 hours ago, duzenko said:

    @MirceaKitsune Sorry, are you messing with @peter_spy on purpose? I sure appreciate your calm tone, but you need to understand that what you're doing here is positive reinforcement of his negativity

    It's funny that so many cultures associate speaking calmly as automatically being superior in a discussion. You can speak in calm tone and be completely clueless, while you can shout in anger and still have a point.

    That said, I don't think it's about messing on purpose, it's just his MO. You've already seen it in multiple bugtracker entries too. He barges in, usually without checking wiki or forums on certain functionality, makes up his own ad-hoc interpretation of it, automatically assumes it is canon, and then it takes several people to explain him the "historical context", or that he mistakes bugs for features, etc. Then either he lets it go, or, if he is stubborn, he'll reply with walls of misinterpretation until the other party has no more energy for it.

  3. 13 minutes ago, MirceaKitsune said:

    Yes: A limitation in the hiding code was lifted, the bug was that it was ignoring light entities entirely, now it allows the functionality of hiding those too like literally all other entity types. You aren't even making sense any more... now you're nitpicking at words to find a reason why I must be stupid because I supported a change you don't like. How much longer do we have to keep doing this? Because I'm not interested in entertaining it whenever I try to have a discussion here. Again I ask that you please let us discuss the LOD system without trying to start drama each time this comes up in some form, before this thread is gonna need to be closed over it. Thank you.

    I am not making sense anymore? :D You seem to have a peculiar cognitive disorder, where you don't see difference between common knowledge and semantics, and what you make up about it in your hopes, dreams, and intuitions on any given topic. And then you mix it up and use in whatever convenient way you find at any given moment. Why do you think you should be the one who's constantly pushing for something, in a discipline where features or changes need to be meaningful and based on data, and not on feelings?

  4. 10 hours ago, Gin said:

    Generally speaking, the automap does reduce the need for landmarks for the players connect the world with the map. Over-reliance of an automap could result in levels that have very samey areas, but the automap isn't necessarily the fault here.

    I think it's kinda the other way around; if the level is samey, labyrinthine and it's too late to change it, auto-map can be added as an afterthought. Better level design is of course much better alternative. TPW is a great example that automap doesn't automatically make things better, since walking a few meters, checking the map, walking another few meters, checking the map, etc. isn't particularly interesting gameplay loop.

    • Like 1
  5. 7 minutes ago, Dragofer said:

    Looks like this is an issue that happens at map start on LOD objects that start hidden.

    Yup. If you place IdMoveables on a model with LOD that is hidden at map start, they will fall on the floor. If the model is visible and you move away beyond the hide distance, they stay where they are.

  6. 1 hour ago, Dragofer said:

    This was just some plain func_static wooden beams made out of patches, with a 'stuck' version of a broadhead arrow lodged in one of them. Only the beams had any kind of LOD, hide_distance, enabled.

    Stuck arrows probably shouldn't be moveables anyway.

    Have you tried making a beam with wood material, shooting a broadhead or rope arrow into it and then moving away beyond the hide distance? That seems like more practical example to me.

    Edit: to answer my own question, they appear and disappear along with the wood beam, nice! It seems like you found a corner case @Dragofer.

    buildercompound_2021-08-07_10_33_22.jpg.44934ae2a9c30204de64a8714271e7bb.jpgbuildercompound_2021-08-07_10_33_26.jpg.619257c213a38134ee7d9f3d52ceb49b.jpg

  7. Opting for mini-maps and accurate maps in general is either forgetting or not knowing the long-time tradition of Thief games having inaccurate maps, so players can make a mental map out what they explored themselves. In this context in game maps are just a template.

  8. 58 minutes ago, Dragofer said:

    Seems odd that a visual performance optimisation makes the entities become nonsolid.

    Yeah, and I think there is this quirk with hide 0/1 as well. If you set an entity to hide 1, it will go invisible on map start, but it will be solid. Set it to 0 and change it to 1 during gameplay, e.g. via trigger, the result will be nonsolid. Is it because of how .cm or .proc files are calculated?

  9. Smaller font looks good, on a 24" screen it could be even smaller, but if it's tweakable, that's great. I don't mind the current color (that saturation though...). If anything, it has to be versatile enough to work on both light and dark backgrounds, so white and black are off the table by default.

  10. 42 minutes ago, Dragofer said:

    My results are as follows, with "objects" being 2 packages, 1 crate, 1 tub, all set to noshadows at this distance. The light itself is shadowcasting, since as far as I'm aware there's no noshadows_lod for lights:

    [drawcalls, tris, shadowtris, VBO]
    1) objects + light
    	1346 	252195	28600	223559
    2) objects
    	1329	249083	28398	220649
    3) light
    	1321	248285	28600	219649
    4) -
    	1309	245915	28398	217481
    
    Fps: always 60 (didn't uncap)

    So the single light causes 12-17 drawcalls, while the group of 4 objects causes 20-25 drawcalls, depending on the extent of light interactions. A small difference in any case when it comes to LOD, but every bit counts, and this almost invisible light is ca. 1% of the drawcalls in that scene.

    Yup, the above makes sense. If you have an ambient + foglight + one regular light hitting those objects, they are already drawn 4 times. So hiding a light has the least impact, because you just remove one light pass + shadows (vs hiding objects, which removes all light passes and shadows).

    Perhaps one other thing to note is that the savings might look high, even with hiding just a light, because of the high material count and complexity stock TDM models can have (e.g. 5-8 materials per model). That much less of a gain with models typically optimized for games (using 1-2 materials max).

  11. 19 minutes ago, MirceaKitsune said:

    which is incomplete functionality

    Please stop pushing this nonsense, LOD system in TDM is and was a complete functionality already; it does what all other engines in the world do in that department. Your refusal / inability to understand the concept, and the context this system works in (proven by the wrong test maps you provided, despite several people giving you instructions), is your problem. Let others provide examples or test maps.

  12. 1 hour ago, Dragofer said:

    The cost of the light is probably very small, but probably no less than that of the crates and packages on that platform.

    That's a good practical example you can analyze. If it isn't too much to ask, you can try taking stats screnshots from the same spot and camera angle with:

    1) both light and objects visible

    2) light entity hidden and objects visible

    3) light visible and objects hidden

    4) all hidden

    The biggest stat difference will be between 1 and 4 obviously, but you should observe much bigger performance gain between 1 and 3, than from 1 and 2 or 3 and 4.

  13. 20 minutes ago, Dragofer said:

    With modern workflows, you probably mean an alternative implementation of the LOD system compared to what TDM has?

    Not really alternative, more like "historically established" and widely known :) If you take a look at various descriptions and definitions from other engines, all LOD systems are about the same thing: https://forums.thedarkmod.com/index.php?/topic/17283-hide_distance-broken-again/page/4/&tab=comments#comment-463315

    and TDM follows that. You can argue that it's a bit broken here and there, or it has some quirks (like with absolute distances from the model instead of relative ones, like everywhere else), but otherwise it's there :)

    And in your example, you could simply hide stuff these lanterns light, because, as proven in the last screenshot in this post, the cost of your lights will be minimal: https://forums.thedarkmod.com/index.php?/topic/17283-hide_distance-broken-again/page/4/&tab=comments#comment-463272

    20 minutes ago, Dragofer said:

    Yeah, hide_distance for lights has strict limitations because in most cases the switch is glaringly obvious, but it's still a tool in the toolbox that has situations where it's suitable.

    That's the thing, and I'm really curious to see this looking good and giving meaningful performance boost at the same time. Since other engines have been around for so many years, and none of them is doing that, I think it's pretty safe to assume that other developers already tried it and it wasn't worth it / looked awful.

    As I said, it would be great to see a meaningful example, but so far we've got a lot of talking and examples that had nothing to do with the subject matter, despite explaining the thing several times over. Let's hope Kingsal comes up with something nice :)

  14. 11 minutes ago, MirceaKitsune said:

    albeit I don't see a reason: The only thing it does is complete an existing feature and give mappers proper control over their map's functionality and performance.

    You don't see a reason because you lack experience and knowledge, you're so focused on "me me me, I want this, gimme!". I'm focused on the big picture, i.e. not being in a bubble, using the common knowledge and language, and working with what has already been established in gamedev, so the engine uses known workflows and isn't weird and insular for anyone coming here from outside.

    21 minutes ago, duzenko said:

    I did not know hiding AI makes them freeze? Sounds like a bug maybe?

    Not sure, but if you use hide 1 on an AI, it stops patrolling. It is there e.g. playing random barks, although it does not appear on the showtris view ;) 

    • Sad 1
  15. Lol, performance has nothing to do with feelings, it's about hard data :D And since you've been so stubborn in pushing your agenda, you should at least show that it was worth the effort and make an example scene where this looks good.

    Also, hide distance worked for AI for ages, but if you took more than a few seconds to examine how this works, it makes AI stop patrolling. If you use timing in your AI patrols to influence player pacing, and create interesting gameplay, this option is completely useless. It's only slightly above the feature that makes AI stop thinking when it's outside player view.

×
×
  • Create New...