1.5 1.6 1.7 - Camera Jitter

#161 Melv,

I noticed yesterday a new (for me anyway) type of jitter when I introduced some moderately-sized rotating objects. I fixed the problem fairly easily by adding some rotation interpolation that parallels the position interpolation scheme.

I know you may have already fixed the issue in your workings with Benjamin, but if not I can send you the code. The basics were easy, but there were a couple gotchas that took a bit of time to track down.

Anyway, looking forward to your updates!

Cheers,

::ken::

#162 If you want to send me the code and your fixes then I'd be happy to look over it and thanks in advance for the help!

Melv.

#163 Ken,

I presume all you're seeing is the large angular movements at the extents of these large rotating objects and not jitter but just the low-frequency updates that occur on rotations? I just wanted to be clear and be sure that you're not seeing something else.

This, as you seem to indicate, is simply because there's no interpolation on rotation. I made a decision not to do that and I'm sure there was a good reason but for the life of me, I can't remember why. Being as we're updating the world-clip, it shouldn't save any time not interpolating rotation.

Be sure to send your script example along if you can.

Thanks!

Melv.

#164 Melv,

I've sent you an email with the changes.

::ken::

#165 Ken,

Just popped in to say I got your email and thanks. I'll not get a chance this evening but I've got all day tommorrow to have a look at it.

Thanks again,

Melv.

#166 I know these things are always hard to say, but can anyone of GarageGames give a rough timeframe when Melvs fixes will be incorporated into an official release?
And if not or it will take some more time (more then a few weeks) is there a way that we can get our hands on Melvs code changes and incorporate them into the engine ourselves?

#167 Hi,

First off, sorry to bump this topic even though I don't have any answers about the camera jitter issue. However, I think I just figured out something interesting today, that may in fact help some people with jittering/stuttering issues:

My project is currently a level with 4 tilemaps, all of which have tiles that contain collision polygons (around 500 tiles with collision in total), about 100 more non-moving scene objects that have "receive collision" turned on, and a player and 12 enemies that have "send collision" turned on. SUMMARY: I have 13 objects that have "send collision" turned on.

I noticed that my game was starting to stutter every once in a while, and so I turned the debug banner on (after having it off for a week or so). I was appalled to see that BinCollis was always 2000+ every frame, and BinSearch was often higher than 30000 (yes, thirty thousand!) every frame. Now, at home I have a very fast computer, so never noticed any real issues, but on my laptop, all hell broke loose. There was a ton of stuttering, things just weren't moving smoothly at all, and I couldn't seem to figure out what was going on.

SOLUTION: After systematically removing everything from my scene, except for the player object, I still had BinCollis reporting 125! That didn't seem right. So I created a new project, and threw in 20 copies of my Player object, all with "send collision" turned on, and BinCollis was around 30. That seemed about right. So what was the difference? Turns out the default camera size is 100x75 (most people probably knew that already), but in my project, I had changed it to 1280x1024 because I'm so used to working with those types of "logical sized units". So all my player and enemy objects were around 150x200 in size. In the new project, the player was only about 15x20 in size. And that's what the problem was!!! I scaled everything in my project (objects, tile layers, everything) down by a factor of 10 (ie: something that was 100x100 became 10x10), and changed nothing else, and magically my BinCollis was never higher than 60, and BinSearch was never higher than 200.

I have no idea if this "discovery" is old news to anyone, but I'm posting it here in the hopes that it might possibly help someone else avoid this issue that I ran into. I'm not sure why things behave this way (I'm sure there's a good reason somewhere!), but the size of the objects was directly proportional to the BinCollis and BinSearch figures. It just sounded like maybe that was the problem that Benjamin was discussing with Melv in mid-February in this topic, when Melv mentioned:

Quote:Second level, per-frame...

213 objects in the scene
2314 objects in bins encountered from 500+ collision send checks
182 objects intersect collision send region (potential collisions)
32 actually collide with 63 contacts (actual collisions)

... giving a 17.6% efficiency for collisions.

Note that 213 objects in scene but 2314 objects encounter for collision searching. This simply means that the same objects are being checked again and again by different objects.

Note that the "efficiency" is comparing potential to actual collisions. In other words, 82.4% of the collision checks are waste time. In time the 82.4% is spend checking 150 objects that don't collide.

It was the "213 objects in scene but 2314 objects encounter for collision searching" that raised a red flag, because that's almost exactly what was happening to me - each object I had that had "send collision" enabled was being checked multiple times - in my project around 100+ times each! I'm going to take an educated guess and say that maybe the collision system breaks down larger collision areas into smaller ones for some reason, so maybe it's breaking huge collision polygons/areas into many small ones for each object? That's the only explanation I can come up with.

#168 Melv's physics/collision theory paper covers this in depth, but effectively yes, your objects were occupying probably up to a dozen or so bins per object, instead of just 1.

#169 Mark,

Thanks for writing that up. It's really nice to see someone using the built-in metrics in a positive way.

There's certainly no decomposition of collision areas, the only conceivable reason for doing so would be to convert a concave polygon into multiple convex ones but we only support convex. Stephen is correct as you are in that it's down to the broad-phase collision (bin-system) producing more work than it's saving. It's a classic compromise that needs tuning if you stray too far from the defaults.

Again, nice write-up!

Melv.

#170 So my project has been suffering from jittering when the camera moves for quite some time, I've recently moved to 1.7.3 hoping it would be gone but it's still there.

I've just made a simple demo using the unaltered 1.7.3 executable to see if it was caused by one of my engine modifications. It isn't, the same jittering appears on a very simple scene, I'm providing the demo here in the hopes that someone will find the source of this issue as it's quite detrimental to my game but I just can't seem to isolate the cause.

JitterTest

edit: fixed url.

#171 Well, on my system it runs fine with around 250 FPS. There seams to be some jittering visible with the edges of the walls but I think it has to do with that VSYNC is not turned into account. When you look at the edges of the ground then there is no jittering at all. So my guess it is strongly media related.

#172 Nelson,

The jittering would be mostly eliminated if you used "SMOOTH" filtering instead of "NONE" in the wall image map. Its not perfect, but it looks better in my opinion.

#173 @Nelson: I don't see any Jittering at all. Runs perfectly at about 500FPS on my system. I even turned on SMOOTH filtering to see if it would make a difference and I didn't notice any change at all.

#174 I had noticed it is much less obvious when using the smooth filtering, but the reason it's turned off is that I'm going for a "pixel art" style, which is known for it's pixelated edges, and even with it on the jittering is still noticeable.

The test is running at around 500 fps on my system as well, but the jittering is so bad that some black lines dividing the wall sections become hidden behind other wall sections, even after the screen stops moving. I tried turning VSYNC on but it doesn't appear to have any effect on the jittering.

I thought it might be related to some float precision problem, so I tried using mFloatLength to round the numbers to integers, that seems to help with the jittering between the wall sections as they jitter together as one, but you can still notice their jittering back and forth in relation to the tilemap.

It's odd that some of you don't see any jittering... it's pretty obvious on my PC(and a couple others I tested it on).

#175 Deozaan,

If it wasn't noticeable at all you must have changed the filtering in the level builder? That got me at first too. You have to change the filtering mode in the datablocks script in the "game" folder.

Nelson,

I like pixel art. The only problem is that the rendering gets a little whacky without any filtering when you rotate an object. As far as jittering, what's your videocard? I get artifacts (not even one pixel lines around the bottom and right edges) around image maps if they are shrunk or zoomed out enough.

#176 Kevin: Yep you're right. In fact, running it from the Level Builder I also didn't even see the TestJitter Button. It looks a lot better with the smoothing turned on. But I still don't see any jittering problems.

Nelson: As far as pixel art goes, it's important that pixel art isn't resized, otherwise you get pixels that disappear or look bad when being moved or rotated. I'm not sure, since I don't see a jittering problem, but it seems to me that you may be confusing "Jittering" with pixels disappearing and reappearing.

Maybe you could record a video of what's going on?

#177 Okay, here is a gif animation I just created that shows the problem. I panned the frames to keep the walls still to make it easier to see.


Also, as far as I'm aware the graphics aren't being resized, I'm using a 1:1(768x768) aspect ratio on the scenewindow and using the original frame size as the object's size.

#178 Okay I see it now.

The strange thing is that when running the demo from within the Level Builder, I see no jitter at all. Just some really bad looking pixel problems with the images being resized.

But when I run it from the standalone exe (or from Torsion) without smoothing on, I can see the jitter on a couple of the walls.

I recently did some tests where the camera was mounted to the player and had similar jitter issues. I wrote about it here. I don't know if that's any help, but maybe it will lead you in the right direction.

#179 Guys,

I think we should really start a new thread here and the reason is this: this thread has already had several problems posted to it and they've all been called jitter which, although doesn't have a specific definition, is being used for very different visual issues.

I don't doubt you've got an issue and I'll do my very best to help you solve it but you really do need to describe what your problem is in detail rather than referring to it as jitter.

Unfortuntately, the GIF animation in the post above doesn't seem to be showing.

By the posts so far it sounds like you're referring simply to aliasing issues when rendering. Because the graphics card is rendering graphics not only at exact pixel locations but at sub-pixel locations, elements of your art can be renderered across multiple pixels. If the object is moving then this will constantly change.

Anti-Aliasing.

Of course I'm guessing what the problem is but I'd still like to help. The original use of jitter (at least in this thread) is one of screen juddering caused by timing jitter.

Melv.

EDIT: GIF showing now!

#180 I can now see your problem and I'm looking at why it's happening now. I'd like to confirm that this has nothing to do with the original post, has nothing to do with tick-physics, has nothing to do with mounting etc etc.

To at least provide something useful for now though, be aware that the container system in TGB is setup to use 256 x 20 (world-unit-sized) bins. If you increase from the 100x75 and have much larger sized objects then you should consider increasing the size of the bins. A complete description of why this is important can be found in a document I put together on TDN here.

You should be aware though that with a viewport of 768x768 and the default container-bin size of 20 you'll get 768/20=38.4 or 39x39 = 1521 container bins searched per-frame just for the camera to see what's in the frame. An object moving will have to update lots of bins as well. It's all about the size of the objects though, not so much the viewport size. It becomes extremely important when you start using collision detection and/or have lots of moving objects.

I would consider up-scaling the bin size by at least the relative object scaling so maybe something like 150 instead of 20 maybe even 100. In the debug banner you can see all the "BinSearch" getting approx 1500-1600 added each frame. The document above will described why this is important though.

I'll continue to have a look at the issue.

Melv.