That’s quite a good list of suggestions. Did you write it?
Nah, this won’t happen. It’s clear from the Maxon policies that they target studios. Zbrush has a huge clientele from the VFX/games/film industries. None of these studios use C4D, and no studio built on Maya/Houdini is going to change their entire pipeline and switch to C4D. Not a chance.
As for stripping tools out of ZB to put into C4D, it just wouldn’t make any sense at all. Zmodeler is very specific to ZB’s no n-gon approach and tool ecosystem concept. The whole toolet would have to be rebuilt. It just wouldn’t work outside of ZB in a trad DCC.
I think they’ll just keep going as is. Pixo, I’m sure, has contract clauses to protect ZB and give them creative control of development, just as the Substance team do at Adobe. Just look at the outcry from the Maxon pricing. Imagine the reaction if they tried to destroy the tool itself.
No, but if I had written it it would look very similar to this.
Totally agreed. I also think this will be Maxon’s path for Zbrush. The bridge between ZB and C4D will probably become tighter as time goes by, making it more interesting for new studios to consider the whole Maxon One package.
I saw that list on the Z C Forum. It’s a very good and precise well thought out list. I think many of us could agree. But also it could be argued I guess that it is aimed towards very specific types of user cases and pipeline workflows.
ZBrush always appeared to be a broad art focused app before all else. It very much pursued it’s own very individual path and users were broadly accepting and very fond of the app and the company. Many of ZBrushes particular eccentricities were forgiven as it was so amazingly good at it’s main specilisations. But with the situation with the buy out now it is hard to see how this very singular and individualist path will be so sustainable. With such a premium yearly price and with the focus seemingly now far more on the studio pipeline market over the independent artist creator. I think the criticisms and feature requests will likely be far more pronounced and insistent.
Of course it is debatable too how some of these feature requests might have been tricky or hard to implement up till now due to the specifics of the technology. Years back I remember it being said to me on a couple of separate occasions by studio colleagues that there had been a design patent taken out on the Pixol technology and concept very early on in the development of ZBrush. Does anybody know if this was true or not ? I can’t seem to find anything about it now.
Sounds intriguing. I’d like to know more about that too.
Nothing about Pixols (as we know it) is listed in the Patent databases.
Other patent claims with either Ofer Alon or Pixologic inc are
I also searched for Nemetschek SE wihtout anything to find.
I couldn’t find anything myself, beyond those patents you found. I was trying to find the Siggraph 1999 paper from the Zbrush reveal presentation, but no success. It is out there somewhere, but according to an academic who read it it didn’t mention pixols?
I wrote to the Siggraph Digital Archive Team about it. Lets see what happens.
This forum and community is amazing and I really don’t want to send people off on any fruitless endeavours and certainly not spread false rumours. Perhaps there was not a lot of truth in it after all since it seems to be so hard to find anything on it. I just remember it being said to me on a couple of occasions way back and wondered if it was one of the reasons ZBrush was such a hard act to follow. Yet I am thinking now if it really was a thing it would surely be far better and widley known.
I spent about 2 hours researching/searching after your post. I think the Zbrush ‘wizardry’ is down to the complex low-level code that it’s built on. I read this on an in-depth thread a while back and apparently the programming feat is still quite impressive 25 years on…
Also, back then Pixologic advertised programming jobs with a low-level programming knowledge required.