Jump to content
The Dark Mod Forums

peter_spy

Member
  • Posts

    3015
  • Joined

  • Last visited

  • Days Won

    102

Everything posted by peter_spy

  1. No, noone cares about you solutioning developers on how a feature should be implemented, you giant confused dummy Since you're so good at extrapolation, how come it didn't occur to you that you can simply emulate the LOD system for lights with trigger brushes placed at certain distances, to toggle lights on and off?
  2. You don't see the difference between making assumptions and extrapolations in your head and doing actual experiments because you're not doing anything with these maps. Read the above posts until you get them, and make a map with actual lights toggled with distance, not with a switch and everything going dark, because this way you prove absolutely nothing. Also, to make it even more literal for you, why do you think noone in gamedev spent time on including lights in the LOD systems? Maybe they experimented with that, and found out there is no way to use it without it looking awful? And/or the performance gains were minimal? Do you think you're better or more experienced than people making Unreal, Unity etc.? Then feel free and supply us an actual proof, not a map that is 50% there, and 50% your feelings, preconceptions and extrapolations.
  3. Nope, that's still making stuff up. Show us a map with lights that can act as standard LOD system, as described above (without impacting visuals), and present us the hard data on performance improvements. Otherwise, you're derailing the conversation.
  4. I think it's ok to end this part of discussion, as it becomes noise. You're just making stuff up now; none of this has any confirmation in any systems used in game engines, past or present. As for overlapping shadowcasting lights, this is what causes performance issues, in any game engine, and it's on you to optimize the lights. And you still don't understand that your map demonstrates nothing. So, to reiterate: LOD system changes model geometry when it's away, in order to save performance, but while maintaining the visuals relatively unchanged. In order to demonstrate that lights with LOD system make sense, you'd have to make a map where they're toggled on and off, perhaps with scripts and triggers placed at certain distances, and in such an environment, e.g. with certain fog settings, where this would also maintain the visuals relatively unchanged. So far you have done none of that.
  5. ...And to give you some perspective on that: https://developer.valvesoftware.com/wiki/LOD https://docs.unrealengine.com/4.26/en-US/WorkingWithContent/Types/StaticMeshes/HowTo/LODs/ http://wiki.polycount.com/wiki/LOD https://docs.unity3d.com/Manual/LevelOfDetail.html And in general: https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html https://docs.unrealengine.com/4.26/en-US/TestingAndOptimization/PerformanceAndProfiling/Guidelines/ These guidelines^ can be applied to idtech4 as well. As you see, there are performance optimization tricks for lighting, but there's literally nothing there on using LOD for lights. By the way: Perhaps in the old days, but having a few thousand of LOD entities in a scene costs CPU next to nothing, while providing substantial savings for the GPU. It's more likely that you'll run into any other bottleneck much sooner.
  6. Perhaps restructuring/rewriting the wiki entry could help as well. It's not even filed under Connection Feature yet. Anyway, 2-3 sentences on what it does, then setup instructions, and then the technical bit for the curious.
  7. I'd rather be worried that with the number of responses being this low, people simply aren't using this feature. And yeah, I'd still blame complexity for that Or perhaps not being advertised enough?
  8. Again, you kind of did the same as in the previous example: you have multiple overlapping lights hitting tons of objects, and everything gets better when you turn them off. Perhaps you should give us a hint on what you understand an LOD system is, because I suspect it might vastly differ from what it usually means.
  9. That's just your interpretation, you said that ss2 was the origin of these games, while I'm just repeating what developers were saying about their inspirations in various documentaries.
  10. Main inspiration for the DS was actually Resident Evil 4 and Event Horizon. Even the creators called it "RE in space" in interviews and documentaries.
  11. FWIW, you can use the stop time cvar to see how the LOD system works even with lights being rendered. So you start here and stop time: As you go further, the number of objects and stats go down: And you finally end up beyond the hide distance range: So even if there are lights there, they don't do much to lower the performance. Lights are not expensive until they hit something expensive.
  12. Ok, so you turned off some overlapping and shadowcasting lights, which obviously got you some performance gains, but drastically changed the look of the environment. So, what's that got to do with an LOD system?
  13. https://youtu.be/hDZSD5XbiN8 That's still 2.08, by the way, and it was recorded @1440p. But yeah, that would confirm my suspicions, other engines don't do LODs for lights because there's no need to. Those ridiculously bad models could be replaced with optimized ones and with more geometrical variety, plus other effects needed to make an FM look complete. Open areas are already possible in this engine, it's a matter of level design and game art tricks
  14. Out of curiosity, did a small experiment with awfully unoptimised nature models in a huge room 4096x4096, and with proper hide distance, lod fade and fog values you can have many lights and still manage performance. This is a top down view: Again, these models are horribly unoptimised, but even with these dreadful stats the game was able to hold 60fps on the gtx 1060:
  15. The thing is, both Unity and Unreal offer both types of renderers (forward and deffered) and all types of lights now. You can use baked lightmaps and dynamic lights, both stationary and moveable, just like in idtech4. But LOD systems are still at geometry level. I get that this idea sounds great on paper. Technically, you could turn off all the shadowcasting lights and reduce your shadow tris to 0, and overall tris count by 1/4th, or 1/3rd even. But I'd hazard a guess that this is nearly impossible to do without the level looking awful. I'd be curious to see a practical example proving me wrong though.
  16. Hmm, I wonder what would that be, since e.g. both Unreal and Unity have LOD systems, and even some pretty fancy fade in/out editing tools (see: https://docs.unity3d.com/Manual/class-LODGroup.html), but none of them have anything like that specifically for lights.
  17. Hmm, I only managed to get this version to work, but it's not super useful, as it kind of extends to infinity, these should be clipped by the light radius: I think this could be done by using spot lights, not sure if that's what Duzenko meant. But that's a common gamedev trick too, using spotlights to avoid hitting too many surfaces by a shadowcasting light.
  18. That reminds me, is there any way to get the old shadows debugger back? It was much easier to read:
  19. In much more grim news, another depressing new low for Activision Blizzard. What a fantastic chapter in the company history. https://news.bloomberglaw.com/daily-labor-report/activision-blizzard-sued-by-california-over-frat-boy-culture
  20. Ambient light does that already too, as I demonstrated earlier. You have to account for the initial tris count to be at least tripled when you're placing a model in a map (ambient world + regular light, or + distance fog, so quadrupled even). If you're using lods/hide distance for models and func portals, and still can't get decent performance, you either need to up your level design game, or find better models (or both). Just hiding lights won't save you. It can be fun gameplay or aesthetic trick though, I guess it will be easier to use than scripts.
  21. That ambient light would already act like tris multiplier. See the comparison I made in the newbie thread again. Even in complete darkness, the tris are still drawn. That's why it's better to address this at model level.
  22. If a model is large and unoptimized, it will still be drawn, even if there's no light. So it's not that much of a performance, but aesthetics-related thing now, and that is subjective. I'd hazard a guess that changing lighting conditions like that will look more jarring than a switching between model visibility or lod stages in the same lighting.
  23. That's why you can have a noshadows lod, and also you can hide models being hit by these lights. As Duzenko wrote, lights are expensive only when they hit something expensive. In that regard your performance won't get magically improved just because you turn off the lights.
  24. That plus you can reduce distant shadowcasting by using as many "noshadows_lod_x 1" as you want. That should help quite substantially, since lights that cast no shadows are much cheaper in terms of performance. It's just that in this case you can achieve this by turning off shadows on the models, not in the light entity. Bear in mind that none of the optimisation tricks will help you much, if you have dozens of overlapping lights hitting tons of objects. That would be just using lights in incorrect way.
  25. IIRC a skybox is always rendered, that would also explain the increased number of subviews and higher texture memory use.
×
×
  • Create New...