4 ms·
For static geometry like this, the entire scene should be uploaded to the GPU in a few calls when you open the page, and then never again. Only the transformat
by mortehu 9y ago
For static geometry like this, the entire scene should be uploaded to the GPU in a few calls when you open the page, and then never again. Only the transformation matrix, a 4x4 matrix which transforms vectors from world space to display space, needs updating. There's no reason this shouldn't run at 60fps on any machine that supports WebGL (excluding CPU-only implementations).
- mattdesl 9y agoThe geometry in this demo already is static. The app is vertex bound since the geometry has 11 million vertices, which is not trivial for any GPU to render.
- izacus 9y agoHow does that number compare to for example Cities: Skylines which renders cityscapes smoothly on the same hardware?
- mattdesl 8y agoI don't know Cities: Skylines but I imagine each city rendering engine has its own set of challenges and performance considerations. Generally my point is: graphics programming isn't always trivial, and it takes time/practice to debug and optimize a WebGL scene with millions of vertices. Comparing this WebGL side project to a full-blown city-scape game engine is apples and oranges.
- mortehu 8y agoI set a breakpoint at drawArrays to verify this, and it's indeed rendering 10,965,264 vertices. It's using neither indexing nor triangle strips, so it uses no post transform cache, and the vertex count is needlessly inflated by at least 3x. But that's still a lot higher than I thought it'd be.