IrrRPG Builder

Welcome to IrrRPG Builder Forum!
It is currently Tue Oct 24, 2017 11:28 am

All times are UTC


Forum rules


Welcome to the forum. In order to make your stay as pleasant and constructive as possible please take your time to read through this document, it will help you navigate the pits and traps this community has created for new members ;) These rules can be changed without notice though normally we announce changes via announcement in all the forums.

1) Do not spam. No blatant advertising.

2) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature (e.g. anything you don't own and/or have downloaded), asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.

3) Multiple registrations are prohibited and are grounds for immediate account deletion.

4) The official language is English. English is the only allowed language.



Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Octree culling
PostPosted: Wed Jul 06, 2011 2:24 am 
Offline
Founder
Founder
User avatar

Joined: Tue Nov 30, 2010 8:08 pm
Posts: 57
Location: ParanĂ¡, Brazil
Ok, this a little (really big for me) improve in the irrlicht engine, i really don't like the limited frustum of IRB camera, and i want to see irb games with perspective cameras, not only top view. One of limitations of the irrlicht engine at the moment is the bad culling management, so i decided to create my own algorithm to do this.

I've based my technique on classic octree and culling methods (found in published articles).
The correct way to cull objects is remove them from "to draw" list in the scene manager, but this is not possible without recompiling the engine, and unfortunately the ISceneManager class cannot be extended (there is no way to replace the scene manager with an extended class, and if exists a solution i did not found it). So my technique just sets nodes as invisible (setVisible(false)) for now.

The frustum culling is the classic axis-aligned-bounding-box <-> camera frustum (aabb) check.
The building of the octree structure is the more complex step and this i've made by myself, i'll try to explain my technique:

at start the octree structure is empty, with a little empty (1,1,1) sized box.
Each time i add a scene node to the structure the algorithm checks if it is smaller of bigger than the root:
- if the new node is smaller then we need to subdivide the root (or use an child if the box is already subdivided) and recursively until we reach a point that the node is bigger than a half of the box, or the node is intercepts the child.
- if the new node is bigger then we need to expand the octree up, creating a new double sized node and recusively expanding up until the size of the node is smaller than the root box.

current limitations:
- only static objects are compatible with this octree, i plan to code a solution for dynamic objects ( if an object modes, rotates, change scale his bounding box needs to be updated to correct octree box ).
- For now you can only add objects to the octree, not remove, but this will be fixed soon.

this will be clear with the source code..

Performance tests:

Hardware: C2D 1.8Ghz, 3Gb Ram, nvidia 9500 512Mb laptop.
Software: Kubuntu 11.04 x64

3600 cubes, random scale and grid position.

Without octree: ~5fps in most of scene
With octree: ~5fps when showing all cubes, ~60 fps when showing little parts of scene (culling most part)

Time to create the structure: ~15 sec

this is just the first tests, i'm sure there's lots of things to improve and we can get better results putting this structure directly on the irrlicht scene manager.

here are some screens:


Attachments:
File comment: First implementation.
Andres_Irrlicht_Octree.tar.gz [8.45 KiB]
Downloaded 205 times
File comment: structure debug 2 (split screen)
octree2.jpeg
octree2.jpeg [ 97.57 KiB | Viewed 8869 times ]
File comment: structure debug 1 (split screen)
octree1.jpeg
octree1.jpeg [ 73.34 KiB | Viewed 8869 times ]
File comment: structure debug 3 (split screen)

cubes drawed out of the camera frustum are in the interception of boxes, so they need to be stored in an upper level.

octree3.jpeg
octree3.jpeg [ 56.59 KiB | Viewed 8869 times ]
File comment: piece of the 3600 cubes scene without octree ~5fps
octree4.jpeg
octree4.jpeg [ 30.84 KiB | Viewed 8869 times ]
File comment: piece of the 3600 cubes scene with octree ~40fps (60 in fullscreen)
octree6.jpeg
octree6.jpeg [ 40.26 KiB | Viewed 8869 times ]
File comment: entire 3600 cubes scene
octree5.jpeg
octree5.jpeg [ 57.22 KiB | Viewed 8869 times ]
Top
 Profile  
 
 Post subject: Re: Octree culling
PostPosted: Thu Jul 07, 2011 2:55 am 
Offline
Developer
Developer
User avatar

Joined: Sun Dec 05, 2010 6:32 pm
Posts: 554
Location: Montreal, Canada
Cool. Have you tried to combine the meshes into a single node? This could also help the GPU process faster the scene.
Is there a improvement overt the IRRlicht octrees?

For the current IRB camera, It is ok (for me) to have this one at the moment, as later I would like to offer a choice of camera types (the current one we use is similar to a RTS type rig).

We could define 3rd person view perspective with variants and a FPS type one. The things to account for the most is the control types for all thoses setups. We should investigate how we could incorporate "intuitive" controls for thoses types. The other view would have to account also for the camera collision with object and perhap even change position when the view is occluded.

Also when in editor mode we should implement a variant of the "maya" camera, so it's easier to model the terrain and place the objects.


Top
 Profile  
 
 Post subject: Re: Octree culling
PostPosted: Thu Jul 07, 2011 8:29 pm 
Offline
Founder
Founder
User avatar

Joined: Tue Nov 30, 2010 8:08 pm
Posts: 57
Location: ParanĂ¡, Brazil
i think join all scene nodes into a sigle is not good, this way we will get an sigle node and that is not the main idea of the octree and disables the culling. Maybe i can join all box nodes into a single one, this way if an octree box have many nodes these will be joined, and we keep the octree properties (in fact thinking now its a very good idea, hehe).

About other camera styles they are just new possibilities we could have with a good scene management.

@serengeor from irrlicht forum suggested an existent OctreeSceneManager (found here: http://irrlicht.sourceforge.net/forum/v ... =9&t=38987). Looking to this one i've saw good and bad things, i'll try to implement the good things on my algorithm, and i need to test this other.


Top
 Profile  
 
 Post subject: Re: Octree culling
PostPosted: Mon Aug 01, 2011 1:01 pm 
Offline
Founder
Founder
User avatar

Joined: Tue Nov 30, 2010 8:08 pm
Posts: 57
Location: ParanĂ¡, Brazil
I'm testing Daniel Sudmann's code and it seems to be very good. Maybe we can use it :D

edit: uploaded my source code (check first post).

edit2: :( unfortunately the code is a little slow, rendering the 3600 scene at the same point as octree6.jpg (check first post) i've got only 10fps (on my code the same scene runs at 60fps). But liked the code, i think we can join the good points of each implementation and create a new and stable octree. I'll try to contact Daniel Sudmann to discuss this.


Top
 Profile  
 
 Post subject: Re: Octree culling
PostPosted: Tue Aug 02, 2011 3:47 pm 
Offline
Developer
Developer
User avatar

Joined: Sun Dec 05, 2010 6:32 pm
Posts: 554
Location: Montreal, Canada
Cool!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group