Efficently drawing 100 000 models in 3D without lag

[Superposed_Cat]

Hi all, I'm currently working on a 3D game and am in the city development phase (its done procedurally). The issue is is that once I get to 22 000 buildings (80 000-100 000 models roughly) it causes a drop to 5fps(frames per second) (even with collision detection off). I'm using instancing to speed things up, octrees for the collision detection etc., I've tried drawing things only within your view frustum but the BoudingBox-Frustum intersection for each building slows it down too much. how do people in the industry still get 60fps with such large maps? Any ideas on techniques ignore the image was an accident

 

[jedishrfu]

Is this 3D game for Facebook?

The only way I know is to not draw something if you don't need to draw it that is if it doesn't change.

As an example, some programmers used to draw some animation by drawing it, blanking the screen and drawing it for the next frame. Latter, programmers started using two buffers one to display and one to draw on and they would switch them so as not to get the screen blank flicker. Later still, programmers would carefully remove selected pixels and add others to adjust the image and getting an animation.

If you're using a library that handles these things then perhaps you need to check for others using that library to see what's supported and tricks they use.

Off the bat, I feel that 80-100k triangles or whatever is an awful lot to draw every 30th of a second.

 

[.Scott]

I will answer in generalities.

I would start by indexing the buildings by direction and distance from your camera. Since the camera is probably not crossing buildings at a high rate - not more than a building per frame - updating the index could be done frequently for near buildings (front of the list) and very infrequently for distant. Then, only consider buildings that are in the directions the camera is looking.
Then work from the near field to the far field, so close buildings can block wide areas of your view. Then fill in the wholes with more and more distant buildings until the view is filled.

Also, at a certain point, a building will only occupy one or two pixels. Those pixels can be precomputed.

 

[DavidSnider]

Google Potentially Visible Set and BSP Trees.

 

[mafagafo]

Off the bat, I feel that 80-100k triangles or whatever is an awful lot to draw every 30th of a second.

Not really. @ 60 Hz it is somewhat average for contemporary GPUs to render 1 M triangles per frame.

However, there are three factors I need to bring to the table:

• Onboard, phone and tablet VGAs are usually pretty weak.
• This is not C / C++ and OpenGL / DirectX, but something running on Facebook. I have no idea of how much overhead this adds.
• Triangles per second is one of the worst dimensions I have ever seen and IMHO no GPU / Render should have its performance evaluated with this.

 

[DavidSnider]

Not really. @ 60 Hz it is somewhat average for contemporary GPUs to render 1 M triangles per frame.

However, there are three factors I need to bring to the table:

• Onboard, phone and tablet VGAs are usually pretty weak.
• This is not C / C++ and OpenGL / DirectX, but something running on Facebook. I have no idea of how much overhead this adds.
• Triangles per second is one of the worst dimensions I have ever seen and IMHO no GPU / Render should have its performance evaluated with this.

I'm pretty sure you can build facebook games in anything as long as they integrate with the facebook API.

 

[mafagafo]

I'm pretty sure you can build facebook games in anything as long as they integrate with the facebook API.

I think you are right, but still, it is running on a web page, right? That must add some (not insignificant) overhead to the game.

 

[jedishrfu]

The question would then be where is the image being rendered in browser or on a facebook server or both.

Is it using the embedded canvas object or SVG objects?

What if the client computer doesn't have powerful GPU then what? does it dumb down the graphics rendering...?

 

[mafagafo]

It should dumb it down. From what I have heard some game studios start with an almost fully fledged engine but simpler graphics and then increase their polygon counts and texture size as much as they expect their target machines to be able to render. Maybe this is a safer way to go than starting with all the sliders at the right end.

I think FB servers are not helping with rendering, at least they should not. If I ping their servers with, say, 60ms, it would be a noticeable delay between getting the latest graphics and deciding upon my next action. That could, however, motivate the application of statistics and machine learning toward predicting what the user's next move will be and anticipating its rendering. The developer time such an endeavor would require would probably make it not worth the investment.

 

[DavidSnider]

Facebook games aren't hosted on facebook servers. Pretty much all the facebook game API does is perform authentication and keep track of friends, scores, achievements, posting to walls.. this sort of stuff. Facebook servers have nothing to do with the graphics rendering.

Web Games usually have some sort of browser plugin which runs in its own thread. It has overhead in the same way Steam has overhead.

 

[jedishrfu]

I didn't think so either so that means it's javascript or some flash plugin running inside the browser. Consequently, low powered computer will render slower. So the OP should consider the screen size and pixel dimensions to decide how detailed he should render his buildings with less being faster.

 

[mafagafo]

Web Games usually have some sort of browser plugin which runs in its own thread. It has overhead in the same way Steam has overhead.

That is pretty much what I was saying. I didn't, however, consider that the browser plugin overhead would be as small as that caused by Steam.

 

[chiro]

If you can store everything on your graphics cards RAM then do so. Once you transfer it to the RAM everything should be a lot quicker than if you keep transferring it every frame. Each graphics API has its own way of doing this and sometimes you may need to use extensions - although most modern graphics cards should have the right OpenGL and DirectX versions to do this.

Aside from this you have scene classification which is a different kettle of fish. If you only want the scene, it fits in your cards RAM and you can render the triangles in a single frame, and the rest of the code can execute in the frame then just upload the whole thing to RAM.

If you want to look at scene classification then you will be getting into computational geometry and that involves a lot of stuff. Basically you are classifying space in many interesting ways and using data structures to do it.

If you haven't really taken this stuff into account I suggest you look at some developed engines and see what goes on.

 

[Carno Raar]

Unity 3d Engine's tech docs say keep vertices/frame in the 500K to 3M range. I'm guessing that with your 100,000 models (each of which will have multiple vertices) that's you're running close to this limit. This may be ambitious for a homebrew 3d engine.

 

[Superposed_Cat]

solved it awhile ago by the way, divided buildings into chunks, then only drew the chunks in the frustum the camera could see