I decided to write a detailed post with some schematics to explain how portals work and how to use them.
Please read this post carefully to learn what you need to know about them.
Imagine the following situation. (please look at the diagram image attached, I will explain what's on it here)
You have an interior scene, with one small window.
In this simplified scenario, we have a simple cube, with one small window/opening, and a camera inside,
simulating a very simple interior setup.
The way pathtracing algorithms work (not directlighting/ambient occlusion),
is that a ray is traced, starting to the camera, which is sent into the room,
and arrives at the first intersection, being a point on a wall.
At this point, we need to trace a shadow ray to the sky, and if the ray is unoccluded (eg there is nothing blocking/in between),
the sky is visible on that location in the direction of the shadow ray, and we can include the environment light.
The orange lines are the rays of the path. The orange discs are the points where they intersect with the scene,
in almost all cases these will be locations on a wall of the cube, inside.
A path bounces around multiple times, so we can determine the full global illumination / reflections for the path.
You will usually get anything between 2 to 16 bounces (depends on maxdepth setting)
like this per path (eg this will be the path length).
To compute if the intersection points (orange discs) have any skylight arriving on them,
we need to randomly shoot a ray from the intersection point into a random direction,
and then, if that ray has nothing in between (eg it's not occluded), it will find the sky,
and we can include the skylight arriving from that direction.
If it's occluded, eg there is something in between, like a wall, the point does not receive any skylight from that direction.
As you can see in the left diagram, most of the bounces cannot find any skylight,
as most of the time, all the random shadow rays will be occluded, eg there is nearly always a wall between it and the sky.
Only when we actually, by chance, go through the small window, will the skylight be found, giving light.
As you can see in the diagram, a lot of computation is lost, as most rays contribute nothing.
This is very inefficient, eg it will converge slowly (you will require a lot more samples per pixel to get a clean render).
The diagram on the right gives a simplified picture of what happens when a portal is used.
A portal is placed in the window, eg a simple plane is placed in the window/opening, which covers the whole opening.
The normal of the portal must face inwards of the room, so the engine can know how to determine if it's going inside or outside (which we want).
As you can see, the intersections here do not shoot shadow rays into random directions anymore,
but, instead, they are shot through the portal.
Eg, we fire the shadow rays through a random location on the portal geometry (being a plane here).
It's pretty obvious that with this scenario, we provide help to the engine and nearly all of our shadow rays will find skylight now,
giving a much improved convergence, and less samples will be needed to get a clean render.
Using a propperly configured scene with portals, you can get a large speed up, sometimes 2 to 4x as fast.
I hope this explains things fully, if you have any questions, feel free to ask.
Here are a few additional things you need to know about when using portals.
* Portals are new in OctaneRender and are not %100 optimized and fully tested in the recently released 2.48 TEST.
Don't use these for production work, and please support us by posting your test results and any issues.
* Portals can only be used for scenes where you render geometry inside a space. (for now, this might change soon)
* If you use portals, you MUST cover all openings, eg if you only place portals on one of multiple windows,
the engine will always shoot rays through the window with the portal, giving incorrect results as the other windows will not pass light through.
* It's important that the normal is on the correct side, eg the engine will always shoot light towards portals,
when it can shoot the ray into the normal of the portal, eg the normals must point inwards.
* Currently, although this will change soon, you cannot place portals in openings which are not open,
eg a window with a portal cannot contain glass at this time.
* In some complex scenes and situations, portals might slow down the render, so a bit of experimentation with/without should be done.
* Portals only apply to pathtracing type kernels, eg pathtracing and PMC. (not directlighting/ambient occlusion)
* It is best to try to use the least amount of geometry for portals, eg only a few simple rectangular planes are best,
the more geometry your portals contain, the slower the engine might become.
* sometimes it is better to place one large portal over many small windows due to the above.
It's ok to make a portal larger than the opening, just make sure it closes/covers all opening(s).
A portal which is unnecessarily large will end up slowing down the efficiency, as some of the rays through the covered parts of the portal will not go outside the space.
* Portals, when defined with the portal material, will not show up in your render, eg this will be invisible geometry.
I hope this explains things for all the users who have not had any experience with portals in unbiased engines.
Note that updates to octane coming out during the next week will improvide portal performance/behaviour.
Win 7 x64 & ubuntu | 2x GTX480 | Quad 2.66GHz | 8GB