ZBrushCentral

ZB3 SDK pls

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 ).
  1. Add tons of SDK examples and good documentation and tutorials

  2. 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!

A well thought-out manifesto. But…

This is where your request becomes less than casual. One little bullet point of “and by the way, re-structure your whole architecture if you haven’t already.”

Pixologic has said on a number of occasions that they recognize the demand for an SDK. But they won’t be able to even think about creating one, let alone documenting and supporting it, until their own house is in order. (this used to mean “2.5 being released”, but now probably includes “porting the old 2.0 plugins” and “releasing the mac version”, as well as any bugfixes that might be in the works.)

Search for the word “soon” and you might get a fair idea of all the things that have to happen before they can give that idea the attention it deserves.

(my guess is they won’t even address the subject before Siggraph)

jogshy: what you say would be so cool. but i’m afraid it is also something that will never happen. I work in a game studio. We dream for a zbrush sdk for so long i can’t remember. We made some inhouse tools, but everything we made , was done by trial and error.

I don’t understand Pixologic’s policy, but hey, it wouldn’t be the first thing they do differently than the other software developers.

In many other cases, independent developers contributed alot to the evolution of the base products.

I was hoping they will add more usefull features to the scripting in Z3 , but by judging from the message regarding the scripting referrence ( slightly outdated ), there’s not much difference.

I would certainly apreciate the possibility to create your own manipulators and custom ways of interaction with the geometry. Personaly , the first thing i would change, would be the interface. It may be something original, but to me is just something that breaks my workflow with other applications. I don’t need something fancy, i just need something that integrates as easy as possible with the rest of the applications i use. Some control of the meshes on vertex level would be great too.

Anyway, there are so many things pixologic could do concerning scripting and sdk, that there’s no point in loosing my time writting them down, especialy when i am prety sure pixologic will make no effort in this direction.

-claudiu

Well, that’s not fair.

I think Pixolgic has made efforts, and suspect their own plugins were built on that foundation. They’ve talked about an SDK forever. But in recent years, they’ve learned the hard way that it’s best to keep silent about things they can’t release yet. People take every word as a promise around here, and take broken promises very personally.

Don’t hold your breath for an SDK, but let’s not assume it’s from lack of trying!

I can’t imagine it’s their highest priority right now, or that it will become so anytime soon. But, I do think it’s still on the back burner, at least.

Ctrl-Z: I may sound harsh, but i am sure of what i said. I never said that there’s no SDK because of lack of trying. For the moment it’s not my top priority either. I wish i had Zmapper and ZappLink as soon as possible. Going back and forth between Z2 and Z3 is not my idea of a good workflow.
If i am a bit pissed off it’s because this release seems rushed. I wish they would have taken the time to finish at least the help. I am aware of the online help, but pressing Ctrl while over a button is so much less time consumming.

As for the priority of the SDK, i think is the natural way of things. At one moment, a software becomes so complex that the team doesn’t have the possibility to release everything the users need. So , third party developers take this role, developing on top of the core software. That’s how things work with major aplications ( 3ds max, maya, xsi etc.).

One thing pixologic doesn’t seem to understand, is the need of customization. And by that i don’t mean the UI customization only. It’s fine to be able to customize the layout of the buttons and menus ( even though i’ve seen better, for example maya, where you can change just about everything in the interface ), but that’s not the only customization needed. Big studios need to work with large numbers of assets, so the possibility to write your own tools in adition to the ones already present in the software is eesential. As said earlier, we had to write some inhouse tools. It was a pain in the ass just to figure out how ZBrush is working under the hood, with elementary operations like subdividing a mesh.

All in all i think this is just a huge limitation. There is so much potential in this aplication that it will may never be explored because the pixologic team doesn’t have the necessary resources.

There are so many people complaining about the interface ( me beeing one of them ), and i don’t understand why pixologic stiks to it with so much fervor. I personaly think a software should evolve with the needs of its users. It may be a trait that separates Zbrush from the other softwares , but that’s not necessarily a good thing. Pixologic should at least allow alternate UI through a SDK or any other mean. I read on some forum at the realease time of ZBrush 3 that if the UI is the thing that keeps you away from Z, it means it is not a software for you in the first place. A great artist said that, and i admire and respect him very much, but i don’t agree with him. The UI should be as transparent as possible to the user. It should not stop him from using the software, on the contrary. Beeing different from the others is not allways the best thing, if it’s not done properly. I love marking menus in maya for example. It might be one of the things i like most about maya. They’re a bit tricky at first, but they become one of the fastest interface items i ever seen ( that’s why i replicated them in a small part in zbrush with a script) . In zbrush, on the other hand, after a year and a half of intense usage, i still haven’t got used to some interface “concepts”. I can’t understand the reason they are made that way. They are just “pretty”. I may like it the first couple of times i open zbrush, but this changes when later it obstructs my workflow.

I may have goten a bit offtopic, but this is just to point out the need of the SDK.

Anyway, it’s late and i have to go to sleep, so tomorrow i’ll have enough patience to work with ZBrush. Sometimes i get the feeling that Zbrush is this big ball of gold, but you have to dig so deep in the mud to reach it…

Happy zbrushing :slight_smile:
-claudiu

Before the SDK, we need the Plugins like Zmapper, Zapplink, Multidisplacement, HD Export, Hotkeyeditor and the Update - i dont like the switch between Z2 and Z3. Thats the Priority, when that all complete than can come a SDK.

A bit rushed?
I can count yrs based on movies about Zbones release way back in 2004.
I’ll admit yes buggy. And I really got flustrated at first using z3. But now I know what not to do and stay away from the forbidden buttons.
Though I guess if we start asking for the SDK now, my children will be able to make training videos for it. :wink: But ya I’ll go with the Zmapper and all the plugins I got to know and love first. Until then I have sculpting with alphas;)

forbidden buttons? :smiley:

nikudy and cannedmushrooms,

It’s funny – where I agree with you is where you contradict each other. ZBrush 3 was an incredibly ambitious undertaking, and I don’t know how they could have made it go faster. More staff? Third parties developing plugins? Maybe. But they were pretty far off the beaten path – I think the law of diminising returns was already in full effect. So, while it’s feels wrong to say that our excruciatingly long wait went by too quickly, for everything that Pixologic set out to accomplish, they could have used another month or two.

(Hence, the upcoming patch. But I do think the majority of us will look back and be glad for this time with the program, even in it’s current state)

My own pipeline’s fairly simple, and I think I’ll be content to use ZMapper 3 for the bulk of it when that’s released. But I can appreciate your need for custom tools – no one solution is ever perfect for everyone.

Interface standardization might be a pipe dream. Developers frequently sue each other to prevent that, after all. And your learning tools pretty much fall apart if the first thing a user does is change the interface to feel like some other app. I’d be afraid of the plugins stepping on each other. So, I think it might be more important to enforce some level standardization within the app than to allow it within the industry.

(Maybe. That paragraph’s deep in the realm of hypothetical speculation, and shouldn’t be taken too seriously.)

Where I personally think the need is strongest is in hardware support. There’s a lot of specialized devices which users would love to play with in ZBrush, from stereo lithography to 6DOF controllers to haptic sculpting tools. None of which has enough market saturation to justify an effort from Pixologic. But, how might the landscape change if those developers could provide their own drivers?

That’s really why I believe Pixologic is making efforts towards it, in some form or another. Free marketing bullet points, and a whole lot of repeated questions they would never have to answer again in the forums. I think that’s compelling.

…but that all of this other stuff still has to happen first.

So, yeah. Hold out hope, but don’t hold your breath.

(You didn’t say there’s no SDK from lack of trying, but you did say “i am prety sure pixologic will make no effort in this direction.” I think there’s been effort, and the incentive’s still there. But effort and direction aren’t always enough – sometimes you just spin your wheels without moving…)