Skybox positioning issues

AngryRemilia

L1: Registered
Sep 21, 2014
6
1
Hello!

With October around the corner i decided i would work on a spooky version of lumberyard just for the fun of it. But i ran into a little issue.

Initially, the entire map was black. After doing some research I found I could fix by moving the entire map down a bit as so the map-origin wasn't covered. It worked but then it spawned this....
15plxg1.jpg

The entire tree background in the skybox is floating, and if i move the map a little closer to the origin the skybox will be in a better position but the map will be all black again.

I am basing this off valve's included sdk version of lumberyard.

Any help is appreciated!
 
Mar 23, 2013
1,013
347
You know how 3d skyboxes work? You should have moved the 3dskybox along with the map, means if you move teh map 512 units down then you have to move the 3d skybox 32 units down (512/16=32) since the 3d skybox is 16 times as small as the real thing.
But I think there is a better way to fix your entire map being black thing...
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
I suspect the black map is caused by the skycards. Anything in the sky will cast a shadow on the regular play space, because those cards have no collision mesh it'll use their bounding box to cast shadows. the bounding boxes for the rotated ones are HUGE and may well cover a lot of the map. To fix this, simply compile properly, that is to say, use -staticproppolys as a vrad parameter when you compile. http://forums.tf2maps.net/showthread.php?t=2994
 

AngryRemilia

L1: Registered
Sep 21, 2014
6
1
I suspect the black map is caused by the skycards. Anything in the sky will cast a shadow on the regular play space, because those cards have no collision mesh it'll use their bounding box to cast shadows. the bounding boxes for the rotated ones are HUGE and may well cover a lot of the map. To fix this, simply compile properly, that is to say, use -staticproppolys as a vrad parameter when you compile. http://forums.tf2maps.net/showthread.php?t=2994
All right so I tried that out on a new fresh copy of SDK lumberyard (probably just going to re-make my halloween version from that).

Well I tried it multiple times. One with just -staticproppolys and another with -staticproppolys -staticproplighting -textureshadows and with a custom RAD file
PHP:
forcetextureshadow models/props_skybox/skycards_forest128bump.mdl
forcetextureshadow models/props_skybox/skycards_forest512bump.mdl
forcetextureshadow models/props_skybox/skycards_forest128dip.mdl
forcetextureshadow models/props_skybox/skycards_forest512dip.mdl
forcetextureshadow models/props_skybox/skycards_forest1.mdl
Non made any difference and still resulted in this:
14e78fq.jpg

I did all this with a "fast" compile to test the lighting, I'm not sure if that would make a difference here (I was going to use Full when everything was done).
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
Try just disabling shadows on the skycards. They have no real need to be casting shadows on anything anyway.
 

AngryRemilia

L1: Registered
Sep 21, 2014
6
1
From the looks of your screenshot, it dosn't look like a hude shadow is cast over teh map.
Well to get the most common beginner error out of the way: Do you have a leak? Did you check your compile log for errors via http://www.interlopers.net/errors/ ?
I did use interlopers. Strangely it said I didn't have vbsp,vvis, and vrad enabled when i put in my log (?). So unless I got the wrong log from vbct, I'm not exactly sure what its upset about there (I do have all those enabled). Other then that it didn't give me anything regarding leaks.

Regardless, here's my log
http://pastebin.com/xrbUb8sK

After I recreated all the Halloween themed stuff, I created a couple extra copies of the .vmf and tried messing around with various parts of the map like takabuschik suggested too but I still couldn't find any resolution.

As much as I don't want to sound lazy, would it be OK if I uploaded the .vmf file for someone to look through?
Right now I'm kinda clueless.
 
Last edited:

wareya

L420: High Member
Jun 17, 2012
493
191
That's fine, it's easier than trying to figure out which obscure mistake is causing this than through twenty questions :p
 

henke37

aa
Sep 23, 2011
2,075
515
You have degenerate faces. Degenerate anything is never a good sign.
 

Freyja

aa
Jul 31, 2009
2,994
5,813
Not to mention VVIS is failing completely for some reason. Even fast VVIS doesn't take <1 second, and you're not even running portalflow, it's just quitting, so you're either on fast VVIS (don't do that, although fastvis = true IS missing, so idk) or something is badly wrong. That's probably why VRAD can't figure out any lighting (because it uses VVIS's calculations to help itself).

I'm not sure how to fix it. Try copying it into a new VMF (this resets all the brush ID's and stuff, can often solve odd problems).

Also, in my experience, when I've had the bug where every face is black, moving the entire map so that the origin (0,0,0 coordinate) isn't inside a brush has worked for me.
 
Last edited:
Mar 23, 2013
1,013
347
Not to mention VVIS is failing completely for some reason. Even fast VVIS doesn't take <1 second, and you're not even running portalflow, it's just quitting. That's probably why VRAD can't figure out any lighting (because it uses VVIS's calculations to help itself).

I'm not sure how to fix it. Try copying it into a new VMF (this resets all the brush ID's and stuff, can often solve odd problems).

Also, in my experience, when I've had the bug where every face is black, moving the entire map so that the origin (0,0,0 coordinate) isn't inside a brush has worked for me.

I'd liek to mention that vvis can indeed take 0 seconds. Without any error
 

Freyja

aa
Jul 31, 2009
2,994
5,813
It can, on like a box map. Highty unlikely on lumberyard (especially considering how open it is). Hence my suspicion of something going wrong.
 
Last edited:

AngryRemilia

L1: Registered
Sep 21, 2014
6
1
So I tried copying everything over to a new .vmf as suggested by Aly.
First it complained about a couple brush errors, that I managed to fix no problem.

Did another compile and.....it spat out more errors? Seems to be regarding some textures but it didn't seem like anything related to lighting.

Here's the compile log
http://pastebin.com/WKYsCYd5
Again it seems vvis decided to give up, so upon playing the map. Black map! Yaaay........

Just for reference here's my map origin
67r5ux.jpg

Here's the position I had to put the origin for the lighting to correctly show
2034gi.png

Of course that came with the skycards floating and repositioning everything doesn't work.

Here's the compile log for the version with the floating origin
http://pastebin.com/mukvk07n
Honestly, with all this weirdness going on I'm starting to think my copy of sdk_arena_lumberyard is corrupt somehow. I'm really lost at this point.

In case anyone wants to look.
Heres my vmf for lumberyard_event and my copy of sdk_arena_lumberyard.
http://tinyurl.com/me5fy5s
(mediafire, sorry)
 

wareya

L420: High Member
Jun 17, 2012
493
191
At some point I got the compile log to spit out "zero area child patch", so I guess that's your error somewhere. I'll keep looking.
 

Empyre

L6: Sharp Member
Feb 8, 2011
309
187
When you move your origin, you need to move the sky_camera entity (in 1:16 scale) to match the new origin. Its position in the 3d skybox represents the position of the origin in the "real" map.
 

Empyre

L6: Sharp Member
Feb 8, 2011
309
187
He had been advised to move the whole skybox, but he should move only the sky_camera entity relative to the skybox so that it is in the same place relative to the skybox that the new origin is relative to the map.