Sign in to follow this  

Huge scene issue

This topic is 4859 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
You need to treat your interior and exterior differently. If the camera is outside a building, you shouldn't bother rendering the rooms and furniture *inside* it, period. At most render the bottom floor, that can be viewed from outside, but ONLY if the door is visible, of course. Portals are a good approach to this. Treat your building as an object in relation to the outside world, and if it's visible, check the portals to determinate visible rooms.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
It doesn't strictly save fillrate (since you actually fill more pixels), but if the second pass uses complex shading, it can be a win since you can save a lot of shading ops (and therefore increase effective fill rate).

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Quote:
Original post by GameCat
It doesn't strictly save fillrate (since you actually fill more pixels), but if the second pass uses complex shading, it can be a win since you can save a lot of shading ops (and therefore increase effective fill rate).


oh yeah thats logic gonna implement this in my engine since i am doing everything 100% with shaders and use up to 16 texture units this definitely should increase my performance

Share this post


Link to post
Share on other sites
think about this post depth map rendering with complex shaders a bit i came to this conclusion

you render the depthbuffer first and then render the scenes with all shading processes you need

you could further more optimize it when you sort your polygonal meshes by the distance from your camera

e.g.: you have a octree with 8 subnodes

find the visible nodes and add them to a render list

when adding them to the render list sort them by distance from the camera

thus you render the nearest first and avoid and depth buffer writes for overdraw pixels


of course this method only works when your meshes are high polygonal since CPU processing time might be quite a bit higher
since i use linked list i just gonna add a distance variable to the meshes which is updated at runtime

Share this post


Link to post
Share on other sites

This topic is 4859 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this