|
Post by futendra on Aug 11, 2013 23:26:06 GMT
|
|
|
Post by Zeph on Aug 12, 2013 11:20:03 GMT
TLDR: Add Cubemaps (correctly) and build them.
You're missing cubemaps. Cubemaps provide the data necessary for reflections. All your reflective objects do not know about the world around them so therefore by default reflect the skybox, causing them to appear brilliantly white.
You're looking for one cubemap per small-med room or corridor, and more in a grid pattern for large open areas. Place it about eye level (64 units from the ground).
Once placed, compile and run the game, type in the console "buildcubemaps", exit the game and reload the game and map.
|
|
|
Post by futendra on Aug 12, 2013 11:40:25 GMT
TLDR: Add Cubemaps (correctly) and build them. You're missing cubemaps. Cubemaps provide the data necessary for reflections. All your reflective objects do not know about the world around them so therefore by default reflect the skybox, causing them to appear brilliantly white. You're looking for one cubemap per small-med room or corridor, and more in a grid pattern for large open areas. Place it about eye level (64 units from the ground). Once placed, compile and run the game, type in the console "buildcubemaps", exit the game and reload the game and map. Could you explain why it only occured to other people, and not to the main mapper who compiled it? EDIT: We didn't add any cubemaps and just typed "buildcubemaps" in console. That fixed it, but you have to type it every time you update the workshop. Is there a way to make "buildcubemaps" a first-run command?
|
|
|
Post by Zeph on Aug 12, 2013 15:11:54 GMT
The main mapper, i guess has the built cubemaps in their BSP, where as the BSP they gave to others does not have the built cubemaps within it.
It's really a final finish thing you need to worry about, when you make public the BSP. not necessary for testing.
Bit concerned about building when there are no cubemaps to build...
|
|
|
Post by futendra on Aug 12, 2013 15:13:40 GMT
The main mapper, i guess has the built cubemaps in their BSP, where as the BSP they gave to others does not have the built cubemaps within it. It's really a final finish thing you need to worry about, when you make public the BSP. not necessary for testing. Bit concerned about building when there are no cubemaps to build... There are cubemaps, way enough really, but somehow we do have to build every update.
|
|
|
Post by Zeph on Aug 12, 2013 15:15:45 GMT
Of course you do. Every time you compile the map, the BSP is overwritten. You then need to build the cubemaps for the new level.
Again, only really necessary if you're giving the BSP to someone else.
|
|
|
Post by futendra on Aug 12, 2013 15:19:26 GMT
Of course you do. Every time you compile the map, the BSP is overwritten. You then need to build the cubemaps for the new level. Again, only really necessary if you're giving the BSP to someone else. So every one who plays the map with workshop, will have to open their console and build the cubemaps before they can play? Strange...
|
|
|
Post by Zeph on Aug 12, 2013 15:42:04 GMT
No, when you build and restart the game, it's coded into the BSP. Then you distribute the BSP. Fore more info: developer.valvesoftware.com/wiki/Cubemap#BuildingEDIT: ooh good to note: Note:Built cubemaps are saved in the bsp file the game loaded, which will be in the maps folder, not the location where the bsp file was built. Basically, don't share the source_sdk bsp, use the one from the game folder
|
|
|
Post by futendra on Aug 12, 2013 16:07:32 GMT
No, when you build and restart the game, it's coded into the BSP. Then you distribute the BSP. Fore more info: developer.valvesoftware.com/wiki/Cubemap#BuildingEDIT: ooh good to note: Note:Built cubemaps are saved in the bsp file the game loaded, which will be in the maps folder, not the location where the bsp file was built. Basically, don't share the source_sdk bsp, use the one from the game folder Yesh! Thank you!
|
|