1.5 1.6 1.7 - Camera Jitter

#61 Melv,

Odd, because I still get the jitter even with removing the lines in t2dSceneWindow::interpolateTick and t2dSceneGraph::interpolateTick and removing the lines from ITickable::advanceTime. (I assume you meant to remove the line from t2dSceneWindow:: interpolateTick; t2dSceneGraph is listed twice above). I didn't disable tick physics though.

Is there any chance there's also a Mac-specific issue at work here?

#62 Ken,

Sorry, I changed the namespace above to t2dSceneWindow. ;)

There's definatley a chance that it's a Mac-specific issue as always but I've not got any immediate thoughts on what that could be. Being as PC users have experienced the problem and assuming that this isn't a multi-component problem then my gut feeling is no.

What I'd like to do though is to try to seperate any potential for a poorly performing simulation from a potential problem with the tick physics and that's not easy to do without seeing first-hand on the system in question.

Part of this can be to try to accurately described the "jitter" e.g. its frequency, magnitude etc.

For instance, if I stress my system by applying a constant load to the CPU of say 75%, I'll get a continuous jitter on all objects of a fixed magnitude. If I setup a load that pulses the CPU then I'll get jitter pulses on some/most of the objects. If I run in debug-mode I'll get bad jitter as well. In these situations, if I increase the simulation frequency, I get worse jitter.

So I guess the inevitable questions:
- Is the system CPU-idle before you execute the demo?
- Does the box jump seeming randomly?
- Does the scene jump coincidental to the box moving?
- Is the jump a minor "twitch" or a major "leap"?
- What kind of CPU utilisation are you having during these periods?
- Do these jumps happen with ticking off?
- Is VSYNC on? If so, at what frequency is the monitor?

Sorry for all the questions but they may be all I can use to solve the problem unless I can duplicate it on one of my systems.

Anyway, I should stop monitoring my email and get some other stuff done. I'll be back later to work on it. :)

Thanks for you help Ken.

Melv.

#63 Also, I guess I'm using 1.7.0. Were any changes made that might affect this in 1.7.2? I was avoiding upgrading just because it takes a while to integrate all my changes.

I also will be out for a while but will be fiddling with it later this evening I'm sure.

#64 That's an interesting point. I'll review the changes between the two as a last resort. ;)

Melv.

#65 @Ken
1.7(.2) seems to be only changes to the builder interface. Except that, there's nothing new since 1.6 and I get also jitters with it.

@Melv
Thanks for taking the time ^^
I sent a more extreme test case to GG not long ago, which is my current project "IceWolf", it suffer a lot more from the jittering than any these little demos had.
If they (GG) hadn't already, I can shoot you a mail with the demo for testing.

#66 Anything you can provide to narrow down the problem would be most appreciated. I don't recall seeing it (IceWolf) on the internal bug-tracking system so please fire it to me (email sent to you).

Thanks for your help guys.

Melv.

#67 Could you guys give me an indication of what FPS you're getting?

Melv.

#68 On my pc (with a 100htz monitor), Ken's version of the demo runs at 100fps, not solid though. It sometimes lower a little (97/98fps), sometimes it seems it could have a correlation with the jitters but I really can't say for sure (I use fraps for monitoring FPS).

I sent the IceWolf demo. If it's not referenced, it could be because it could be hard to see what's going on as the game scripts are almost complete and running a lot of things at the same time. But it is a true game situation.

#69 Blush. Okay, so I had done something so that in t2dSceneObject::interpolateTick(), updateWorldClip() was no longer called. Fixing that, in fullscreen things move perfectly fine, nice and smooth, both for my game and Benjamin's demo.

In windowed mode with VBL sync enabled I still get odd flickers about every 1/2 second and very regular. They're less pronounced in scale than the jitters I was getting earlier though. With VBL off, it seems okay. The flickers don't seem to be overly affected by CPU activity although of course the odd burst of activity will cause larger jumps . I'm getting about 200-300 frames a second with VBL off, 60 with VBL on.

Lowering the smTickShift doesn't help and doesn't seem to affect the frequency. For kicks I've even tried pushing the smTickShift up to 12 and I still get the same flickers.

Setting disableSceneTick=true makes little difference in windowed mode but actually introduces very minor stuttering in fullscreen.

It's really difficult to tell what exactly is happening during the flickers. I think it's just one frame being displayed twice. I think.

Hope that helps. I won't be around much the rest of the night, but will do my best to answer any questions. Overall I'm much happier with the smoothness of the animation than I was a before the changes.

#70 Ken,

All info helps. To be honest, I've had a long day and a cold isn't helping either. I'm probably going to call it a night soon and do some more work on it in the morning.

I'll be working on it until I say otherwise. :)

Melv.

#71 One last thing ... in the demos, try setting the mount-force to "0" instead of "5" e.g. a rigid mount and let me know what happens.

Thanks again,

Melv.

#72 When I set the mount force to 0, everything still jitter while moving, except for the (player) object the camera is mounted to.

'night ^_^

#73 Ben, this might sound a little stupid, but when your player interacts with the world, do you modify his position at all? (i.e, %player.setPosition(X Y)). In the last game that I was making, I would update the player's position each tick to ensure that he stayed on the ground or in line with a wall. Even though the change was very small each frame, it was enough for a slight jitter to be noticed.

I now only apply velocities to my player and everything runs perfectly after implementing Melv's fix.

#74 I use only setlinearvelocity for the player. But, right now in IceWolf, I do use an object that moves instantly each frame for directing the camera position.
Maybe that's not helping the issue, but as I still get jittering when directly mounting the camera to the player, I supposed it wasn't really an important factor, too bad I can't try Melv's fix myself to verify it (I don't own a pro version).

Ah! I just realized Melv question was addressed to those who can actually try his fix :o, if so disregard my response.

#75 Phillip is quite correct in that if you continually change the objects position you effectively reset the ticking for that object until the next tick comes along and it immediately moves to the requested position. It's also important for objects that are mounted to that object.

In either case, it sounds like something that needs documenting.

By the way Benjamin, the demo looks very cool. :)

Melv.

#76 For all the help you've been giving with solving this issue I just granted you a pro version Benjamin.

Huge thanks Melv for putting your time into this :)

#77 Woaw! Thanks a LOT Matt, you rock \o/

@Melv
Okay, so I'll change this bit of my code by using moveTo instead.
(and thanks about the demos, you may understand why I want this jitter fix so badly =p)

Ok, now installing the pro version and updating the piece of code. Then let see how it run.

#78 Guys,

Had an emerging cold the last day or so and woke up this morning feeling worse than ever. I'll definately look at this later when I've got my mind in order. Don't want to make it worse! ;)

Still on it.

Melv.

#79 Benjamin,

One thing that is killing me in the demo is that for some reason I loose the controller settings even though my previous selection shows. I have to go in every time and set them up which really slows me down. Also I'm really crap at it and I can't seem to stay alive long enough to get to a position that's showing jitter.

It'd be nice to be invincible starting at the worst place for jitter! Is that easy to setup? Obviously this is assuming that the code modifications described above (which you can now make) don't solve the problem. :)

Melv.

#80 Guys,

The good news is that I believe I have got a case where I'm getting jitter even with the changes above (which are still correct). Tracing this it seems (in this case) to be related to particles. Obviously particles are expensive but there seems to be extremes of CPU time being taken on certain particles that are added to the scene. Because these are periodic "pulses" they don't affect the average FPS too much, just a slight bias.

Benjamin noted above that he was using Fraps to measure the FPS and whilst this works, there's a much easier method. If you go into TGB and select the background and then "Edit" in the right pane you'll see a section named "Debug Rendering". If you turn-on the "Debug Banner" you'll see a blue banner appear at the top of the screen that displays FPS as well as a host of other important T2D technical information. Note that you can also configure this banner using scripts (see doco). This was a feature that I added in the early stages of T2D development and can be extremely useful.

I've been using the demo provided by Ken and all was well until I added some particles. Obviously particles can be expensive but the hope is that they're designed so that they don't suddenly have expensive pulses of CPU utilisation. Interestingly there seems to be a correllation between the jitter and the value of "BinSearch" in the debug-banner. This would indicate that something is doing excessive broad-phases searches (collision/picking etc). I did notice that some of the particles have "collision bounds" which can be shown again using the "Debug Rendering" options.

I've tried adding lots of statics sprites to the screen but they don't seem to cause jitter. I suspect that something is indeed taking regular and extreme hits on the CPU causing these "hitches". When I say extreme I'm talking about a sudden prolonged simulation tick processing time, something that would probably not show-up using an OS CPU utilisation graph.

I'm wondering if jitter (post the fixes above) can be seen without any particles in the scene?

Tracing into the particle code I have found a particularly expensive portion that dynamically calculates the particles bounding-box. I haven't yet found what's causing the extreme broad-phases searches but that's a matter of time.

Anyway, thought I'd keep you updated.

Melv.