Create test chamber 15

[Deconimus]

What is the enhancement?

Test chamber 15 is yet to be created. Rough steps include:

• Map structure
• Level objects (ball-catchers, buttons, switches etc)
• Animations (pistons, platforms, glass doors in last room)
• Cutscenes
• Details (decals, decor, observation rooms etc.)
• Lighting

Mapping progress per room:

• Room 1 (see note)
• Room 2 (see note)
• Room 3 (in progress)
• Moving-Platforms Hallway (mwpenny)
• Final Room (mwpenny)

Related issues:

• Add floor tile variation material #37
• Add collision for Fizzler frames #41
• Apply blender object size to fizzlers #38

[Deconimus]

I mainly opened this issue to start tracking related progress and to enable collaboration on this, while chamber 14 ist still being finished.

Initially I was just trying to get more familiar with Blender but ended up mapping out the complete first room of chamber 15. I used the other levels as well as the decompiled Portal map (testchmb_a_10) in Hammer Editor as reference.

chamber15_first_room.mp4

[hackgrid]

How do you create maps for portal64 correctly? I was under the impression, that James imported the original Portal maps into blender?

Is that false and he always recreated them?

[mwpenny]

@hackgrid they are created from scratch. This allows changes to be made as necessary (e.g., simplification), and many elements of the original map are irrelevant Source engine features.

I have created documentation in https://github.com/mwpenny/portal64-still-alive/blob/master/documentation/levels/file_formats.md and related pages on level objects.

[Deconimus]

How do you create maps for portal64 correctly? I was under the impression, that James imported the original Portal maps into blender?

I can't say how James created the maps exactly. There are tools to import Source engine maps into Blender, such as Plumber. However, the level geometry in Portal64 maps is simplified in many places and significantly differs in format, e.g. Portal maps use box shaped brushes for most geometry Portal64 uses plane surfaces for walls etc. to reduce polycount. Materials, decals, models, lighting and other entities are handled very differently. This makes the effort required to make imported maps compatible with Portal64 not really worth it imho.

[hackgrid]

James explained:

There were some tools that let me export the maps from the game into blender. I then used those as a guide to manually recreate the geometry and game objects in a separate blend file
It was a pretty manual process but fortunately it wasn't too bad because of the low poly nature of the project

[Deconimus]

@hackgrid Thanks, good to know for sure! Then my process is not too different. I just prefer to use Hammer to view the reference map as I'm more familiar with that.

[mwpenny]

I mainly opened this issue to start tracking related progress and to enable collaboration on this
[...]
ended up mapping out the complete first room of chamber 15

I'm glad my documentation seems to be helpful.

I don't have as much free time as you, and project documentation/management takes up some of it, but one of the main motivators for me continuing this project is being able to build game content such as levels. I'm happy you're excited about it too, though collaboration/sharing of work is important to me here.

The rough order of detail passes you've listed above looks good. I think a good way to split this up would be each working on separate rooms to avoid conflicts (e.g., begin at start/end of the level and meet in the middle).

chamber 14 is still being finished

As an update, my current focus is making the animated stairs performant. It's a balance between Portal 2007 parity and smooth gameplay, and I'm also finding gaps to address along the way (e.g., f16f88a, 35e9d43). With this in mind, before chamber 15, I'd be fine if you want to take some of the remaining chamber 14 items in #5. I can resolve the conflicts - just leave a message on the issue if you go ahead with this so we don't duplicate work.

[Deconimus]

I don't have as much free time as you

Bold assumption. Not that I particularly care in this instance, but I'd keep statements like this one free of personal comparisons in an environment like GitHub. "I have limited freetime" would have been more apropriate.

[...] one of the main motivators for me continuing this project is being able to build game content such as levels. I'm happy you're excited about it too, though collaboration/sharing of work is important to me here.

Then we are on the same page, perhaps my wording didn't capture my intentions very well. I'd have mapped out the first room of Chamber 15 regardless of its relevance for this repository, simply because I had fun doing so. This might also be true for any contribution I've made so far, but I'd rather collaborate than just tinker with this on my own. With opening this issue, I wanted to make sure I don't step on your toes if I wanted to contribute to mapping this chamber.

The rough order of detail passes you've listed above looks good. I think a good way to split this up would be each working on separate rooms to avoid conflicts (e.g., begin at start/end of the level and meet in the middle).

Sounds like a good plan. I made a branch for this chamber on my fork, you could check out the state of the .blend file there when you want to start working on this chamber. Aside from that, I'd just keep this issue updated with what rooms I'm working on.

[...] With this in mind, before chamber 15, I'd be fine if you want to take some of the remaining chamber 14 items in #5. I can resolve the conflicts - just leave a message on the issue if you go ahead with this so we don't duplicate work.

Thanks for the update. I'll leave a note if I'll start working on these.

[mwpenny]

Bold assumption. Not that I particularly care in this instance, but I'd keep statements like this one free of personal comparisons in an environment like GitHub. "I have limited freetime" would have been more apropriate.

Didn't mean to offend here. In a comment in PR #15 you mentioned you recently got some free time on your hands, and you've been making frequent helpful contributions these past few weeks. "My schedule doesn't allow me to work at the same pace you have been, but this area is important/motivating to me" is all I meant. I wanted to highlight that we work in different ways which each impact collaboration, rather than "I don't have time for this". Sorry if it felt like anything more.

Then we are on the same page, perhaps my wording didn't capture my intentions very well. I'd have mapped out the first room of Chamber 15 regardless of its relevance for this repository, simply because I had fun doing so. This might also be true for any contribution I've made so far, but I'd rather collaborate than just tinker with this on my own. With opening this issue, I wanted to make sure I don't step on your toes if I wanted to contribute to mapping this chamber.

Sounds like my wording wasn't great either. But I agree, we have similar motivations here. This is something - in spite of time restrictions - I want to work on since I find it fun in the same way as you do. I could do that independently, but the purpose of "Still Alive" is to help encourage collaboration, focus effort, and avoid fragmentation so that we can make this project as great as it can be. So splitting it up into sections to share would work best.

Sounds like a good plan

I'm looking forward to progress on this. As for chamber 14, it's been quite helpful in uncovering some engine limitations. Most recent I've found is #40, which will be needed to complete the stair pit. I'm going to work around it and leave the stairs as "non-behind-the-scenes" until then (as in the above screenshot).

[Deconimus]

"My schedule doesn't allow me to work at the same pace you have been, but this area is important/motivating to me" is all I meant. I wanted to highlight that we work in different ways which each impact collaboration, rather than "I don't have time for this". Sorry if it felt like anything more.

Oh that makes perfect sense now. No worries and I didn't mean to put you on the spot or anything. That statement just seemed odd to me, as I simply didn't see how it would be of relevance before.

Mapping is also one of my more preferred areas of working on games, so I get your sentiment. I won't mind at all, if you'd like to "reserve" certain parts of that process or certain chambers for yourself. Looking at how much more has to be mapped just didn't lead me to worry about that.

As for chamber 14, it's been quite helpful in uncovering some engine limitations. Most recent I've found is #40, which will be needed to complete the stair pit. I'm going to work around it and leave the stairs as "non-behind-the-scenes" until then (as in the above screenshot).

Even without knowing of that bug, I was wondering if the floor surface geometry being split into the individual stairs would also be an issue by itself.

Just spitballing and perhaps that is already the work around you mentioned, but wouldn't it suffice to have a static @collision quad where the floor used to be? If necessary the stair collision boxes could be lowered by a fractional amount more than would be visually correct or more elegantly even deactivated (though I don't think that's supported as of now).

[mwpenny]

Great, glad it's cleared up.

Even without knowing of that bug, I was wondering if the floor surface geometry being split into the individual stairs would also be an issue by itself.

That's right. Portals in P64 can't overlap multiple pieces of collision. So the stairs can't come together to form one surface, and each individual step is too narrow on its own. The original game doesn't have this limitation and so portals on the descended stairs "just work".

The added constraint in P64 allows portal placement logic to be simpler and faster. I suspect that the performance impact of changing this wouldn't be too bad (shouldn't affect portals after placement), but reworking it is non-negligible effort that doesn't feel particularly worth it for this one part of the game (I can't recall another that needs this).

Just spitballing and perhaps that is already the work around you mentioned, but wouldn't it suffice to have a static @collision quad where the floor used to be? If necessary the stair collision boxes could be lowered by a fractional amount more than would be visually correct or more elegantly even deactivated (though I don't think that's supported as of now).

Lowering the stairs beneath a static floor is what I'm mostly doing now, but portal surfaces currently require both collision and @static geometry to work. Collision on its own isn't enough. So I just have a second floor that the stairs hide beneath for now. This obscures the pit with the pistons and orange glow.

A transparent material could be added to allow the player to see the pit when the stairs are up, but portal placement logic only cuts holes in the surface a portal is attached to, so the floor would z-fight with its portals. Placing the portal surface slightly above would solve that, but also mean portals wouldn't sit flush with the floor. This would probably still look okay if the distance were small enough, but now there is another problem: when entering a portal, the player can still collide with objects behind it - i.e., the stairs hidden beneath the floor. I currently solve the collision issue by hiding the stairs far beneath the floor, but that disallows a transparent portal surface.

You're right that disabling the collision would work. But in practice it doesn't seem as elegant as at first glance. For instance, how would it be configured? If in another animation channel, all animations would increase in size. If in the object name in Blender (e.g., "deactivate at beginning/end of animation"), that doesn't work nicely with the stair's different up/down animations. If in a cutscene, that would require animating and playing each stair step individually which is quite cumbersome compared to two Blender animations. Another options is a new kind of level object which deactivates the collision of everything inside of it. That could work, but doesn't have a use (for now) outside of this chamber.

Some of the negatives above aren't as bad as others, but I didn't want to get too complicated in my first pass. I could animate the collision separately from the geometry. However, the animation is already fairly expensive and this change would result in doubling the number of bones. So the compromise I was working on was to have just one extra bone to show/hide a floor over top of the stair pit, which seemed like the best middle ground for the short term - until I found bug #40 at the end of my last session.

So it looks like any solution will necessitate some engine improvements. It's been on my mind and now, with everything above, the approach that sounds like it strikes the best balance is the transparent floor with stair collision animated separately from geometry. I'm currently looking at some promising hot spots in code to optimize to hopefully make this more viable. I will also look at supporting nested bones in level animations. Both of these things will not only help with the stairs, but any other complex animations later in the game (escape sequence). If it's going to take more than a few more sessions, I'll push my 2-floors hack so there is a base in master that can be improved.

Hope that explains the limitations and my thought process. Let me know if you have suggestions (let's continue discussion in #5).

[Deconimus]

Update on the mapping progress: The second room along with the hallway connecting it to room three is mostly finished.

ch15_second_room.mp4

[mwpenny]

Nice work. And with decor/decals/indicator lights too.

I added similar polish to chamber 14 the other day and will finish up this week.

Next week I'll be able to start on chamber 15's final room and moving platform room/hallway.

[Deconimus]

I added similar polish to chamber 14 the other day and will finish up this week.

Nice, looking forward to seeing that in-game!

[Deconimus]

Next week I'll be able to start on chamber 15's final room and moving platform room/hallway.

If you would open a chamber_15 branch on here, I'd be happy to make a pull request from my branch. I'm guessing this would be the easiest way to kick things off. I've kept the branch up-to-date with the master and since #43 has been merged, it only contains on-topic changes for the build system / level definitions / menu entries and assets.

[mwpenny]

Sounds good. I've created a new branch. I'll work in a separate blend file so we only have to deal with merging our work at the end.

[Deconimus]

Great! Just something to keep in mind: if we're working on different blend files, we should try to have the same orientation in regards to the world coordinate system from the start. When rotating groups of objects in blender, small numerical imperfections can show up in the position or volume attributes due to limited floating point precision. This shouldn't generally be a problem, but can be a bit pesky to clean up afterwards.

[mwpenny]

Yes, this is something I've run into it in the past. Good to keep in mind.

I'm going to use the scaled coordinates and same orientation from the original game so it should be drop-in.

[mwpenny]

Update: I am about ready to merge the second half of chamber 15 with the first.

Along the way when building part 2 it seemed that most rocks I turned over revealed a bug or something missing.

Fixed/added:

• Fixed UV translation arguments not working for @static geometry
• Added portalability on a per-object basis (for one-off geometry)
• Added support for rotated doors (needed for final room ball enclosure)
• Updated door_02 model to not include border (needed for final room ball enclosure)
• Fixed doors not blocking energy balls

Things I've found that aren't addressed:

• Missing observation room decor models (bts_stool and bts_chair): Model missing chamber 15 observation room decor #72
• View through non axis-aligned portals is not properly rotated (angled walls in room 3): Non-axis aligned static geometry is visible behind portals #73
• With enough momentum, the player can clip through walls/floors/ceilings (in the floor the player gets stuck and can't jump): Player can pass through collision with enough momentum #74
• Current movement physics make some flings very difficult (and in general, the player doesn't land where they do in the original game): Better match movement physics of original game #8
• Level animations get duplicated for objects that use other animations, which can add bloat (maybe just an issue with the .blend files): Level animations are duplicated on build #75

Given the number of items, I'm going to finish the chamber itself and merge to master so we will have a base that can be fixed/iterated on more easily, rather than hold it up indefinitely. Many of these affect more than just chamber 15 as well.

I've started looking at updating the movement to be more like the original game and have made some good progress. I have the player landing in the same locations as the original game. Right now I'm looking at improving air control/strafing, which makes a big difference to the feel.

@Deconimus let me know if you're interested in looking at some of the above.

[mwpenny]

I found another issue involving how room visibility is determined, making it easy to trigger false positives. Since chamber 15 is so large, this caused the maximum number of static objects per frame to be exceeded and portions of the level to not be drawn. I've merged a change that improves this (see 220dd58) and will look at further improvements later. In addition to making larger chambers possible, this is worthwhile to improve general performance.

Similarly, there is a maximum number of dynamic level objects (currently 48). Since fizzlers have 3 dynamic objects (fizzler itself + collision on 2 sides), and the level has 14 fizzlers, the limit is quickly exceeded and most dynamic objects are missing. I've disabled fizzlers for now. I'm thinking of supporting vertically tiled fizzlers to reduce this number, and will likely need to increase the limit as well after investigating the implications.

For now - the first pass of chamber 15 is merged. There's still a lot of work to do, but this is an exciting milestone. Thanks for your help, @Deconimus.

[Deconimus]

Good to hear chamber 15 is coming along well!

Similarly, there is a maximum number of dynamic level objects (currently 48). Since fizzlers have 3 dynamic objects (fizzler itself + collision on 2 sides), and the level has 14 fizzlers, the limit is quickly exceeded and most dynamic objects are missing. I've disabled fizzlers for now. I'm thinking of supporting vertically tiled fizzlers to reduce this number, and will likely need to increase the limit as well after investigating the implications.

Tiling fizzlers vertically sounds like a good plan.

Another thought I had back when I added the fizzler collision boxes: Instead of adding the collision as dynamic objects, we could create them as static level geometry, since fizzlers are not movable objects. I suppose this would have to be done when parsing the .blend files, via the .lua scripts.

[mwpenny]

Yes, that would help. For chamber 15, that won't be enough to fit under the limit. However, optimizations like this add up. General reduction of dynamic elements avoids waste, helps avoid exceeding the limit in future levels, and is good for performance even if the limit needs to be increased regardless - especially since these elements aren't really "dynamic" in practice.

The general technique of baking level data could even be extended to other "dynamic" objects. For example, converting collisionless @decor to @static at compile time.

[hackgrid]

Awesome work guys! :-)

I noticed if you try to shoot the first camera in chamber 15, the game will freeze and the rumble goes berserk!

It freezes on this frame.

Shooting the second camera causes no problem at all. Trying the first camera after that again, freezes again + rumble goes berserk. (ares 136 and 1e8275e

[mwpenny]

Thanks, I'm aware of this one. It's due the ceiling geometry when trying to place a portal there. It also happens on the back wall of the hallway you're facing. Firing directly on the camera wall should work.

It's possible to fix by adding a couple more vertices but I'm going to look at the portal placement code to see if it can be made more robust in general so we don't have to think about stuff like this or add extra detail.

Appreciate you testing this out!

[hackgrid]

Great, thanks! Of course, still a big fan! :-)
But pretty busy atm, I still want to contribute the language selection menu at first startup + reactivate the deinterlacing option.

[mwpenny]

Sounds great! And that's understandable. No rush/pressure.

[mwpenny]

I've created some issues for the problems discussed above. I mentioned this issue so they're linked.

[mwpenny]

Earlier this week I added the moving platforms above the goo, and I just merged some basic lighting.

With that, I think it's safe to call chamber 15 "created" :) There's more work to do but it's tracked in separate issues.

I didn't expect the number of engine enhancements and bug fixes that would be required for this chamber, but the good news is that they benefit the entire game. In hindsight, it makes sense that 15 would push some limits given its size and complexity.

[hackgrid]

Great work, it is awesome! Thanks for continuing this! :-)