What sort of numbers can I expect to put into UDK on the iPhone?

[marscaleb]

A friend of mine and I are trying to make an iPhone game with UDK. Right now we're a bit unsure of what we can push through it.
I've looked through the citadel demo on my computer and I've tallied the numbers for how many textures the demo is using, and getting an idea for how many polys I can load into memory, but I have nothing to give me an idea of how many polys we can render in one scene. I can't tell how many separate objects I can draw before I may start dropping frames. I can't even get the stat command to tell me how many tris are being rendered at any given time when I'm in the citadel demo.

We're trying to get some characters built, but we're not sure what sort of range we need to keep the models in. How many tris can we put into our characters? Would a difference of a thousand be a real problem? We're trying to be cautious but being overly cautious creates poor models.
And we're not at the point where we can actually test out the game on an actual iPhone to see how it handles.

[CSlegers]

Check this: http://udn.epicgames.com/Three/DesigningForMobile.html

"Character meshes should be as low poly as possible Infinity Blade characters are around 8k poly 3k verts."

[marscaleb]

Thanks for the link! I never saw that page before, and that is some dang useful info.
From what I gather, animated characters are going to tax the system a lot...

[marscaleb]

Hey here's a wild thought.
If I shouldn't have an animation bone influence more than two vertices, could I get away have a character be vertex-animated?

[marscaleb]

Okay, actually I have a question my friend brought up when I showed him the specs.
The bone limit, is that per actor or for a whole scene?

[ShaneC]

The bone limit is per actor, meaning that is how many that can be rendered in one pass. You can have more than that in 1 actor, and it will just render in 2 passes, which will be slower. I would try to keep it under 75 per actor.

[marscaleb]

Thanks Shane! I can't imagine ever needing that many bones in one actor, which is why it sounded like an odd limit to mention.

But then again, I suppose that if you were getting slapped by the suggested limit of no more than two bones influencing a vertex, it might be effective to add more bones for a smoother animation.
Hmm, I wonder if it would be more taxing to have 70 bones in a model and only one bone per vertex, or to have thirty bones with the vertexes influenced by two bones each...

[Geta-Ve]

I have a follow up question to this. How many bones can be calculated on screen at once?

For instance. My main character has around 20 bones to his skeleton, with each enemy having about 12 to 15 bones each.

How many enemies could I have on screen at once? (poly limit is quite low, under 500 tri. main character is 1k tri)

Thanks!

[zero4]

I'm messing with UDKM for 3 months now so I will try to get you some informations:

- polycount doesn't matter that much. I'm using UT assets in my game and I've 30 fps on 3gs. One character = 15k tri, 50 bones, 15 characters on scene = 20-25 fps.
- bones: I've 20 bones in my characters and 15 of them on the scene with animations and with ragdolls = 30 fps
- textures: basically Unreal is compressing textures a lot, you should decorate your envrio using meshes. Textures aren't looking good. you will need to hack them using emissive channel. Basically it's thing that your artist need to figure out. Texture size: try to make them small, iPhone doesn't have much memory.
- rigidbody collisions: try to avoid them, they are expensive.
- vehicle physics - when they are on I've fps -= 3
- dynamic light - don't know, but I'll try them on iPad 2 soon
- Actors Count: basically that's the biggest problem now. When you have 20+ characters (even if they will be simple box mesh) your fps will go down. Maybe Epic will implement one draw call for the same object in the future.
- pathfinding using pathnodes - without any fps lose.
- particles: they are damn expensive. I'vent figured out how to optimize them.

So generally, if you want to create good game using UDKM:
- don't limit your polycount that much,
- add good artist with mobile experience to your project. Give him time to find out what would be the best approach for lighting textures and whole level,
- keep your bones at minimum, even if UDKM don't have problem with them, they are expensive,
- try to have small texture size,
- don't try to put 20+ actors in the scene, found out how you can delete them,
- learn US, replace ticks for your random tick, don't use foreach functions, try to use WorldInfo functions.

Basically rendering performance in UDKM is really great (I think the best) but still there is couple of things that could be optimized.

[Tom Shannon]

Textures aren't looking good. you will need to hack them using emissive channel. Basically it's thing that your artist need to figure out. Texture size: try to make them small, iPhone doesn't have much memory.

Can you provide some info on this?

[Geta-Ve]

@zero4:

Hey there! Thanks for all the valuable information. If I may, I just want to confirm a few details.

You stated that on the iPhone 3GS, you are running at 30 frames per second with roughly 15 characters on screen at once? Each character consists of 20 bones?

That is 300 bones on screen at once. Is this correct?

I assume this number goes up if you are using the iPhone 4? and subsequently, down, if you are using the iPhone 3G?

Regarding rigid body collisions, these would be, for instance, having a character bump in to meshes such as, trees, desks, boulders, etc?

Thanks once again zero4!

[zero4]

You stated that on the iPhone 3GS, you are running at 30 frames per second with roughly 15 characters on screen at once? Each character consists of 20 bones?

That is 300 bones on screen at once. Is this correct?

Correct.



I assume this number goes up if you are using the iPhone 4? and subsequently, down, if you are using the iPhone 3G?

iPhone4 doesn't need that much compressed textures so game is looking much better than on 3gs, and it doesn't scaling textures. (as far I can know we can change that in .ini file for 3gs too), and yes - when I've 20 fps at 3gs I've 30 fps on iPhone4 (and iPad). I'm really looking forward to check iPad 2 performance when running UDKM ;] (2 weeks left and I will be able to do that)



Regarding rigid body collisions, these would be, for instance, having a character bump in to meshes such as, trees, desks, boulders, etc?

I'm not sure if I'm right (I'm learning US) but I think that RigidBody = advanced physics. Bump/Touch are using different physics (much simpler) and you don't need rigidbody to have collisions between meshes, but if you want to have rolling ball for example it need to be rigidbody. (so you will have rolling physics etc and every function that is needed for ball)

[Geta-Ve]

Also, regarding the actors. What is included with this? lights, meshes, characters, enemies, etc?

And is that per scene, or simply 20 actors ON SCREEN at once?

EDIT: Thanks once again for the great reply! :)

[zero4]

What is included with this? lights, meshes, characters, enemies, etc?

to be honest I don't know :) basically it's everything that is extending from Actor.

But I've found something that is usable. My level is one static mesh, so it's one draw call for Unreal. Collision is advanced, but I've really big and with good quality level running with 30fps. Basically mobile game dev = you need to found out best solution. So if you are creating simple level with trees, add the trees to level geometry. Don't add them one by one as another static mesh actor. I found that Citadel is adding static meshes separately, but they are without collisions, and these doesn't slow down your fps counter.



And is that per scene, or simply 20 actors ON SCREEN at once?

it's 20 actors on screen. You can mess with .SetHidden(True) function to hide something out if it isn't visible for camera.

Basically you will need to found that by your own. I can only tell you that bones/tris aren't the issue in Unreal.

[Geta-Ve]

Thanks zero4 yet again. The information that you have provided is extremely useful and valuable to us.

:)

[m00t]

Thought I would keep this question in this thread as it is about optimizing.

I'm just curious if a 2048x2048 diffuse/normal map is ok for a "terrain" static mesh - as you know drawing out a hunk of static mesh for an outdoor environment can get quite large - so in order to keep some detail at the scale I have to use a rather large diffuse and normal map. or should I be going about this a different way? Mostly I'm wondering if performance wise if I have one 2048x2048 texture and the rest are all 512x512 or 1024x1024 - could the iphone handle that? I don't really want to tile and stuff, as I prefer to carve little roadways etc in the normal map and paint the landscape.

thanks in advance.

[zawette]

The ipad 2 is 9 times faster than the ipad :D

[Zach Lehman]

There's a large jump in hardware going from iPad to iPad2, but keep in mind the millions of iPad users when developing games. They need some love too.

m00t: iOS devices can handle a 2048, but it needs to be used sparingly.

Our lead artist, DennisG, took some snapshots of texture consumption rates and came up with this table:



Texture Size > Memory Usage
64 > 112kb
w/alpha > 224kb

128 > 116kb
w/alpha > 232kb

256 > 132kb
w/alpha > 264kb

512 > 196kb
w/alpha > 392kb

1024 > 365kb
w/alpha > 730kb

2048 > 1,365kb
w/alpha > 2,730kb


Considering you have roughly 150-170MB of total memory to play around with (on the iPad), 2048's can get expensive in a hurry.

Also - draw calls are important when it comes to performance. I'd do some research on those as well if you're worried about response times.