peter_spy
-
Posts
3201 -
Joined
-
Last visited
-
Days Won
109
Posts posted by peter_spy
-
-
Stuff like load map file preference is something you probably set once and forget about it. Wouldn't it be more convenient to have most of such options in a Preferences section instead of a widget? This way you could have just a minimal set of buttons/icons over the perspective window.
-
@HMart you should be able to have detail textures with certain material keywords. You can do this by e.g. stacking normalmaps with addnormals, or by using gl blend modes. I'm using something a la detail noise texture in Rage, since one of the gl blend modes seems to work like Overlay mode in photoshop:
Edit: sorry, you can't really make detail normalmaps with addnormals, since this is image programs territory and there is no option to tile the second normalmap there. It's quite confusing, because there's a scale keyword for image stage, which is responsible for tiling, and there's a scale image program function, which acts as a multiplier for image RGBA values. Two completely different things.
-
By the way, I guess you'll see that in the code, but the way the lod_fadeout_range works right now makes it unusable with anything but LOD 0 models. Maybe it's because it uses hide_distance as a starting point instead of fading out to hide_distance?
In any case, you can have a model with e.g. LOD 0 that is 3k tris and cast shadows, then LOD 1 that is 1k tris and noshadows, and when you reach the hide_distance, the model switches to LOD 0 again.
Not only can this look bad, with shadows suddenly popping in before the model fades out, but I guess it can also generate unnecessary performance spikes, going from properly optimized models to full quality in the last stage.
-
11 minutes ago, kingsal said:
What about texture resolutions? Would rendering less pixels at distance do anything for us?
Note that mipmapping still applies here, although that still means keeping the base (highest resolution) texture in memory. Otherwise you can set different materials for different LOD levels, so they could use lower resolution textures, but IIUC, TDM would need to have texture streaming to use that effectively.
-
I'm only mean because my god you're annoying
To be fair, I much rather see such proof of concept from @kingsal who also showed interest in this feature; he's in touch with modern gamedev, and he knows the proper level design tips and tricks. Plus he already has experience with making such lights in his maps, so this way we'd be sure we're on the same page and his example is relevant.
-
5 minutes ago, MirceaKitsune said:
Again: You're asking me to implement this feature myself in order to show that it should be implemented. That's like saying "build a car to prove that someone should go through the effort of building a car". Really?
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?
-
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.
-
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.
-
41 minutes ago, MirceaKitsune said:
I think we're talking about two different kinds of LOD overall: One is using a lower polygon version of a model after a certain distance, which obviously applies only to meshes... the other is hiding and derendering an item after a certain distance, which can be applied to anything and I'm not sure to what extent LOD is even the best term to describe it. From a technical standpoint I can see why it's included in the same category, theoretically though it's hiding something entirely not changing the detail level.
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.
-
...And to give you some perspective on that:
https://developer.valvesoftware.com/wiki/LOD
QuoteLevel of Detail (LOD) is the principle of having lower-detail versions of models in memory and switching to them when the object is small/distant. This saves a lot of unneeded processing power at the cost of a not too big memory/disk size increase.
https://docs.unrealengine.com/4.26/en-US/WorkingWithContent/Types/StaticMeshes/HowTo/LODs/
QuoteWhen a player is up close to a Static Mesh you have placed in your level, you want the mesh to look very detailed. However, you do not need that mesh to be very detailed and complex once the player moves far away from the mesh. There is no point in having a very complex and detailed mesh if it is only taking up a few pixels on the screen and the player can barely see it. However, the mesh needs to be detailed when the player is up close to the mesh and can see it clearly. In UE4, you can place a mesh in your level that switches to a less complex mesh as the player moves away from it in order to make your level perform better. You can do this through the use of Level of Details, or LODs. This How-to will show you how you can import a less detailed version of a mesh into UE4 and have your mesh seamlessly swap from one mesh to the other as the player moves closer or farther away.
http://wiki.polycount.com/wiki/LOD
QuoteA Level of Detail model (LOD) is a lower-resolution version of a game model. The lower-res version is used to improve performance by being swapped in whenever the higher-resolution of the game model is not apparent anymore, for example when it is a certain distance from the player. Usually LODs have a lower vertex count (50% or so) and simpler shader (diffuse only, for example).
https://docs.unity3d.com/Manual/LevelOfDetail.html
QuoteLevel of detail (LOD) is a technique reduces the number of GPU operations that Unity requires to render distant meshes.
When a GameObject in the Scene is far away from the Camera, you see less detail compared to when the GameObject is close to the Camera. However, by default, Unity uses the same number of triangles to render it at both distances. This can result in wasted GPU operations, which can impact performance in your Scene.
The LOD technique allows Unity to reduce the number of triangles it renders for a GameObject based on its distance from the Camera. To use it, a GameObject must have a number of meshes with decreasing levels of detail in its geometry. These meshes are called LOD levels. The farther a GameObject is from the Camera, the lower-detail LOD level Unity renders. This technique reduces the load on the hardware for these distant GameObjects, and can therefore improve rendering performance.
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:
12 hours ago, MirceaKitsune said:remember that using the dist_check_period call can have its own impact too
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.
-
1
-
-
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.
-
1
-
-
3 hours ago, stgatilov said:
As of now, I see only 3 responses.
And every feature (except for "pause game") has its users.If it continues the same way, then I'll ditch @peter_spy's idea of "less buttons", and put all implemented features into the GUI, like it was in my original suggestion (except LEDs replaced with something like radio buttons).
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?
-
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.
-
5 hours ago, JackFarmer said:
From RE4 it only has the shoulder perspective and the direct attack without weapons. The rest is copied from SS2 and Bioshock (stasis, telekinesis, etc. - not to mention some story elements that had been adopted from SS2).
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.
-
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.
-
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.
-
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?
-
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
-
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:
-
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.
-
18 minutes ago, kingsal said:
Basically we'd have an industry standard system.
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.
-
9 minutes ago, kingsal said:
Yeah so I had to turn off a couple things to get it to work, new front end renderer and obviously use stencil lights. You might also have disable uncapped FPS.
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:
9 minutes ago, kingsal said:No unfortunately you cant clip light volumes in that way.
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.
-
15 hours ago, kingsal said:
Edit: Keep in mind in the top image, the light debugger is showing where the light is bleeding through so thats why you see the back wall illuminated.
That reminds me, is there any way to get the old shadows debugger back? It was much easier to read:
-
In much more grim news, another depressing new low for Activision Blizzard. What a fantastic chapter in the company history.
-
1
-
hide_distance broken again?
in TDM Tech Support
Posted
That plan is good; if possible, I'd probably move the lighting phase onto the first place. If you focus on placing shadow casters so they don't overlap, and using noshadows lights as often as possible, you should have fewer performance problems down the line while adding more objects and geometry (you should be less restricted in doing so).
That said, it's worth noting is that with stock TDM objects achieving good performance is an uphill battle, as they're not optimized like they typically are in games.