[CS:GO] - Lighting and compiling questions

[biXen]

Hi,

Soon time to enter my map into the competition and for playtesting (obviously won't be detailed and proper finished for deadline, but still). I have a couple of questions.

1) Is there any way to get coloured shadows from coloured glass? In the Valve docs I see that projections are disabled because you can only have one in a level, but is there an easy way to fake it with baking or something? 

2) When making a 3D skybox, my thinking is that if I build the 3d skybox around the map, select it and export it to a new map file. Work on it there, and then I can import it back into my level and make it smaller and that will be an easy workflow for updating it later too. Have I missed something or is there an easier way? (do you guys actually work on it in 1/16 scale or do you always scale it down?)

3) When I start my map for the first time it generates a lot of extra data, paths for bots etc. , is that something that is then packaged into the same file I distribute? Or is there some process I am not doing that I should do? This also goes for "buildcubemaps".

I might have more questions, but that was what I had right now.

[jackophant]

1) Could you use coloured light_spots to crudely mimic the colour of the light coming through? It's a bit hacky, but it could work?

2) Historically I've always built around the map and shrunk after finishing like you suggest. My skyboxes are often quite simple so I've not bothered moving them into a new file, but dont forget there are the "_skybox" props which are super tiny as well you can use.

3) When starting a map for the first time, the game looks for an associated nav file and if none is found it would proceed to generate one, but only if bots are present. If you run the command "bot_kick" before you choose your team, the bots will never connect and you won't need to build the nav mesh. The file is stored in the same directory as the bsp, and the workshop uploader will automatically package it for you when submitting to the workshop if it exists.

Cubemaps are automatically saved into the bsp when "buildcubemaps" is run. Make sure you upload the right version of the bsp with the cubemaps inside when uploading to workshop! (and turn mat_specular 0 on when generating and preferably keep cubemaps for players at a height of 64 units to best reflect head height reflections, if you don't know already)

[Evert]

Regarding the skybox question:

I've always found 3d-skyboxes to be cumbersome to iterate on, but now with the instances support in CS:GO I've noticed a pretty decent work flow.

It requires a few steps to set up BUT once it's been done it should be smooth sailing.
1. Place a dummy entity in the origin of the world. Select that and fly around and select the most important geometry from your level, like the extents of the playable area, or where the framing of the 3dskybox is the most important or whatever.
2. Paste that stuff into a new 3dskybox instance and place the sky camera on that dummy entity.
3. Scale it all and align it as closely to the grid as possible (the ref geometry will not be compiled so it doesn't necessary have to be on grid, but I usually make sure that the ref dummy is in the origin here)
4. Put the reference geometry in it's own vis-group so that you can easily disable the it before compiling.
5. Place the skybox func_instance anywhere in your level.

I've found this to be as close to building around the level, but without having to constantly select and re-scale stuff when aligning stuff.

[laminutederire]

Isn't a paste special even more effective to align things?

[Evert]

Yeah true, does that work as intended when scaling though?

Since the scaling is based on the bounding volume of the selection IIRC?
Never tried it

[laminutederire]

Yeah true, does that work as intended when scaling though?

Since the scaling is based on the bounding volume of the selection IIRC?
Never tried it

neither did I, that's why I formulated it as a question  with ctrl+m  it may work!

Edited August 21, 2015 by laminutederire

[biXen]

Regarding the skybox question:

I've always found 3d-skyboxes to be cumbersome to iterate on, but now with the instances support in CS:GO I've noticed a pretty decent work flow.

It requires a few steps to set up BUT once it's been done it should be smooth sailing.
1. Place a dummy entity in the origin of the world. Select that and fly around and select the most important geometry from your level, like the extents of the playable area, or where the framing of the 3dskybox is the most important or whatever.
2. Paste that stuff into a new 3dskybox instance and place the sky camera on that dummy entity.
3. Scale it all and align it as closely to the grid as possible (the ref geometry will not be compiled so it doesn't necessary have to be on grid, but I usually make sure that the ref dummy is in the origin here)
4. Put the reference geometry in it's own vis-group so that you can easily disable the it before compiling.
5. Place the skybox func_instance anywhere in your level.

I've found this to be as close to building around the level, but without having to constantly select and re-scale stuff when aligning stuff.

I am not familiar with the instances, but this is essentially making the skybox in another file, and the func_instance is referencing the content of that file's compiled result? Or how does it work exactly?

1) Could you use coloured light_spots to crudely mimic the colour of the light coming through? It's a bit hacky, but it could work?

2) Historically I've always built around the map and shrunk after finishing like you suggest. My skyboxes are often quite simple so I've not bothered moving them into a new file, but dont forget there are the "_skybox" props which are super tiny as well you can use.

3) When starting a map for the first time, the game looks for an associated nav file and if none is found it would proceed to generate one, but only if bots are present. If you run the command "bot_kick" before you choose your team, the bots will never connect and you won't need to build the nav mesh. The file is stored in the same directory as the bsp, and the workshop uploader will automatically package it for you when submitting to the workshop if it exists.

Cubemaps are automatically saved into the bsp when "buildcubemaps" is run. Make sure you upload the right version of the bsp with the cubemaps inside when uploading to workshop! (and turn mat_specular 0 on when generating and preferably keep cubemaps for players at a height of 64 units to best reflect head height reflections, if you don't know already)

Thanks, useful info.

1) I thought about doing something like that, it might work, but I it doesn't work exactly like I want to I Think. I was actually even thinking about recreating the scene, lighting and baking in a 3d program and making a decal of the result. But it's a bit over the top

[jackophant]

Maybe ask @Squad how the light-through-water effect was achieved in the mid/B connector?

Also, I've jsut realised you are saying coloured shadows from coloured glass... Do you just mean coloured light that has been filtered by the glass, or the ambient light colour for shadows as well?

[Evert]

@biXen https://developer.valvesoftware.com/wiki/Func_instance

It's pretty much a vmf inside a vmf so yeah it's exactly what you're describing. They can be handy for organizing levels, but can also make stuff a become a hierarchic mess I just found them very handy for seperating the skybox from the level, it's a matter of preference I guess.

[jackophant]

If you have areas of high repetition, you can use them to keep file size down, as the different instances will be referring to the same vmf, although this may not make a difference post-compilation.

It really has it's benefits in off grid work as it can be on grid in it's separate file, and then freely rotate it in the main file.

[biXen]

Maybe ask @Squad how the light-through-water effect was achieved in the mid/B connector?

Also, I've jsut realised you are saying coloured shadows from coloured glass... Do you just mean coloured light that has been filtered by the glass, or the ambient light colour for shadows as well?

I have to check out his map to see what you are referring to. 
No you were correct the first time, just bad wording from me, I meant coloured light casted onto the floor. In regards to your suggestion about the spots, it might actually work if I could make an invisible frame that would block and allow light through in a certain pattern while itself being invisible to the player and not block or cast shadows. Might have to experiment more, surely not the most important part of my work now, but would be a key identifiable area.

 

@biXen https://developer.valvesoftware.com/wiki/Func_instance

It's pretty much a vmf inside a vmf so yeah it's exactly what you're describing. They can be handy for organizing levels, but can also make stuff a become a hierarchic mess I just found them very handy for seperating the skybox from the level, it's a matter of preference I guess.

Thanks, didn't actually know this, might come in handy like jack describes too. Any downsides to it? Except hierarchy mess if you overdo it.

 

[biXen]

I noticed this in the wiki for the func instance:

Replace <string $variable> <string value>
This is a replacement parameter. Any usage of $variable inside the instance will be replaced with value.
Example: $color 255 0 0

Does that mean you can use variables to only define light color once for all lights in an area in Hammer? Or is this for something different?