I managed to successfully build the jME3 bullet natives to the latest release, 2.81:
LINK REMOVED, NEW LINK BELOW
The current release of jME3 native builds have messed up physics ray tests (e.g. the start & end positions are swapped on Windows & Linux, but not on MacOSX). However, these new builds do not have that problem (and probably contain lots of other fixes). I was NOT able to build the latest MacOSX native, since I was building on Linux, but @normen believes the Mac native build may already be up to date. I’m hoping this gets into the main jME3 repository, but until then, you can use this JAR instead of the pre-packaged one!
May you please build 2.81 for consistency, now that we have that build for Windows & Linux? I may be able to grab a Mac at work for building, but it won’t be until mid next week…
I just realized the 32-bit Windows natives have NOT been updated and still have the raytesting swap problem. It looks like the 32-bit libraries don’t build on linux, since this is all that is under the build script for that particular library:
[java]
[target name="-nativelib-linux-mingw"/]
[/java]
@normen, isn’t it possible to build the 32-bit libraries with mingw on a 64-bit machine? I’m just installing mingw32 on my linux box now, I’ll see what I can do… but how do you build the 32-bit library? Can you offer any help on building it?
My son has been sick the past few days, so I haven’t been able to get to building the latest MacOSX libraries… but getting a 32-bit Windows library is more important now!
Success! Looks like I got the 32-bit Windows libraries to build correctly – but I don’t have a 32-bit version of Windows to test… so please test it!
(note: greater than/less than signs have been changed to { } so it would display properly)
(double note: variables using ${…} were not replaced greater than/less than signs)
I had a player with a 32-bit Windows machine confirm the problem is fixed & these natives are working.
I’ve been daddy daycare this week, and I’m not sure if I have access to a Mac to build v2.81… @normen, can you build v2.81 for MacOSX, or at the very least, get the updated native builds into the main jME3 svn so everyone can benefit?
Nope, nobody should “benefit” from the bugs in native bullet. I also don’t know why you didn’t build the version that was tested (2.80) then you wouldn’t have to ask me.
You already include the buggier version of native bullet now in jME3. How is it not a benefit to put in an improved, updated version of the natives? Personally, I haven’t noticed any bugs in the v2.81 builds after lots of testing. I already did the hard work of building the natives, I’m just asking nicely if they could be put into the main jME3 svn for everyone else. Keep in mind I had to use the native bullet builds for multithreading, so it’d be unfortunate to see you abandon them.
Also, if I’m going through all the trouble of building the natives, why wouldn’t I build the latest stable release available?
I hope you reconsider – I’d actually recommend the natives over jbullet if the updated natives were put into place.
If you don’t, I’ll do my best to build v2.81 on MacOSX and share it with the community when I can.
Well, you are the one addressing me so you will get some answer from me. Depending on what you ask and how you can interpret any stance from my side into it. But in fact my stance never changed since you started this or we talked first about native bullet. And I don’t know why you expect this to change. Also the OSX natives work fine, I don’t know why you want 2.81 so badly. If you had just chosen to use 2.80 you’d have perfectly synced libraries. If you had chosen 2.80 I’d give you commit acces, you’d commit and it’d be done. Thats why I think choosing 2.81 wasn’t wise. You have to ask me to build it for OSX and my build setup isn’t up to the task atm due to various reasons.
I keep telling you I don’t have time for this and that native bullet is not yet stable but will replace jbullet from 3.1 on, yet you keep @mentioning me and ask me to do stuff for you. Theres enough other new things about the physics to verify so this is not what I will do first when I have time for it as it brings us 0% closer to stable. Why would I make your current self-induced problem my agenda? I make no money with jME, you do. If you want this done so bad, I take 45€/hr for things like these, I estimate it’d take me 4hrs at least due to the mentioned circumstances. So there you go, sorry if you or anyone feels like I’m an asshole, life’s a bitch.
Asking you to put my fixed natives into the jME3 svn isn’t doing something for me, it is doing something for the good of jME3 & the community, something that I thought was your agenda.
I didn’t think it was a big deal to change the download location of the Mac build scripts to v2.81 and re-run the script, since it sounds like it has been building on MacOSX fine on your end. It would have been nice to have the jME3 bullet natives up to v2.81, which is the latest stable release, across all platforms. However, I agree v2.80 appears to be working OK, so it would have been sufficient to push my fixed natives in the meantime, which is the least I was asking for.
You can still give me commit access, and I can still push the better natives myself if you do not have the time. I have tested these natives with many users & they work much better than the current natives.
PS: I get the feeling that you don’t enjoy working on jME3 anymore & may even be stressed out by it… which is OK. Maybe it is time to pass the baton on to somehow who will enjoy it and have more time to deal with us pesky users?
So what you say is that
a) I should upgrade our version to 2.81 when you want me to.
b) I don’t know what I’m talking about when I say its not so easy for me to build it right now.
c) I thwart your contributions and keep you from making a better jME for everyone and not just for your game.
d) Your bullet version is a tangible improvement over ours, you call it “better” after all .
e) I am very unclear about native bullet being unstable and addressed in 3.1.
f) I should just get out of the team and leave so you don’t have to ask me for your builds.
Well, as I say, life’s a bitch.
Anyway PM me your googlecode mail if you have no commit access yet (I think you do).
P.S. If you had followed the community instead of just appearing randomly with games or change requests you might have seen that I in fact will not have much time for jME in the future, yet some people keep asking me to build stuff for them, idk…
a) Remember, jME3 isn’t you, and upgrading it doesn’t just benefit me.
b) Not building something right now & never building it are two different things.
c) Saying you won’t push fixed natives is kinda doing just that, but it looks like this has been resolved by providing me commit access.
d) It isn’t “my bullet”, it is the updated official stable releases. Also, it is a well known problem in the current jME3 builds that the physics ray test source and target positions are swapped in some OSes, when in the later versions, which I have built, are not.
e) I’ve been using the current v2.81 native builds in a commercial product being sold around the world. I understand it isn’t perfect, but it is stable “enough” and a marked improvement over the current builds (see “d” above). I look forward to v3.1 being used, but that doesn’t mean we have to wait until v3.1 to see any improvement.
f) Your confrontational attitude leads me to believe you are stressed out & don’t enjoy doing this anymore, which means it may be in everyone’s best interest for you to leave. According to your PS, looks like you will be doing just that.
Guys, i hope you are all fine and in a good shape. I love you all.
@phr00t if you commit the libs, so just give us to know. I use physics for ray collision. I’m on linux.
And what should i do to replace old libs with new libs? Will they be called in some way?
Usually, when a new version is about to be pushed out the door, release teams become very reluctant about exchaning anything, for any reason.
In this case, while 2.81 may be an improvement overall, but it can still break JME if JME (unwittingly, possibly) has a bug or workaround that doesn’t matter in 2.80 but breaks in 2.81. So 2.81 would have to be rigorously tested to ensure that a minor known problem isn’t replaced by an unknown quantity and quality of unknown problems.
That’s why I’m sceptical about introducing a new bullet version right now. I can’t speak for Normen’s reasons though.
I also think that Normen went into abrasive passive-aggressive mode a few posts ago.
I have learned the hard way that arguing against that is useless; the choices I’m seeing is ignoring it or filing a complaint.
Ignoring often works great. I once complained and it did help.
@mifth said:
Guys, i hope you are all fine and in a good shape. I love you all. :)
@phr00t if you commit the libs, so just give us to know. I use physics for ray collision. I’m on linux.
And what should i do to replace old libs with new libs? Will they be called in some way?
Thanks.
Thanks, I’m doing good
Do you use native physics for ray collision or the standard jBullet? I’m also running Linux & I tried to use the jBullet libraries, but they just don’t work in a multithreaded environment. I switched to the bullet natives, but I had a few crashes & physics ray testing wasn’t consistent across different OSes. The solution was to build the new bullet natives, which I have done & no longer experience crashes or inconsistent ray testing.
If you manually download the native files in this thread, you need to remove the “normal” bullet-natives library reference from your jME3 project and add my build via “Add JAR/Folder”.
You don’t need to do anything else – the new libraries will be used, fixes & all, and nothing should need changing in your code.
So 2.81 would have to be rigorously tested to ensure that a minor known problem isn’t replaced by an unknown quantity and quality of unknown problems.
I’ve seen nothing but improvements when moving from the current build to v2.81 in 3089. I recommend pushing the update so other people can see those improvements (and help test it out). However, I won’t do a commit unless others agree it should be done.
Do you use native physics for ray collision or the standard jBullet? I’m also running Linux & I tried to use the jBullet libraries, but they just don’t work in a multithreaded environment. I switched to the bullet natives, but I had a few crashes & physics ray testing wasn’t consistent across different OSes. The solution was to build the new bullet natives, which I have done & no longer experience crashes or inconsistent ray testing.
If you manually download the native files in this thread, you need to remove the “normal” bullet-natives library reference from your jME3 project and add my build via “Add JAR/Folder”.
You don’t need to do anything else – the new libraries will be used, fixes & all, and nothing should need changing in your code.
I’ve seen nothing but improvements when moving from the current build to v2.81 in 3089. I recommend pushing the update so other people can see those improvements (and help test it out). However, I won’t do a commit unless others agree it should be done.
I used bullet-natives and jbullet. I had no diference between them. But if you say that there is an issue with the ray collision so i would like to update the libs.
I downloaded your archive. Thank you!
Another question: what about android? Will there be android build?
Edited: Forgot to say. Good luck with 3089! You make good business with JME.
@mifth said:
I used bullet-natives and jbullet. I had no diference between them. But if you say that there is an issue with the ray collision so i would like to update the libs.
I downloaded your archive. Thank you!
Another question: what about android? Will there be android build?
Edited: Forgot to say. Good luck with 3089! You make good business with JME.
The Linux & Windows native builds are behind, because the jME3 team had trouble building them. However, the MacOSX natives still built, causing a gap. The biggest problem I noticed with that gap was the physics ray tests were different. I also noticed some random crashes when using the native builds on my Linux OS.
I don’t know anything about the Android natives… it doesn’t look like they are included in at least my build, but I did see them mentioned in the build scripts. Someone else may need to comment on this…
Jbullet seems to have stopped development while Bullet has continued to improve performance and features.
Normen mentioned that Jbullet is being phased out from JME for that reason.
@toolforger said:
Jbullet seems to have stopped development while Bullet has continued to improve performance and features.
Normen mentioned that Jbullet is being phased out from JME for that reason.
I use physics for ray collision. I’m on linux.