Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (711)
Games in Android Showcase (213)
games submitted by our members
Games in WIP (785)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  jBullet3  (Read 4976 times)
0 Members and 1 Guest are viewing this topic.
Offline elect

JGO Coder


Medals: 39



« Posted 2015-08-28 09:01:48 »

Hi, I am evaluating porting bullet 3 to java (using also opencl via jocl), is there anyone who also is interested so that we may unite all our efforts?

I like what it is happing with JOML and I really hope we could do something similar
Offline KaiHH

JGO Kernel


Medals: 384



« Reply #1 - Posted 2015-08-28 09:27:35 »

Sure, it will be great! I would certainly like to use a modern bullet port.
But basically, with all open-source projects that start out: You somewhat have to have an intrinsic motivation to do it regardless of what other people think of it, and you should not care whether other people will like/use it or not. It should be benefitial to you in the first place.
Sure, you can have some extrinsic motivation by people telling you that they would like it. But the base motivation needs to be intrinsic.
So, please just start with it. Smiley
Offline basil_

« JGO Bitwise Duke »


Medals: 393
Exp: 13 years



« Reply #2 - Posted 2015-08-28 10:34:09 »

i'm game. the current jbullet port is pretty awkward (to me).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Longor1996
« Reply #3 - Posted 2015-08-28 12:30:13 »

Don't forget about supporting LWJGL3 (which has OpenCL too).

Offline elect

JGO Coder


Medals: 39



« Reply #4 - Posted 2015-08-28 13:32:47 »

Sure, it will be great! I would certainly like to use a modern bullet port.
But basically, with all open-source projects that start out: You somewhat have to have an intrinsic motivation to do it regardless of what other people think of it, and you should not care whether other people will like/use it or not. It should be benefitial to you in the first place.
Sure, you can have some extrinsic motivation by people telling you that they would like it. But the base motivation needs to be intrinsic.
So, please just start with it. Smiley

Let's say I'd need it both for my work and my personal projects.

You know, Kai, actually I was thinking if we can rely on joml... it'd be cool, what do you think?

i'm game. the current jbullet port is pretty awkward (to me).

Nice basil

Don't forget about supporting LWJGL3 (which has OpenCL too).

Yeah, I guess lwjgl had an opencl binding too, but I wasn't sure.

Sure btw, as I already told SHC in chat, we could do something generic and then everyone can use the api he likes most
Offline SHC
« Reply #5 - Posted 2015-08-28 13:46:08 »

For the purposes of history, let me state what he said to me on the IRC:


<SHC>   I really like the idea about porting bullet 3
<elect> excellent
<SHC>   right now, I have no experience with it (not porting but using it) so I'm now setting up a test workspace in VS2015
<SHC>   Yeah, I would also like to integrate bullet into my engine, so that would be pretty good to have.
<elect> nice
<elect> I took a look to their repo
<elect> it seems they are still in the phase of transporting bullet2 to 3
<elect> Im writing down the validation right now
<elect> I need the stl
<SHC>   Standard Template Library?
<elect> I think so
<elect> We are gonna need some collision detection in the future for our engine and therefore I was looking at jbullet
<SHC>   How are you planning to port it? You write JNI code? or port it to java manually by hand?
<elect> I dont want any binding
<elect> I want pure java code
<elect> so that we can tune everything
<SHC>   So porting by hand? That's a lot of code there..
<elect> yep
<elect> I need hardbody collision for the moment
<SHC>   So we chose the hard path of thorns,.. so shall we spend some days getting used to bullet 3 in C++ first?
<elect> maybe
<elect> I was also thinking if launching a kickstarter could make any sense
<SHC>   Aren't you making it opensource? I mean, working it on free time?
<elect> both
<elect> opensource for sure
<elect> I will work on it during some part of my work and in my free time
<elect> if we go for the port
<elect> I'd like 100% java so that we can also choose to avoid some class instances for performance and memory footprint
<SHC>   My idea is a bit different, we can avoid the vector classes, like btVec etc., and instead construct the structs in JNI code?
<elect> we shall discuss the pro and vs
<elect> actually I was thinking to rely on JOML
<elect> from kaihh
<elect> it looks very good for performances
<SHC>   That's a good idea too, I thought so since constructing objects is very expencive but struct instances is not..
<elect> so at least the math part is "already done"
<elect> ^^
<SHC>   haha yeah, agreed, we shall be using JOML. And the bindings? I have to see an overview of bullet and read some demos.
<elect> what is your dev os & machine, SHC?
<elect> Im using an i5 & 770 on 15.04 x64
<SHC>   Windows 10, i7 4790k, NVIDIA GTX 750 Ti and 16 GB RAM.
<elect> or i5 & 680
<elect> good
<elect> modern enough
<elect> (for opencl support)
<SHC>   Yeah, I think OpenCL is supported even on GTX 210
<elect> yeah, but it is not mature
<SHC>   That's the minimum I heard
<elect> I read the guide, they say cl kernels are very likely to crash for a large number of reasons
<elect> moreover they cannot use cpu as opencl devices, dont know why
<elect> does lwjgl has a opencl binding?
<elect> I guess so
<SHC>   Yes, LWJGL had OpenCL bindings
<elect> nice, we can do then something generic and everyone will choose what he likes most
<elect> like joml
<SHC>   yeah
<elect> I already cloned and built it
<elect> most of examples run
<elect> just a couple crashes
<SHC>   Oh I'm now reading the manual.
<elect> the problem is that they made a browser windows example and when you open it selects automatically the last example you run.
        This means once it crashes I have to clean and clone again, since everytime I open from that moment going on it keep crashing
        (coz it tries to open the same example)
<elect> anyway the opencl support is experimental
<SHC>   Did you create a repo?
<elect> no
<elect> not yet
<elect> I am still in the decision phase
<SHC>   oh kk
<elect> the thing is that it relies of course also on acceleration structures
<elect> I am just starting with that too

Just posting it here in case anyone would like to know what happened behind the scenes in the IRC.

Offline KaiHH

JGO Kernel


Medals: 384



« Reply #6 - Posted 2015-08-28 14:00:54 »

You know, Kai, actually I was thinking if we can rely on joml... it'd be cool, what do you think?
I don't know what requirements a physics engine like bullet has regarding math.
I'd suggest you take one or two weeks digging inside bullet's sources, playing with a native bullet build for a while to get a feeling, and then see if JOML can help you with anything.
You see, JOML is geared towards transformation calculations for OpenGL rendering. Not towards a physics library.
So I reckon you have to write most algorithms and data structures by hand anyways. Of course, there are basic data structures you always need, like vec3 for acceleration, velocity and position vectors. But that's basically it, I guess.
Also understand that JOML tries to cover far less surface (meaning set of requirements) than what a full-blown physics engine like bullet does.
And a physics engine is driven by alot more forces (all kinds of features (rigid body, soft body, ...), performance, runtime-footprint, ) to be useful to a broad set of people than what a simple linear algebra library like JOML is.
Online kappa
« League of Dukes »

JGO Kernel


Medals: 115
Projects: 15


★★★★★


« Reply #7 - Posted 2015-08-28 14:27:48 »

One thing to keep in mind is that Bullet3 is still pretty much experimental (under heavy development) and depends on OpenCL.

OpenCL support and drivers are still not very widespread and judging by current trends its not looking like it'll get much better any time soon (both OpenGL compute and Vulkan seem like much better bets atm). Therefore any application using Bullet3 (in its current form) will only really be usable by a small and niche target audience unlike Bullet2 which works well for the mass market.

Its a big undertaking to port and maintain a C++ code base (especially a fast moving one like Bullet3) to Java, so you should consider your options carefully (like whether to go for making a binding instead of porting).
Offline gouessej
« Reply #8 - Posted 2015-08-29 21:07:00 »

both OpenGL compute and Vulkan seem like much better bets atm
What do you mean by "better"? OpenGL Compute != OpenCL

In my humble opinion, some forks of JBullet available on Github and the native bullet binding of JMonkeyEngine are some more viable options on the long term.

Offline theagentd

« JGO Bitwise Duke »


Medals: 947
Projects: 4
Exp: 8 years



« Reply #9 - Posted 2015-08-30 03:00:50 »

What do you mean by "better"? OpenGL Compute != OpenCL
OpenGL compute shaders have better driver support is what he's saying.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline elect

JGO Coder


Medals: 39



« Reply #10 - Posted 2015-09-03 07:40:47 »

Me:

Quote
Hi Tommy and Gideon,

I am writing around in order to test the availability of doing a java port of the bullet 3, using also its opencl support.

I write to you too since you are the most active devs of https://github.com/bubblecloud/jbullet

I opened also thread on JGO (http://www.java-gaming.org/topics/jbullet3/36579/view.html)

What do you think about?


Regards,
Giuseppe Barbieri

Gideon:

Quote
Hi Giuseppe,

In the end I found it was better (for me at least) to use the C version via JNI. This way, we could take advantage of the main distribution, and all of the latest features.

It was a while ago since I looked at it, but I could dig out the code and give you a bit more information if you are interested.

Regards

Me:
Quote
Hi,

thanks both for your replies Smiley

let's say both ways have their pro and vs.

If we do the port, we have 100% pure java, we can simply add a single fat jar and we'll get physic. Downside we have to keep it up with the updates on the C side, but if we match closely the C style we can reduce the work that needs to be done in order to update the java version.

If we do the bindings, we take advantage of all the latest feature as Gideon says but we may get in trouble with the memory management since we will have no garbage collector and we have to free manually the resources. Moreover the usage in project gets a little more complicate and small updates are still required to match the future features.

My hope is to create a java community that helps maintaining that.

However one of the problems right now is that bullet3 looks under heavy development..and the opencl stuff is not very stable I read somewhere (experimental). What do you suggest to do? How much will it take to do a reasonable complete port? Is needed/helpful a deep mathematical knowledge for that?


Ps; may I report this discussion on the JGO forum?


Regards

Gideon:
Quote
Hi again,

At the time I thought it would be very difficult to maintain a Java version that was as good as the C++ version, because it was implemented for SIMD (special instructions for high efficiency), and wasn't documented. This made it very hard to understand the implementation, in order to port to Java. Is Bullet 3 much easier to understand?

This discussion has made me want to go back and refresh my memory, clean up our code, and open source it. I'll let you know if I get to this.

Good luck, let me know what you choose to do.
I would be happy for you to report this to the JGO forum!

this is how things are right now.. Let's see what Gideon will bring to us Smiley

I also tried to probe on the bullet forum, not that success so far


                                                                                                                                                                                                         
Offline basil_

« JGO Bitwise Duke »


Medals: 393
Exp: 13 years



« Reply #11 - Posted 2015-09-03 13:12:05 »

i was thinking the same. after goofing with the c-source it looks like JNI bindings would serve best.

testing swig'ing it at the moment.
Offline gouessej
« Reply #12 - Posted 2015-09-04 09:47:35 »

i was thinking the same. after goofing with the c-source it looks like JNI bindings would serve best.

testing swig'ing it at the moment.
There is already a similar solution implemented in JMonkeyEngine, why do you want to reinvent the wheel? There is gdxBullet too.

Elect, if you prefer creating another binding to Bullet, think about using GlueGen.

Offline basil_

« JGO Bitwise Duke »


Medals: 393
Exp: 13 years



« Reply #13 - Posted 2015-09-04 11:17:31 »

gdxbullet is using swig too and just like the jmonkeys bindings, it is much more then just the bindings.

using swig is not really reinventing the wheel and it's giving us a decent level of customisation of type translation. i'm looking for low level bindings without the bloat of intermediate wrapper classes - which i couldn't find in the wild yet.
Offline gouessej
« Reply #14 - Posted 2015-09-04 11:57:55 »

gdxbullet is using swig too and just like the jmonkeys bindings, it is much more then just the bindings.
gdx-bullet uses only LibGDX math, jme3-native-bullet is a bit similar. It's possible to use them without depending on the engine/framework. Both aren't bloated.

using swig is not really reinventing the wheel and it's giving us a decent level of customisation of type translation. i'm looking for low level bindings without the bloat of intermediate wrapper classes - which i couldn't find in the wild yet.
Even JBullet uses Vecmath and each engine or framework has its own math library. If you create a low level binding, you'll have to use another math library (JOML or a library integrated into another engine or framework) or to create your own one. There is a reason why you don't find such a library... There was a similar concern about JUMI.

I see some NIH syndrome here or a desire to spend some time in creating a new tool whereas it's not necessary.

Offline gouessej
« Reply #15 - Posted 2015-09-04 12:20:06 »

Imagine that you succeed in writing yet another native Bullet binding with your own math class or JOML. The developers who use a framework or an engine depending on another math library won't use it because it would add a lot of overhead because of the conversions between 2 math libraries (look at how JBullet was integrated into the existing engines) and it would force them to package their games with 2 math libraries.

Imagine that you succeed in writing a pure Bullet 3 port depending on a particular math library and a particular OpenCL binding (don't tell me that you will support all OpenCL bindings, be honest). Those who use another OpenCL binding or don't want to use your math library wouldn't use it.

At the end, you would target only some developers interested in physics but who don't want to use any framework or engine. Is it worth? When they need numerous features already supported by existing engines, will they go on using your stuff?

In my humble opinion, contributing to some existing projects would be more useful than creating yet another library. Good luck anyway.

Offline basil_

« JGO Bitwise Duke »


Medals: 393
Exp: 13 years



« Reply #16 - Posted 2015-09-04 12:36:50 »

guess we have different definitions of "bloated" and "bindinds". Wink

if you create a low level binding you should be allowed to use just the math lib you _already use_ and not be forced to use another 3rd party lib which you would not use otherwise.

i agree with you tho'. writing another binding which pretends to be a API is not a good idea.

The developers who use a framework or an engine depending on another math library won't use it because it would add a lot of overhead because of the conversions between 2 math libraries (look at how JBullet was integrated into the existing engines) and it would force them to package their games with 2 math libraries.

isn't that the whole point? not using jbullet exactly for that reason. same applies to GDX - requires you to put lots of GDX classes into your CP. JME bindings i did not look deep enough to say much about it.

When they need numerous features already supported by existing engines, will they go on using your stuff?

again, you pointed it out already. if you go around and pick any lib that supports "some" functionality you would like to use - you might just end up with a CP which contains alot unused code. the threshold before it becomes awkward is pretty individual i guess.

how about start small and get things done before thinking about the NASA using your code ?
Offline gouessej
« Reply #17 - Posted 2015-09-04 12:57:48 »

if you create a low level binding you should be allowed to use just the math lib you _already use_ and not be forced to use another 3rd party lib which you would not use otherwise.
There is no way to do it efficiently. I don't think that returning only plain Java arrays would be a good idea and you would still have to convert them explicitly or implicitly when using a math library.

isn't that the whole point? not using jbullet exactly for that reason. same applies to GDX - requires you to put lots of GDX classes into your CP. JME bindings i did not look deep enough to say much about it.
It requires to put only the math library of LibGDX (a few classes) into your classpath, not LibGDX as a whole. "a few classes" != "lots of GDX"

again, you pointed it out already. if you go around and pick any lib that supports "some" functionality you would like to use - you might just end up with a CP which contains alot unused code. the threshold before it becomes awkward is pretty individual i guess.
It's not the case, it's even more evident with Ardor3D and JogAmp's Ardor3D Continuation as ardor3d-math can be used alone Smiley

how about start small and get things done before thinking about the NASA using your code ?
Start by proving that it's possible to create another binding without creating another math library and then, we'll talk about that too.

Offline basil_

« JGO Bitwise Duke »


Medals: 393
Exp: 13 years



« Reply #18 - Posted 2015-09-04 13:51:18 »

bullet uses a C math lib. expose it with JNI. let the user decide which API to build on top. i know, that's simplified but you get the idea.

*edit*

or even more low level - leave the "math lib" SWIG template open to the user. in the end it's about objects - vectors, matrices, etc.
Offline elect

JGO Coder


Medals: 39



« Reply #19 - Posted 2015-09-04 14:18:50 »

Imagine that you succeed in writing yet another native Bullet binding with your own math class or JOML. The developers who use a framework or an engine depending on another math library won't use it because it would add a lot of overhead because of the conversions between 2 math libraries (look at how JBullet was integrated into the existing engines) and it would force them to package their games with 2 math libraries.

Imagine that you succeed in writing a pure Bullet 3 port depending on a particular math library and a particular OpenCL binding (don't tell me that you will support all OpenCL bindings, be honest). Those who use another OpenCL binding or don't want to use your math library wouldn't use it.

At the end, you would target only some developers interested in physics but who don't want to use any framework or engine. Is it worth? When they need numerous features already supported by existing engines, will they go on using your stuff?

In my humble opinion, contributing to some existing projects would be more useful than creating yet another library. Good luck anyway.

I don't know, it seems to me they are useless problematics...

I mean, I am daydreaming about a working out-of-the-box physic lib.

I have my project, I add jbullet.jar and I have physic, simple.

I dont like the math lib jBullet is using? I clone it and modify it in order to use the one I want. Althought I dont see any problem, honestly, why a developer couldnt have an engine or a framework with a math lib and a phyic engine with another math lib. I agree it doesnt make more sense, but it is modular and a math lib doesnt take that much space.

I am pretty sure it is not such a critical thematic. And if I will be wrong, I have no problem at all developing the lib in order to use different math lib or opencl binding.

However, I see there are potentially a lot of java user who would benefit from a pure java bullet, but we are too many willing to actually write it... what about crowfunding platforms?
Offline gouessej
« Reply #20 - Posted 2015-09-04 20:50:58 »

If you want to spend your life in reinventing the wheel, I won't waste mine to convince you not to do so.

Why not contacting the contributors of LibGDX? Why not asking them to extract the math and their bullet binding into a separate sub-project?

I don't know, it seems to me they are useless problematics...
It seems to me that you lack of knowledge about the current Java ecosystem.

I mean, I am daydreaming about a working out-of-the-box physic lib.

I have my project, I add jbullet.jar and I have physic, simple.
In the reality, it's not so simple, especially with Bullet 3 and I read somewhere that Bullet 2 already offloads a bit some computations on the GPU but I've never checked in the source code if it's really the case.

I dont like the math lib jBullet is using? I clone it and modify it in order to use the one I want. Althought I dont see any problem, honestly, why a developer couldnt have an engine or a framework with a math lib and a phyic engine with another math lib. I agree it doesnt make more sense, but it is modular and a math lib doesnt take that much space.
It doesn't make sense because you can't write that you don't want to bloat your classpath with useless classes and that you accept using 2 math libraries, it's not logical. Secondly, do you realize that the source code of Bullet is quite big? Do you really imagine that numerous developers would modify entirely an API in order to use the same math library?

I am pretty sure it is not such a critical thematic. And if I will be wrong, I have no problem at all developing the lib in order to use different math lib or opencl binding.
Maybe it would be better to make the right choice now.

However, I see there are potentially a lot of java user who would benefit from a pure java bullet, but we are too many willing to actually write it... what about crowfunding platforms?
Why not posting a poll here before launching a crowd-funding campaign?

Finally, can you explain to us (without using your favourite search engine) what mean "tunneling", "continuous collision detection", "discrete collision detection", "sweep and prune", "broad phase", "multisampling" (in the context of physics), "soft body", "framerate independence", "joint", "Minkowski addition", "contact", "Gilbert-Johnson-Keerthi", "Expanding Polytope Algorithm" and "Voronoi Simplex Solver"? If you can't, please don't even plan to make a pure Java port of Bullet 3.

Offline ziozio
« Reply #21 - Posted 2015-09-05 06:20:20 »

I would vote yes for a java only physics engine, I dislike having the requirements for native files being bundled up in a java projects. This might mean there is a bit of "re inventing the wheel" but I think there a lot of advantages for this for the people that dislike natives.

@gouessej - quoting buzzwords to dissuade people from trying a project like this isn't very helpful and doesn't really mean much. Porting a library, essentially requires no knowledge because you are just porting code, you just need an understanding of the computer languages at both ends. A long while back I started porting bullet2 to java (a more up to date version of jbullet), I didn't know anything about physics at that point but by porting the code I actually went off and learnt about the topic and I actually learned quite a lot in the process. Everyone starts somewhere.
Offline elect

JGO Coder


Medals: 39



« Reply #22 - Posted 2015-09-05 06:56:28 »

If you want to spend your life in reinventing the wheel, I won't waste mine to convince you not to do so.

This is partially true, there isnt right now "the wheel" we would like to have.

Why not contacting the contributors of LibGDX? Why not asking them to extract the math and their bullet binding into a separate sub-project?

Done Let's see what they reply.

It seems to me that you lack of knowledge about the current Java ecosystem.

It is more than probable  Tongue

It doesn't make sense because you can't write that you don't want to bloat your classpath with useless classes and that you accept using 2 math libraries, it's not logical.

You have a single jBullet.jar including the math. When a new version of the math lib is out, we include it, run the tests and if everything all right we release a new jBullet.jar. Why make your life complicate?

Secondly, do you realize that the source code of Bullet is quite big? Do you really imagine that numerous developers would modify entirely an API in order to use the same math library?

No, indeed, I told you  Grin, I think most of devs will be just fine knowing that jBullet is working out-of-the-box and they don't want to touch it.

Maybe it would be better to make the right choice now.


Sure, it'd be, but unfortunately I dont have enough experience and data to take a decision now and know that is the right final one.

Why not posting a poll here before launching a crowd-funding campaign?

I was thinking also the same..

Finally, can you explain to us (without using your favourite search engine) what mean "tunneling", "continuous collision detection", "discrete collision detection", "sweep and prune", "broad phase", "multisampling" (in the context of physics), "soft body", "framerate independence", "joint", "Minkowski addition", "contact", "Gilbert-Johnson-Keerthi", "Expanding Polytope Algorithm" and "Voronoi Simplex Solver"? If you can't, please don't even plan to make a pure Java port of Bullet 3.

I'd not like to explain because I think it doesn't make that sense to do this (and also because I wouldn't be that good at it  Grin). But I can say I have a quite solid mathematic and geometric background, I know the following terms "broad" and "narrow collision phase", "solid" and a "soft body", "framerate independence", "joint" (with 3 different types). I don't have idea what the other are, honestly.
However I think that while it'd be surely useful knowing all those, it will no be impossible to make it. After all, I do not want to write a physic engine, but I *do* want to port it.
Offline gouessej
« Reply #23 - Posted 2015-09-05 08:22:59 »

I would vote yes for a java only physics engine, I dislike having the requirements for native files being bundled up in a java projects. This might mean there is a bit of "re inventing the wheel" but I think there a lot of advantages for this for the people that dislike natives.
You already have to bundle some native libraries if you use OpenGL and JBox2D is enough for 2D projects.

@gouessej - quoting buzzwords to dissuade people from trying a project like this isn't very helpful and doesn't really mean much. Porting a library, essentially requires no knowledge because you are just porting code, you just need an understanding of the computer languages at both ends. A long while back I started porting bullet2 to java (a more up to date version of jbullet), I didn't know anything about physics at that point but by porting the code I actually went off and learnt about the topic and I actually learned quite a lot in the process. Everyone starts somewhere.
If you really know Bullet 2, then why don't you admit that these aren't buzzwords? They refer to numerous features implemented in this physics engine. Sorry to be a bit harsh but you should know some of those words if you learned something when porting Bullet 2, those terms should make you think about the solvers... and when something goes wrong, if you don't understand what you port, you won't be able to fix it, that's my experience of porting a lot of OpenGL stuff (I'm responsible of engine support in the JogAmp community). Moreover, if you don't understand a bit the concepts, a physics engine will just be a useless toy.

This is partially true, there isnt right now "the wheel" we would like to have.
There is still a problem with your way of evaluating the wheels already available.

Done Let's see what they reply.
Some maintainers were ready to separate some other parts of their engine (the GL abstraction). We'll see what they say.

It is more than probable  Tongue
Seriously, it doesn't make me laugh. If you don't really know the Java ecosystem, how can you claim that you have something new and better to bring?

You have a single jBullet.jar including the math. When a new version of the math lib is out, we include it, run the tests and if everything all right we release a new jBullet.jar. Why make your life complicate?
You can hide the new math library inside your own library but it doesn't mean that a developer won't have to make some conversions between your math library and the one (s)he uses in her/his project.

No, indeed, I told you  Grin, I think most of devs will be just fine knowing that jBullet is working out-of-the-box and they don't want to touch it.
It's already wrong with JBullet, the JMonkeyEngine team has its own fork of this library. I remind you that LibGDX and JMonkeyEngine are used by lots of Java developers.

Sure, it'd be, but unfortunately I dont have enough experience and data to take a decision now and know that is the right final one.
Glad to read that you admit it.

I was thinking also the same..
Let's do it  Grin

I'd not like to explain because I think it doesn't make that sense to do this (and also because I wouldn't be that good at it  Grin). But I can say I have a quite solid mathematic and geometric background, I know the following terms "broad" and "narrow collision phase", "solid" and a "soft body", "framerate independence", "joint" (with 3 different types). I don't have idea what the other are, honestly.
However I think that while it'd be surely useful knowing all those, it will no be impossible to make it. After all, I do not want to write a physic engine, but I *do* want to port it.
I'm sceptical.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 
numerical (172 views)
2017-02-21 07:32:16

numerical (172 views)
2017-02-21 07:31:46

theagentd (280 views)
2017-02-18 13:42:33

theagentd (280 views)
2017-02-18 13:35:16

h.pernpeintner (1447 views)
2017-01-24 22:39:11

h.pernpeintner (1432 views)
2017-01-24 22:38:32

Galdo (1996 views)
2017-01-12 13:44:09

Archive (2046 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2583 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2332 views)
2016-12-15 21:50:57
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!