Hi,
I'm an independent developer and want to expand ZB3 with some plugins. I'm new to this so perhaps this is not the good place to post this and neither sure if this is already possible...
Currently I see ZB allows to do limited things using ZScript. The scripting system is very good to automate things and create some interesting tools but is a bit limited at the moment. Could be possible to use ZScript mechanism to write, for example, an image exporter/importer? Also i'm a bit worried about scripting speed... how fast is ZScript compared with C and lua?
Well, I think what we need is a C/C++ SDK which:
1) <b>Allow to read and write ZB3 geometry meshes</b>. I need to be able to access the loaded ZB3 geometry and also to create new one. Also could be good to be able to import/export the mesh tangent basis for normal mapping. This last thing is crucial because each game engine uses a different method to compute it. Currently I can read ZB data with the Mesh3DGet but cannot write it and neither play with the tangent basis.
2) <b>Make ZB3 completely plugin oriented </b>so everything ( including materials, 3D viewport, objects, etc...) could be accessed from the SDK. Pretty much in the 3dsmax or XSI style.
3) <b>Make the SDK free and public</b> so everybody with a ZB3 copy and programming knowledge could write a plugin. As more developers you get more will grow ZB3, no need to make the SDK private. If you make it private you are just slowing your growing rate! Include it in the ZB3 installation CD and also allow to download sepparately it from the web.
As a Photoshop SDK programmer I can tell you is a real pain to sign all the NDAs, fax them, receive them back, agree, talk with the developer relations, etc... specially if you are outside USA.
Just release an interface ( some .h/dll/lib files ) without intellectual property code inside. If you need to use some IP then get a pointer to the ZB3 object inside a DLL and operate with it.
I should be able to write and redistribute my game engine mesh importer/exporter for ZB3 ( as 3dsmax/maya does ) so the MOD-fan community or everybody could use it if own a ZB3 license.
Once the SDK is done search some partners and make/support some official plugins but allow homebrew coders to write their own too!
4) <b>Include UI features or allow to use custom dialogs</b>. This is crucial to reuse the existing UIs for macintosh or linux. The idea is to write the code and just recompile it and should work in any OS. If you have seen the Photoshop SDK it uses something called ADM ( adobe dialog manager ) to do this. You design the dialog then can be used by any OS.
The current ZScript contains a low of useful UI options which is good but,
personally, I would make a dialog editor like Glade or Gazpacho so the interface could be sepparated from the coding ( like XAML does ).
LW8/9 and Softimage 4 also used this kind of dialog designer and I think was very good! The programmer just need to binds the onButtonClick, etc signals manually.
Also, let the user to decide if wants to use that OS-independent-dialog -system or a custom one ( for example, .NET/Mono winforms or MFC or Cocoa UI ).
5) <b>Integration with ZScript</b>. Like Maya C SDK + MEL. I need to be able to call C/C++ functions(and DLLs) from ZScript. I need to be able to call ZScripts from C/C++ too. Currently I can call a DLL from ZScript but the inverse is not possible? Currently the ZScript speed is good but I would prefer the C one, specially dealing with superdense meshes.
6) <b>Allow to use other scripting languages</b> like LUA, Ruby or Python. ZScript is cool but if you could "abstract" the scripting host to include more languages will be even better! Tons of people know already these languages so no need to learn other like ZScript. Just expose the C/C++ ZB3 object model to some standard scripting virtual machines like the LUA one. For example, see the Blender's python scripting.
7) <b>Create the SDK for x86 and x64, Windows, MacOSX and linux libraries</b>. As more OS and CPUs as better. Give us Visual Studio and GCC precompiled libraries if required.
8) <b>Consider a C interface vs a C++ one</b>. C can be integrated better with languages like Java(using javac), ObjectiveC(not ObjectiveC++), Digital Mars's D language, VB6(using a DLL with extern "C" model), etc... Using pointers to functions you could do something similar to the Photoshop SDK "suite" interface model which is very portable and also much more resistant to SDK "versioning".
For all the remaining languages you could write a COM wrapper so could be used by the Windows Scripting host, Javascript, etc... There is COM port for linux in sourceforge ( I think XSI and firefox used it ).
-
Add tons of SDK examples and good documentation and tutorials
-
Make a developer section in the ZBrushCentral and divide it into ZScript, C/C++ SDK, .NET/Mono SDK, language wrapper interfaces, general questions, new plugins created, etc…
thx!