Non-Euclidean Portal Renderer

[gregwarner]

Hi, first post, as I am new to the Irrlicht engine. Migrated from jMonkeyEngine.

I am seeking some advice/tips on a non-Euclidean portal-based rendering system. Let me explain with an example. See image below for illustration.



For the most part, consider this your standard portal-based rendering engine. However, I want the ability to include portals that lead to other cells which may not be directly adjacent to the current cell.

The top half of the image represents how the level is laid out in Euclidean space. The bottom half is how I want it to appear to the camera. The pink planes represent the portals that are connected to each other. In the left-hand image, the current player location is indicated by the (poorly drawn) camera symbol, which is facing toward you (out from the screen).

What I propose is, whenever a non-Euclidean portal is within the main camera's view frustum, I would generate a 2nd camera at the same relative position from the destination portal as the main camera is from the origination portal. You can see this in the right-hand image, in which the position of the 2nd camera (pointing away from you, into the screen), has been rotated 180 degrees around the portal. The first cell (the active cell, in which the player is currently located) would be rendered first from the vantage point of the main camera, and then the 2nd cell would be rendered from the vantage point of the 2nd camera, obviously cropped to the smaller view frustum bounded by the dimensions of the portal.

That is my idea, and I am looking for feedback/critique from those more familiar with Irrlicht or with non-Euclidean rendering. Do you think it would be possible to write this so that Irrlicht could render one scene using multiple cameras during the render process?

Thanks.

[HerrAlmanack]

i had designed on paper something similar to this, it would use shaders, but unfortunately I never got a chance to try and implement it.

the way it would work would be to use a shader to render the other room in a way that the orientation of the one portal door and the other portal door would match. that could be done in the vertex shader by essentially taking the different between portal one and geom of the "go-to", and transforming by that matrix frame.

you would then use a stencil to only render the "go-to" room that is showing through the silhouette of the portal you are looking through.

using shaders would be much faster than using two cameras, also you could have different door shapes if you used a stencil, rather than a quadrilateral frustrum.

however then compatibility on older computers would be an issue..

[gregwarner]

Thanks for the vertex shader idea. That's probably much faster than my dual camera approach.

This also brings up issues around lighting as well. I would want lights in one cell to affect objects in the other cell, even when crossing a non-Euclidean portal like this. Additionally, I would want to make sure shadows behave as expected. In my example above, if the player steps through the portal and is standing just at the edge, the lamp in his current cell would cast a shadow through the portal and onto the ground of the first cell. I suspect similar tricks with shaders would be at play here as well?

This'll be my first time writing a shader. Any tips on writing custom shaders for Irrlicht? Any good tutorials or examples of this?

Thanks again.

[randomMesh]

This'll be my first time writing a shader. Any tips on writing custom shaders for Irrlicht? Any good tutorials or examples of this?

Have a look at example 10.Shaders in the examples folder in the SDK. It teaches you how to use shaders with Irrlicht, but not how to write them. Writing shaders is black magic and can't be taught.

[mongoose7]

Might be a bit hard?

I'd render the portal to a texture and then render the scene, applying the texture to a wall of the room.