Occlusion and portals

#1 The interior engine is BSP based. Like Quake II, in addition, to BSP culling, it also supports portals. So you can add portals as needed to additionally optimize performance. You can't cheat the portals, though, without cheating yourself - adding see-through areas will require more portals. On the other hand, the interior system is pretty robust, and supports level of detail, so you should be able to find a good balance between segmenting your interiors and framerate... And of course, you have the source, so you can always add more exotic LOD to meet your needs!

3space, or "the mesh engine" is used for rendering shapes in-game, such as players, vehicles, projectiles, trees, etc. There is also a terrain engine, which is optimized for rendering large-scale terrain.

Torque has unified lighting, so shadows cast properly between objects. I would strongly suggest finding a better solution than close clip&fog for visibility management; nothing makes a game feel fake quite like that approach. ;)

There is a new demo for Torque under production right now. It's really nice. :) It should be released soon.

#2 Yes you are missing something, the interior parts, .difs, are CSG / BSP based structures just like Quake. The manual portal stuff is to tie it to the exteriors. The things that is missing is all the entities that Quake and Quake derivied games have like all the func_entities. So don't expect to do anything nearly as complex as you could with Quake or Half-Life that requires use of any func_XXX anything. from a functionality standpoint, interiors are probably one of the weaker aspects of the engine.

There are some really good tutorials on building interiors on the web I foroget what the site is, but there was a site dedicated to interiors.

#3 @Ben: Thanks for the reply. You might want to add that word "BSP" to your main features list (such as "BSP based interiors with Portals" rather than the current "Portal based interiors").

The "cheating" I'm after is to get a detailed, fast running level that "looks" like its open-topped. For example my GTA3 style level with buildings densly placed around you, or a complex zig-zagging valley (with concave bits in it before you suggest the TERRAIN(edit) thang).

The BSP process would see these types of levels as one big expanse as they don't "know" I will never get into a flying position that would see it all.

I think what I need is the ability to have transparent walls which are still considered solid by the BSP process, so I can transparently "seal up" the tops of sections. Can this be done?

Chris

P.S. Looking forward to the demo! I'm happy to test it and offer early feedback if you like.

#4 I think you're confusing mesh with terrain. Anyway, you can do concave terrain (caves, etc) by opening a whole in the terrain and putting an interior there. Tribes 2 did that if you want to see it in action.

#5

Quote:
I think what I need is the ability to have transparent walls which are still considered solid by the BSP process, so I can transparently "seal up" the tops of sections. Can this be done?

No need. Torque interiors do not 'leak' like quake and half-life levels. This allows the player access to the terrain (by way of holes in the interior).

John.

#6 Actually, some of the info presented here is wrong.

The interiors only use BSP for collision, *not* for visibility.

With quake-like levels you typically walk the BSP tree to find your location and then read out a list of which of the other "leafs" are visible from there (typically a compressed bit array) and then render all of the geometry contained in those leaves. This visibility info is generated when the map is compiled and (if detailed enough) can virtually eliminate overdraw. Unfortunately, TGE doesn't use this system.

TGE splits the interior up into "zones". These are rooms/areas that are sealed with "portal" brushes (must be leak free). When TGE renders the interior, it tests to see if any of these portal brushes are visible. If the portal brush is visible then any zones attached to it have all of the geometry inside it rendered. Sadly, this is only a manual process which means if you don't zone your interior then all of the geometry in it is rendered (possibly a lot of overdraw). Even with a properly zoned interior you are going to get a certain amount of overdraw (which is part of the reason TGE interiors are slower than quake-based ones).

As far as your GTA-like levels take a look at this: tork.zenkel.com/index.php?module=My_eGallery&do=showpic&pid=55&orderby=dateD

To do a GTA-like level you are going to want to split your buildings up (instead of one big level) and assemble them in the mission editor (one advantage is that you can reuse buildings with different scaling/transformations/rotations). You are going to want to zone off the insides of these buildings (using standard quake-based tricks like having twisty halls and walls that block the view just inside the doors and windows). You are also going to want to heavily LOD the buildings (if the building is relatively distant away you don't even need an inside!).

#7 Yeah, I think Matt is right... it doesnt look like TGE uses the BSP tree or anything else for advanced occlusion culling... either you extend the engine (using occlusion horizons, etc.) or you have to "cheat" where you can... use different LODs for all your buildings, work with city skyboxes, have your "decorational" buildings as simple "blocks" (and even LOD those), etc.
as Matt stated we are working on a GTA-like environment, check out some more pics here:
Project:C.A.
As of yet, we try to go with the "cheating" approach and therefore every building has up to 5 diff. LODs, etc. (mainy of those will be available in "content packs" soon, btw., if you need something to test with... ;))
beffy

#8 Matt is right about the visibility stuff, it is Portal and LOD only it seems, especially when running the debug modes. There was an interesting thread at one time about making cities and doing visibilty culling on .dif objects from the terrain. The person basically added some code to remove .difs that were completely hidden behind other .difs.

For a densely packed "downtown" that along with LOD might suffice. Since most of the "buildings" will occlude all the other buildings. For height you could split the buildings vertically so that the tops middles and bottoms were differnt .difs for say skyscrapers, that way the parts that were completely hidden could excluded and still get the tops.

#9 Thanks guys, I think we've cleared this up. But it brings me back to my first quiestion

Quote:
...say I wanted to do a GTA style game, which has buildings in a simple street block layout and you travel only on the floor. Assuming its all done with the interior engine (so I can get some occlusion speed) would I be able to portal at each entrance to a street, with them presumably reaching up to an invisible roof (I understand portals need to seal an area, so can you make a sealed area look open with clear textures)?

So can I use invisible walls to seal up a section so that the portal occlusion will work? Or do I have to do something else?

Chris

(btw I'm not doing a GTA style game, but it serves as a good example)

#10 Forget invisible walls, unless you need collision. Just use more portals.