Portals Demonstration

[warwickallison]

Hello all (my first post, so I'll say that)...

I've implemented working and visually-correct Portals in BGE. As far as I can tell, they look like and work like Portals in Valve's awesome game of that name. Any object will transport (smoothly) through them automatically, preserving (but re-orienting) linear and angular momentum. The Portals themselves can be moved and reoriented as you please.

Basically the implementation uses VideoTexture.ImageMirror and a little maths. I'm no mathematician, so it took a few hours to get right, so I thought I'd save you all the trouble.

The script is in the attached blend file. You can use it in your own projects under this license:

Arrow-key around and enjoy "thinking in portals".

[Sim88]

Sweet! you should post this in resources. And maybe my thread of bge demos (se sig). Awesome work!

[Mentalturkey]

Looks awesome, but doesnt work for me

[vitorbalbio]

Amazing Work!!!
Fantastic! xD

[IAmThisGuy]

OH MAN!! That's just plain awesome.

[OTO]

Your first post is much more interesting/valuable than my 3,000!
Great work, bravo!!

[Captain Oblivion]

Very nice!

now if only the physics engine were more exposed to python, the portals could be placed in walls and solid objects...

[warwickallison]

Originally Posted by Mentalturkey Looks awesome, but doesnt work for me

Check:

Blender version 2.49a. Portals require ImageMirror from VideoTexture module. Another "interesting" thing I do is call scene.addObject on an object in the current scene (to create the temporary copy so objects are half in two places at once while transitioning through portals). As I understand it, that wasn't always permitted.

GLSL. Does any GLSL work for ou? That's probably required (I only tested with it on - I'm interested in game creation).

Otherwise, what sort of problem do you get? I might be able to guess the cause with more info. Any error in the console window?

[warwickallison]

Originally Posted by Captain Oblivion if only the physics engine were more exposed to python, the portals could be placed in walls and solid objects...

In Valve's game, portal placement is quite restricted (for gameplay reasons I suspect, more than engine constraints).

But given similar constraints, I think it would be possible to implement "portalable-wall" objects just using the current APIs:

1. Make all portalable walls just be Ghost boxes.
2. At startup, use a script to generate a matrix of small Invisible solid static "blocker" objects coincident with the portalable walls
3. When a blocker object touches a portal, hide (or just disableRigidBody) it until the portal goes away

The effectiveness would depend on the resolution of the blocker objects, which you would need to trade-off against performance.

Portals could be forced to only occur at the grid positions of the blocker objects, so there would be no "gaps".

The blocker objects would also double as portalgun impact detectors. Unlike the portals in Valve's game, portal projectiles could then even travel through portals (a game mechanic I always thought was sadly missing from Valve's game).

Hm... this doesn't really sound all that hard to implement. I'm working on something else of which portals are just a minor part (and more restricted than those in Valve's game), otherwise I would have just talked myself into doing it!

[mcguinnessdr]

I found out about portal just a few weeks ago, and have been thinking of ways to do it in blender. Looks like you have the same problem that I couldn't figure out, it doesn't work to well if the camera goes through the portal. Other than that, great job!

[Minifig]

Awesome!
This is so much better than a silly teleportation system.

[Captain Oblivion]

The blocked up walls solution will work in a pinch, but it's tough on resources and the collision for portals would be wonky (not round, and wouldn't fit perfectly around the portal)
As long as these portals are used like the ones in Prey (fixed to objects or positions, not dynamically created) they will be fantastic.

In terms of collision, it might be feasible to use a boolean modifier once the realtime-collision updating is implemented (in 2.49b, if I'm not mistaken) However you would need a boolean modifier on each portalable wall for each portal that could be in the scene. Still pretty damn resource heavy.

[warwickallison]

Originally Posted by mcguinnessdr it doesn't work to well if the camera goes through the portal

My use of it doesn't have a first-person camera, so I've not looked into that problem.

But I imagine it would particularly be a problem of resolution - you'd need to have a very high resolution on the VideoTexture. Maybe you could hide that with an excuse for a filter ("light get's blurred by quantum effects when passing through a portal"). ;-)

[warwickallison]

Originally Posted by Captain Oblivion The blocked up walls solution ... collision for portals would be wonky (not round, and wouldn't fit perfectly around the portal)

Computer games are all about faking it. Add blockers around the portal, scaled to fill gaps to the wall blocks, plus whatever extra mesh for the portal (if you want them round). This would solve both the wonkiness near the portal and the resource costs (the blocks could be much lower resolution in this case).

The more I think about it, the more this "blocked up walls" solution corresponds to the constraints in Valve's Portal game. Makes me wonder if their game constraints are not perhaps similar engine constraints.

[Captain Oblivion]

I believe their portals are hard-coded, using direct access to the physics engine- they cut a section into the wall wherever the Portal is placed (at least, that's what the design documents for the game Portal was based on said, and it's the same people who made Portal)
I think they might have actually used a method to split up the objects between portals, too, so if the portal was on a shallow wall objects wouldn't bump into the other side. (for example, portals can be placed on very thin panels, and long objects can still pass through them without issue)

[otto riis]

Very cool setup you've got going here, it even handles the infinite depth very well (when you're looking down the tunnel). However one thing I noticed was when you set up two portals face to face, and start making the ball go faster and faster through them, the ball eventually starts to hop, I think it is cause by collision with the bottom of the box portals, still a very nice demo

[Minifig]

May I use this in a game that I'm making?
I can reference you however you like...

It's called Space Laser Battles (Name WIP)
It is similar to asteroids, and the portals work very well for the sides of the screen!

[Sim88]

I still expected much more excitement, like 2-3 pages of "yeaahhh!!!!", portals have been wished for a lot here.

[cray]

You are right, Sim88.
That release is amazing.

Warwickallison, congratulations

[Captain Oblivion]

Minifig- if you use the portals for your game, I recommend wither showing them (it would be cool to see the game repeating infinitely in all directions) or dramatically simplify the math (since I'd imagine the sides of the screen can't rotate, you don't need to account for that)