moonODE (Open Dynamics Engine (ODE)) bindings

[kikonen]

Just in case 3D physics in LÖVE is soft spot for anyone...

May not be interest to anyone, but I did some experimenting with 3DreamEngine, which felt rather lacking in physics department. Thin wrapper for Box2D just couldn't do it. Thus did some searching and found MoonODE, which seemed rather promising. After some twiddling managed to compile version of library for Windows 11 box for LÖVE, and well, "me like it" (in few days managed to do something workable, versus 1+ week I spent trying to get physics extension of 3DreamEngine to work, without success).

Why all this, well, it is just my personal project, for personal time wasting, in the end I will be experimenting 3D stuff in LÖVE and migrating results into my separate C++ opengl project.

Disclaimer: No warranties, just experimentation, works fine enough for my case, cannot warrant other case

**References**
- MoonODE bindings compiled for Windows
+ https://github.com/kikonen/moonode/tree/windows/luajit
+ for luajit x64 for LÖVE
+ i.e. my use case was to get it working with LÖVE in Windows 11
+ prefer first checking if original moonode works for you instead of my fork
- Documentation
+ https://stetre.github.io/moonode/doc/index.html
+ https://ode.org/wiki/index.php?title=Ma ... troduction
+ https://compusciencing.github.io/starting-with-ode.html
- demo
+ https://github.com/kikonen/love-test/tr ... point/demo

[pgimeno]

The problem with binary libraries is platform support. I don't have a windows machine to check it.

Anyway, lovr has built-in 3D physics (although lovr doesn't work well on my machine for some reason).

[kikonen]

true. "cannot warrant other use case" is very true here. Compiling MoonODE should be actually much easier in Linux, had to run extra hoops just since I had use case that I needed to run it in windows 11 LÖVE, and default instructions in MoonODE to compile with msys2 were not helpful on that regard

I did look into Lovr, and might look into it more later (when getting VR headset and having inspriration to experiment with that). Now my goals were different, and main interest point for me was to experiment with some robust physics library, and ODE seemed to fit that bill.

[pgimeno]

I did look into Lovr, and might look into it more later (when getting VR headset and having inspriration to experiment with that).

I believe lovr supports traditional 3D without a VR headset (just so you know; since you already have ODE it seems you're all set anyway)

[kikonen]

yes, ODE fits this use case, especially since it fits into my ultimate goal of implementing some physics into my separate c++ based project; i.e. I can simply directly apply ODE there without relearning some other lib (or worse, trying to implement own crappy physics logic, which was my initial aim )

However, this my experimentation with LÖVE is on bit unstable ground, since I encountered some odd issues with 3DreamEngine; i.e. errors which does not make any sense, and makes me suspect some memory corruption happening in native code level (for the sake of curiosity or insanity, I'm trying to debug that a bit to see if I can pinpoint it into something relevant, before giving up). If I don't manage to resolve those issues (like suddenly "table" is not table but "number", 3d elements disappearing, and such), I will look into some other 3d lib for LÖVE (picked 3DreamEngine since it seemed to be most recently updated one), or LÖVR if no luck.

[kikonen]

ok, I just to try see could I compile this moonode for luajit in linux for LÖVE. Sure tried it in VMware linux guest (not perfoect for 3D graphics, but works surprisingly well for simple 3D cases like this...), and it did work. Sure ugly Makefile on so on, but at least it compiled and I managed to run my test program.

LÖVING it

[kikonen]

*BUT* this drives me nuts,

Code: Select all

[START: addObject-3]
----------1/3 (addObject-3)--------------------
...
meshes: 
  Cube: Cube (36 vertices)
...
----------2/3 (addObject-3)--------------------
-1.1102230246252e-16
----------3/3 (addObject-3)--------------------
nil
------------------------------
stack traceback:
        utils.lua:70: in function 'trace'
        ...rnal_modules/3DreamEngine/3DreamEngine/classes/scene.lua:145: in function 'addObject'
        ...rnal_modules/3DreamEngine/3DreamEngine/classes/scene.lua:72: in function 'add'
        external_modules/3DreamEngine/3DreamEngine/render.lua:41: in function 'buildScene'
        external_modules/3DreamEngine/3DreamEngine/render.lua:154: in function 'render'
        ...nal_modules/3DreamEngine/3DreamEngine/jobs/sunShadow.lua:90: in function 'execute'
        external_modules/3DreamEngine/3DreamEngine/jobs.lua:55: in function 'executeJobs'
        external_modules/3DreamEngine/3DreamEngine/render.lua:499: in function 'present'
        main.lua:174: in function 'draw'
        [love "callbacks.lua"]:168: in function <[love "callbacks.lua"]:144>
        [C]: in function 'xpcall'
        [love "boot.lua"]:370: in function <[love "boot.lua"]:337>
[END: addObject-3]
NOT A MESH      nil     nil

while doing this iteration (3DreamEngine/classes/scene.lua), "trace" is my hack of dumping values out (as seen above)

Code: Select all

function class:addObject(object, parentTransform, dynamic)
...
	--meshes
	for v, m in pairs(object.meshes) do
     if type(m) ~= "table" then
        trace("addObject-3", 2, object, v, m)
        --debug.debug()
     end
     self:addMesh(m, transform, object.reflection or lib.defaultReflection, scale)
	end

i.e. WTF, there is table of "meshes", while iterating it (sometimes, not always), suddenly key is number, and value is null (sometimes value is number). Beats me to understand what is going on. This same behaviour, I recall, was already randomly before trying this physics lib.

It is hitting same actually in both windows and linux, thus rule out OS specificity.

Thus I would have liked to rule out that it is not Löve 0.11.4 or luajit issue, but haven't managed to do that yet.

[zorg]

*BUT* this drives me nuts,

Code: Select all

[START: addObject-3]
----------1/3 (addObject-3)--------------------
...
meshes: 
  Cube: Cube (36 vertices)
...
----------2/3 (addObject-3)--------------------
-1.1102230246252e-16
----------3/3 (addObject-3)--------------------
nil
------------------------------
stack traceback:
        utils.lua:70: in function 'trace'
        ...rnal_modules/3DreamEngine/3DreamEngine/classes/scene.lua:145: in function 'addObject'
        ...rnal_modules/3DreamEngine/3DreamEngine/classes/scene.lua:72: in function 'add'
        external_modules/3DreamEngine/3DreamEngine/render.lua:41: in function 'buildScene'
        external_modules/3DreamEngine/3DreamEngine/render.lua:154: in function 'render'
        ...nal_modules/3DreamEngine/3DreamEngine/jobs/sunShadow.lua:90: in function 'execute'
        external_modules/3DreamEngine/3DreamEngine/jobs.lua:55: in function 'executeJobs'
        external_modules/3DreamEngine/3DreamEngine/render.lua:499: in function 'present'
        main.lua:174: in function 'draw'
        [love "callbacks.lua"]:168: in function <[love "callbacks.lua"]:144>
        [C]: in function 'xpcall'
        [love "boot.lua"]:370: in function <[love "boot.lua"]:337>
[END: addObject-3]
NOT A MESH      nil     nil

while doing this iteration (3DreamEngine/classes/scene.lua), "trace" is my hack of dumping values out (as seen above)

Code: Select all

function class:addObject(object, parentTransform, dynamic)
...
	--meshes
	for v, m in pairs(object.meshes) do
     if type(m) ~= "table" then
        trace("addObject-3", 2, object, v, m)
        --debug.debug()
     end
     self:addMesh(m, transform, object.reflection or lib.defaultReflection, scale)
	end

i.e. WTF, there is table of "meshes", while iterating it (sometimes, not always), suddenly key is number, and value is null (sometimes value is number). Beats me to understand what is going on. This same behaviour, I recall, was already randomly before trying this physics lib.

It is hitting same actually in both windows and linux, thus rule out OS specificity.

Thus I would have liked to rule out that it is not Löve 0.11.4 or luajit issue, but haven't managed to do that yet.

Try replacing any and all pairs loops with calls to next; luaJIT has/had a bug with pairs that doesn't exist when calling next directly.
(I believe next löve release will have a luajit version that has a fix for that specific issue though)

[kikonen]

Try replacing any and all pairs loops with calls to next; luaJIT has/had a bug with pairs

Marvellous! I will try that, you may have saved my sanity, Sanity-San

[kikonen]

I presume you meant something like this,

Code: Select all

function for_in_pairs(t, fn)
   local k, v = next(t)
   while k do
      fn(k, v)
      k, v = next(t, k)
   end
end

foo = {
    c = 'this',
    d = 'that'
}

for_in_pairs(foo,
             function(k, v)
                print(k, v)
              end)

However, 300+ "for pairs" calls is pita to convert

Q: any ideas when next LÖVE release could be coming?