Can someone please enlighten me. Im not sure if its 7000 or not.
Thanks.
There isn’t a hard limit. Generally, the more polygons you have, the slower it gets.
–Eric
Give me your consensus. We have set a limit of 7000 on screen for our game. Is that feasible for a good fps (frames per sec)?
Thanks.
The 7000 polygon limit is meaningless.
The question can not be answered because there are too many unknowns. Are you using physics? How many and what size textures? How many draw calls are there per scene? What else is going on in your game?
You need to test until you get to a frame rate you are comfortable with.
More than polygons, the real bottleneck is in the draw calls.
You can push a lot of polygons (‘a lot’ in phone terms :P), but with too many draw calls the performance take a steep dive…
Oh, Ok.
So its all about testing to get the frame rate that you want. Yeah there will be physics too since its a racing game.
Thanks a lot everyone.
also 7000 poly is static.
With animated objects your border is 2000-2800 polygons
So its really needed to test it, at best on a 1st generation iTouch or an iPhone
don’t do that testing on a 2nd generation iTouch for now.
So far I’ve run into low frame rates on just one iPhone app - my maze game runs anywhere from 6-30fps depending which direction you look. In the worst case, standing in one corner of the maze and looking diagonally toward the other corner, it’s 8x8x6 walls of each of which is a tile (all with the same texture), and if my stats are to be believed, totalling 50k tris! I don’t want to shrink the maze, so I guess I’ll have to reduce the tri count on the tiles (I just hope the dynamic lighting doesn’t look worse)
Everything else I have runs reliably at 30fps, including a bowling game with 8k tris and way too much texture and sound (memory is the issue there), a couple of simultaneously dancing animated characters with song (not sure now about the tri/vtx count) and a tilt game with 3-4 balls bouncing at a time on a plane (maybe 3k tris)
That is way too much for any decent framerate!
You should use Occlusion Culling instead. file:///Applications/Unity%20iPhone/Documentation/Manual/Using%20Occlusion%20Culling.html
Check out Occlusion Culling sample: http://unity3d.com/support/resources/example-projects/iphone-examples.html
The maze is instantiated at runtime and reconfigured every time you find the exit, so I don’t think occlusion culling will work - am I right?
I don’t think Unity’s occlusion culling will work for you since you generate the maze on the fly. I bet if you wrote a simple script to hide everything that was x units away from you, you’d get a big speed up.
How does your maze work if you have only a walls?
Since Unity can’t tell what walls you want rendered, it probably just falls back to frustum culling and the far clip plane. That still means that it is possible for your app to try and draw a lot of walls that won’t be seen.
What happens if you set the far clip plane really close (2 or 3 block units)?
The maze is just a grid of cells, each of which has a plane (I used the built-in Unity plane game object) for each of the four surrounding walls and floor and ceiling. The maze configuration itself just selectively deactivates individual cell walls, via a recursive algorithm I pulled off Wikipedia - the script is pretty simple:
Frustum culling makes a huge difference - say if you’re in the corner of the maze an you look along one corridor, half of your FOV is filled with nothing and the frame rate is great. The worst case is if you’re in that corner and you look along the diagonal toward the far corner of the maze, then you have a lot of the maze in your FOV (probably not the entire 50k tris, but a good chunk of it). I played a bit with shrinking the FOV and thought that helped but since I’m using the horizontal screen I wasn’t sure that looked right (could switch to vertical, but then the two-thumb operation isn’t quite as comfortable, I thought).
Adjusting the clip plane is an interesting idea, I’ll take a look at that. Depending on the maze configuration, you might be able to see along a diagonal a few rows away, but in practice not along the whole length of the maze (especially if I can increase the size - the widget version is 12x12 and I only limited it there because it takes a while to instantiate all those walls). Along those same lines, I was thinking I might be able to set up some occlusion views with some placeholder geometry based on those assumptions, but I haven’t thought very carefully about that.
By the way, if you want to take a look at the maze and don’t want to spend 99 cents, here’s the widget:
Are you doing a CombineChildren on that maze? If not, you’re going to have a huge number of draw calls, which is probably worse than the number of polygons. Ideally you’d build a single mesh from scratch anyway instead of combining objects, but that’s somewhat harder.
–Eric
If I combine all the walls, then I can’t selectively reactivate/deactivate individual tiles the next time I “scramble” the maze, can I? But I guess I could generate it completely from scratch each time (completely throw away the old maze and reinstantiate all the tiles) and combine the walls after opening up all the holes.
The user would have to wait for the rebuild each time the maze is solved vs. the current behavior where the scrambling is near-instantaneous, but that’d be a reasonable tradeoff if there’s big improvement in frame rate. And I when I first ported the maze from Unity standard, I was surprised to find the wall-instantiation didn’t feel terribly long on the iPhone compared to the desktop version. One potential benefit - right now some users seem to think they’re going through the same maze over and over even though it’s really different, so if I make them wait and watch the maze rebuild, that might be a feature!
You wouldn’t have to rebuild the maze. If you use combine children, then you delete the old mesh and recombine. If you build the mesh from scratch, you’d still do it from data that’s already been computed. I’d recommend using 2 polygons for each wall segment…it will reduce poly count, and the vertex lighting is pretty useless in this case anyway. Maybe show an overhead view of the maze when you finish, so people can see it’s different.
–Eric
OK, thanks, I’ll give that a shot!
So I’m guessing the 300k+ vertices I have won’t make the cut for iphone :'C
You’re replying to a topic from 2008. It’s now 2015. Maybe the hardware has changed a bit since then. Maybe the info in this topic is hopelessly outdated. Maybe there was no reason to necro.
–Eric