Author Topic: Yay framerate  (Read 9415 times)

Yeah, Now it will just be annoying but it does not lag so who gives a stuff [/sarcasm]

65k and no lag?
what specs you have entrepreneur in?



edit:
well i guess it wouldnt matter, since bricks thatcant be seen arnt being rendered, i guess a full out wall of 1x1's that fill the entire bedroom and every brick can be seen.

now THERES a way to test it
More object culling is hard on your processor, I think.

Depends on how you do it!

exactly, for example Zhang's HOM algorithm is generally considered an excellent algorithm for occlusion culling that needs to be recalculated every frame.

OQ still aren't a win - esp when you're rendering extremely cheap objects like bricks.

the main win in a game like blockland is to avoid traversing all the bricks. just a single iteration per frame is enough to hurt performance by a large amount.

now, if we were doing a ton of shaders on each brick - then we might be getting somewhere.

how do you prepose avoiding bricks? you can't do any sort of culling at all if you can't read information on where each brick is and how large it is.

and with HOM you can remove up to 95% of the objects in a high density scene (such as the afore-mentioned 1x1 castle)

ONOEZ NOT USING HOM HOW CAN IT BE?!!?!?!

Zhang's work is almost ten years old and it's been effectively supplanted by the widespread and efficient hardware occlusion queries. It's not worth the overhead to do heavy duty occlusion brown townysis when you have potentially hundreds of thousands of objects in the scene. In particular, the main weakness of Zhang (and other occlusion brown townysis schemes) is picking good occluders; you have to draw enough of the scene to get good occlusion without drawing so much that by the time you're ready to query it's already drawn!

If the bricks were highly shaderized this would be a win. (We could test against faster approximations.) But right now they're only marginally more expensive than a fast-z pass, and there's no way to simplify the geometry for most of them (they're already cubes, what more can we do?)! The GPU is really, really fast at drawing single-textured triangles with no shaders, faster than the CPU is at determining occlusion, so it's cheaper to just draw and let the z-buffer sort it out.

As it is, we already mark invisible bricks (ie, ones that are covered on all sides with other bricks), so building a huge cube of bricks only incurs the rendering cost of the outside bricks. And that really isn't all that much - maybe a few thousand polies for a large cube. Try running Blockland in wireframe some day. (Turning on wireframe left as exercise for the reader.)

But surely OQ helps? It does! Barely. In our tests, it did boost performance slightly in the "Everything" stress test - which was approx 100k bricks in view. It took the FPS from 5 to 10, if most (ie, all but one, the brick we stuck our nose in) of the objects in the scene were occluded. In every other case it reduced the FPS by a noticeable margin (10-30%, I believe).

We actually got a bigger win by simply optimizing the code that displays the names of players than we did from OQ. And all that code was doing was iterating over each brick in the world and checking a single bit on them.

The octree,  of course, enables us cull large numbers of bricks at once, meaning that we don't, in fact, read any information about where bricks are unless it's needed (or almost certainly needed). :)

BTW, I think you're mixing up your dummy accounts.

Blocks are static last time I checked.