One Billion Polys

Started by
17 comments, last by Krypt0n 12 years, 9 months ago
ok ok, quite a catchy name. what you actually see is my culling lib, supporting

-frustum culling


-occlusion culling

you see a cube consisting of 135k objects, slightly over one billion polys made of 3 mesh types

-utah teapot, about 500poly, mostly contributing to drawcalls

-stanford bunny, 15k poly, simulating nowadays game models

-tetrahedron, highly tessellated, simulating micro polygons (which are quite challenging for software rasterizers)

some benchmarks, without/with the lib

- 135k object, 1Billion polys -> 0.3fps/5-6fps

- 13k objects, 100MPoly -> 3fps/30fps


-1.3k objects, 10MPoly -> 30fps, 65fps

-130 objects, 1MPoly -> 111fps/105fps (about 3-5objects get culled, kinda useless lib in this case, creating just overhead)




there are just a few occlusion libs, I wanted to create an alternative that have some quality goals:

- handling high object counts, that's usually the limiting factor on PC games using D3D nowadays

- drop in solution, handling all culling you need, without much coding or level setup. supporting ogl/d3d (you can just call glget.. to get matrices and pass them to the lib)

- handling low poly (boxes) to Million poly meshes, with a win if culling is possible, but without performance penalty if it's impossible.

- simple c interface, few functions, supporting "scenes" and "cameras" with shared meshes, but instanced objects. so you can make one cam, one scene, thousands objects games, but also split screen games with shared cams, you can use the cams for occlusion culling of shadows, or in some rare cases also simulate separate scenes.




the scene from the screenshot is quite a worst case for the culling lib, high poly and extreme drawcall counts, low pixel cost (opengl phong shading), and it still is a win or at least not a big hit. Common in nowadays games are rather high pixel cost with 1000-5000 drawcalls, which makes this tech very beneficial for real world scenarios.







if you have any interest to integrate this lib into your existing project, drop me a pm please















Click here to view the iotd
Advertisement
This is amazing to me though that may be cause I haven't messed with 3D in a while. It reminds me of one of the Silicon Graphics workstation demos from (I think) around 2000 which had a 3D oil rig model with (IIRC) around 2 billion polys.
Pretty cool!

What methods are you using for the occlusion culling?
For once technology as reached the point where we are able to make a cube out of a 135,000 teapots. :)

Seriously, awesome work! What are you planning to do from here?
[size="2"]I like the Walrus best.
Game needs to be made purely out of teapots.
Latest project: Sideways Racing on the iPad
thanks guys :)




@Hodgman

it's a software rasterizer with triangle and quad support and some obvious optimizations like removing duplicated vertices etc.

in general the lib is working like a physics/collision lib, the camera is collided against the objects in the broad phase and the fine grain phase is checking objects against the software zbuffer.




@owl @Tachikoma

can't do anything wrong with teapots, everyone love them, right? :) actually I was thinking of using just teapots, dynamically tesselated with catmull clark, but that would kinda move the whole scope of this demo, maybe the next IOTD




@owl

I hoped some people want to use the lib for their project (and I got some pm which seem promising), as it is quite a basic thing for most engines, but people seem to struggle (or at least wasting time) to get a well working system.

If it really will be used, I'll optimize it further, to make it a real alternative to portal, pvs and other systems.

then I'll add more optimization and try to make it more of a 'drop in' solution. I've also designed everything in a way that it would be easy to get it working on PS3/X360, in case someone wants that.




Surprisingly I got request from non-graphics programmers, who said they might have use for it for AI (visibility checking seems to be a hassle as it's done with raycasts?) and a sound programmer said, with cubemap rendering, he could use it to check the occlusion of sound sources. (I guess that's easy to add).







I have implemented some software rasterizer based occlusion culling on my own, but yours is most impressive!

I wonder how it compares to modern hardware approches like CHC++. What do you think?
[color="#1c2837"]

Which version of DX dose this work for? dx9 or dx11?
[color="#1c2837"]



[color="#1c2837"]

becuse i made 30K objects run at 100 fps with an GTX 280.
[color="#1c2837"]

and im using DX11

"There will be major features. none to be thought of yet"
@Tordin how many polygons?

@owl

I hoped some people want to use the lib for their project (and I got some pm which seem promising), as it is quite a basic thing for most engines, but people seem to struggle (or at least wasting time) to get a well working system.

If it really will be used, I'll optimize it further, to make it a real alternative to portal, pvs and other systems.

then I'll add more optimization and try to make it more of a 'drop in' solution. I've also designed everything in a way that it would be easy to get it working on PS3/X360, in case someone wants that.

Surprisingly I got request from non-graphics programmers, who said they might have use for it for AI (visibility checking seems to be a hassle as it's done with raycasts?) and a sound programmer said, with cubemap rendering, he could use it to check the occlusion of sound sources. (I guess that's easy to add).


Awesome, keep us posted!
[size="2"]I like the Walrus best.

This topic is closed to new replies.

Advertisement