hi, i've got into a little problem while the artists are building the world for my game...i have one huge scene, about 512x512 units, the problem is that i have 3 huge buildings with dozens of rooms and as the scene is building up, i'm estimating about 1 mil tris if not more. I'm curently using octree/frustum culling. Oh and another problem is that i cannot use haze..because in every moment i have to be able to see everything. BSP are also not an option and the whole scene is exported from 3DSMax as single texture meshes. Would ABT solve my problem in any way? Would portals solve my problem? Is there a way to add them in the current context? Should i take another approach? Thank you.

Probably portals and/or occlusion culling will speed up performance.I guess it would be better to assign the scene designers to place the portals by hand.Also,try using dynamic LOD if possible.

ok...but how could i integrate everything in a 3DSMax exporter? would this work for portals? : i have a box around the building/levels with a property and everything inside it it's 'linked' to it...and in the engine if i'm outside that box i don't render anything inside it..i know this isn't the real portals but wouldn't be a fast and effective way of doing it?

How about LODS? should i export more loded meshes for each object(mesh) and depending on the distance to render the appropiate one?

if you are thinking of using LODs, you have to find an algorithm to use to make switching between different LODs unnoticable.This should include determining how many pixels on the screen does each object take before switching to another LOD.I don't think this will be very easy unless you use occlusion query.
I think culling and visibility recognition is better. . You can use AABB but you should note that big objects that can contain another objects should be divided into more than one box . For example, for a room, each wall can be contained in a box (or more than one box if the wall contains holes or doors or windows), but for a chair, the whole object can be in one box.
by this method and using some sort of view frustum culling and visibility recognition, you can determine which objects are completely visible, and which objects are partially visible and which objects are completely invisible.
you can also do a quick render pass to fill the z buffer first before rendering to save you fill rate

how does this seperate renderpass save fillrate?


@pasman: in my engine i handle exterior and interior geometry this way

exterior == octree + frustrum culling
interior == some unique portal rendering technig which i am going to explain at the bottom

the interior rendering is related to PVS (potential visible set)
the difference is i don t perform CSG on my brush base geometry to get a solid mesh all i do is remove the polygons that are absolutely never visible

now since i use convex brushes to create my world geometry i can easily create handmade PVS with a punch of brushes

just take a room and add a brush with a pvs texture that covers all the polygons inside the building
you can use several brushes and link those together to a func_pvs in the editor. the engine itself doesn t treat it as a entity dont worry

now you have a PVS made up of convex brushes, and each PVS holds information about lights polygons ...

now to get the portals i place a portal texture onto those faces of the PVS brushes where i have a door or a window ingame

now when i link this pvsinto my octree i choose those portal faces that don t touch other portal faces(aren t identical to other portal faces)


i just store a pointer list of portals to the octree where each portal can be called a head/tail of a PVS (head/tail -> see linked lists)

with a proper implementation this method is absolutely one of the best i can think of

another thing i plan to add is static/dynamic antiportals

i gonna use these to cull wide range environments with complex geometry e.g.: 2 bombed out villages within the viewing frustrum but never visible cause they are blocked by some hills or large factories/walls

i do this on a node base

get the players view origin and a anti portal polygon

use this to set up a frustrum like you did with your view frustrum and cull all the geometry nodes which where left after frustrum culling

once this is done i do the pvs with those pvs that are left

this should give the mapper the possibility to design his world in every way he wants to with all the freedom indoor and outdoor engines offer just at much fast speeds

this is just about the culling part

the lighting system and the physique engine are another story which doesn t belong into this topic, just be sure you store your data in a way that you can use it for collision detection as well so you dont have to store several copies of the same data

in my engine this point doesn t matter, since i will never reach the system memory limit with my scenes but with 3dsmax as design tool this is a point to take into consideration

Quote:Original post by Basiror
how does this seperate renderpass save fillrate?

you should take a rendering pass to fill the z buffer with out any color calcuation or texturing, just rasterizing.
in the other rendering passes,you disable writing to the z buffer and only draw the pixels that have a z value equal to that stored in the z buffer.

and how does this save fillrate?

you need 2 passed instead of one

and you still need to read from the z buffer when rendering the 2nd pass

thanks for your replies, but why noone mentioned ABT? isn't it he best approach for space partitioning?

Also LODing doesn't have to be perfect i mean optimal, all i need to find is a good ratio object size/distance at which i change lod levels. wouldn't it work?