Portal render laggy

My latest attempt at implementing portals is working (looks nice!) but is laggy

code here PlayCanvas | HTML5 Game Engine
published here Portal Experiments Part 2 - PLAYCANVAS

I’m not sure where the bottleneck is.

  1. I’m using a shader to display the portal as a post-processing effect. Would this slow things down?
  2. The position of the portal camera is updated in update(), is there a way to do this on render?
  3. Or to sync it with render some other way?
  4. I’m using matrices to determine the relative position of the portal camera, which I assume is quicker that using vectors, but uses an invert(), would this be expensive?

Thanks in advance.

2 Likes

What do you mean by ‘laggy’?

The portal placement takes a fraction of a second to update when the player moves (lagging behind the the correct position before settling to the correct one).
The “published” link links to a demo which shows what I mean.
HTH
Thanks.

Often if the “lag” is just one frame, it means you need to change the camera priorities. Give the camera that renders to texture priority -1, so that it renders before the main camera, that has a default priority of 0.

I couldn’t set the value below 0, so incremented the main camera priority to 1.
A definite improvement :slight_smile: , but still laggy :frowning: .

It looks like it is one frame behind and wondering if it’s just an update order issue. Perhaps moving whatever does the masking position to postUpdate /last in update stack would help

And there are some Application internal events you may try to subscribe in addition:

Yes, I does look as thought the portal lagging one frame behind, but I don’t think that there’s any code to move to an event.
The mask and portal cameras simply render to texture. So, no event there.
Then those textures are passed in a post effect shader.
I would’ve though that the scene is fully rendered before a post effect would be called.

I think your second camera that renders to texture has to be updated after the main camera. If it updates before it, it would use its position / rotation from the previous frame.

1 Like

Ah, yes. It needs to move before it renders.

Added: this.app.on("prerender", this.track, this); much better!

Thanks!