One possible approach I try to use in my engine:
Think about your game world as a database. Each object has set of properties, some read-only, some read-write. Some are stored with object, some calculated on-the-fly.
Then think what kind of queries you have to do with objects. For example rendering involves spatial queries like "list all opaque objects, visible from current camera location, that lie inside view frustum". For game logic you may need queries like "list all NPC characters that see given character".
For complex and frequently used queries you will build indexes - octree is a special kind of spatial index.
In your case I'd still attach bounding box to specific object - because it is spatial property of given object and it is used a lot. But object should neither be an octree node nor "belong" to octree. If an object has a single "true location" or "true parent" at all this should be level loading/caching system - i.e the part of code that can build and destroy object.

A virtual base 'Drawable' class isn't a great design here because it couples drawing with culling, but also because it makes the culling system responsible for the order in which things are drawn -- most renderers should have the ability to sort draw-calls themselves for correctness (e.g. transparents after opaques), special techniques (e.g. offscreen passes) or performance (e.g. reducing state changes).

There's no best way to do this, so here's some ideas as food-for-thought --

If you were going to have a virtual 'Drawable' class, I would re-design it so that it doesn't actually draw anything, but instead adds itself to a draw-list that can later be sorted and drawn by your renderer.
e.g. something (pseudo) like:
vector<RenderItem> toBeDrawn;
foreach( o in visibleObjects )
o->AddRenderItems( &toBeDrawn );
Ideally the culling system would know only about occluders and object bounding volumes, and not know at all about drawables.
However, you could break this idealism a small amount by having Cullables know which Drawables exist within their bounds, but not actually draw them. After determining the visible set of cullables, you can then iterate through them to find the list of visible drawables.
e.g. (pseudo)struct Cullable
{
Aabb bounds;
vector<Drawable*> drawables;//the drawables that are linked to this bounding volume

};
vector<Cullable*> visCullables = GetVisibleObjects();
vector<Drawable*> visDrawables;
foreach( v in vis )
{
foreach( d in v->drawables )
visDrawables.push_back( d );
}
Render( visDrawables );

To make the culling system fully unaware of the rendering system, you could reverse the above, so that each renderable item instead contains a link to the cullable region that contains it. You can then test the visibility of each cullable to obtain a big list of 0's/1's indicating which regions are visible. You can then iterate all renderables and test whether their cullable is true or false.
e.g.vector<Aabb> boundingVolumes = ...;
struct Drawable
{
int aabb;//an index into the above vector
...// other data - e.g. mesh to be drawn, etc...
}
vector<Drawable> drawables = ...;
vector<bool> visibleCullables = GetVisibilityFlags(boundingVolumes);
vector<Drawable*> visDrawables = ...;
foreach( d in drawables )
{
if( visibleCullables[d->aabb] )
visDrawables->push_back(d);
}
Render( visDrawables );

scene graph that contains list of the base classes

Can you describe this? "Scene graphs" have a bad name in the industry and can be the root of inefficiencies and coupling problems... Also, using inheritance should be pretty rare, so if you've got many things inheriting the same base class, it could be part of your problem.

I'm thinking if I should make a specific kind of scene management system for the meshes and a simpler one for all the other kind of objects.[/quote]Is scene management the same as your culling/visibility management system? If so, then once you've de-coupled culling from rendering, then you won't have a scene for meshes/particles, you'll have a scene for culling objects.

except that I'm not entirely sure if indexes to vectors should be the way to implement it.[/quote]It's just pseudo-code to get some ideas across; the indices could well be pointers if you preferred.

You are correct, it is not.
Leave behind any thoughts about a scene for now and think only inside a little black box that represents a model.

Any model, drawable or not, has some form of bounding box, perhaps optional collision data, and probably vertices, perhaps in pool form or perhaps expanded. At this point we don’t care what the purpose of the data is. Collision detection? Rendering? Who cares. We now have CModel.

Now we want to render some of those. Enter CDrawableModel : public CModel.
CDrawableModel introduces a concept completely foreign to CModel: graphics.
It creates vertex and index buffers for all the parts of the model (using smaller classes to organize each part of course) and holds shared pointers to the shaders it needs.

Notice, though, how these objects manage themselves. Having a scene module handle this will be a mess when you introduce particles, terrain, etc. Each new type of object has a special way for drawing itself, and trying to put all these special cases in one spot will be unmanageable and fast.


Another point is that the above classes are shared. They contain the raw data that instances use for rendering themselves. With that said we can get out of the box and think about scenes.

A scene knows what CActor or CEntity is.
It isn’t bothered when it receives a “CModelInstance : public CActor” or “CDrawableModelInstance : public CModelInstance”.
It only needs to have a method for determining if something can be drawn at render time so it can cast it accordingly, or else you end up with CActor having an interface for every possible type of functionality that everything inheriting from it will ever need.

Time to render.
Run through your oct-tree and gather only renderable objects into an array. An array that avoids constant re-allocation by always growing and never shrinking. Pointers to the objects are gathered.
Models are composed of a bunch of smaller meshes, and each mesh may have multiple vertex/index buffers. These little parts are what you actually gather.
Opaque parts go in one list, translucent in another.
Sort the list by fewest major render state changes for opaque. Swapping textures and shaders are the 2 things you want to avoid most, so make them high on your priority list.

Objects should then render themselves in that order. The scene manager/module has no business rendering for others. It simply pulls the strings orchestrates the render process from a manager’s point of view. That’s what managers do. They boss people around but the people have to do their own work.


L. Spiro

Ok, maybe the methods of CDrawable could have GLint *loc as argument to pass arbitrary shader locations. These would then be also passed to drawDrawables function. But let's say that the drawables in question want to implement object space normal mapping. Then they require the object space camera and light positions, so these transformation would have to be done in drawDrawables. In what kind of abstractions could these be included in the CDrawable? It gets messy.

In my engine I made the actual draw call a virtual method of Material object instead of Mesh object.
I.e.
Mesh::display() calls scheduleRender, the latter appends small RenderData structure to render list. RenderData contains links to index and vertex buffers, backlinks to mesh and material, sorting keys and some other data
After sorting etc. a Material::render is called
The reason is, that only material instance (which manages shaders) knows, what actual data it requires (vertexes, normals, texcoods, colors, all kinds of matrices, special textures, lights, reflections, sky, aerial thickness etc. etc.)