Portal Rendering - How far is Irrlicht?

L o · Post by **L o** » Fri Apr 17, 2009 6:00 pm

Hey,

I have heard of a project which lets Irrlicht use portal rendering:
http://irrlicht.sourceforge.net/newsarchive.html
The project was said to be unfinished in Nov 2003. How far is it now?

Anyway, if I would like to do my own portal rendering, would two rooms need two meshbuffers in every case? Do I have to inherit the default meshbuffers to let them have portals?

Thanks in advance,
Lo

hybrid · Post by **hybrid** » Fri Apr 17, 2009 8:47 pm

Maybe Niko still has the code, but I don't know if it's still useful. But there was some kind of portal code in a very recent thread. Anyone for search?

christianclavet · Post by **christianclavet** » Sat Apr 18, 2009 1:11 am

Wow! That is on the drawing board since 2003! Maarten Bosma seem to have dropped on doing that.

It's not implemented on the current release, and I doubt it will be on the next release.

But a lot of people right now seem to put great interest on having this. Hope it will not go down as it did. Seem that it was more difficult than they anticipated. Today there is more documentation on the technique.

For proper VIS info to be create there is a need of some kind of tool to process the VIS info. I really don't think this can be created in realtime. Reading Quake 3 vis info from the BSP file could be a first step. Right now IRRlicht can read Quake 3 files, but don't take and process the VIS info from them.

IRRlicht developpers have advanced a lot since the last version, since now we can load Quake 3 shaders, and I think MD3 mesh support as been improved (with a lot of other things)

Here is some link from the forum:

MD3 mesh support with shaders:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=31814

IRRlicht occlusion culling:
ht[url]tp://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=28913[/url]

Katsankat implementation steps for occlusion culling:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=31780

And I think there is more...

Frank Dodd · Post by **Frank Dodd** » Sat Apr 18, 2009 10:11 am

I'm no portal expert so don't take this as gospel

but ... if someone said to me 'Irrlicht' and then 'Portal' I would say 'Render to Texture'

I would probably support it by rendering to a texture and then mapping that texture onto my portal object. I would probably use the same technique for video camera monitors, mirrors and 3D object based user interfaces.

hybrid · Post by **hybrid** » Sat Apr 18, 2009 10:30 am

There are two kinds of portals. One is the graphical element as known from the game with a portal gun where you can step through, but also see through into completely different places of the scene. Such add-ons have been made for Irrlicht several times already. We could put one of them into irrExt if someone could point me to a working one.
The second kind is a rendering optimization, where geometry outside of a room is only rendered if it's visible through some "portal" such as a door, a window, or a corridor. This visibility information needs to be precalculated for proper speedup, and needs to be handled by the culling algorithms.
The latter was asked for in this thread.

L o · Post by **L o** » Sat Apr 18, 2009 6:04 pm

Yep, I asked for the second thing.

Thank you for the links, but most of the projects where dead or windows-only-binaries.

The portals are specified in the format I loaded. Could you please tell me just where to start with the rendering algorithm?

christianclavet · Post by **christianclavet** » Sat Apr 18, 2009 7:40 pm

Hi, Lo.

Googled and found this:

http://www.flipcode.com/archives/Buildi ... tion.shtml

Here is an university esay talking about PORTAL rendering method they've worked on. Check on the implementation section of the document
http://liu.diva-portal.org/smash/get/di ... FULLTEXT01

puh · Post by **puh** » Sat Apr 18, 2009 8:13 pm

Electron was developed full working version of portals for irrlicht and later added pvs (potentially visible sets)
I successfully implemented his portals into my small demonstration application.
Here is link to the forum treads (its very old - 2005):
portals: http://irrlicht.sourceforge.net/phpBB2/ ... php?t=5192
and
pvs: http://irrlicht.sourceforge.net/phpBB2/ ... php?t=5707
though downloading still working:
http://crucibleofstars.sourceforge.net/ ... dering.zip

christianclavet · Post by **christianclavet** » Sat Apr 18, 2009 11:41 pm

Wow! Thanks.

I've downloaded that source code and checked the thread.
Is there a PVS tool? Would you think that code will be hard to adapt to the new IRRlicht version?

hybrid · Post by **hybrid** » Sun Apr 19, 2009 12:01 am

The tool is linked in the second thread. The code shouldn't be too hard to port. It might make sense to diff those sources against the portal rendering system in lightfeather, since electron is now working on that engine.
But if someone comes up with a working example with this code it could have good chances to be included into the engine. Maybe it should me more decoupled from the basic scene node interface and just rely on the portal manager somehow...

Katsankat · Post by **Katsankat** » Sun Apr 19, 2009 7:15 am

In some engines, portalling is a task dedicated to the level designer. HINT brushes for quake engines

hybrid · Post by **hybrid** » Sun Apr 19, 2009 9:42 am

Yes, that's why some external tool is (almost always) necessary. Just as in this case.

shadowslair · Post by **shadowslair** » Sun Apr 19, 2009 10:17 am

Hmmm... This may become useful. In fact, it is sth I intended working on in the near future.

Implementing such culling methods in Irrlicht would be nice.
Will take a better look when I have some time. I checked the code in a hurry and here`re some questions I ran through:

1) The level is loaded from a .X if I`m not wrong. Where do we set the portals? I saw that when loading the level we`re splitting the level to 20 sectors. Are these used for portals?

2) How can this be used for a .bsp, and isn`t there a way to use its own (.bsp`s portals)?

Mel · Post by **Mel** » Sun Apr 19, 2009 10:33 am

QIII had its own portal system. Although it would be nice to have irrlicht to be able to use that info too, wouldn't it be just turning Irrlicht into a QIII engine subversion? Just my paranoids, don't pay much attention to this.

But Irrlicht needs a portal occlusion system, imo, and for more than the rendering itself. Perhaps, Collision detection would find benefits of this too, if collision could be restricted to the implicated areas, it would be accelerated quite a lot. Besides, putting each section into their own set of Mesh buffers, could keep everything in Video, saving memory bandwidth, and speeding things up even more.

In Torque, the portals were done using special brushes, same as in Unreal Engine 2. Some polygons were flagged as "portal" Perhaps a special texture name, in a square polygon, but these engines have something in common, their levels are preprocessed, something that Irrlicht doesn't do, for the moment. I say that for portal Occlusion techniques, Irrlicht should have its own format for levels.

christianclavet · Post by **christianclavet** » Sun Apr 19, 2009 5:12 pm

Yes, and why don't we use the BSP format, for IRRlicht need?
Meaning using the BSP file structure, but compatible only to IRRlicht. This could be a nice binary SCENE format for IRRlicht.

We could use tools like IRRedit to put the lightmaps, and the portals inside the IRRlicht BSP file. This file could be loaded as a scene inside IRRlicht.

Since we have VBO now; when a zone is determined, this zone could be send to the VBO, and changed only when we enter a new zone. This would be even faster.

As another extras of using BSP:

We could later add features to the BSP like for example a KEY (encryption). We could use also the ZIP library to compress the meshes inside the BSP, Create Cubemap reflection and skybox images inside, etc. Since it's IRRlicht own format.