Two bugs...

[3TATUK]

I *really* don't mean to crosspost, but this was probably better to be posted here: http://irrlicht.sourceforge.net/forum/v ... =4&t=49355

[3TATUK]

Does this maybe have something to do with it?

// the additional mesh can be quite huge and is unoptimized
const scene::IMesh * const additional_mesh = mesh->getMesh(quake3::E_Q3_MESH_ITEMS);

Is there any fix for this?

[3TATUK]

Hm, so I just found this at the bottom of CQuake3ShaderScene.cpp

setAutomaticCulling( scene::EAC_OFF );

commenting that out makes it behave "somewhat" better. If I stare out to space, it goes from 70 to 100 FPS... and if i fly beyond the map bounds and look out its 500+... but that's not much good...

I guess this is probably as good as it gets? The whole octree system is just for frustum culling, and not actual occlusion... which means if you're staring at a wall that goes through to the other side of the map, your FPS is shot.

There's really no actual occlusion culling like what's done in quake or similar? They use a combination of the BSP architecture and precomputed PVS to limit renders tris to just what's visible.

I think that would be a major win for irrlicht, over, ie, OGRE, or even other more fully-featured engines panda3d, horde3d, etc.

Does anyone know of a decent way to do this with existing irrlicht "plugin" code or similar?

Thanks

[hybrid]

Not sure what quake versions did, but Irrlicht has no automatic occlusion culling. That's correct. Since octree node uses some low-level handling of the vertices, it wouldn't even benefit from general approaches anyway. But you could try to use hardware buffers instead of software octrees. IIRC, this can currently only be enabled via compile switch in octree sources. In many cases, this leads to much better performance.

[hendu]

The PVS is not much use, as it would not work with hw properly. Sending visible verts over and over by the cpu is not a good way to go in the 2000's

[3TATUK]

quake's "occlusion" was PVS. that's what i meant. so it's not real occlusion because triangles in front of other triangles don't actually trigger those triangles behind them themselves to be hidden, but they *are* hidden regardless, because of the PVS.

And hendu i think you might be mistaken... take some hard performance values.... With irrlicht, this map runs at ~constant 70 FPS, with my own custom engine using octree occlusion, it runs at 70-150... In Xonotic, it runs at 200+

Also, a lot of major games/companies either use probably their own PVS, or license from Umbra Software. PVS is definitely worth it. Also, I think you're mistaken on how you're thinking about it. The PVS vertices lists are *precomputed*. Either at load time(less likely), or baked into the map file itself. That means the CPU doesn't generate these lists themselves. Instead, it just sends the proper list to the GPU, which is what's done anyway with regular rendering, but instead of sending a huge list of a bunch of not-visible polys, it sends a much smaller list of only the visible polys.

I think this is one major feature irrlicht and ogre are missing. Without them, at almost makes them worthless except for very novice users just tinkering with development. If you can manage implementing your own spacial structure such as BSP/octree, with culling such as occlusion/portals/PVS, then you're much better off. Once you start dealing with "actual" data - not even necessarily that complex, say just a decently-sized quake map, you'll see that irrlicht and ogre's simple frustum culling is just too slow.

[hendu]

I do not mean that PVS in general cannot be made good. But it is a significant problem, and getting good pre-calculated divisions is quite difficult.

Quake 3-style PVS, calculating the lists on the cpu each frame, is not a good way. Even if all the verts were stored in VRAM and you were only sending indices, you would still be sending a considerable amount of data over the pci-e bus. I'm decently familiar with it.

If you instead had a number of buffers, all in VRAM, that would increase your draw calls, while also limiting the granularity at which you can cull. It's all a careful balance, and I think you underestimate it.


For your numbers, I assume you mean a typical Quake-style map with big triangles and little else. If that's the case, then purely cpu-based PVS could work, as I believe your numbers show. However, if your map had instead some more complex meshes, starting from a few dozen k to million verts, any cpu-based PVS would quickly collapse.

Please post the amount of meshbuffers, verts, and indices you have there. In your other post you mention 50k tris; that is quite low.


I should also mention that when comparing a general-purpose engine to a highly specific and tuned one (Xonotic), it's quite obvious which one will win