Model rendering problem on iPhone

Unity Engine
,
1

Ok, I’m near at the end of my rope on this one… Hoping someone can point me in the right direction.

I modeled several space ships in Cheetah 3D, exported a nice UV map, put together some real basic graphics in Photoshopt C3, and I’m getting a “shimmering” effect that’s making me crazy!!

The models are basically, a cylinder, a ball, and a box. The ball fits into the cylinder for the “cockpit”, and the skinny box slides into the end for a “rudder” tail section. I’ve applied a subdivision for smoothing (which I have tried removing!!).

In the editor … nice smooth models (ahh a vision of alien-ly-ness :wink: ), deploy to the iphone, and the textures applied to each piece “shimmers” (a kind of blocky pass through) through anywhere the meshes overlap from the camera’s point of view!! I cut out the bottom of the ball “cockpit” and now the cylinder texture is flickering through the cockpit ball! same for the tail section.

I’ve tried everything that I can think of, shaders, textures (I figured out how to flatten the images, all 100% opaque), modeling… nothing! I have noticed that the transparent->cutout->vertex lit shader stops the shimmering but shows sections of the meshes as open holes!!

sigh I really don’t want to submit the app to the itunes store like this :frowning: People who have play tested it said they didn’t notice, but… I"m a perfectionist around these things, I hate loose ends, OH, and customers are a d*mned sight more critical than people you know :wink:

Anyone have any ideas where I should look??

Thanks,

Galen

2

did you enable iphone graphics emulation?
Otherwise the content in the game window is likely pretty off from reality

3

Yes, which adds to my frustration!

Thanks,

Galen

4

do you have a picture of the effect?

Its hard to say much without more visuals as there could be different things involved:

  1. Import settings interfering
  2. You have polygons that are near identical which can cause zfight
  3. Your camera near clip to far clip ratio is completely out of scale for the iphone (far clip / near clip distance should be 1000 or less normally)
  4. you have lights in the scene which you don’t force to vertex
  5. not applying vertex lit shaders or applying them while not wanting any light reaction
5

I know, I’ll try and post some pics tonight, in the mean time I’ll try and answer your questions as best I understand them:

I have tinkered with these endlessly… If there’s a secret sauce… I know know it!

I have no idea what zfight is (i’ll look it up now). So this is possible.

I’m pretty sure my near clip is like 0.03, with far clip at 100-500 (possibly 40-60, I tried to rein this in). All models move within a fixed path within the clip range (not too close, not too far).

I don’t know how to get a light to force to vertex (I’ll look that up too, thanks) I did change the light’s culling mask to exclude the ships (and turned off accepts and makes shadows on the models)

I don’t really care about light interaction (I can bake the shadows etc… but no other shader seems to work to prevent this either (I’ve mostly tried diffuse variants, but anything that looked like it might work as well).

Thanks,

Galen

6

zfight is when you have two polys so close together that the renderer isn’t accurate enough to determine which to render first, and it will randomly select a face to render first.

A few more things it might be that Dreamora didn’t add…

  • Totally broken UV export from Cheetah, broken UV’s will render very random stuff. This can be the UV’s exporting wrong, exporting the wrong UV channel, etc.

  • Broken scene scale (similar problem to the clip ratio, but at the object end).

I personally have never had the lights cause any rendering issues. Are you just using the default Diffuse shader?

7

By your description, it sure seems like I’m experiencing zfight, which makes sense given the difference between the editor (using my imac 256Mb graphics card to do the rendering (even in iphone sim mode), verses the iphone. (it might be broken scene scale, could you describe that some more?)

I don’t think the UV is broken, everything renders fine in the editor, cheetah 3D, and any other 3D model tool I can find.

I’ve never had lights cause a negative effect either, but I did read that was possible, in my case, it’s described as something to do with calculating the light reflection messing up the rendering order when one texture is suppose to be enclosed by another.

If it is zfight, what’s the best cure? should I make the models larger to help the renderer decide “who’s on first”?

Thanks (btw) everybody… this problem is like the straw that broke the camel’s back, while I’m fighting a hundred small details… this one keeps staring me in the face… laughing… (come to think about it, it sure makes shooting them a lot easier :lol: )

Thanks,

Galen

8

Okay, zfight…

Puts on his TD hat

All polygons are rendered in a specific order, for example, from the back to the front (this way you just draw forground polygons over the background ones, and you don’t need to ‘clear’ whats already on the frame).

Typically, to speed this up, it is not done in 32bit float, its done in 24bit, 16bit floating precision. This is enough, normally.

So if you imagine you have two objects, one behind the other, like this…

o< …O…O…

o< = camera
… = levels of depth
O = objects

So imagine that’s ‘floating point’ precision, now lets lower that precision to like, 5 levels of depth.

o< .o…

Uh oh, there’s still two objects, but as far as the renderer is concerned, they’re on the same level of depth? Which should it render? … It hasn’t got a clue, so it gives you a hideous shimmering mess with triangular or blocky artefacts.

Okay, so Unity/iphone don’t have a quality issue, but if your scene is really out of scale, you might get issues.

Basic example, the camera has a clipping range of 1km, and lets say, if you divide that by the levels of depth it has, that works out to 100,000 levels of depth… That means if your object has polygons closer than 1cm together (toward/away from camera), they’re going to ‘zfight’.

So, easiest ways to test…

  1. Scale your object up by 100 or 1000x, does this fix the problem?

  2. Change the clip settings on your camera, most move the close/far closer together.

  3. Try export from your 3D package at different scales (both larger and smaller, emphasis on larger). Some exporters may also have accuracy issues at small scales. This is a common problem for people using older versions of 3D max where the ‘grid’ was infinite in all directions, since you had absolutely NO idea what scale you were working in unless you went and set it :slight_smile:

  4. I’m out of ideas.

9

While adjusting the near and far clipping plane of your camera will give you more Z precision and help solve z-fighting, I’d also reconsider your model itself. If your intention is for portions of the ball, cylinder, etc, to never be visible, then you’re wasting lots of vertices, and therefore performance, by having that extra geometry in there.

If you want to solve this, and get rid of your Z-fighting issues at the same time, the quick’n’dirty solution in Cheetah is to combine those objects together using booleans. Combine them two at a time as children to a boolean object, and play with the settings (can’t remember which one you want) so that it combines the two shapes, but cuts out where they overlap. Once you have them combined, double-click on the boolean object and it’ll create a single mesh.

This can still lead to some extra vertices, and sometimes even some unwanted artifacts, and if that’s the case, you should hand-model it, manually welding certain vertices, etc until you get the shape you want. But booleans should get you pretty far along, if not solve it entirely.

10

UPDATE: The problem seems confirmed to be zfight

Adjusting the near clip plane seems to have done it!! I pulled the far clip plane in as far as possible as well, but that adjustment was from 60 to 58.5. Near clip was increased from 0.01 to 2.0, and the problem seems completely gone!

Thanks all for your help! Hopefully someone else will benefit from this post as well.

Thanks again,

Galen