I’d like to set up a portalling system.
This entails rendering a room, rendering a portal, then rendering the next room, only in the area of the portal.
I was wondering if there’s a way to explicitly tell unity to render a set of game objects, and not the whole scene.
Thanks.
The way I achieved that effect was with 3 Cameras.
Camera 1 Renders the Area through the Portal.
Camera 2 Clears the Depth Buffer and renders the Portal to the Depth Buffer (so it’s the only object). It keeps the Colour from Camera 1
Camera 3 Renders the Area you are in, using the Portal to cull out objects that would be behind the portal, keeping the Colour info in Camera 1.
The challenge with this method was constantly switching between near and far cameras, and having 1 camera + 2 Cameras per portal becomes a hassle to maintain proper rendering order.
its possible to tell it so: disable all other objects or at least their renderers.
portaling is nice, but keep in mind that it won’t be working correctly or not efficiently, because you can’t detect “whats seen through the portal” in any meaningfull way, because unity isn’t limited to BSP which are normally the base for a usefull portal calculation.
Thats why Unity Pro integrated umbra, for powerfull occlusion culling
Nteros approach works up to a given border, main problem is that without occlusion culling, unity uses view frustum culling, which doesn’t care if stuff in front of it is in this room or a room 10 walls further behind, as long as it is in the view frustum.
Right, I forgot to mention, that to manage the clipping planes you use something like this:
http://www.terathon.com/code/oblique.html
This way you can make sure the far cameras clipping plane matches it’s portal.
I will be precalculating what rooms can be seen from each portal, probably manually to start with.
Is there a way to find out if any pixels were changed when an object was rendered?
not if the idea was to be faster than just rendering it all without portaling, no, cause pixel access means copy backs to RAM which on any kind of gpu is horrible slow.
clipping would be done mathematically basing on bounding volumes, at best. or basing on rooms at simplests.
As I understand it, render querys are very fast, I just wondered if querys were supported directly in unity.
OpenGL includes glBeginQuery and glEndQuery, and so I wondered if an interface was available to these functions, other than using the GL object.
Thanks.
Render queries are fast, right.
But no they don’t exist in unity, you would have to do physics raycast for anything where you want to check “visibility” on such granularity
Thats where my two option for doing it reasonably on the math level come from.
Camera 2 isn’t necessary. I use a portal mesh with ColorMask 0, in the background rendering queue. It is rendered with the main camera, which only clears the depth buffer.
Thank you, that is going to simplify/speed up my little portal test thing immensely. (I use a similar ColorMask 0, but completely forgot about using Render Queues).
yeah, and you need even more cameras to render the portals visible from other portals, like an infinite hallway. (This is because of a bug in unity where camera.render() doesn’t work so you need to use multiple cameras with different depth settings)
Also, the oblique frustum clipping has precision issues when close to the clipping plane. (besides what Ntero posted, you can also find a function to do this in unity standard assets: somewhere in the water scripts).
If you start to notice that you might not be clipping things properly (when the camera is very close to the clipping plane) you could try to use a clipping shader instead but that’s also going to be a bit of a mess.
The other approach would be to physically duplicate the worlds. This has been done somewhere in the forums by yoggy I believe. I don’t think it had too much depth though.
I would personally prefer the first approach.
I know from experience that this is true, but all you need to do is move the near face of the frustum slightly closer than the actual portal. Such small values fix this, that the tiny imprecision will never cause problems.
A more important problem is that when the frustum intersects the mesh, you see what is behind the portal. This kind of problem does not exist in the game Portal; I have no idea how they solved it. My best solution has been to make the portal a rigidbody, and teleport the player upon colliding with it. It’s not as clean as Portal’s approach, but has worked fine for me in practice. I wish I knew how to avoid that though.