iOS Technical Question - Lightmaps, dynamic lighting, drawcalls

[DGlow]

we use navmesh for all the collisions which is pretty good for performance.

epic citadel used a similar solution except with a mesh with per poly collision, which worked for their product.

really depends on your particular project.

You could even optimize your stair collision by making it like a ramp instead of actual steps.

[SunSetter]

Are all 3 of those boxes separate objects? if not it will think its concave and convert it to the convex shape you see in udk.
If they are all separate then make sure they are named

UCX_Mesh name_Collision model suffix (this is for fbx)

For example:
UCX_StairStep_1
UCX_StairStep_2
UCX_StairStep_3

assuming your actual mesh name is StairStep

Thank you guys for reply.
I didn't try DGlow solution yet cause I have another question:

Whats the best way(aka performance wise) to set collision for iOS devices? Like the UDK did it or how I did it in 3d max?

[DGlow]

Are all 3 of those boxes separate objects? if not it will think its concave and convert it to the convex shape you see in udk.
If they are all separate then make sure they are named

UCX_Mesh name_Collision model suffix (this is for fbx)

For example:
UCX_StairStep_1
UCX_StairStep_2
UCX_StairStep_3

assuming your actual mesh name is StairStep

[woodesh]

it hasn't merged it, that appears to be the collision you was using before reimported the mesh with the 3dsmax collision model. for whatever reason the import didn't work, i can't remember of the top of my head but i think if you import the mesh as .ASE file as oppose to the standard .FBX fle then it should work.

[SunSetter]

Hey guys,
I have this collision import problem. I make my collision in 3d max, but when I imported in UDK it looks completely different. Does anyone know why its looks like it merges my original boxex?

http://deviart.ro/layer/3ds_max/wtf.jpg

[WilliamDocherty]

HI

If your screenshot represents a typical in-game camera angle (1st or 3rd person) then you want to be using pre-computed occlusion culling for your level (looks as if there may be more objects behind the walls etc). Distance Culling will also probably help as it will quickly be able to cull objects that are far away (assuming you have large levels), stopping them from being passed to the frutrum culler & then on to the occlusion culler.

As your columns are close together, chances are they'll be rendered at the same time - I'd test out at least grouping the clumps of 4 pillars together. However - you really need to know what else you're going to be doing and how hard you are going to be pushing the device - chances are you might be able to just render all those columns individually anyway - would need testing.


The quote from the "other" forum matches what UDK does as far as I understand things.

I'd like to see UDK support an explicit "I'm in this area/volume, so render only this explicit group of objects" (simplified the description/complexity quite a bit) - but it's a method that's conceptually easy to understand & very fast to render (requires design time though).

Cheers
William

[XilenceX]

So UDK Mobile has frustrum culling activated?!!? I never heard a word about that but that would totaly explain why my draw calls in birds eye view are MUCH lower than I expected. o,0 I heard that precomputed occlusion culling is often only a tradeoff into other problems rather than a solution. So I wouldn't want to use that.

Uhm I could've sworn that each individual material adds a drawcall?... Well I will have to look at my STAT command outputs a bit more if you say no...

[SunSetter]

thank you William for your answers.

this is a pass without materials in 3d max : http://deviart.ro/layer/3ds_max/level.jpg

In my case, there are "2 layers of depth"(the first set of column and further away from camera a wall and some columns LODs and other misc objects like barrel and stuff.) Is it still better to use DistanceCullingVolumes?

I find this in unity forums while looking for info on frustrum culling: "Frustum Culling only disables the renderers for objects that are outside the camera's viewing area but does not disable anything hidden from view by overdraw.Note that when you use Occlusion Culling you will still benefit from Frustum Culling." Is this true for UDK mobile also?

Anyway, I will make a test scene and post the results here. It will take some time though, because I'm new to UDK.

[WilliamDocherty]

Hi

In order to get the best performance on mobile you really need to tune your level design & art assets well.

I'd recommend using "stat initviews", "stat Es2", "stat unit" & "stat fps" at least from the command line & watch what's going on as you move your camera around (and the actual profiler).

You will quickly be able to determine what's going on.

1. You should be seeing 3 draw calls; the non-visible meshes should be frustum culled. This answer assumes that your column uses a single material on all it's polys. If not, the numer of draw calls is 3xnum materials used.

Regarding pre-computed occlusion - you've not said what type of levels you're trying to make - but if you have a top-down or a side scrolling style of level then pre-computed occlusion will have no performance benefit at all. The reason for this is that your meshes are frustum culled before passed to the occlusion culler anyway. For those types of level I believe it's better to not use pre-computed occlusion culling - as there's nothing to cull (usually). In those cases you are better to use the DistanceCullingVolumes as the radial checks it does are much faster than a frustum check. It's best to minimise the number of meshes that get passed to the frustum culler & from there into actual draw calls (that render something). Pre-computed occlusion culling is perfect for levels like the Citadel map when used with a 1st person camera - in that case it would make a huge difference. If you changed that map to be top down camera based, the occlusion culling wouldn't do anything.

Also, depending on your level design & how complex the columns are, merging all your column meshes together may not be a good idea either. There's a balance between the high level culling of objects and the lower level (that you don't see) culling & scissoring of mesh polys. It also means that the UV set for lightmaps for the larger combined object is more complex.

You'll also need to pay attention to the complexity of the material you design on mobile & how much screen space it occupies. You could easily tank the performance of an iPad2 using 1-2 drawcalls on a full-screen sized single poly object, but with all sorts of material parameters enabled.

Another thing that can make a huge difference in performance is using texture atlases for you levels. ie: using large textures that contain multiple smaller textures that are UV mapped to your meshes appropriately. This can help turn an otherwise multi-draw call mesh object into a single draw call mesh object. Obviously there are some artistic restrictions involved in doing this though.

2. For your columns, you just provide a 2nd set of UVs (either via art package export or generated them automatically in the UDK editor) & set the desired light map resolution values. The light map resolution you pick should be based on the size of the object (or more importantly it's surface area) , how close the player sees it, etc, etc - it's more an aesthetic call (within reason) to use as low a value as possible that achieves a good result. You shouldn't see any mapping problems as you use multiple instances as the lightmap textures are created individually for each instance.

3. Yes, the iPhone 4s can handle 1 dynamic light. Obviously you'd need to pay attention to what else in the level you are lighting as well. There are various controls, flags etc that control how each game object reacts with lights. It's worthwhile checking those all out - it's quite a complicated topic, but understanding them is critical for good performance.

4. Here's the link for baking normal maps into lightmaps (under lightmass...) in UDK

http://udn.epicgames.com/Three/Mobil...der Generation

It's worth noting - the normal map referred to is the PC MATERIAL shading network. If you add a normal map to the mobile shader settings, it's not used in the lightmap creation, but used realtime instead. I use baked normal maps in my game - they make a HUGE difference to the quality - but only for the statically lit components. It's also worth remembering that no directional lighting information is baked in on mobile.


Hope that's helpful

Cheers
William

[Solid Snake]

iOS can use precomputed occlusion.

[jrapczak]

1. 20 drawcalls at all times. 10 for the column meshes and 10 for the materials if you use separate materials. iOS has no occlusion culling!

This is not true. 1 static mesh with 1 material is 1 draw call, not 2.

[SunSetter]

1. 20 drawcalls at all times. 10 for the column meshes and 10 for the materials if you use separate materials. iOS has no occlusion culling!
2. UDK bakes the lightmaps you only provide the 2. uv channel layout.
3. Depends on your level.
4. Hourences said in his Eat3D videos that this is the method Epic Games use to make things look NormalMapISH! These do not work as REAL normal maps they only fake the details of NormalMaps. Hence they are also not so performance heavy at all. IMHO this method is the wtg on iOS as most devices don't even support REAL NormalMaps...

So, if I merge all those columns in 3d package I need to rearrange the second UV layout, yes? And so I will end up having only 2 draw calls, one for the merged mesh and one for the mesh material?

Thanks guys, you're really helping me out as I have a few assets done for my level but I got stuck with these little details.

[XilenceX]

1. 20 drawcalls at all times. 10 for the column meshes and 10 for the materials if you use separate materials. iOS has no occlusion culling!
2. UDK bakes the lightmaps you only provide the 2. uv channel layout.
3. Depends on your level.
4. Hourences said in his Eat3D videos that this is the method Epic Games use to make things look NormalMapISH! These do not work as REAL normal maps they only fake the details of NormalMaps. Hence they are also not so performance heavy at all. IMHO this method is the wtg on iOS as most devices don't even support REAL NormalMaps...

[darthviper107]

There's nothing to do with normal maps and lightmaps. It counts normal maps when generating lighting, but that's not anything for better quality or anything.

Usually what I do is make my content and keep it as simple as possible, keep an eye on how it runs then adjust settings accordingly. Like if it runs great then maybe you can increase your lightmap resolutions. If not then you can decrease the lightmaps or try and reduce poly count. For animated stuff there's things you can adjust as well.

[SunSetter]

I would run some tests, because those things depend on many other things--lightmap resolution and geometry count both use memory so you have to balance it.

Dynamic lights and normal maps are things that will slow things down a lot, you'll have to test to see if you can manage it beyond what you already have.

As for baking normal maps, you need to do that yourself in a separate program. You build your high-resolution model and then you could bake your normal map onto a low-poly model that you would then export to UDK. UDK itself can't generate normal maps.

Thanks darthviper for prompt answers.
I know how to bake normal maps, my question was if UDK uses those normal maps to generate a better lightmap. I don't remember where I read this unfortunately.
So, if I load the normal map in the Mobile Normal Texture, UDK will use this normal map real time?!

And one more thing, is there a rule of thumb on how to start testing. Because I made a scene with 60 objects, one diffuse and one normal texture and run it on iphone 4s and the device handles it without a problem. Is there a starting point for testing?