PhysX Read/Write capability in libPlasma

[Tsar Hoikas]

(except for the PhysX IO library I wrote).

Then it is useless to us, it seems.

[Branan]

One thing to remember is that the GPL doesn't apply until you distribute an executable. As long as you only use the executable built with PhysX for personal use, it's completely legal.

Thus, including the PhysX code with a compile-time option to enable it (disabled by default), and printing a big nasty warning that distributing the resulting exe is a violation of the GPL if it's enabled would work, assuming Zrax is OK with that.

And not to toot my own horn, but that would be incredibly easy in the CMake build code I wrote.

[Deledrius]

That sounds more like a loophole exploit (if it's even a valid assertion) and wouldn't really be adhering to the terms of the license.

[Branan]

That sounds more like a loophole exploit (if it's even a valid assertion) and wouldn't really be adhering to the license.

It's the way the license is written, and it's intentional. This way companies and individuals can modify GPL'd code to their hearts content on their own, and not be bound by the license until they try to give someone else the new version. How many in-house modified versions of GPL'd code do you think depend on proprietary libraries?

You'd probably have to distribute the PhysX stuff as a patchset... like I said, IANAL.

And of course, if you can get everyone who's contributed code to agree to a GPL exception for the PhysX libraries, it would be possible to include it as-is with no problems.

[Paradox]

I believe our best option for this is the NxOgre LGPL library, which supports baking data, and also integrates to an extent with Blender.

[Deledrius]

That sounds more like a loophole exploit (if it's even a valid assertion) and wouldn't really be adhering to the license.

It's the way the license is written, and it's intentional. This way companies and individuals can modify GPL'd code to their hearts content on their own, and not be bound by the license until they try to give someone else the new version. How many in-house modified versions of GPL'd code do you think depend on proprietary libraries?

Sure, but you suggested distributing the non-GPL binary along with the GPL code as part of it. I don't think simply having it "disabled by default" really qualifies. IANAL either, but that doesn't seem like the intent of the GPL. Do you know of any projects that use it this way as an example?

And of course, if you can get everyone who's contributed code to agree to a GPL exception for the PhysX libraries, it would be possible to include it as-is with no problems.

That would only fix the problem in one direction... I dunno, something feels off about this, but I can't put my finger on it.

I believe our best option for this is the NxOgre LGPL library, which supports baking data, and also integrates to an extent with Blender.

I agree. It's definitely the most obvious avenue to pursue.

[Robert The Rebuilder]

I'll take a look at NxOgre and see if I can somehow replace the PhysX calls in the PhysXIO lib with it. Given the 'bloody mess' nature of the project, I'm not too optimistic about the chances of success. But NxOgre is an excellent example of an open source project that uses PhysX and the LGPL.

For those of you who want to try out my modifications, just place the files from the Contrib folder into where they belong within the rest of the tree, then recompile Plasma. To run, you'll need to install the PhysX System Software.

[ddb174]

I would like to see PhysX replaced with ODE, even if ODE sucks even more than PhysX for open-source. Another (not as good) possibility would be to set it to not use pre-cooked data if possible. Of course, both these options require the source code.

[Paradox]

Another (fourth o.o) option is the open-source Bullet physics library used by Blender.

[Trylon]

From what I can see, NxOgre is just a wrapper for the binary sdk too.
Ofcourse, there might be a GPL loophole that if you use an LGPL library that in turn links with a non-OSS library it's okay, but I'm not too sure about that.

The way I see it, a binarry wrapper implementation could be a first step to a working model, followed by empirically determining how the mesh data is stored. (Which is a lot easier if you know what the input mesh is)
If I have some time this week I'll take a look at it. Haven't picked apart hex files to determine data formats ever since the first camera implementation - I must be getting rusty

Another (not as good) possibility would be to set it to not use pre-cooked data if possible.

It seems to me that that would be a good idea no matter what phyisics engine is used. (Once and if OSS Uru lands ofcourse).
Having a storage sytem for phyisical objects that isn't physics-implementation dependent would be a great help in keeping different versions compatible.