BatchNode bug

Hi,

I have found a bug with BatchNodes. My test object consists of 1 BachNode and 6 sub Nodes. Every sub Node has only 1 Geometry (I use this construct to realize rotation points).
The model is animated (spatial animation - animation controler from jme). After some time (10-15min) the polygons or the whole sub node/geometry of the batched node change their position slightly. The test models only rotates their sub nodes within this time.

How is that possible? o.O

screen:

I think I have seen something similar to this. I had a batch node of spatials that had their locations updated every frame. The updates would, for the most part, just keep the same translation as before, but this would cause a slight shift in the geometries over a period of about 20 seconds.
If you can boil down a quick test case @nehon and/or I could take a look into it.

uhg…that’s really strange…

Yea I only noticed when I was updating my entity’s translation every frame even when the translation didn’t change. It was only noticeable with some fences that I had, gradually they shifted apart. I fixed it by not updating the translations every frame if they did not change, this provided a little speed up, and then I completely forgot about the issue until now =)
It feels like there might be a precision error happening with how gradually the objects shifted. And when I rebatched, they were fixed: the objects went back to their regular positions. Only to begin drifting again.

Sounds like accumulated rounding errors?

@zarch said: Sounds like accumulated rounding errors?
yes...a test case would be cool

ok the test case code is not very clean. It consists of some code snippets from my project (I am open to any suggestion for the improvement of my code).

You can see the bug if you fly around the testmodel and then you must as close as possible to the model. Take your hands of the mouse ans look :smiley:

screens:
20:06

20:09

test case (runnable jar included!):
http://www.alrik-online.de/BatchTest.zip

EDIT: look at every leg. Not every leg is drifting! Hope this test case helps :slight_smile:

1 Like

Ok I’ll look into it

1 Like

ok…I found the issue…It’s kind of a design flaw.
The batch node computes the offset transforms from previous frame each time you move, and applies them to the mesh.
The problem is that it seems there are some accumulation errors and if you constantly update the spatial pos on each frame (even if it’s the same position) the error starts to accumulate and become visible.

I managed to make it work properly by generating a bind position for the batch mesh and apply the world transform to it instead of the offset since last frame. But it kind of broke all the test cases :stuck_out_tongue:
Also this solution will use a lot more memory…
I’ll continue to dig into it.

3 Likes

@nehon if we ever meet in person I will have a whole bunch of really good micro brew beer for you! =)

@nehon: Cant you simply use the meshes from the original models?

@Momoko_Fan said: @nehon: Cant you simply use the meshes from the original models?
Yep that's what I was thinking. At least now those buffer will be kept for a reason :p
@Sploreg said: @nehon if we ever meet in person I will have a whole bunch of really good micro brew beer for you! =)
:D micro brew beers FTW \o/

Micro brew beer time! this issue should be fixed in last SVN
Could you please test?

2 Likes

looks good … no bugs until now :slight_smile:
great job, thanks! :affe:

1 Like