Leadwerks Engine - portal system

Community Forums/Showcase/Leadwerks Engine - portal system

JoshK(Posted 2006) [#1]
The last couple of days I was working on a brush slice routine, and cutting brushes up within whichever portalzones they resided in. The portal system is pretty much like UT2004's. You can see what UT2004 does if you open the console and type "rmode 1", 2, 3, 4, etc.

My portal system uses brushes designated as "portalzone" entities. Brush geometry is cut up and collapsed into single meshes within the portalzone. If the portalzone is not in the frustum, none of the contained geometry is drawn. If a portalzone has a portal that lies along any of its surfaces, it is only visible if the portal is visible. The portalzone is only visible through the visible portal, so all portalzone geometry not visible through the portal is clipped. All outdoor/non-portalized geometry in the scene is considered to be a part of the default "virtual" portalzone. I have it set up so the outdoor portalzone will automatically connect to any one-sided portals (a portal only touching one portalzone), which are taken to mean there is a transition from outdoor to indoor areas.





This room is full of meshes, but most are not visible through the portal in the entrance, so they get hidden. There are just as many shelves on the right as there are on the left. Also notice the brushes on the ramp are clipped to the portal edges. You are viewing in wireframe, so nothing is being obscured from view; the brush geometry is actually clipped.



Erroneouss(Posted 2006) [#2]
Cool :]


Amon(Posted 2006) [#3]
Nice. :)


puki(Posted 2006) [#4]
Yeh - looks good.


Regular K(Posted 2006) [#5]
Cool, I assume this is B3D?
I was just wondering, does B3D render stuff not remotely visible on the screen (like stuff out of the field of view)?


Gabriel(Posted 2006) [#6]
Cool, I assume this is B3D?

I'm pretty sure it's his open OpenGL engine.

I was just wondering, does B3D render stuff not remotely visible on the screen (like stuff out of the field of view)?

Depends on your definition of remotely visible. It does cull entities but somtimes they can be considerably out of cameraview and still get rendered. IIRC this is because it uses a frustum sphere to determine whether things need to be rendered or not. Fast, but inaccurate. It's better than nothing.

Anyway, what portals do is hide things that *are* in the field of view but are obscured by other things. It really only suits certain types of games ( first person perspective mainly ) but it's quite effective within those genres.


JoshK(Posted 2006) [#7]
It suits any game with a camera and more polygons in the scene than you want to render each frame. The portal visibility is recalculated each frame, and takes 0-1 msecs in this scene.

Culling is precise down to a model's bounding box. The engine actually creates a hidden brush object (like in 3D World Studio) around each model, and tests it for intersection with the camera frustum (a pyramidal brush with the apex at the camera position).

Occlusion culling isn't always important for rendering plain triangles. A lot of graphics cards could handle the non-portalized scene. Portals do make a huge difference when it comes to updating objects and calculating things like shadows, lighting, physics, etc.


Wiebo(Posted 2006) [#8]
Looks cool! Are portals still valid with the amount of raw power the current GPO can throw at drawing the polygons? How much do you win with this, Halo?


JoshK(Posted 2006) [#9]
Well, if your card can draw 200,000 polys at 60 FPS, if you have the scene portalized, you can use a 1,000,000-poly scene instead. There will always be a point where the scene gets too big, and you need to dimiss areas that are offscreen, occluded, or very far away.

I think current GPU abilities are a little overstated/misunderstood. They might be able to do x,000,000 polygons per second, but when you add textures and separate objects into the equation, everything slows down. I don't see portal occlusion going away any time soon.

There are also a lot of updating routines that are slower than just rendering triangles. Dynamic lights and shadows are rather expensive routines. If you can cut the number of faces those need to be performed on by 75%, obviously there will be some speed gains.

Of course for simple scenes, no portal system is needed. This is designed to support more demanding scenes.


Ross C(Posted 2006) [#10]
Portals don't really require much processing time at all. I don't really see any disadvantages to using them, except from setting them up. As halo says, why draw things that aren't on screen, or really far away. Good work :o)


boomboom(Posted 2006) [#11]
What si the leadwerks engine? Will it become a 3D module engine for Bmax, or a standalone product?


Red Ocktober(Posted 2006) [#12]
and... the inevitable question... when...

:)

--Mike


Gabriel(Posted 2006) [#13]
It suits any game with a camera and more polygons in the scene than you want to render each frame. The portal visibility is recalculated each frame, and takes 0-1 msecs in this scene.

Really? Well I'd certainly like to see a demo of it working on a large, complex scene, with outdoor areas. If it could do a good job there, it would certainly be impressive, since all the engines I've seen which use portals are only doing it for relatively simple indoor scenes.


jfk EO-11110(Posted 2006) [#14]
The portal visibility is recalculated each frame, and takes 0-1 msecs

That's indeed impressive since the calculation of visibility is a slow process by nature. Personally I was using precalulcated VIS lists for that purpose. I have to say, even with the lists ready, my engine was slower when it used to hide/show the clusters or portals each frame based on the VIS lists, compared to when I simply broke up the map in portals and let blitz cull as good as it gets (camerarange, fustrum culling etc.)


JoshK(Posted 2006) [#15]
It's fast because you start with the portalzone the camera occupies and work your way outwards in a recursive function. You can usually only see 1 or 2 portalzones away, so as soon as the portals start coming up as being occluded, the function returns. I haven't seen a need for any precompiled vis data, other than splitting the geometry up into portalzones.

Of course, in some situations using portalzone occlusion would actually slow the scene down. It's all about how you set the portals up, and how many polygons and objects you want the world to consist of.

3D World Studio 5.47 comes with an example scene of a large warehouse complex. This is probably the most demanding kind of scene you can render, because it combines large areas of terrain with high-poly interior structures. I set portalzones up inside all the buildings, and added portals at the building entrances. Then all the objects inside the warehouse structures only have to be drawn if the entrance to that building is visible. The speed gains are definitely worthwhile, even when no dynamic lights or shadows are being processed.


Mustang(Posted 2006) [#16]

I think current GPU abilities are a little overstated/misunderstood. They might be able to do x,000,000 polygons per second, but when you add textures and separate objects into the equation, everything slows down.



Yup. And you can bring down even the fastest cards on the market just with 100 polygons - try to draw them so that every polygon fills the screen and is on top of each other... that will fill the screen 100 times over per frame and as you can guess the fillrate needed is massive and will kill your speed totally.


jfk EO-11110(Posted 2006) [#17]
>>...and tests it for intersection with the camera frustum (a pyramidal brush with the apex at the camera position)...<<

I don't get it. What happens when the object hull is completely encapsuled inside the pyramidrical brush thing?

and will it be rendered even when it's occluded by a wall that is in front of the camera?


JoshK(Posted 2006) [#18]
I don't get it. What happens when the object hull is completely encapsuled inside the pyramidrical brush thing?

If the object bounding box intersects the frustum volume at all, the object is rendered. My intersection test returns "true" is one volume encapsulates the other one, since they are considered solid objects.

Most of the time, an object occluded by a wall will not be rendered. There are portals that you see through, and antiportals that act as occluding objects. Not every single wall is considered an antiportal; it's easier just to set up a few portals.


Ross C(Posted 2006) [#19]
Yeah, portals need to be used and set up properly, or else it's more trouble than it's worth. The way i'm setting up my portals, is making small passageways, witha trigger at each end, telling the engine to show hide the other side.


Picklesworth(Posted 2006) [#20]
This is why I should never do a first-person game...

This looks like a very smart engine!

Do you think it could ever be possible for a program like 3dWS to calculate portals automatically?


JoshK(Posted 2006) [#21]
3DWS will use the same exact engine, so portals can be calculated and displayed in the editor.