3.2.0 alpha phase

Development
21

Thank you it’s fixed on master and will be fixed in 3.2 alpha 2

2 Likes
22

Error!!!1111

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.

23

Mhh that’s strange …
What do you mean by

?
to my knowledge the sdk hasn’t been updated to 3.2 alpha1.

24

SDK is separate from engine and 3.2 is not official release, its a preview of before Alpha.

Caution: This is the earliest possible 3.2 build. If you want something more reliable have a look at 3.1.0-stable

25

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.

26

If you have a simple test case it would be really helpful

27

it was jme3test.bullet.TestBrickWall, as it was written in the logs

28

yeah but I can’t reproduce it, it’s working fine for me.

EDIT:

As explained it’s not using 3.2 alpha1 yet, it’s using an old master version.

29

Because it is probably a system dependent problem. Try on x86 machine. There are two different dlls for x86 and x64 systems.

30

it seems a problem only with x86 .dll library, x64 .dll works fine.

31

Which platform toolset was used to build x86 version of dll?

32

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.

1 Like
33

@sgold do you remember what that was fixing?

34

I guess the problem is here

We do need the actual world transforms even if ignored…
EDIT : this whole ignore transform and isInworldSpace thingy is really hackish…

1 Like
35

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.

36

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.

1 Like
37

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.

38

Alpha 2 is out

Some fixes and some enhancements in jme-vr stuff.

There are couple of remaining bugs in the gltf loader that are hard to crack, I’ll fix them before beta.

10 Likes
39

And… Alpha 3
A lot of fixes on the gltf importer.

10 Likes
40

There is a typo on 3.2.0-alpha3’s title

jMonkeyEngine 3.1 alpha 3