Is there any project to port jigLibX to OpenTK ?
This physics engine is very powerfull and maybe not hard to port to OpenTK.
i haven't found any good C# 3D physics engine compatible with OpenTK.
Any C# (actually .NET) physics engine is compatible with OpenTK. Because OpenTK doesn't care about physics. It provides only interface to OpenGL and OpenAL. What your application does with physics is no concern of OpenTK. You can use any managed physics or wrapper around native physics libraries.
I agree that a physics engine has not to be included in OpenTK.
But i wonder if someone has already ported a pure C# Physics engine to work with OpenTK.
> Any C# (actually .NET) physics engine is compatible with OpenTK
All serious open source 3D Physics engine written in pure C# i have found depend on XNA Math classes. They do not use there own math library.
JigLibX is a great 3D Physics engine but it depends on XNA math library
A cursory glance indicates that a port of the physics code should not be too hard. Most math functions have direct equivalents, maybe with slightly different names:
this kind of things.
I wonder if it makes sense to bring OpenTK.Math closer to XNA, to ease porting efforts. Anyone familiar with XNA to say if this is feasible?
Edit: Ok, after a quick search-and-replace attack, I am left with the following missing classes:
I'll check if there is anything to salvage from Mono.XNA.
Edit 2: I have created a math branch with the changes so far: it contains several new structures and methods (BoundingBox, BoundingSphere, Plane, Ray, several helpers). JigLibX does not compile yet, but it's getting closer.
If someone wishes to finish up the work and get JigLibX to compile, you can checkout the relevant code with: "svn co https://opentk.svn.sourceforge.net/svnroot/opentk/branches/math math". I will gladly accept patches that implement missing math functions and get OpenTK.Math closer to XNA.
"svn co https://opentk.svn.sourceforge.net/svnroot/opentk/branches/math math"
I found the new physics engine written in pure C# called matali physics. I noticed that matali physics has the own math library. I will report the new functionality to them: cooperation with openTK
(however it does smell like a conflict of interests. maybe the math lib should be separate from both opentk and matali..?)
There have been talks about creating a common Mono.Math library, but the code was stale last time I checked.
I would be all for such a move, as long as it follows a sane interface (preferrably similar to XNA).
The math library should be from openTK.
I am searching for good physics for my project.
I thought that perhaps it would be possible to use JigLibX or matali physics with openTK rather than with XNA.
Fiddler: I guess one problem would be to define what "Maths algorithms" mean.. It is just a little bit too vague to me.
Since the types of OpenTK.Math are vectors, matrices and quaternions, one could argue it is about Linear Algebra (although I'm not sure Quaternions really fits there) or, looking at the field we're in, Computer Graphics, maybe something that resonates to that legacy.
Boring try: OpenCGLAK? As in Open Computer Graphics Linear Algebra Kit? (Kit to attribute the OpenTK roots?)
@stereo: This would require OpenTK to implement the XNA math API. This would allow a large amount of applications to be ported from XNA to OpenTK.
Some initial code exists in the math branch of OpenTK (details in a previous post), but it is far from complete. I do not have time to dedicate to this task. but I will gladly accept (and help with) contributions, provided they are submitted as patches against the math branch.
@objarni: My impression is that the XNA API covers about 95% of what you'd typically need in a game: matrices, vectors, quaternions, bounding volumes, planes and rays. It is missing a tessellator (but there is enough sample code out there to solve this) and curves (beziers etc) which we already have.
I'm not quite sure why they added parts of collision detection to XNA, many games can have their collisions resolved in 2D and for anything 3D you will want something deeper than XNA's classes. Physics API do have to solve collisions before simulation anyway and for example PhysX provides callbacks which return ray collisions or even all objects within the camera frustum.
Regarding Physics API ported to C#: Be very careful with such libraries, they are usually immature and under no circumstances will any of them be able to compete speedwise with physics APIs which use OpenCL. If the C# port uses OpenCL bindings you just moved the dllimport to a different spot. If dllimport/pinning are your concerns, you can limit the communication between your app and the physics API alot by taking a deeper look at their "sleep" mechanisms (No point in querying matrices for sleeping or static bodies).
Site design by Stefanos A. Icons courtesy of gnome-colors.