Finish test chamber 14 and document findings

[mwpenny]

What is the enhancement?

Before he stopped working on the game, James created most of chamber 14. This task is to finish where he left off by adding:

• ~Indicator lights~
• ~Decals~
• ~Observation room decor~
• ~Rising staircase~
• ~Death trigger for water~
• ~Check for trapped player~ (#15)
• ~More light sources~

Completing this level will help in understanding what is necessary to develop game content and build out more test chambers. Findings should be documented.

[Deconimus]

If you haven't started working on this, I'd like to contribute modelling / mapping the rising staircases.

[mwpenny]

@Deconimus I've already started working on this. I didn't have much time to continue last week, but should this week.

I've logged some issues if you're looking for something to work on.

[Deconimus]

(Continuing discussion regarding the stairs in #39)

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 a cutscene, that would require animating and playing each stair step individually which is quite cumbersome compared to two Blender animations.

Not necessarily. I'm guessing the animation of the stairs as a whole is already being controlled in a cutscene? The collisionboxes could be activated/deactivated at the start/ending of an animation as a whole. This would of course not allow for proper use of portals while the descending animation is still running, but I'd think this is negligible. With the other solutions in mind though this is probably not worth it indeed.

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 https://github.com/mwpenny/portal64-still-alive/issues/40 at the end of my last session.

This actually seems like a perfectly reasonable solution to me (were it not for #40). Would there be practical advantages in using separated collision/geometry animation of the stairs instead of this? Further, since you already have a static collision quad beneath the stairs for the second floor, would it be possible to just animate the @static geometry of that floor to show/hide the surface? Since #40 occurs with dynamic collision boxes, I'm wondering whether this would work around the issue.

[mwpenny]

This would of course not allow for proper use of portals while the descending animation is still running

That's what I meant. Ideally, I'd like to support this. But if not, then something like the dynamic floor compromise would be easier. Similarly, an advantage of separating stair collision and geometry animation is that the lowered part of the floor could be visible and portalable while still-raised steps could show the pit below them.

Further, since you already have a static collision quad beneath the stairs for the second floor, would it be possible to just animate the @static geometry of that floor to show/hide the surface?

It would need to be a transparent surface + static collision, along with separately animated static geometry. But it would work.

Do you mean revealing it one stair at a time as they descend, or snapping it into place at the end of the animation before the stairs+collision are moved out of the way? The former may be noticeable visually (but maybe not), and the latter prevents portal placement until after the animation. But it's a good idea that keeps the animation simple and is no more limited than my original dynamic collision approach.

In the interest of not letting "perfect" be the enemy of "good enough", I'm going to do it in stages. First with the second floor that obscures the pit (along with performance optimizations), then improve it from there based on our brainstorming.

[Deconimus]

Do you mean revealing it one stair at a time as they descend, or snapping it into place at the end of the animation before the stairs+collision are moved out of the way? The former may be noticeable visually (but maybe not), and the latter prevents portal placement until after the animation. But it's a good idea that keeps the animation simple and is no more limited than my original dynamic collision approach.

I was thinking of the latter actually, but I'm guessing the former could also work without being visible if timed well enough. It probably wouldn't even need to be frame-perfect, as long as it's early rather than late, as the descending stairs could still obscure it.

[mwpenny]

Revealing the floor one step at a time works surprisingly well. I update its position right before each step is moved below the stage, which hides the animation completely.

Since portal surfaces are defined by level geometry, I had to add a transparent/invisible material and use it for the second floor. The invisible portal surface and animated floor are offset by a small distance to avoid z-fighting. This distance is small enough to not be noticeable, particularly at native N64 resolution.

[mwpenny]

@Deconimus I've added some light sources to chamber 14 and am going to move on after finishing the level documentation.

@ambient and @point_light objects are helpful, but leave a lot to be desired. James did some manual painting in chamber 4 which looks really good. Eventually we should go over the levels in detail and do the same.

[mwpenny]

I also added plastic/plasticwall003a to materials.blend. I noticed in your most recent video that you use it in chamber 15. I decided not to in chamber 14 due to the way it is shaded - it stands out in the darker rooms of the chamber. Something to improve.

[Deconimus]

@Deconimus I've added some light sources to chamber 14 and am going to move on after finishing the level documentation.

The level polishing looks pretty nice, good work on that!

@ambient and @point_light objects are helpful, but leave a lot to be desired. James did some manual painting in chamber 4 which looks really good. Eventually we should go over the levels in detail and do the same.

Yeah, James did an amazing job with the lighting in that chamber especially. Perhaps there are ways to improve the light sources further though, so that we can avoid having to do manual painting too much if not for detail work. I could imagine having a type of directional_light similar to source games could be beneficial for some maps, e.g. where observational rooms have bright source of light shining onto the chamber.

Another thing I've been thinking about in that context is the color correction that Portal chambers use globally. It's pretty evident when comparing Portal64 and Portal side by side, as Portal has a much more "blueish" toning. I'm aware that we'd need something in the veins of a color-lookup shader which is probably not too viable on the N64 (although James did something along those lines in his toon shaded game jam entry). But, perhaps we could emulate the color correction up to a certain degree by just color toning the vertex colors globally in a similar sense as with colored ambient lights.

I also added plastic/plasticwall003a to materials.blend. I noticed in your most recent video that you use it in chamber 15. I decided not to in chamber 14 due to the way it is shaded - it stands out in the darker rooms of the chamber. Something to improve.

I pretty much just copied it from the window frames of chamber 0. It's more of a detail really, so having correctly shaded material that looks close enough is probably better for now, like you decided here. In chamber 15, I'd leave it in for now though as I'm hoping we'll resolve the shading issue before that map gets finished.

[mwpenny]

Yes, adding more light object types and enhancing the bake script will be helpful (lack of directional light sources limited me in chamber 14). I do think that some manual work will be required regardless though to get it just right.

As for the blue hue, it's definitely a big missing piece. The technique James used in that video doesn't allow for a large variety of colors though. Better vertex coloring similar to that of chamber 4 should go a long way to help.

I pretty much just copied it from the window frames of chamber 0

I see now - test_chamber_00.blend references the material from window_frame.blend. I thought it was defined as-needed. I'll undo my change to materials.blend. Sounds good regarding chamber 15.

[mwpenny]

Level documentation is finished and I've updated the Development Progress page to indicate chamber 14 is complete.

I'll document the asset pipeline when I refactor the build system in #4.

Additional polish can be done separately from this issue. That is a general enhancement that will apply to all chambers.