[Hammer] Add rtx-support in hammer, like cs2 does have

[Unusuario2]

For?

Hammer

What can't you do?

i cannot use an amd/nvidia card to prereview lighting in hammer. It is much faster to use the gpu rather than the cpu in order to see true lighting

How would you like it to work?

Things to works: 1) Add gpu prereview in hammer

2) Add rtx-support for vrad3 (very useful for cutting up compile time) 3) Add a small option in the compile windows in order to set the compiler cpu or gpu

What have you tried?

nothing since is not possible to have this features without the src code

Additional context

No response

[Nolankicks]

Sadly facepunch has shot down the idea of gpu vrad. They are done working on hammer and are now working on scene lighting.

[LVJohnFreeman]

Wish FP reconsidered this, even if "wow its not 8 hours, but 4 now". Light solution switch from baked and switching from working with Hammer doesn't seem like will go away any time soon, unless it's forced and that would be horrible because of current state of the scene solutions atm and legacy support would be messed up again.

At most I just wish the light preview in Hammer could of been better RT preview, as it's currently very-very slow and that's your only way to properly preview it. Whilest in CS2 it's actually useful, at most only annoyance is no denoising, which is still better than nothing (right now). At that point I'd still wait through CPU compile, just need a better way of looking at the thing prior to that.

[wheatleymf]

The plan is to replace Hammer with mesh editing tools right on your scene, eventually. It makes more sense to stay focused on scene and all related rendering stuff than doing anything for a tool that'll removed someday.

Baking lighting right on scene would be actually neat, but that'd be a separate feature request, and not for Hammer.

[LVJohnFreeman]

The plan is to replace Hammer with mesh editing tools right on your scene, eventually. It makes more sense to stay focused on scene and all related rendering stuff than doing anything for a tool that'll removed someday.

But that's not happening any time soon it seems? So realistically to get something nice you have to use that, otherwise you have to force yourself to use a worse tool (as of right now), at that point why even make anything?

For instance, mesh editing in scene right now is ages behind Hammer, and Laylad is open to the fact specifically that it's on hold rn as other stuff is taking priority. Due to that I don't want to even touch scene solution, because not only is it still ways off, but it's not getting active development as of this message and zero idea when that's gonna happen.

Additionally on lighting, baking light would be nice you say, but as of right now Sam doesn't want to touch light map baking and has his own idea how a static light can potentially be done it seems and well generally cool GI too. While that's also all cool and great and although I'd love light mapping too personally, that's still not happening soon-ish?

So to get great lighting, still better off with Hammer rn as well? At the very least unless you want to do dynamic lighting or if your game can go by with just scene lights, due to your stylization. As a result you have a tool you are more prone to use and you shouldn't use it, because eventually you'll get a replacement.

As for from FP perspectine, I mean alright, but I don't think we've had a significant update to Scene meshes in 3 months (i think) though. So, probably would be good to provide something in the mean time, at least for better preview? As said, just using scene solutions as of rn is just not practical for quite a few games.

Might as well delete Hammer then right now, see what happens (nothing good)

[aylaylay]

I don't see much harm in adding this in if it's ever included in a new code drop but it's not something we'll be chasing valve up on either

[LVJohnFreeman]

I don't see much harm in adding this in if it's ever included in a new code drop but it's not something we'll be chasing valve up on either

Could we at most have a better RT preview (cs2 one is p great), if a next code drop just so happened to have it? Sort of a cop out, but would be my MVP to help me work. I fully understand not taking a priority on that, but it would help for the remainder of scene solution not being there yet fully (I'd gladly switch when it is though).

[Unusuario2]

I would like to have all of this features into hammer because (rtx-prereview and also gpu-vrad even is not hammer) it makes my life much much easier, right now i am fully working on s2 proyects, why? Because source 2 is very time efficient but s&box to be honest is not. Why? First, i dont want to spend 26 hours in a final 8k compile (i have a 7 5800 xd) or having to compile make a full compile since the rt prereview is kinda shit and not very exact. (The difference between cpu/gpu compile if you are making a full map like in hla is literaly days of difference 26 hours (cpu) -> 8 hours (gpu/cs2)).

There is a bunch of things in the scene system that cannot be archive like in hammer or standart source 2, for example if a want to make a map that has baked lighting since it is more realistic and more effitient (because it is a very heavy scene) i have to use hammer, wait +20 hours and then start working in the scene system, it is a nonsense to have compile times so heavy in 2024. (Of course it depends of what type of map you are making, in my case i am making very heavy maps (like hla maps))

About hammer removal why would facepunch remove such a great tool? It is very time efficient and there is NO alternative, scene system is "good for small tasks" but for mesh editing to be honest it is like working with source 1 hammer. Is not efficient for those things (mesh editing and the workflow), also the filosophy of the scene system is different (very dymanic/no baked lighting) which for a bunch of games is a headcache.

[LVJohnFreeman]

@Unusuario2

About hammer removal why would facepunch remove such a great tool?

To be the "devi's advocate here", the reason is to have the tool integrated with the rest of things naturally, have scalable modification ability, all be part of the same codebase (c# instead of Valve's c++) and then also at the end of the day make it be exactly like Hammer. The reason its not right now is the reason I'm not using Scene right now either, its ways off to get to that point, but also according to Laylad they are just copying Hammer stuff, so one day it should be way closer than now. Minus the fact you have tools as a level designer you might not need, which is another complaint of mine, but its more of a UI/UX problem.

[Unusuario2]

I fully understand the devs, but as a level designer (and in the future game producer in s&box) my focus is to use tools which are made with one thing in mind, efficency and not be "time consuming". I dont want to battle the tools or waste 30 secs in something that can be done with 3 secs in hammer, if there is an option of what i am doing of course. That is why i stopped using source 1, it is annoying. I want a workflow to be as efficient as possible which the scene system laks. (I understand the devs and what they are trying to do with the scene system, but right now is a very early system that is not powerfull enough, it is going to change with the time?, yes, but at the current moment and following years is it not a tool that can realisticly replace hammer without making users spend x2/x3 time.

[handsomematt]

It's an absolute mountain of work to add this when we have loads of better things to be doing instead of making bakes take 4 hours instead of 8 hours

We have the code from Valve, it involves weeks of backporting that will end in:

• Breaking all existing lights in maps and shaders
• Removing CPU light baking (So everyone without an RTC GPU starts to cry)

[LVJohnFreeman]

It's an absolute mountain of work to add this when we have loads of better things to be doing instead of making bakes take 4 hours instead of 8 hours

We have the code from Valve, it involves weeks of backporting that will end in:

• Breaking all existing lights in maps and shaders
• Removing CPU light baking (So everyone without an RTC GPU starts to cry)

I don't really like the 4 hours instead of 8 hours quote at this point, because not only does it scale and when it scales it's a significant difference for the quality you get by using a regular PC, but also 8 hours is almost a full day, whilest 4 hours is "I just go out for a lunch or for a walk, go jugging etc", thats a significant difference in practice when I've compiled my maps for both Alyx and CS2, especially if you cordon it! Feel a bit silly to say as if it's nothing, especially for the quality you get with it and performance out of the box, like I understand it can be instant eventually with Sam's solution (that won't be lightmaps anyways, but that's another point), but I don't know if that's gonna be any time soon?

However, I do understand not wanting to break CPU compiling and existing maps though so I understand still not wanting to do it, I just wish a cop out with better preview in Hammer would happen. So if it's still 26 hours instead of 15 at the end of the day (that's still a massive improvement if you don't have a compile farm!!) at least it would be a better experience previewing the lighting, even if its not 1:1. At the very least it would be closer than old-old vrad2 preview and is useful at the end of the day as even vrad2 doesn't work right now with light bounces in Hammer right now... So your only option is RT preview, which is ass and hides most of the visuals so you have to estimate.

Especially right now, while waiting for scene solution and new lighting, which will take more than few weeks at current pace (which is completely fine, but still need something right now and Hamer when works, does the trick).

[MrBrax]

honestly, some kind of hammer map -> scenemesh -> bake in scene workflow doesn't sound all that bad if baking was possible in the editor

[Unusuario2]

It's an absolute mountain of work to add this when we have loads of better things to be doing instead of making bakes take 4 hours instead of 8 hours We have the code from Valve, it involves weeks of backporting that will end in: Breaking all existing lights in maps and shaders Removing CPU light baking (So everyone without an RTC GPU starts to cry)

I understand that is not a priority right now, but if i you are making a big map (type hla for example) that is going to make a very huge difference, in my experience it cuts a lot of time 26 hours -> 8 hours. Of course a lot of people doesnt make maps so big and detail, it is not common.

About "Breaking all existing lights in maps and shaders" i have no idea not be honest, but all the new shaders found in cs2 arent suppouse to be only a thing that rtx-vrad3 uses for baking lightmaps? Also rtx-vrad3 has support for the standart lights (light_onmi, light_ortho, light_spot), it wouldnt break the current maps no? Here is what I am saying (you can enable the old lights in cs2 by removing the @exclude), see the video:

https://github.com/user-attachments/assets/713836ae-98f0-4c60-a0af-202fa6f5f263

About the "Removing CPU light baking" why? cs2 supports both See the video:

https://github.com/user-attachments/assets/6cd0ca4e-6695-4b58-93ff-6315fb416d0e

[LVJohnFreeman]

26 hours -> 8 hours compile time change example from Unusuario2 is a perfect example why I don't like the 8 -> 4 hours compile time quote. It's a massive difference in practice, always rubbed me the wrong way hearing it. Cause in practice its just not true, especially final product or early on when you need something fast, both scale well. And the quality is clearly there.

[LVJohnFreeman]

About "Breaking all existing lights in maps and shaders" i have no idea not be honest, but all the new shaders found in cs2 arent suppouse to be only a thing that rtx-vrad3 uses for baking lightmaps? Also rtx-vrad3 has support for the standart lights (light_onmi, light_ortho, light_spot), it wouldnt break the current maps no? Here is what I am saying (you can enable the old lights in cs2 by removing the @exclude), see the video:

I think the values you have per light are not exact same, and some entities were deprecated/replaced/updated as far as know, so out of the box it might be broken without recompile. I think it could be worth it in current state, because not many maps have final-final proper compile, although people without that RT gpu would not be happy 100%. As for if CPU compile works, again if I recall correctly the difference between it and gpu compile is you won't be able to do emissive textures and that's mostly it? Need to have a better example with proper lit env to check.

[LVJohnFreeman]

honestly, some kind of hammer map -> scenemesh -> bake in scene workflow doesn't sound all that bad if baking was possible in the editor

You can do that right now, but I feel like we are better of getting the scene solution with everything in it long term and in short term just have a solution that doesn't require you to jump this much, this is what sucks about other engines with making your levels in third party 3d kits during art pass mostly, like in UE with it's modular kits approach and dog shit default mesh editing. Just feels like it would be a better balance, personally.

[Unusuario2]

About "Breaking all existing lights in maps and shaders" i have no idea not be honest, but all the new shaders found in cs2 arent suppouse to be only a thing that rtx-vrad3 uses for baking lightmaps? Also rtx-vrad3 has support for the standart lights (light_onmi, light_ortho, light_spot), it wouldnt break the current maps no? Here is what I am saying (you can enable the old lights in cs2 by removing the @exclude), see the video:

I think the values you have per light are not exact same, and some entities were deprecated/replaced/updated as far as know, so out of the box it might be broken without recompile. I think it could be worth it in current state, because not many maps have final-final proper compile, although people with that RT gpu would not be happy 100%. As for if CPU compile works, again if I recall correctly the difference between it and gpu compile is you won't be able to do emissive textures and that's mostly it? Need to have a better example with proper lit env to check.

The difference between cpu and gpu compile is the emmisive shader, cpu cannot support that shaders and also some other features of the next-gen lights, but i dont care. I dont need the next gen light or a emmisive shader i just want to cut compile time to be honest that would be great. Also no one in s&box has mentioned the use of this type of lights (next-gen) so it doesnt matter

[LVJohnFreeman]

That I understand but I'm not 100% sure its forward compatible out of the box, no way to test it either (cant really port forward hla compiled map to cs2 that easy). So people would have to recompile, and some might not be able to do it with a better compile, some might have to adjust their lighting and/or will have to do CPU compile, and if they did a final compile and there's stuff to fix, that means they'll have to do several big compiles. Which people will definitely be not happy about, some might not even do it. I think that's what Matt was alluding to? Which I peronally get.

[MrBrax]

honestly, some kind of hammer map -> scenemesh -> bake in scene workflow doesn't sound all that bad if baking was possible in the editor

You can do that right now, but I feel like we are better of getting the scene solution with everything in it long term and in short term just have a solution that doesn't require you to jump this much, this is what sucks about other engines with making your levels in third party 3d kits during art pass mostly, like in UE with it's modular kits approach and dog shit default mesh editing. Just feels like it would be a better balance, personally.

you can't bake lighting on (any) mesh in the editor right now, i was thinking about doing it separately from hammer

[Unusuario2]

That I understand but I'm not 100% sure its forward compatible out of the box, no way to test it either (cant really port forward hla compiled map to cs2 that easy). So people would have to recompile, and some might not be able to do it with a better compile, some might have to adjust their lighting and/or will have to do CPU compile, and if they did a final compile and there's stuff to fix, that means they'll have to do several big compiles. Which people will definitely be not happy about, some might not even do it. I think that's what Matt was alluding to? Which I peronally get.

I understand but my point is that rtx-vrad3 only is for baked lighting and it doesnt affect it self other parts of the engine so badly, i believe. It doesn't matter how the lighting is bake cpu or gpu.

[Unusuario2]

I hope that the facepunch devs consider this features

[LVJohnFreeman]

honestly, some kind of hammer map -> scenemesh -> bake in scene workflow doesn't sound all that bad if baking was possible in the editor

You can do that right now, but I feel like we are better of getting the scene solution with everything in it long term and in short term just have a solution that doesn't require you to jump this much, this is what sucks about other engines with making your levels in third party 3d kits during art pass mostly, like in UE with it's modular kits approach and dog shit default mesh editing. Just feels like it would be a better balance, personally.

you can't bake lighting on (any) mesh in the editor right now, i was thinking about doing it separately from hammer

Well I mean you can do it, its just kinda ass to do it rn personally. Wish Hammer preview as just better and would fix my issues personally.

[MrBrax]

honestly, some kind of hammer map -> scenemesh -> bake in scene workflow doesn't sound all that bad if baking was possible in the editor

You can do that right now, but I feel like we are better of getting the scene solution with everything in it long term and in short term just have a solution that doesn't require you to jump this much, this is what sucks about other engines with making your levels in third party 3d kits during art pass mostly, like in UE with it's modular kits approach and dog shit default mesh editing. Just feels like it would be a better balance, personally.

you can't bake lighting on (any) mesh in the editor right now, i was thinking about doing it separately from hammer

Well I mean you can do it, its just kinda ass to do it rn personally. Wish Hammer preview as just better and would fix my issues personally.

you can do it externally in something like blender yes, but as far as i know there's no way to do it in the editor?

[LVJohnFreeman]

That I understand but I'm not 100% sure its forward compatible out of the box, no way to test it either (cant really port forward hla compiled map to cs2 that easy). So people would have to recompile, and some might not be able to do it with a better compile, some might have to adjust their lighting and/or will have to do CPU compile, and if they did a final compile and there's stuff to fix, that means they'll have to do several big compiles. Which people will definitely be not happy about, some might not even do it. I think that's what Matt was alluding to? Which I peronally get.

I understand but my point is that rtx-vrad3 only is for baked lighting and it doesnt affect it self other parts of the engine so badly, i believe. It doesn't matter how the lighting is bake cpu or gpu.

We had a person actually talk about this on s&box server, apparently it does indexed lights differently. So you WOULD break stuff, and according to Matt it would take weeks to implement to begin with. Generally by reading the room it seems to be just full stop not worth it at this point, unfortunately.

You will have to wait for scene solution at this point.