solved Are cameras not allowed to have moving parent meshes?

[fenomas]

I assume this is a bug, but wanted to check:

 

It seems that if you parent your camera to a mesh, and then move the mesh around, then any other meshes in the scene that are moving get rendered with extreme jitter, as if the camera and the other meshes are moving at different framerates.

 

Demo: http://www.babylonjs-playground.com/#1RRYJR

 

In that scene, the green sphere is stationary, while the red moves in unison with the camera's parent mesh. If you toggle the "bug" variable to move the camera rather than the camera's parent, the bug goes away.

 

Am I breaking some rule here or is this a bug?

[JCPalmer]

Fixed.  You really need camHolder to have its own mesh level, beforeRender. 

http://www.babylonjs-playground.com/#1RRYJR#1

[JCPalmer]

No I guess the green ball was still supposed to move.  Maybe you should use a follow camera, rather than parenting

[Wingnut]

Hi

I was doing a little experimenting, too.  Strange issue. 

 

http://www.babylonjs-playground.com/#1RRYJR#2

 

I removed the 'mesh' and parented the camera to sphere1.  And I turned on a skybox to see if I could learn more.  Skybox on, no jitters.  Skybox off... jitters.

 

Then, change scene.registerBeforeRender to sphere1.registerBeforeRender ... jitters gone.  Strange.

 

And the camera is acting strange...  seems to sort-of lag behind, even with camera.inertia set to 0.

 

*scratch scratch*

 

I've seen this issue before... on a crappy raycast car demo that I made, using debris I found in AltReality's github bucket.  WASD drives that thing. Sometimes you need to hit W multiple times, to get speed-up.  Then hit 'c' to change to car-cam, and do some turning.  jitter jitter jitter... from parenting the cam to the car.  hmm.  (You might need to click the canvas to get WASD keys working.)

[fenomas]

Fixed.  You really need camHolder to have its own mesh level, beforeRender. 

http://www.babylonjs-playground.com/#1RRYJR#1

 

I don't know what you're trying to do there, but "camHolder.registerBeforeRender" isn't getting called.

[JCPalmer]

I don't know what you're trying to do there, but "camHolder.registerBeforeRender" isn't getting called.

That's is probably because camholder has no geometry.  Just a cheap experiment. To see a change in behavior.  I do not know if mesh level beforereenders are done before or after scene level, want to see order did something.

 

I added geometry,  look now fixed link http://www.babylonjs-playground.com/#1RRYJR#5

[fenomas]

*scratch scratch*

 

Another workaround I found is that if the camera's own position changes every frame, jitter never occurs:

http://www.babylonjs-playground.com/#1RRYJR#3

 

Possibly something internal skips updating the camera unless its own (local) transform has changed since the last frame?

[GameMonetize]

JCPalmer is right. With no geometry, the system tries to cache matrix computation.

[fenomas]

Sorry, I don't understand what the takeaway is.

 

Is this the intended behavior? If so, what is the rule to follow - that all meshes must have geometry for their children to render correctly? (In which case, how do you make a container?)

Also, why is it important to use the mesh's registerBeforeRender instead of the scene's?

[Wingnut]

Hi guys.  Fen... I make containers with planes that are real tiny, or have their .visibility = 0  ... but I don't know if that's the approved way.  One can think of it as a "gizmo" for the group/container.

 

Also, I think deltakosh will have more to say about "the jitters" because... i found something interesting...

 

[all these use scene.registerBeforeRender().  No non-geometry mesh is used.]

 

http://urbanproductions.com/wingy/babylon/fenomas_jitters/index109.html

http://urbanproductions.com/wingy/babylon/fenomas_jitters/index110.html

http://urbanproductions.com/wingy/babylon/fenomas_jitters/index111.html

http://urbanproductions.com/wingy/babylon/fenomas_jitters/index112.html

http://urbanproductions.com/wingy/babylon/fenomas_jitters/index113.html

http://urbanproductions.com/wingy/babylon/fenomas_jitters/index114.html

 

To be brief... this "jitters" issue seems to have been introduced in BJS 111.  The 109 and 110 demos are clean, and 111-114 show the "drag".

 

The "drag" is moving the camera and red sphere #1 up and down... in BJS 111+.  That's not correct behavior. 

 

I think drag = jitters.  If I turn-OFF the skybox... the drag becomes jitters.  Let's test that.  Here's 110 and 111 versions WITHOUT skybox...

 

http://urbanproductions.com/wingy/babylon/fenomas_jitters/index110ns.html

http://urbanproductions.com/wingy/babylon/fenomas_jitters/index111ns.html

 

When I first load 111ns, I see "drag" (red sphere moving up/down a little, but smoothly) .  Then I alt-tab to a new window and then come back, and it turns to jitter.

 

Yuh yuh yuh... we got trouble... right here in River City.    110 clean, 111 jittery.  The adventure begins.  But I'm not going to jump to any conclusions.  Same results seen in both my auto-updating IE, and in my FF 30.0.

[GameMonetize]

And we got a bug!!! I'll fix it for the next commit

[fenomas]

So the original behavior, with the camera parented to a mesh with no geometry, wasn't a bug?

[GameMonetize]

It was

you can now check your link. it should work

[fenomas]

DK or Raanan,,

 

Can you point me at the commit that fixed this?

 

The same issue is still happening in my full project, even with current daily builds, but I'm having trouble isolating a test case.

[GameMonetize]

I think it was this one:

https://github.com/BabylonJS/Babylon.js/commit/15713594184434624ec02295ca6f9300e5b16442

[fenomas]

Thanks - I found my issue and it wasn't a bug in BJS.

 

 

With that said, that commit is clearly broken, isn't it?

   if (this._parentRenderId !== this.parent._currentRenderId) {      return false;   }   this._parentRenderId = this.parent._currentRenderId;

It's trying to cache the parent's ID, but it returns before doing so, so that last line will never be reached.

 

It should probably be: 

   if (this._parentRenderId !== this.parent._currentRenderId) {      this._parentRenderId = this.parent._currentRenderId;      return false;   }

[GameMonetize]

Good job catching this one

[davibail]

Hi everyone,

I found the same issue of jitters with a camera attached trough parent with a moving mesh. Here is the working example:

http://www.babylonjs-playground.com/index.html#PT66R3#3

The jitters seems to affect only the moving mesh and only in rotation. Is that a bug or am I using the camera and mesh in a wrong way?

Strangely enough, the same weird fix still works.

[RaananW]

Hi @davibail,

What weird fix solves this? could you show it in the playground?

Side note - try removing event listeners in the playground, otherwise each time you press run they register again (causing the function to execute n times, n being the amount of times you press "run"). You can do that by implementing the scene.onDispose function (for example)

[davibail]

It is the line just after "//fix" in http://www.babylonjs-playground.com/index.html#PT66R3#7

When this line is commented the box flickers when rotating. When uncommented it has smooth rotation.

[RaananW]

I see. It is all about updating the camera's view matrix. This is the real fix: http://www.babylonjs-playground.com/index.html#PT66R3#8

Need to see why the view matrix updates too late. seems to me like it updates before the parent updates its position. or that the cache prevents it from updating at the right time. 

[GameMonetize]

Yeah cache issue..I'm on it

[GameMonetize]

Ok found the reason

The locallyTranslate function force a flush of the cache because it needs the update world matrix. Then the cache thinks that everything is up to date

But no worry, here is the fix:

https://www.babylonjs-playground.com/index.html#PT66R3#10

 

Just need to flag the mesh as dirty again

[adam]

or translate before rotating:

https://www.babylonjs-playground.com/index.html#PT66R3#11

[davibail]

Thanks,

I will try that as soon as possible