According to other forum. Parts of the geometry of the map are duplicated. All the maps where you see a version withouth light, and then with lights… use two maps, and you are seamlessly teleported from a version to another[B]. [I have not checked that myself][/B]. Acording to that forum post, this was because limitations of the light rendering on Source.
Wait, you’re saying source doesn’t support dynamic lighting? In 2011? That seems so unlikely.
I seriously doubt that. I think someone is misunderstanding how that all works. Hell, L4D has dynamic lights so that makes no sense whatsoever.
This is the worst description of precomputed lightmaps I’ve ever seen in my life. We are all dumber for having read it.
Left 4 Dead doesn’t really have dynamic lighting, it just sort of fakes your own flashlight and how it affects pre-baked light maps.
Portal 2 does however have much more substantial dynamic lighting, which is obvious looking at certain Wheatly segments. However, I wouldn’t be surprised if that’s also faked in a way unlike how dynamic lighting works in more modern engines.
Not to mention the fact that the lighting actually moves across the surfaces when the layout changes. It doesn’t just appear.
Right, but it does have things like shootable lamps which cause lightmaps to be swapped out (ala old school Quake) without teleporting you to a new level where that lamp is burned out.
[I]I normally test my comments before posting. But just now I can’t, so I added a caveat.
I have not tested that myself, so I don’t know if was true.[/I]
Anyway I can’t see how “duplicated geometry” could describe lightmaps. That Zylon comment confuse me.
I see lightmaps a texture with light information for the geometry, so wen the texture is applied, is combined with the lightmap to paint some areas darker than others.
Normally the lightmap is compiled from the geometry using some tool that runs radiosity checks … maybe per-pixel? I am not expert. The lightmaps are stored in the BSP file, with the actual BSP tree and maybe some textures.
I think I know what is a lightmap, Zylon.
As LMN8R points out, COMPLETELY BORING AND UNINFORMATIVE SPOILER, there’s a part of the game where you’re walking down a series of dark hallways, and there’s a dynamic light above your head swinging around.
That’s so obviously dynamic lighting, I find myself wondering if they were trying to brag that they support it.
Teiman, Zylon is a troll. You don’t have to justify yourself to him because, frankly, he doesn’t care.
I was thinking the same thing. “Somebody got some Doom 3 up in my Portal 2”. I was half expecting to be surprised by a hidden demon closet.
Source SDK does have Dynamic light. but it is nowhere near the level of Doom or Unreal. Left 4 Dead’s dynamic light is actually a bunch of pre-baked textures swapping out for one another, with several others lighting the texture when it needs to. Source can’t handle too much dynamic lighting.
That being said, I did notice lots of areas in Portal 2 where the dynamic lighting was quite good. Shadows shifting across the wall as the light passes, moving sources of light that flash across surfaces. I wouldn’t be surprised if they updated the engine to include some form of dynamic lighting now, since it’s the most major thing Source has been lacking for quite a while.
Warren jumping in to defend Teiman, ladies and gents. You can’t make this stuff up.
Here’s a video showing the changes to the original Half-Life 2, before and after the Orange Box updates. There were also further updates to the older Source games in 2010 when they were made OS X compatible, to bring the tech in line with L4D2 - I don’t know if the video reflects that.
I for one would be totally satisfied if Valve updated the Source engine to remove all loading sequences, but didn’t change anything else. I was totally happy with the textures, lighting, etc in Portal 2. I can’t think of a company whose games would benefit more from removed loading screens really, given what a high priority Valve puts on “immersiveness” (yes, that’s right, I just made up a word).
Removing (well, diminishing) load screens means switching from static resource loads to dynamic streaming, which is astoundingly non-trivial. It doesn’t just affect resource management, it affects scripting, AI, physics, audio propagation… pretty much everything. You basically have to architect an engine from the ground up to support it.
I like to think that this is what Valve has been working on for Half-Life (Ep)3.
Even if Valve moved to a Metroid Prime model where you’re stuck staring at a door waiting for it to open for a few seconds as it’s loading things in the background, I’d be happy. Just please keep the gameplay and my look/movement controls active, and for the love of god, stop cutting out the music playing in the background!
Even that one thing - keeping the music playing - would significantly improve the experience, even if the video still froze up with a “Loading” string or a full loading screen showing up.
Hah! I just searched my gmail and found an e-mail I sent to Gabe way back in 2006, since he always says to send him feedback. Getting rid of loading screens altogether would be great, but at the very least, they need to figure out a way to stop even the music from getting annoyingly cut off.
Eh? Being able to look around at a world that’s suddenly frozen in time sounds more creepy than immersive.
/has not played Metroid Prime
You can still move around etc, the door just takes forever to open as stuff loads in.
The funny thing about this suggestion is that with all the elevators in Portal it would have been a fine time to do such a thing. I suspect that a loading screen with progress bar was a better solution.