SEVERE: main() method had exception: jme3test.bullet.TestBrickWall
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at jme3test.TestChooser$2.run(TestChooser.java:270)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.UnsatisfiedLinkError: D:\Projekty Visual C\JMonkeyProjects\JmeTests2\bulletjme.dll: Nie można odnaleźć określonej procedury
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at com.jme3.system.NativeLibraryLoader.loadNativeLibrary(NativeLibraryLoader.java:683)
at com.jme3.system.JmeDesktopSystem.initialize(JmeDesktopSystem.java:348)
at com.jme3.system.JmeDesktopSystem.newContext(JmeDesktopSystem.java:271)
at com.jme3.system.JmeSystem.newContext(JmeSystem.java:162)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:461)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:424)
at com.jme3.app.SimpleApplication.start(SimpleApplication.java:125)
... 6 more
There is something wrong with bullet on x86 machines. Can anyone confirm or reproduce it?
Test case:
I just installed clean sdk 3.2 and ran one test project.
Downloaded it from here: Releases · jMonkeyEngine/sdk · GitHub
Anyway, I had that problem before trying to run Space Shift Editor which was based on 3.1, but I forgot to report it. Now I have it again with JMonkeyBuilder, and this time I tested it with some simple JME application.
So I found a bug with the current master. With the commit hash 0137670487e79f554f18dd9b8504b7743574bfbe there was a change to ignore transform that broke particle emitters with the world space flag. Basically all of the particle effects with the World Space flag on are completely gone (or I would imagine in the wrong place given the commit). I’m not exactly sure how to go about fixing it since I don’t know what it was trying to fix.
As far as I know, reverting PR 746 won’t break anything. There’s a slight performance benefit to skipping Spatial.checkDoTransformUpdate when the transform is ignored. The main rationale for the change was that it seemed logical for localToWorld(), worldToLocal(), getWorldScale(), getWorldTransform(), and getWorldRotation() to apply/return identities when transforms are ignored.
I’d like to understand why a particle emitter would utilize an ignored transform; I’ll dig into the code and see if there’s an easy fix.
The relevant test is TestMovingParticle. The particles should “trail” behind the source of the emitter. With your change all the particles are moving with the emitter. I looked into it, and I’m not sure why the ignoreTransform is set on the emitter though… emmit in world could be separated from this… @Momoko_Fan any insight on why particleEmitter need ignore transform when emitting in world space?
That said @sgold now that I looked into it closely, the fact that world transforms return identity when ignoreTransform is on seems wrong to me.
The ignoreTransforms is essentially ignoring Parent’s transforms, but the geometry still has world transforms which are its local transforms.
I guess they don’t strictly require it. It just means that the particle mesh must apply the inverse world transform to the particle prior to writing the vertices into the mesh, hence negating the effect of the transform. The ignore transform is merely a shortcut to avoid doing that, but it turns out the simplification in that part of the code causes complexities in another.