PoC Prototype - day 04 [2023-08-08]

Teleporting betweeen platforms (portal visualization)

It's portal rendering day!

The first step in any portal rendering system is placing a secondary camera. One must take the offset from the player to the portal entrance, and apply it "reversed" to the portal exit.

Then, as far as I know, it's either a render from this camera to a texture, and applying such texture to the portal surface, or using the portal as a mask and directly rendering the portal camera using the stencil buffer.

The second approach should be better but a little more complicated, so in the spirit of keeping it simple for the prototype, I'll try the render to texture approach first and see if it's "good enough" for now.

As an added layer of complexity, in VR we must consider not one but two cameras, for the stereo rendering, which also means two render textures and a shader that shows the correct texture on the portal surface depending on which eye is being rendered.

It's time stop and do a bit of research, checking tutorials and code samples about the subject, which should be quite popular thanks to the impact of Portal and Portal 2 (masterpieces!).

---

When I'm looking for ready to use systems or code samples, I usually search on

• Unity Asset Store

• OpenUPM, the Open Source Unity Package Registry

• GitHub

• Google

I found plenty of resources and based my implementation on some open source example which used the approach I had imagined.

After a bit of fiddling with vectors and quaternions, I got the basics working.

As you can see, I didn't apply the render texture to the hexagon I used as portal placeholder yesterday, which now acts just as a "frame" of the quad I actually use as portal.

Why? Well, it made sense to use quads to get started. They are the simplest geometry to apply a render texture on, and the example I studied used quads. Additionally, it is usually easier to try out these kind of systems creating and linking together components in edit mode, but I am creating the hexagons at runtime, so I couldn't do that.

Again, it's about splitting complex task into multiple steps, solving one problem at a time (when possible!).

After having the system working with the quad, it wasn't too hard to adapt it to use the hexagon I used yesterday as placeholder.

Actually, I had to add another, so that there's a kind of hexagonal frame, and then the hexagonal portal inside it. Without frame, because of the regularity and emptiness of the scene, it was hard to understand what was going on.

Well, I think that's it for today.

I'm quite happy about the result, even if there are a couple of problems.

The first is the the fact that what is shown through the portal lacks anti-aliasing, and so is perceivably lower quality. The other is the corner case where one eye is across the portal and not the other, causing a bit of glitching.

I did a little more research and decided that trying to fix properly the portal system now would not be a good idea. I'm at day 4/16 of my "prototyping jam", and a polished and high performance portal system could eat a significant chunk of the remaining time (if not all of it).

Part of the prototyping process is deciding that something is "good enough" and going forward, instead of obsessing over details and edge cases.

Lots of things could happen for the "real" game: I might change engine, I might switch to URP (during my research, lots of examples and assets took advantage of the SRP features), I might integrate an off the shelf component from the asset store... or I might decide that it's worth taking the time to implement a more polished and hand-tailored system myself.

The basic locomotion is done, I just need to change the input for portal activation/deactivation. I have a couple of ideas about that, but they will have to wait, because they are related to other gestures and hand poses that the game is going to need for the combat system.

Which might very well be what I'm going to start building tomorrow.