1.5 1.6 1.7 - Camera Jitter

#81 Okay, so this is becoming more like a blog than a bug-fix but it helps me think it out...

I added some expensive particle effects (default effect in Kens demo). These, on my system, definately cause periodic jitter during the particle rendering phase. If I allow the particles to work as normal but disable the rendering then everything is fine at least showing that expensive particles (lots of them) are mostly limited by the GPU or at least in this case.

I'm going to trace to see what the iTickable interface class is doing in this test case and see if there's any way that the tick-processing can be further improved.

Melv.

#82 Melv -

I back-burnered my TGB project some time ago (partly due to this problem), but I do intend to pull it out of mothballs once my current project is done. I really, really appreciate the effort you are putting into it to fix it. Thanks!

#83 @Jay: If I can fix this and ressurect some projects at the same time because of it then that's a good motivation. :)

@All:

I've been looking at this further and it's starting to look like I might have to reconsider using iTickable as the only source of timings. At the moment all objects will render at the interpolated time but of course the model assumes that they all update nearly simultaneously.

I remember discussing this with Clark @ GG some time ago. The idea is to do the interpolation just-in-time within the render function. This can be done here because the interpolation doesn't actual persist state so if the item isn't actually rendered then it doesn't matter. The end result might actually be slightly faster as well.

Not an easy change though. Ho Hum ... onward and upward.

Melv.

#84 (sorry, it's a little late, but here I am, I had to setup the c++ environments, then I had to take some sleep)

Quote: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.

I just saw that, it's happening only on 1.7, the save function doesn't work anymore on movemap, I don't know why it was removed, and how else the guy who did this would expect me to save the controls O_o, I don't really have a solution to that right now, so I'll quickly put together some default controls that set itself automatically. But this is a bug that need to be addressed.

As for the camera code update, I will send it to you too, but strangely, using moveto on my camera object has a very negative impact on FPS, so acknowledge the fact that I would have to change it in the future.

I tested the source changes on both my game and the demo test case, it still jitter, a little differently, but still (and because I have this strange FPS slowdown on icewolf, I can't really say clearly how the jitters play in all of that). I'm making a little patch, that also have a level without enemies, sending it asap.

About the particle, you make a great point, I do have a very large amount of particles anytime on my game (took advantage of it in the old 1.1.x times when it could support a large amount of them without any difficulties), so it must explain a lot of things, especially why I'm the first one to have suffered so much from these jitters.
Maybe disabling the "ticking" of the particles could help (just like how the particles behaved before the 1.5 update), and (at least for my case) it could also look better xD

#85 Benjamin,

I had a quick look and I couldn't find any changes on ActionMaps. There's still a "save()" method call. Of course I presume this is what you mean. ;)

There's a strong indication that the ticking can be sensitive to quite expensive objects such as particles. Of course particles could do with having batching implemented, something that's long overdue.

It's certainly possible to exclude certain objects from interpolation but in the case of particles these don't interpolate because it'd be simply too expensive at least in the way its setup now. That said, they are based upon t2dSceneObject so they do interpolate basic physics state but the particles themselves don't.

It'd be interesting to turn-on the debug-banner in your game and see how many particles are alive. "ParFree" is how many are allocated (not alive) and "ParUsed" is how many are active (updated/rendered).

It'd be very helpful if I could monitor the debug-banner in your game.

A quick check to see if it's the particles that's causing the jitter would be to inject a "return" at the beginning of the method:

void t2dParticleEffect::renderObject( const RectF& viewPort, const RectF& viewIntersection )
{
    return;
...
}

This would stop all particles rendering. Of course, it could still be the particle update in which case you would also inject a "return" at the beginning of the method:

void t2dParticleEffect::integrateObject( const F32 sceneTime, const F32 elapsedTime, CDebugStats* pDebugStats )
{
   // Call Parent.
   Parent::integrateObject( sceneTime, elapsedTime, pDebugStats );

    return;
...
}

I definately think that the way to go is to calculate the interpolant as part of the render-loop though.

Melv.

#86 Well, in some places, average ParFree can be up to 3000+ and ParUsed 1000+, as almost everything in my game world emit particles at some time, a lot of them.

I did the no-particule change, I see no particle, but it still jitter (both with indirect mounting and with direct mounting to the player).

#87 In fact it's like if the camera movement is limited to 32ms update or with very little jitters that happens every two frames (or something like that), sometimes it can lead to believe the movement are normal and "smooth", but in fact it could behave a lot more smoother (the difference with 1.1.3 is very noticeable), and it gives the false impression of lower and limited FPS when it is not (I'm speaking about how it behave in my game (with or without indirect mounting), on top of the "big" jitters). It's hard to explain but I guess you can already see it anyway.

And for the action map, it is really a 1.7 bug, simply try to save any actionmap with the save function to any destination, it will tell you that it is unable to open the file for writing no matter what. But this subject would fit on its own topic.

#88 Benjamin,

Got your latest download no problem.

I'm noticing some potential performance hogging things in the debug-console. One thing that threw me was that I had permanently turned-on the debug-banner in the executable and I was getting a very odd debug-banner. It seems as if there are two t2dSceneWindows overlaid? Is one from the menu? That seems to be there when the game is being played. This shouldn't cause too much of a problem but it is being rendered whilst the game is running!! What I want is to turn-on all the debugging options including link-points, bounding-boxes, collision-boxes etc. I can hack that here though.

Anyway, I tried the "no particle" one and the particles still appear. Not a problem as I did an executable myself to do it but I have to ask if you've seen it without particles? I presume you have and it's just the wrong exe sent. :)

void t2dParticleEmitter::integrateObject( const F32 sceneTime, const F32 elapsedTime, CDebugStats* pDebugStats )
{
 return;  // <- Add me here.
...
}

Looking at the paricle-count of 1000 doesn't sound like much but it is quite alot when you consider what's on the screen. It would certainly waste alot of CPU time, especially on low-end systems. I suspect that this is just the snow? Is there one particle-effect spread across the whole level? You could consider slightly reconfiguring this emitter to track the screen and be slightly wider that it. Also you can set the particles to not track the emitter so that when the emitter/effect moves, the particle don't move with it which is important for snow/rain etc. Anyway, this would mean that you could easily cut the particles down to a very small fraction of what they were before saving buckets of CPU time.

The power of the particle-system is also its undoing. If you want very simple effects then you're still paying some of the price of the other features although that's been reduce to a small amount. I've been thinking that it'd be nice to leave the existing system but create a bunch of standard modifiers that use the core particle engine but only have specific concrete parameters so you can have a "SnowEffect" or "SplashEffect" etc. Anyway, I digress.

Another metric in the debug-banner that is worrying me and I'm going to see if I can figure out what is causing it is that you've got a very high "BinCollision" and "MaxCollision" count on the order of 2000+ in the first level and 2300+ in the second. The "BinCollision" shows you the instantaneous bin-collisions and the "MaxCollision" well the maximum ever encountered.

"BinCollision" is a metric gathered in the method U32 "t2dSceneContainer::findPotentialCollisions()". Its purpose is to monitor how many objects are found (broad-phase container system) all collision-check operations. The calls which use this process are "castCollision", "castCollisionList" and "checkCollisionSend". The first two are synonymous with their script equivalent where "checkCollisionSend" is used by objects that are sending collision irrelevant of whether they collide or not. These 2000+ bin-checks are presumably returning objects, none of which may be interested in collisions but it's waste time. Also, it gives you an erratic simulation from frame to frame.

I'm obviously saying this without understanding how the scenes are setup but I am worried.

At first I suspected that it's the tracked-robots making lots of calls to "castCollision" but after killing them (and shouting my war cry) the figure didn't go down so I suspect that it's the standard collision-send.

Why am I not talking about tick-physics? Well, no matter how the tick-physics is implemented it can't smooth-out lots of eratic CPU work so getting these things out of the way can mean that we can focus on any potential problem that's left. Also, it means that your game works faster so it's all good. :)

Melv.

#89 All the information below is from the debug-banner, not some secret method I hold to myself. :)


Further investigation reveals that on the first level, per-frame...

275 objects in the scene
2045 objects in bins encountered from 500+ collision send checks
427 objects intersect collision send region (potential collisions)
59 actually collide with 115 contacts (actual collisions)

... giving a 13.8% efficiency for collisions.

If you count the player and a few NPC's roaming the level then I'm wondering if the scenery is sending collisions when perhaps the player/NPC's should be instead?

Again, I'm trying to remove any potential for bad CPU utilisation that causes these jitters.

Melv.

#90 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 might be worth us discussing your collision setup? Do you want to do this off-forum then come back when we're talking about ticking?

Melv.

#91 My first guess here would be that all the "static" scenery has "send" collisions enabled when perhaps they only need "receive" collisions e.g. the player/NPCs colliding with them. Scenary that doesn't move shouldn't need to check for collisions.

This may not be the case but I cannot think of anything else in the scene that would cause so much work.


It'd be great if you could check these numbers as I've got a stinking cold (sniff sniff) so who knows what my brain is tell me.

Melv.

#92 Back!

@Melv
hum about the nopart exe, I copied 2 time the same exe by mistake, I do have an exe without particles ^^'

There's about 10 scenegraph here, one for the menu, and the others for the parallax backgrounds, but none of the additional scenegraphs have any colliding objects to my knowledge.

About the collision bin, this is very odd. The statics objects (mainly floor) are already only in receive mode. So it must be something else... It surprise me, because I've been trying to be cautious about what collide with what

I have one big trigger (that's 2 time the size of the screen or so), this trigger is the one who activate or deactivates the enemies and other stuffs that moves (so only the things who are close are actives, you can see it if you set a wider zoom on scenewindow2d), the intent here was to have better performances, but it seems this trigger is colliding with everything anytime. But if I delete it, it reduce the collision bin by 200, so I suppose it's part but not the main problem.

I'm currently trying to see what else could be colliding so much, because beside the player and this trigger (and bad guys when there's some of them), there should be nothing else. It seems I messed something and didn't know about as it had no incidence in 1.1.3.

PS: and about the snow, it's already following the screen and not on all the level, but it must be large enough so that it's a believable snow as you run.

#93 Benjamin,

Because of the sophistication of the collisions it's obvious that you've got a good grasp on how it all works so I was suprised when I saw so many collision-checks.

At the moment I can't check the detail of how it's setup so all I can do is change the underlying executable. It'd be nice if your F11 turned-on all but the bounding-box debugging output rather than the banner-only. If I do this in the exe, I'll get all of your scene-windows rendering onto of each other.

It is hard to judge particle-density but with 1000 particles being reported it could be that they're living too long?

Again, this is slightly off track but if I can discount some of this stuff then hopefully we can focus in on the root cause.

Do you want to take this part off-board for now?

Melv.

#94 Maybe we should continue off-board, this is (still related but) off-topic.

#95 For everyone else, I'll post back any relevant findings that relate to this thread directly.

Watch this space.

Melv.

#96 Melv,

You are the man. Good to see you around again! Hope you guys can figure out this problem -- I've been dying to play a demo of Benjamin's game -- especially if it has parallax scrolling layers. That's some code I'd like to get my grubby little paws on.

Good luck,
Kevin

#97 Thanks Kevin.

I personally don't get jitters in Benjamins demo and I've got a little distracted playing it. ;)

I've just got to figure out why Benjamin (and potentially others will) get it.

... and did I mention that the parallax scrolling layers look cool, especially the foreground ones? :)

Melv.

#98 Wow, want to see some huge jitter? Using my version of Bejamin's test case, insert the following code into createTestSquare() in game.cs:

$squareSpriteTwo = new t2dStaticSprite() { scenegraph = scenewindow2d.getSceneGraph(); class = testSprite; };
    $squareSpriteTwo.setImageMap (testSquareImageMap);
    $squareSpriteTwo.setSize (4, 4);
    $squareSpriteTwo.setBlendColor (0, 1, 0);
    $squareSpriteTwo.mount(player, -2, 0, 1000, true, true, true, false);

Now move the player. The higher the mount force, the greater the effect. Setting disableSceneTick=true removes the huge stutter (but as before, leaves some llittle jittering behind).

I only noticed this because in my game the player sprite is mounted to the mouse and objects are mounted to the player. When the mouse goes outside the window bounds, the player sprite stops at the edge fine but anything mounted to it continuously jumps around, even if those objects are mounted with force 0.

#99 Just to be clear, is this using an executable compiled with v1.6+?

Melv.

#100 Yes. And smTickShift also has to be the normal 5. The green square lags about 1/5th of the window behind, catches up then incrementally falls behind again about twice a second. The effect's not very noticible at smTickShift 2.

I also get the same effect with zero mount force if the parent moves very quickly.