What needs to be done with the Plugin?

[Chisaipete]

I now have a copy of VS 2008, so hopefully I can get it building with that.

Although the GoW guys aren't too keen on getting the plugin compiling. I'm under the impression that Max is not a priority at all for them.

[JWPlatt]

That might be for the better. If they can concentrate on Blender and we concentrate on 3ds Max, everyone wins.

[Chisaipete]

From the puttering I did last night, it appears that MOST of the source for the plugin is still intact, but a few files might have been left out by Cyan. More on this later when I can confirm with data.

[Nye_Sigismund]

Well, I think that if the GoW developers decide to work on the plugin, people win too - I've seen the frenzy of development over there in recent days and it's certainly impressive. Everyone can work on whatever they wish to work on.

My CGsociety post went up, by the way.

[Chisaipete]

So, let me share some more thoughts/memory-dump about this process...

I believe that we'll be able to take the plugin code (mostly as-is) and compile it against a newer MAX SDK. The libraries that the plugin includes (and uses functions from) are standard libraries from the Max 7 SDK which haven't even changed name from 7 to 2011 SDK (the version I'm working with). It may even be possible (with the correct compiler flags) to build plugin binaries that would be compatible with Max 7 with an SDK from Max 2011/2012--this isn't fully confirmed (almost no one does this), but it's very likely from what I've read so far.

Thoughts about compiler errors:
Now, if the CWE plugin compile happens to break on the Max libs then that should be a sign of a SDK function change which means we'd have to tweak the plugin code that makes the call. Should be easy enough to trace.

Now, there are also quite a few third party libraries that the plugin code includes (and uses functions from), it could break here as well. This would be a sign that there were changes in the 3rd Party lib functions--further plugin code tweakage here.

Finally, the plugin compile may break on it's own source, which would indicate Cyan crippled or left out code or didn't fix holes they created by changing to third-party libs. In this case, a bit of code wizardry would be needed to patch or erase the holes here.

[Chisaipete]

Is there any chance I could get a hold of the original (completely unmodified) code (whole package) as delivered from Cyan? With no modifications to the VS projects to get CWE to compile? I'm hoping to use it to piece together what is missing from the plugin code. Detective work is easiest when there are as few after the fact changes as possible.

[JWPlatt]

You can get the raw sources here:
http://wiki.openuru.org/index.php?title ... .26_Plugin

Or you can pull CWE and update to an earlier point in time before the work to make it build.

[Chisaipete]

Thanks JW, I probably could have found that by actually looking.

[Nalates]

There is a lot posting in OU these days. It is hard to keep up. I may have missed some points in regard to the plugin.

Presumably OU wants to be able to distribute a working copy of the 3DS version of the plugin. This means either proper licensing for included libraries or replacement of the libraries is needed.

Chisaipete’s review of the SoftDesk licenses doesn’t seem to give a conclusion as to what we can do. I take it that distribution of SoftDesk code and libraries are simply forbidden. JWP is looking for a way around that with a license of some type. Is that correct?

I suspect Chisaipete is going for plugin with fewer dependencies on 3rd party proprietary stuff. Yes?

I am left wondering if the plugin can be written to only make calls into the existing 3DS installation on a user’s computer and not have to include any of the libraries. Much like Photoshop plugins (many that work in PS and GIMP). That is possible? Yes?

I suspect the GoW people will find or build replacements for the SoftDesk libraries. I think it is obvious that the 'replacing' code’s work parts could be used in a 3DS plugin. While input parameters and data arrangements would be different the output to MOULa and CWE compatible formats would have to be identical. Changing the input seems less work than creating a whole new function. Or is there a limitation I’m not seeing?

[Mac_Fife]

The thing about the 3ds Max SDK is that the question of redistribution is a largely moot one except in respect of any possible implications caused by the GPLv3 license on the code that SDK is linked to. This is because the SDK is only provided on the media for 3ds Max. And the plugin is only any use if you have 3ds Max to plug it into, ergo if you have Max you have the SDK anyway.

I haven't been able to find a copy of the license that goes with 3ds Max, so I don't know how permissive it is anyway on redistributing the SDK within a binary. I wouldn't expect it to be too restrictive as apps using the SDK will likely be seen as helping to push sales.