ObjectArrayList IndexOutOfBounds exceptions

phr00t · October 13, 2012, 7:07pm

I may have solved this by making sure two more things were done:

Make sure all controls (e.g. RigidBodyControl) are created in the thread the physics space was initialized in
If you do a rayTest, it cannot happen while shapes are being made in another thread – use a synchronized block

normen · October 13, 2012, 8:39pm

The last errors rather look like you added/removed objects twice, could it be you fixed something like that on the way too? Raytest, right… That bugger might basically cause all kinds of calls…

phr00t · October 14, 2012, 11:51am

Waiting on rayTest / shape synchronization causes lag in the rendering thread, which defeats the whole purpose of wanting them multithreaded in the first place. You mentioned native bullet shouldn’t have these problems, correct? Is this as simple as just using the native libraries instead?

normen · October 14, 2012, 12:18pm

@phr00t said:
Waiting on rayTest / shape synchronization causes lag in the rendering thread, which defeats the whole purpose of wanting them multithreaded in the first place. You mentioned native bullet shouldn't have these problems, correct? Is this as simple as just using the native libraries instead?

..and living with its bugs, yeah. Native Bullet isn't finished.

phr00t · October 14, 2012, 12:24pm

@normen said:
..and living with its bugs, yeah. Native Bullet isn't finished.

How "bad" is it? :P Is there some nasty known bugs, or just likely a bunch of unknown ones?

normen · October 14, 2012, 12:25pm

@phr00t said:
How "bad" is it? :P Is there some nasty known bugs, or just likely a bunch of unknown ones?

Its not done :) Especially collision still has issues.

phr00t · October 14, 2012, 12:34pm

@normen said:
Its not done :) Especially collision still has issues.

Welp.. guess I'm going to give it a go. I suppose finding bugs and reporting them will help move the libraries along? :D

normen · October 14, 2012, 12:53pm

@phr00t said:
Welp.. guess I'm going to give it a go. I suppose finding bugs and reporting them will help move the libraries along? :D

Sure but most collision stuff needs to be rewritten anyway because its a contribution, so I don't know how much single details really lead to solutions. But coding and building the natives yourself using our project and NetBeans is very easy too ;) Final move to Native Bullet is designated for 3.1.

normen · October 14, 2012, 12:55pm

… I’d rather look for a solution for the jbullet implementation to be clear

jmaasing · October 14, 2012, 1:02pm

@phr00t said:
How "bad" is it? :P Is there some nasty known bugs, or just likely a bunch of unknown ones?

Just a heads up if you're playing with rayTests, last I checked (a few days ago) native bullet reverses the hit fraction, so you'll get "far" reported as "near" and the reverse. Might save you a bit of frustration to know :)

http://hub.jmonkeyengine.org/groups/physics/forum/topic/raytest-difference-between-jbullet-and-native-bullet/

normen · October 14, 2012, 1:08pm

@jmaasing said:
Just a heads up if you're playing with rayTests, last I checked (a few days ago) native bullet reverses the hit fraction, so you'll get "far" reported as "near" and the reverse. Might save you a bit of frustration to know :)

http://hub.jmonkeyengine.org/groups/physics/forum/topic/raytest-difference-between-jbullet-and-native-bullet/

This is corrected in the sources but idk to what binaries it really went because the windows build for native bullet on our server is broken due to mingw issues :( It should be fixed in android and macos at least in RC2

jmaasing · October 14, 2012, 1:11pm

normen said:
This is corrected in the sources but idk to what binaries it really went because the windows build for native bullet on our server is broken due to mingw issues :( It should be fixed in android and macos at least in RC2

Oh, I'd better check again then, I'm on RC2-nightly linux. It ought to work then. Sorry for the false alarm.

phr00t · October 14, 2012, 1:47pm

@normen said:
.. I'd rather look for a solution for the jbullet implementation to be clear :)

I would too... I got the exceptions to stop, but at the cost of practically all benefits I was trying to achieve from multithreading. It really helps to be able to handle heavy physics calculations in one thread, while doing quick physics stuff in another... so far, it seems like jbullet just can't do this.

I remember reading about the rayTest reversal stuff earlier.. I can wrap the rayTest calls and switch the hitfraction value if needed, thanks for the heads-up. I'll let you know if it is still swapped now.

EDIT: Yes, rayTest hitfraction is still swapped on Linux 64 (if it is fixed for MacOSX, then my code won't work on MacOSX if I "fix" the swap for Linux 64?) :/

zzuegg · October 14, 2012, 1:58pm

A downside of using native bullet is that if you have an error, it fails silently without any error message. (At least on my build)

normen · October 14, 2012, 2:00pm

@phr00t said:(if it is fixed for MacOSX, then my code won't work on MacOSX if I "fix" the swap for Linux 64?) :/

correct

phr00t · October 14, 2012, 2:01pm

@zzuegg said:
A downside of using native bullet is that if you have an error, it fails silently without any error message. (At least on my build)

@normen said:
correct

So, there really isn't any decent solution for this :(

phr00t · October 14, 2012, 2:45pm

Actually, I should just build bullet myself and make a bullet natives jar, then all the latest fixes should be in it…

I’m going to build it and post a link to the bullet jars when it (hopefully) completes.

phr00t · October 14, 2012, 3:11pm

I think I’m close, but I get this error:

[java]-compile-bullet-sources-linux:

[exec] – The C compiler identification is GNU

[exec] – The CXX compiler identification is GNU

[exec] – Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc

[exec] CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):

[exec] The C compiler “/usr/bin/i686-w64-mingw32-gcc” is not able to compile a

[exec] simple test program.

[exec]

[exec] It fails with the following output:

[exec]

[exec] Change Dir: /home/phr00t/jme3src/-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc – broken

[exec] – Configuring incomplete, errors occurred!

[exec] jmonkeyengine-read-only/bullet-2.81-rev2613/CMakeFiles/CMakeTmp

[exec]

[exec]

[exec]

[exec] Run Build Command:/usr/bin/make “cmTryCompileExec/fast”

[exec]

[exec] /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make

[exec] CMakeFiles/cmTryCompileExec.dir/build

[exec]

[exec] make[1]: Entering directory

[exec] /home/phr00t/jme3src/jmonkeyengine-read-only/bullet-2.81-rev2613/CMakeFiles/CMakeTmp' [exec] [exec] [exec] /usr/bin/cmake -E cmake_progress_report [exec] /home/phr00t/jme3src/jmonkeyengine-read-only/bullet-2.81-rev2613/CMakeFiles/CMakeTmp/CMakeFiles [exec] 1 [exec] [exec] Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o [exec] [exec] /usr/bin/i686-w64-mingw32-gcc -o [exec] CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c [exec] /home/phr00t/jme3src/jmonkeyengine-read-only/bullet-2.81-rev2613/CMakeFiles/CMakeTmp/testCCompiler.c [exec] [exec] [exec] Linking C executable cmTryCompileExec [exec] [exec] /usr/bin/cmake -E cmake_link_script [exec] CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1 [exec] [exec] /usr/bin/i686-w64-mingw32-gcc [exec] CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o cmTryCompileExec [exec] -rdynamic [exec] [exec] i686-w64-mingw32-gcc: error: unrecognized option ‘-rdynamic’ [exec] [exec] make[1]: *** [cmTryCompileExec] Error 1 [exec] [exec] make[1]: Leaving directory [exec] /home/phr00t/jme3src/jmonkeyengine-read-only/bullet-2.81-rev2613/CMakeFiles/CMakeTmp’

[exec]

[exec]

[exec] make: *** [cmTryCompileExec/fast] Error 2

[exec]

[exec]

[exec]

[exec]

[exec]

[exec] CMake will not be able to correctly generate this project.

[exec] Call Stack (most recent call first):

[exec] CMakeLists.txt:7 (PROJECT)

[exec]

[exec]

BUILD FAILED

/home/phr00t/jme3src/jmonkeyengine-read-only/engine/build.xml:10: The following error occurred while executing this line:

/home/phr00t/jme3src/jmonkeyengine-read-only/engine/nbproject/build-bullet-natives.xml:569: exec returned: 1

Total time: 4 seconds

[/java]

normen · October 14, 2012, 3:17pm

The same error we get on the build server, yeah ^^ hf

Hint:

this does not work:

-DCMAKE_SHARED_LIBRARY_LINK_C_FLAGS=’’

-DCMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS=’’

-DCMAKE_SKIP_RPATH=ON

phr00t · October 14, 2012, 3:21pm

http://www.maniacworld.com/internet-high-five.jpg

See if I can solve this.. I think I'm at a standstill if I can't :/