What to do with an object that is split by one or more grid planes?
[/quote]

That is not a problem at all, I'll put it in both cubes, and then when i iterate over octree i just set a flag to visible for that object. No harm done doing it multiple times.

this:

octree->process(camera.frustum);
...// more work here
...
...
...
...
drawAll()
if(object.visible)
object.draw()

there is no redundant drawing only redundant copies of pointers.

The problem is that there is something wrong with my code for creating cubes.

Ok, but with your design you'd get the same or better performace with a simpler grid approach, because most objects will be in the small max level nodes.
The result looks more like a sparse grid, that you could clip with large cubes containing smaller cubes without the need of an octree... where's the win from the octree?
If if you use dynamic objects in it, it's slow - too much recursion, shared pointers and dynamic memory allocation... slow.

However, i can't see a bug in the code. Are you sure the frustum check is right?

where's the win from the octree?
If if you use dynamic objects in it, it's slow - too much recursion...
[/quote]
Its just for static objects since i have ~3000 in current scene. I am planing to mix this with hw occlusion query like in this article (someday if i can done coding right):
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html

For now i want octree done right if possible.

However, i can't see a bug in the code. Are you sure the frustum check is right?
[/quote]
I am going thru code for hours now and can't spot what else is wrong.
If i use frustum check with all objects bboxes culling works, but not with octree bboxes.

[quote name='SaurabhTorne' timestamp='1355753695' post='5011700']
Jim Adams book has a good octree sample. Might as well check it

What is the name of the book?
[/quote]

"Role playing games using directx". A very good book for starting with directx.

I still believe its a geometirc issue.
Are the missing objects popping depending on camera or do the never appear?
Did you check after the creation, if each object ist at least in one node?
Did you visualize the node extends, maybe one of the 8 cases has a bug?

For occlusion query it's good to draw objects in raw front to back order, even without occ. test that saves pixel shader due to early z-test.
To achieve that you draw objects by traversing the octree bottom down drawing the near child first.
Here the loose octree has advantage too, because front back order is more precise and you draw large objects (good occluders) first.
but its easy to try that after you found the bug...


Some other things you may or may not end up with later, just to keep in mind:
Node extends and position can be calculated dynamically while traversal, no need to store them for each node.
If you align the grid at integer coords, you can use brachless integer bitmath for very fast searching in the tree.
Mostly it's a win to either point to an array of 8 children (some of them may end up unused), or there are no children.

Personally i use it for the same purpose, but i have not made any of those optimisations listed above
But i did it with a software-renderer that used quadtreecompressed lightmaps, so each scanline was clipping a line into the quadtree,
and there i saw a great speedup.

Thank you very much for trying to help me. I am working on it today, and hopefully resolve this problem.

About cases, i think i got this right (i made a reference image in modeling editor showing one subdivision):


each bbox min is in lower left and max in upper right corner like in the picture? I mean they are min a max possible coords for bbox.

if(result)
{
sNode = nodes;
++cnt;
}

This adds the object to a vector, right? It looks like it replaces the current pointer with a new one, storing only one object at the end.
I'm noob with stl and c++11.



The image looks nice (min / max is good way to define axis aligned boxes),
but you need to visualize that inside your engine, to proof that its right.

I'd do this: Turn off Z-Test, traverse the entire tree, if a leaf is found, draw its slightly shrinked extends with a transparent color.
Build the color from the nodes memory adress, so you can see different nodes better.
For each object in the node, draw a line from node center to object center.

Afterwards draw all objects in wireframe. Navigate through the scene, and check if the objects are linked correctly to the nodes.
If an object has no line, or the line points to a node far away, you know more.

If still anything looks right, visualize the cameras viewing pyramid (to see that, you need two cameras, one to observe and one for yourself to fly around).
While traversing octree, draw nodes extends in white wireframe, if they fail the observeds cameras frustum check.

...that's some work, but you will surely see the bug - from another perspective - and then its easy to find it.
And its good for future bugs.

Found where the bug was.

In create function

_tree->vNode.clear();
for(std::size_t i = 0; i < 8; ++i)
{
child = std::shared_ptr<OcTree>(new OcTree(_tree->pSmgr, subdivide(_tree, i)));
create(child, curr_level + 1);
}


Should be:

_tree->vNode.clear();
for(std::size_t i = 0; i < 8; ++i)
{
_tree->child = std::shared_ptr<OcTree>(new OcTree(_tree->pSmgr, subdivide(_tree, i)));
create(_tree->child, curr_level + 1);
}


Damn recursive functions, should step back and learn again about them better.