kingsal

Yeah this is tricky, frivolous shadow rays *used* to be a big issue, but with all the renderer and GPU updates maybe not? I wonder if transparents, alpha tests, and FXs are bigger culprits now. Having a light touching a glass window with fog and trees behind it might be a worse case scenario. Would switching to a "less expensive" lighting model at a distance be beneficial or even feasible? Are there less accurate, but cheaper lighting methods outside of just shadow/ no shadow? What about texture resolutions? Would rendering less pixels at distance do anything for us? Sorry just kind of troubleshooting here. @MirceaKitsune @duzenko I think the proper approach here would be to open up a heavy map like TPW or the opening shot in your FM Mircea, and look into the impact lights, emitters, transparents, ect are having on it. I'm sure turning off lights will have an impact, but doing it in an elegant manner might not feasible. I'll look into this a bit more this weekend and see if I can really prove that dropping lights out can A: give back enough performance in enough situations to warrant the change and B: actually be done in such a way that isn't glaring to the player.

Got it. Regardless we should be able to get light models to hide if not the lights themselves.

Yeah its possible that lights are harder to do, but maybe more feasible in a dynamic-only light engine like doom 3.

Also we should probably discuss light clipping and lighting techniques in a different thread as that's own can of worms. @duzenkoSo for the hide_distance stuff it looks like these things would be helpful to add to the list: Func_rotating and other movers? SEED (more so investigate why they aren't working properly) Lights, specifically entities that spawn lights and FX. If we can get a gentle fade out / in on all those things that would be incredible. Basically we'd have an industry standard system. I can see lots of cases where gradually dropping out lights and objects at distance will significantly help performance on larger maps or outdoor areas. Also being able to fade out FX when you get close to them is valuable for stuff like fog. This helps prevent "washing out" the screen when you get close to an emitter.

Yeah you might be able to use a spot light, but that wont work for most of our custom light entities which use volume lights. There are definitely ways around this problem. My point it is they are fiddly and time consuming and in some cases require specific engine knowledge. It might be easier for a mapper to just hide that light at a distance or yeah draw some kind of clipping volume.

@peter_spy 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. @duzenkoNo unfortunately you cant clip light volumes in that way. You can move the volume to fit the space so it doesnt go outside the wall and then adjust the center. However, thats pretty time consuming and it wont work for lights that spawn and attach things to their entity origin, torch flames for intance. A lot of authors use the custom light objects that automatically def_attach lights and FX, so those rely on the center and origin being the same. it would be pretty useful if we had a kind of brush that just acted as a light clip volume that stopped the shadow rays. It would give us more explicit control for sure.

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.

Okay so Ive updated the test map to reflect this. Maybe this isn't an issue with shadow mapping, but I dont know. Dmap and then load it up lodfade.map So this is the common scenario. A light inside a closed portal is still bleeding through the walls and shadowing the boxes on the outside of the building. Obviously if I add a door we won't have this problem, but this isn't always feasible. In complex spaces this happens a lot. Now if I could just hide that light at a certain distance I can eliminate that problem. There might be other ways to fix this problem, but once again in complex spaces (which are most city missions) this happens more than you would think. Its not a systemic solution, but it could give mappers more control.

Awesome for mappers, as it will give us another avenue for controlling light count and performance. Ill agree that its an edge case, but if we are supporting lights with models hiding or fading out a distance, street lamps for instance, wouldn't we need code to turn lights off anyhow?

Being able to hide lights at a distance would be helpful actually. Better yet being able to fade them out gently would be awesome. There are cases where lights bleed through walls and being able to just turn them off with a distance check would be a very quick and easy way to prevent that. Controlling that with scripts is a mess, imo.

The particle on the right alpha blends I believe.

@HMartFade in/ out is possible in TDM, see the test map below. The glow and grass textured planes will fade in and out. @duzenko @stgatilov Pasting from discord: Here is the test map I put together based on an old one Peter_spy had: lodfade_example.pk4 Couple bugs I noticed right off the bat: Light entities will not hide Strangely the SEED entity hides different func_static children at different distance even though they are set the same Any hide or LOD setting on SEEDs don't seem to propagate to their children. Didnt thoroughly test this though Fade only works with those specific materials in the material folder. Lod_fadeout_range controls the fade distance. This is absolute from the origin of the object and needs to be higher than the hide_distance. So its starts fading at the hide distance. Im not sure why its called lod_fadeout_range, maybe it fades after the last LOD stage? Im not sure but we'll need to investigate this. I assume if no LOD is set it just starts from the hide_distance.

@peter_spyReally? Thats great. Do you have an example of that material set up? I swore I read somewhere that doom can't do alpha blends, maybe that get patched into TDM at some point.. I dunno. @nbohr1more @duzenko I can throw in some lights and other func statics in the test map so we can test stuff like that.

@nbohr1more @duzenkoI could probably cook up a simple test map this weekend. I imagine we want func_emitters, SEEDs, and maybe a couple various func statics. Side note: We do not have fade in/out capabilities currently. Fade in and out doesn't currently work on LODs. Having that would prevent a lot of that annoying popping in and out on hide. Is it possible to add this to the list of things to explore?

I can confirm the mirrors arent working for me either. Using Chrome.

Sort of related, but I wish we had a simple stair tool to work with. Building stairs is incredible tedious even without carpet! Im not sure how it would work, potentially drawing a brush in DR and hitting "convert to stairs" and you punch in the height and direction? Maybe a "build with patches" feature as well? Ignore the brushes that descend all the way to the floor. (Unless its possible to have it do that as well) With a stair "thickness" setting could get designs like this: height = 12 thickness = 4 Bonus feature if you could pick a nodraw surface that auto built around it Anyhow, something to consider if anyone is up for it. Would save some time on the mapping end of things for sure.

@greebo Hey awesome! I'll be using this version and doing some testing. The pointfile feature is great. Found a weird bug where non-symmetrical light scaling is borked for me. 5644

I just looked, loading screens are held in guis/map/cauldron_v2.gui (map name) Those need to stay as overridable by authors.

So I released this mission right around when I started tinkering with .GUI files, so its probably a mess. Yes, this and I think volta 1 both have a custom objective screens + guis. These can go for now. I think we can keep the dds file overrides as those shouldnt interfere. Down the road, I'd like to revisit the objective pages for the core, we can fit more objectives on that page and clean it up a bit. As long as the custom MM_backgrounds, the briefings, MM audio, and custom loading screen stay. I am happy. Many missions use custom loading screens GUIs so those we need to keep. I might have forgotten that in my list of requests, sorry.

Yeah exactly, It also depends on the program used to generate the normals. A lot of "auto generating" programs have heavy default settings and do weird things. I do think these HD version look good and I wonder really how much trouble it would cause replacing the old ones. The risky thing here is like you said, these are used in tons and tons of missions so the potential for trouble is high.

I don’t necessary prefer a low res look, but a clean, less noisy look. Many of the dark mods normal maps were made incorrectly and add a lot of high frequency detail and noise. It would actually be beneficial to have more visually different carpet textures rather than HD versions of the current ones. I would suggest releasing these as a “texture pack” to the community to use rather than increasing the mod size and creating the _HD convention.

Right on. Well we're headed down this route for the time being. Unless a better or more practical solution comes along.

No, we're trying to explore solutions to an issue that's have been raised among the community (not being able to tell loot apart from other objects). Its a pretty reasonable choice to try doing this with a the frob system, since we already planned on revamping it. If you're argument is that we should *teach* mappers to make better considerations with object placement, why don't you make a separate thread in the Editors Guild and you can discuss there. Definitely. "Missing the highlight" is something we'd like to avoid all together. Yeah I think this is a good analogy. It still forces to the player to explore the level and objects in it (which is the interesting part of any mission IMO), but isn't telegraphing "go here pick up THIS loot". Distant shimmers are definitely not something we'd do

I think there are more interesting ways for the player to interact with the environment than going up to everything and fiddling with it to see if its loot. One of the wonderful things about the old Thief games is pickups, loot or otherwise, really stood out because the environments where so simple. That's just not the case with TDM and modern games, unfortunately. However, I do agree the loot models could be freshened up for sure, but that's a good chunk of work and as Orbweaver mentioned, probably not the best solution given the circumstances.

This is probably a little too subtle but a slightly yellowish glow would look nice for loot objects IMO.