Un overwriteable black cubemaps and staticproplighting problem.

  • If you're asking a question make sure to set the thread type to be a question!

Jusa

aa
May 28, 2013
377
618
I am having a hard time trying to get static prop lighting working and cubemaps built.

So basicly, the bsp file is included with default cubemap textures after the compile. These textures are completely black, which causes the map to not have reflections at all.

If i want to rebuild cubemaps into the bsp i have to first detele these black textures using pakrat.

Deleting these textures completely removes static prop lighting.


So, what can i do to have actual working cubemaps AND static prop lighting in the map?


Also found someone else having this problem
 

Jusa

aa
May 28, 2013
377
618
68747470733a2f2f662e636c6f75642e6769746875622e636f6d2f6173736574732f353035363937382f3833313239302f30633938376130612d663163392d313165322d383836642d6662353962616365313836352e706e67
 

Jusa

aa
May 28, 2013
377
618
iGHeb0I.png


Heres a screenshot of VIDE. All of the cubemap textures are the exact same black.

If i remove them manually, static prop lighting disapears.
 

Jusa

aa
May 28, 2013
377
618
I think i managed to get them working now:

First I copied the file so i have a copy of the orginal bsp. I then removed the cubemap textures from the copied bsp and build propper cubemaps on it. Then i took the cubemap textures from the copy.bsp and saved them in materials/maps/ramjam_b13. Then i removed the copied bsp and opened the orginal bsp with VIDE and replaced the black cubemap textures with the new cubemap textures built using the copy.bsp.

I tried this before and only got some of the reflections to work, but now everything seems to be in order.

Anyone else experiencing this issue?



Also, why does removing cubemap textures from the bsp remove static prop lighting?
 

Crash

func_nerd
aa
Mar 1, 2010
3,315
5,499
I used to get this problem all the time. Most often when I compiled using vbct. How are you compiling?

I haven't been able to narrow down what exactly causes it, but I haven't had it since I started compiling in Hammer with expert options set up instead.
 

Jusa

aa
May 28, 2013
377
618
$bsp_exe : -game $gamedir $path\$file

$vis_exe : -game $gamedir $path\$file

$light_exe : -staticproppolys -textureshadows -staticproplighting -both -final -game $gamedir $path\$file

Copy File : $path\$file.bsp $bspdir\$file.bsp

$game_exe : -dev -console -allowdebug -game $gamedir +map $file

And yeah, compiling with hammer Expert
 

Vel0city

func_fish
aa
Dec 6, 2014
1,947
1,589
Don't even start about black cubemaps. They're the sole reason I didn't build any for my 2014 Detailing contest map because it, as you said, destroyed the lighting done with -staticproppolys on props.

I too compile with VBCT. Hammer's GUI is something I just don't like. Give me checkboxes to check and I'm fine. Give me command lines and I'm out.

Now that link in the OP says something about vbsp.cpp, however, I can't find that file. VBCT uses the standard VBSP program to make the bsp file, so commenting out that line said in the link in the OP should help.
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
I too have this problem.

Up until a year or so ago, any map I made was not given any cubemap VTFs. Then one day I noticed my maps were being given cubemapdefault.vtf and cubemapdefault.hdr.vtf.

Today I did an experiment and found that I was also being given a set of black cubemaps, one for each env_cubemap entity, including a set of black HDR cubemaps for a map that was only compiled in LDR.

I renamed the BSP and was able to build cubemaps in the game without a problem. I am wary of deleting content from a BSP using VIDE or Pakrat as I have heard it can cause corruption. I believe I may have experienced that myself in the past.

The strange happenings seemed to coincide with a great purge I had of all the downloaded content from my TF2 directory. At that same time I also noticed that the game engine now had a default cubemap of its own, where before I had never seen one, and all the documentation I had read insisted that TF2 was not shipped with its own set of default cubemaps. Yet they exist in the materials VPKs.

I believe I read something about a BSP not being writeable due to cubemaps that Hammer was including. Though it might have been some talk in the chat room. Since the default cubemaps do not take up much space you could try renaming your BSP after compile, and then buildcubemaps and pack custom content, ignoring the default cubemaps and leaving them there as a sort of vestigial organ. Static prop lighting may work correctly then as you won't be deleting anything from the BSP.

Some of the discussion on the web, including the thread you linked, mentions an altered version of VBSP for Source 2013 that stops the default cubemaps from being included. Perhaps that's worth a try?

Have you tried extracting all the VHV files from the BSP, and replacing them later, when you pack your new cubemap textures?

Another interesting point - I took one of my old, fully-detailed maps and saved it as a differently-named VMF. I compiled it on full HDR with the special prop lighting command arguments and the BSP was not given its own set of black cubemaps.

EDIT: I took the plunge and tried that modified vbsp.exe file but it doesn't work. Maybe it's too old for TF2's Hammer.
 
Last edited:

Jusa

aa
May 28, 2013
377
618
I too have this problem.

Up until a year or so ago, any map I made was not given any cubemap VTFs. Then one day I noticed my maps were being given cubemapdefault.vtf and cubemapdefault.hdr.vtf.

Today I did an experiment and found that I was also being given a set of black cubemaps, one for each env_cubemap entity, including a set of black HDR cubemaps for a map that was only compiled in LDR.

I renamed the BSP and was able to build cubemaps in the game without a problem. I am wary of deleting content from a BSP using VIDE or Pakrat as I have heard it can cause corruption. I believe I may have experienced that myself in the past.

The strange happenings seemed to coincide with a great purge I had of all the downloaded content from my TF2 directory. At that same time I also noticed that the game engine now had a default cubemap of its own, where before I had never seen one, and all the documentation I had read insisted that TF2 was not shipped with its own set of default cubemaps. Yet they exist in the materials VPKs.

I believe I read something about a BSP not being writeable due to cubemaps that Hammer was including. Though it might have been some talk in the chat room. Since the default cubemaps do not take up much space you could try renaming your BSP after compile, and then buildcubemaps and pack custom content, ignoring the default cubemaps and leaving them there as a sort of vestigial organ. Static prop lighting may work correctly then as you won't be deleting anything from the BSP.

Some of the discussion on the web, including the thread you linked, mentions an altered version of VBSP for Source 2013 that stops the default cubemaps from being included. Perhaps that's worth a try?

Have you tried extracting all the VHV files from the BSP, and replacing them later, when you pack your new cubemap textures?

Another interesting point - I took one of my old, fully-detailed maps and saved it as a differently-named VMF. I compiled it on full HDR with the special prop lighting command arguments and the BSP was not given its own set of black cubemaps.

EDIT: I took the plunge and tried that modified vbsp.exe file but it doesn't work. Maybe it's too old for TF2's Hammer.


I tried the custom vbsp but it gave a "slate bsp file" error or simething after a while and didnt compile any lighting.

Anyways as i said, i got it working by not deleting but replacing the cubemap textures with the correct ones. Or maybe its because I used VIDE this time, who knows?
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
Aye, 'stale BSP'. I think the custom VBSP is out of date.

Aye, who knows. I just want a good clean method without having to faff about.

I've posted a feature request that this functionality be moved to a compile argument, over at the 'Source 1' GitHub page. But the place looks pretty dead so I don't expect to see anything from it. Apparently it also affects other games.
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
I've asked in the chat room who to email about Hammer-related things, in the past, but I was met with silence, Crash. Perhaps I should have been asking when you were on :)

I also wanted to ask someone about restoring the coloured lightmap grids in the lightmap grid view.

Here are my issues, FYI: https://github.com/ValveSoftware/Source-1-Games/issues
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
and all the documentation I had read insisted that TF2 was not shipped with its own set of default cubemaps
Well, that can't be true; there's definitely some sort of generic orangeish sunset cubemap in the game that used to be used whenever you compiled a map with no cubemaps in it at all (the purple checkers would only appear if you did have cubemaps but failed to build them). You can still see it in Hammer if you look at a reflective texture, like water or glass or the model for the Land Rover.
 

Crash

func_nerd
aa
Mar 1, 2010
3,315
5,499

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
Last edited:

Vel0city

func_fish
aa
Dec 6, 2014
1,947
1,589
This is the general all-purpose TF Team email:
http://www.valvesoftware.com/email.php?recipient=TF+Team

They don't read that. I've sent them about 15 emails in the last 3 weeks alone about a memory leak in the bsp tree that's causing the game to crash every time you switch maps yet there hasn't been an update to the game that fixes that or even a response back that they know it's there and that they're working on it.
 

Vel0city

func_fish
aa
Dec 6, 2014
1,947
1,589
It was the same stuff over and over again: crash reports from the same ginormous memory leak that's causing the game to crash every map change. You'd figure that shit would be patched out within 2 days but here we are 3,5 weeks later, still with a broken game.

How do these game breaking bugs get past the testing (if Valve is testing their updates in the first place)?