Status of my physics extension

[amnesiasoft]

[][]I have seen it, but it would be impossible in MMF 2. MMF 2's drawing capability is far too slow for such a system, and with even a few objects I believe the game would slow to a hault.[/]So how Irrlich object will draw a complex 3D world full of objects in realtime? This means that this is very possible. [/]

I imagine the Irrlicht object works in a similar manner to the OpenGL objects form MMF 1.5, they create their own hardware accelerated window.

You could make Physical run at an acceptable speed if it used that same method, but then you'd have to write so much additional code that you'd bebetter off using C++ over MMF.

[amnesiasoft]

[][]I have seen it, but it would be impossible in MMF 2. MMF 2's drawing capability is far too slow for such a system, and with even a few objects I believe the game would slow to a hault.[/]So how Irrlich object will draw a complex 3D world full of objects in realtime? This means that this is very possible. [/]

I imagine the Irrlicht object works in a similar manner to the OpenGL objects form MMF 1.5, they create their own hardware accelerated window.

You could make Physical run at an acceptable speed if it used that same method, but then you'd have to write so much additional code that you'd bebetter off using C++ over MMF.

[Bovril]

I can't see why regular active objects couldn't be used, I thought the idea was to have the real simulation done via the ODE then to map active objects to nodes. And if it uses active objects, it should have no more slowdown than MMF itself (i.e. very little :P)

Or do you just mean that particular example would need more drawing capability? If so, I still don't see why it needs a new sprite type. It looks to me like it could be done with what you're planning at least (maybe some of the scenes would be slow, but still possible).

[Bovril]

I can't see why regular active objects couldn't be used, I thought the idea was to have the real simulation done via the ODE then to map active objects to nodes. And if it uses active objects, it should have no more slowdown than MMF itself (i.e. very little :P)

Or do you just mean that particular example would need more drawing capability? If so, I still don't see why it needs a new sprite type. It looks to me like it could be done with what you're planning at least (maybe some of the scenes would be slow, but still possible).

[Percival]

[]I can't see why regular active objects couldn't be used...
...I still don't see why it needs a new sprite type. It looks to me like it could be done with what you're planning at least (maybe some of the scenes would be slow, but still possible). [/]In the Vortex2 extension the objects only rotate and move physicaly, things that normal actives do, so they can be used. In the other hand, in the Physical engine the objects bend, distort and even broke, so this is why normal actives can't be used.

But I don't see why it needs a new "sprite type" since the object editor from the Physical engine already generate an object file that could be draw directly to the screen, the same way the KlickOpenGL do with 3D objects.

[Percival]

[]I can't see why regular active objects couldn't be used...
...I still don't see why it needs a new sprite type. It looks to me like it could be done with what you're planning at least (maybe some of the scenes would be slow, but still possible). [/]In the Vortex2 extension the objects only rotate and move physicaly, things that normal actives do, so they can be used. In the other hand, in the Physical engine the objects bend, distort and even broke, so this is why normal actives can't be used.

But I don't see why it needs a new "sprite type" since the object editor from the Physical engine already generate an object file that could be draw directly to the screen, the same way the KlickOpenGL do with 3D objects.

[Bovril]

Yes, but it could still be represented by a series of square active objects (one for each point of the mesh). And it would only need one extra rule added as far as I can see - the ability to break springs when they're pulled too far (I don't know if this is already in the ODE or not).

[Bovril]

Yes, but it could still be represented by a series of square active objects (one for each point of the mesh). And it would only need one extra rule added as far as I can see - the ability to break springs when they're pulled too far (I don't know if this is already in the ODE or not).

[vortex2]

I already plan to have breakable joints (for things like ragdolls), but I think having a ton of actives like that will be quite slow.

[vortex2]

I already plan to have breakable joints (for things like ragdolls), but I think having a ton of actives like that will be quite slow.