[5.3.0f4] Unnecessarily agressive culling - how to tweak it?

Hi there!

I’m experiencing some trouble with some effects and graphics in the game we are currently developing. Some objects (particles and 2D sprites) cease to be rendered when they reach the border of the screen, even if they should still be visible. Since the camera barely zooms, we do not have any kind of LOD or custom culling zones in the game (and those objects are non-static, which should avoid culling calculations for them). I’ll give you some visual examples:

In the first screenshot, you can see how a fog particle effect is perfectly rendered but disappears when the camera is a few pixels ahead. In the second one, the medallion sprite is rendered but, as the camera moves a little bit, vanishes.

We have a Perspective camera because we do make use of the Z axis for a lot of things (and we have some Z movement in some specific areas of the game), maybe that’s part of the problem? I haven’t configured anything related to culling, so this is Unity working automatically. How can I deal with this issue? It gets very annoying when you are walking and see sprites and particles pop in suddenly. And we are working really hard on our game’s art, so we really want to solve any erratic behaviour concerning visuals. Our workaround for the sprites (this won’t solve it with particles, I’m afraid) is to set their Zscale value to 0.01, which is not nice.

I’ve double-checked the scene setup and every gameObject’s renderer has a unique sortingLayer value, so it’s not a rendering issue.

Thanks for your time.

I’m sorry to bump this up, but we really need help. We are so close to launch and we still have no clue on what’s causing this issue.

Anyone?

5.3 is out and there’s still not a mention to the wrong culling of particles (and sprites too). The bug was reported almost half a year ago, and has to do with the Subemitters, as discovered by the Unity team (case 723993):

Is there a fix for it in sight? The bug report focused on particles but our 2D sprites suffer from it, too (our workaround is to set their Zscale value to 0.01, which is not nice).

We have fixed some culling issues but are still working on some. Try this. Create a script with a gizmo drawing function and draw the particle systems bounding box, this is what is used to cull. See if anything looks wrong. The box should contain all the particles.

The problem is that the scale affects the bounding box, this is something we are working on but for the moment you will need to have a scale greater than 0 on z.

1 Like

Nice, thanks for that. I’ll try what you say as soon as I find some time.

@karl_jones Ok, I see. The thing with some particles (like fire) is that their size is variable since the emitting is somewhat random, and that makes that, sometimes, the particle is on a corner of the screen and its bounding box can for a few frames be small enough to get out of the camera frustum, and then get in again. In the frames in which the bounding box is smaller and it’s not inside the screen space, the particles are culled and, as soon as the particle grows bigger and the bounding box expands, the particle appears again.

Damn, that’s a tricky one.

What sort of particles are you using? Mesh? We did have a bug with the calculation of the bounds when using mesh particles but it was fixed, maybe it still has issues. We are looking at allowing users to add custom bounds in the future but for the moment the best bet is to play with the scale values and see if this can help increase the size of your bounds.

1 Like

Back in the day, the engineering team guy that answered me told me that it was something related to the subemitter of certain particles (only those with subemitters experience this weird behaviour, apparently. At least in our project), and tweaking their Yscale value usually solved it (beats me).

Anyway, no, we’re not using mesh particle emitters.

EDIT: Well, no, I double-checked and particles without subemitters also experience this behaviour.

Yes the issue is not just subemitters.
When using the scaling mode “Shape”, the particle system ignores transform scaling except when spawning particles.
However, the generic transform calculations receive the transform scale regardless.
So we need a way to tell the system to ignore the scale in these situations. We are working on some bounding box calculations bugs at the moment so hopefully this can be fixed at the same time.

1 Like

Nice, it’s really good to know where does it come from, as well as your progress on that bug. I really appreciate you took your time to answer and explain to me this issue.

Thanks!

1 Like

I just stumbled upon this bug. Basically an emitter reaching the side of the screen (both in scene camera view and game view) causes its particles to instantly disappear. That’s err… a pretty BIG problem as far as particles are concerned.

(And it’s new in 5.3.0.f4. There was no problem in 5.2)

1 Like

So bad you have to face it too!

By the way, we’re super fans of GoaT here at Teku Studios :slight_smile: hope you manage to work it out and have an awesome launch!!

Can you file a bug with an example project so we can take a look?

Hah! Got it! It was coming from the fact that the particle system’s parent transform’s local scale was set to 0. The particles were playing normally but they disappeared as soon as their emitter got out of screen.

I’m fixing that on my side so the parent’s local scale remains at 1. Thanks!

Ah yeah that will do it. You could also try changing to a local scaling mode, that may also work.

1 Like

Oh sorry I didn’t see your post before! Thank you very much! :slight_smile:

1 Like

@Seith It has finally been fixed in 5.3!

http://issuetracker.unity3d.com/issues/culling-unnecessary-culling-on-specific-particle-object

P.S.: My and a colleague here at the studio are backers of GoaT on IndieGoGo, we’re following your blog posts about it and let me tell you that you seem to be making a superb job. Hope it goes well!

You noticed that quick, I only just fixed it :wink:
I put 5.3.3 for the release but hopefully It will be sooner. Got a lot of testing to make sure I didn’t break anything else :slight_smile:

1 Like

Nice! Thanks for your hard work @ !

1 Like

Well in that case a big thank you to you guys for your support! I’m glad you like what you’ve seen so far… :slight_smile:

And thank you @karl_jones for taking care of the issue! Do you have an ETA on the first 5.3 patch release?

1 Like