func_physbox Lighting
Quote from lightOfDay on September 19, 2013, 8:29 pmI'm having a problem with func_physboxes. I'm trying to make an exploding wall, that explodes into it's individual tiles, using physboxes. However, I can't start them in the wall, or else they will not get lit on the faces that are adjacent to the wall. Since both sides of the wall, as well as the inside edges, have to be visible, I can't use work arounds like invisible brushes or anything. What is the best way to move all of the physboxes to their proper position after map spawn?
EDIT: I believe I have identified the program causing all of the multi-posts, so it shouldn't happen again.
EDIT2: Yay! Everything's fixed. Sorry for any inconvenience I may have caused.
I'm having a problem with func_physboxes. I'm trying to make an exploding wall, that explodes into it's individual tiles, using physboxes. However, I can't start them in the wall, or else they will not get lit on the faces that are adjacent to the wall. Since both sides of the wall, as well as the inside edges, have to be visible, I can't use work arounds like invisible brushes or anything. What is the best way to move all of the physboxes to their proper position after map spawn?
EDIT: I believe I have identified the program causing all of the multi-posts, so it shouldn't happen again.
EDIT2: Yay! Everything's fixed. Sorry for any inconvenience I may have caused.

Quote from lightOfDay on September 20, 2013, 10:05 amI mean this problem:
http://steamcommunity.com/id/lightofday ... 1199052538
All I did was tilt it out from the wall. As you can see, since it was originally touching the inside edge of the wall, RAD didn't assign it any lighting information.
I was thinking if there is no "direct" fix, then putting them in a external room in seperate trigger_teleports pointed at their final destinations might work, however that doubles the entities, and I have no idea what the overhead of teleport a bunch of physboxes (set to no motion) at map spawn is.
EDIT: It fixed the crazy lighting artifacts on the edges of surrounding brushes though.
I mean this problem:
http://steamcommunity.com/id/lightofday ... 1199052538
All I did was tilt it out from the wall. As you can see, since it was originally touching the inside edge of the wall, RAD didn't assign it any lighting information.
I was thinking if there is no "direct" fix, then putting them in a external room in seperate trigger_teleports pointed at their final destinations might work, however that doubles the entities, and I have no idea what the overhead of teleport a bunch of physboxes (set to no motion) at map spawn is.
EDIT: It fixed the crazy lighting artifacts on the edges of surrounding brushes though.
Quote from lightOfDay on September 22, 2013, 1:48 amtrigger_teleport's won't work. Is should have known that a "brush entity" was a stretch for "an entity, that's not a brush". Is there a way to change something to a physics entity on the fly? I could have the wall pieces start an an open area, and than door/pathtrack in, then make sure to light them dynamically. This still causes problems though, as my lights have to be dynamic and they have to start in a place with no light...
EDIT: I got it! Parent the physboxes to pathtracks and put a node at the point I want the physbox, and place the physboxes, and their pathtracks in a nodraw containment bix outside the map. If I set the pathtrack speed high enough, they will practically spawn at the node. 3 limitations: Path can't intersect with other physics object, physboxes can't be simulated until after the move, and lights around them have to be dynamic. The third one is the main one, but it's not that big, considering that all lights coming from textures (AKA, glass lights) are dynamic. I'll try it out and get back.
trigger_teleport's won't work. Is should have known that a "brush entity" was a stretch for "an entity, that's not a brush". Is there a way to change something to a physics entity on the fly? I could have the wall pieces start an an open area, and than door/pathtrack in, then make sure to light them dynamically. This still causes problems though, as my lights have to be dynamic and they have to start in a place with no light...
EDIT: I got it! Parent the physboxes to pathtracks and put a node at the point I want the physbox, and place the physboxes, and their pathtracks in a nodraw containment bix outside the map. If I set the pathtrack speed high enough, they will practically spawn at the node. 3 limitations: Path can't intersect with other physics object, physboxes can't be simulated until after the move, and lights around them have to be dynamic. The third one is the main one, but it's not that big, considering that all lights coming from textures (AKA, glass lights) are dynamic. I'll try it out and get back.
Quote from FelixGriffin on September 22, 2013, 10:47 amlightOfDay wrote:Is there a way to change something to a physics entity on the fly?Yes. It's called a phys_convert. It's an extremely useful if hacky entity.
Yes. It's called a phys_convert. It's an extremely useful if hacky entity.
Quote from lightOfDay on September 23, 2013, 2:42 amThanks, I'll try to put something together with it. Hacky seems to be the only way to go. I've found this problem across the web, but the threads are always cut short, so I assume there is no other answer.
Thanks, I'll try to put something together with it. Hacky seems to be the only way to go. I've found this problem across the web, but the threads are always cut short, so I assume there is no other answer.

Quote from ChickenMobile on October 9, 2013, 7:13 amIsn't there a minimum light level for func_physboxes?
Sorry for late answer.
Isn't there a minimum light level for func_physboxes?
Sorry for late answer.
Quote from lightOfDay on October 24, 2013, 3:46 pmI don't know what you mean by that. They seem to light up normally, as long as the faces aren't set by the compiler to be unlit.
I don't know what you mean by that. They seem to light up normally, as long as the faces aren't set by the compiler to be unlit.
Quote from HMW on October 28, 2013, 3:05 pmJust an idea: couldn't you turn the surrounding walls into a func_brush? func_brush entities cast no shadows by default. (Remember to plug any leaks, if it's an outer wall.)
Just an idea: couldn't you turn the surrounding walls into a func_brush? func_brush entities cast no shadows by default. (Remember to plug any leaks, if it's an outer wall.)
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic