HEllo,
i d like to mention that i stopped the private beta program , its more works for me and no consistent feedback on the tools.
i looking to get in touch with pixologic developers directly, but none seems to be interested by my progress. will see someday if i can send them a version so they can play with it.
hello
serious thing is starting now !
on left, baked using Substance Painter
on Right, baked using ZGametools ( 6 seconds to bake the normal map 2048*2048 )
final render in Marmot toolbag 2
both materials has the same settings
now comparing the two textures :
SP :
ZGameTools:
Voilou 
the second image rendered in toolbag looks bad for Spainter baker, it because i removed the displacement map on both, and mine still looking correct on the reflection of the second light in my scene.
I drop a bomb today =)
Some Features :Bake incredible normal maps and target the engine of your choice compatible with GGX and metalness workflow.
*** Optimize GGX reflections for Marmot toolbag, or Unreal Engine 4 using engine target presets, and some more support to come for ( maya/stingray, unity, cryengine)
**** Baking time are faster that substance painter baker or any other solution on the market ! *
***** BPR rendering AA is taking no time ! better quality that what Substance Painter 2.4.1 gave me after 1 minutes of baking with no AA !
- Bridge Zbrush to Photoshop, Marmot Toolbag, and Unreal engine 4 with no effort.
Use Toolbag or Unreal Engine 4 as previewer during your sculpting session in zbrush.
Switch to normal map shader then, sculpt directly the normal map in zbrush canvas.
More Details on my blog post here :
i was so excited to post the video and sharing my workflow, that i forget to prepare the descriptions 
i d just edited the previous message and you can read all details on my blog !
Impressive list of things on your blog.
Give us some beta testing demo thing to play and I am 100% sure you’ll get huuge feedback
Right now, too much teasing ( in a good way)
Today I alone to feel really unhappy and angry against pixologic…
why they don’t just get in touch with me instead of redoing/copying the work i already done with my toolset especially the Renderer module… their zbrush to photoshop CC is good at only for one part, the generated JSX file, which is something i didn’t had time to develop , but i had in mine.
they also decided to create a tangent normal matcap, exactly what i worked on for the entire last month.
https://puppet-master.net/zgametools-normal-map-algorithm-test-and-comparison/
check the link above, it’s a long review that make the demostration the best point of my normal mapping algorithm that is somehow better than the allegorithm algorithm…
Another point with subtoolsmask and custom material slots that was also something i planned to add to my toolset 
Joseph, is not like i didn’t asked you to join the beta program of my toolset, it was three or four month ago from now, I posted here about the wish to have some people to beta test my toolset, . I also attempted to get in touch with you via the nanotile plugin thread but never get any return from you.
The ZGametools Renderer module it’s not exactly the same plugin as your zb to ps cc plugin.
Mine has a lot of more features, but no layer construction into PSD, isn’t something i had time to develop because of the extend script documentation.
well i don’t know what to say, just that i will have to maintain more quality that was provide your plugins. its just stupid situation really…
Nicolas, please don’t feel disheartened. Your plugin will provide a “one stop” solution which I’m sure a lot of people will find very useful. But exporting render passes to Photoshop is a fairly obvious development so I don’t think you really need to think that any of your ideas have been taken. (Indeed, I thought of developing such a plugin myself when render passes were first introduced into ZBrush and wrote a Photoshop script for importing the passes but then other projects had to take precedence.) And writing plugins shouldn’t be some sort of competition but simply a way of enjoying helping the community. For example, a very long time ago I wrote the “Adjust” plugin for changing Draw Size by just moving your mouse. Well sometime later Keupon wrote something similar but rather better - his ZAdjustor - which is fine by me, as users can use whichever they prefer.
So keep on with your plugin and I look forward to seeing its release. And in the meantime, all the best for a happy holiday season.
I agree with Marcus, your plugin is very unique and it will still be very useful no matter what others do. So don’t be discouraged, please. I am 100% honest, I think it will be awesome.
I also agree with this idea of a more collaborative, less competitive community but this is just fair since I have learnt mostly by studying Marcus code… I try to follow his philosophy.
As a zbrush user I like to have as many choices as Possible and I would rather find a good tool someone else did already than having to make my own. After all I still am a lazy Spaniard.
I have also learnt that if I think of something it might be good to have, chances are someone else thought about it before or will in the future.
It’s difficult to try and say something without being unfair to you or pixologic but it could have been much better if someone had taken the time to talk to you about this. After all, we are also part of this community that makes zbrush central. When someone like you put a good amount of time and energy to make something like zgametools he deserves some special attention and care. But that’s only my point of view.
There is something more I would like to say about this collaborative spirit and helping the community.
I know writing ZScripts isn’t important for most of ZBrush users but many benefit from the scripts that a few are making. Marcus work here is excellent and I don’t think there would be ANY guys making zscripts without him but I believe it’s fair to point out that Pixologic isn’t always a good example of collaboration. I will explain why I said that with a few examples:
Example 1.
Imagine you want to make a plugin that creates masks on your model based on its geometry (Something similar to a cavity or curvature mask). You need information about faces, vertices, and a way to write per vertex mask. I believe ZScript should have direct access to all that but anyway it’s still possible to do it if you know how read and write GoZ files. ZBrush has a Go SDK but I didn’t even get lucky enough to know what you can do with it. I mean, not only I couldn’t have it, I don’t even know what IT IS!
My solution was, Well, I had to save dozens of Goz files changing a little thing every time, open them with a hex editor, study how it changed and write my own C++ Reader and writer. I actually learnt C++ only to be able to do stuff like this. Collaborating?.. Ha! Not exactly…
GoZ is supposed to be a file format created to communicate with other programs and it still remains top secret and it’s only available for guys who are really really cool. So I like Christmas spirit like anybody else but some good criticism is sometimes more necessary than plain good words.
Example 2.
ZTL or ZBR file formats or really any ZBrush file formats remain undocumented. What’s the purpose? why can we have access to that? And I know I am probably the only person on earth who has the need for this but I do want to know what’s inside a ZTL. For example I wouldn’t have to write and import PSD for importing terrains to ZBrush. I think it’s pretty silly I am using an Adobe file format to communicate with ZBrush when this program has its own format specific for 2.5D, the .ZBR. The result is I have to fill the Alpha palette with garbage in order to use my plugin. This is NOT collaborating at all. It’s not, and I take it as it is and I don’t like whining but this a bit frustrating to be completely honest. Actually I am pretty much done with it.
Example 3.
I also had to decipher strokes. Should I release what I know about them as a contribution to the zscript community? I don’t mind at all but my documentation would be incomplete and unofficial.
So, why is all this connected to what Faceless is saying? I believe Pixologic isn’t really open to suggestions and new ideas until suddenly someone has the guts and the time to implement them.
Take the Excellent ZScene manager as another example of a very demanded feature that was suggested by many until someone said, Enough! I will make it. Now, Pixologic has all the right to develop folders for subtools in the future and it will probably work really smooth since it won’t depend on external windows etc… Nobody will be able to say Pixologic did something wrong. They are just improving their software but let me think it still sucks.
Or Think about Caliper Master, that addressed the issue of real measurements, units and 3D printing… Someone came up with a solution for that and now Pixologic implemented it, fixed the 3d printer plugin etc. Great for us the users, the plugins are really GOOD… but hey, is this really the way of doing things?
Hello guys,
Hey marcus, yes sadly i fight against this sentiment , but it probably the period and because it now a year after i started this long project.
I fully agree with both of you Marcus and Ignacìo, my project is different and more complete, it not really something that we can to compare,
I like to say that, I don’t feel like Joseph attempted to take anything from my idea, i just had listed two compoenent that i had no time at the moment to implement.
it cool to know this feature is possible ^^ ( iam trying to only retain the positive )
Well after you second reply Ignacio, i would have a lot to say to and lot of idea on what Pixologic should focus
one that illustrated your purpose to, is that plugin can’t to communicate together, so what i like pixo apply on next Zbrush build, is to port all their plugins (uvmaster, decimation, )into Api function that we can use with Zscripting.
Even better i like pixologic share an SDK for third party developers not that goz sdk that none of us has been capable to work with or just to read it.
What is wrong with Pixologic is the lack of communication, an annual update is not enough, look at how allegorithmic had taken his place and provides alot of update and new features for every builds.
And to illustrate how this situation is stupid:
At the moment I still develop the TEXTURER Modules and had letted the RENDERER on a side for a time,
First question i could ask, why i would use Zbrush normal map algorithm , as we know ( pro ) the normal map is not accurate at all.
Joseph don’t take it bad, but your tangentnormal map algorithm is terribly wrong and useless, none should use your algorithm .
It took me one month and an half, to polish my algorithm
Please have a reading of these articles posted on my blog
https://puppet-master.net/zgametools-normal-map-algorithm-test-and-comparison/
I should had compared with native (Zbrush) normal map algorithm, but i choose to compare my own algorithm to Allegorithmic normal mapping algorithm,
which is top level quality for realtime/game engine.
Here are some screen to compare the 3 algorithms in Unreal engine 4.14.1
Allegorithmic :
Zgametools :
ZB to PhotoShop cc :
You can read the complete tests with Unreal engine but there is more, ( marmot toolbag 3, unity, substance painter )
I update each articles from time to time, you have no idea how it was long odyssey to reach the perfection and setup all games engines and having a none conventional scene and lighting setup, it so easy to get off board without to notice that what you are doing is not realistic, and at what degrees you are shifted from what make sense to be the more realistic ( even if i need a quantum computer to think it myself, when i analyze all the renders i had output from all my testing sessions.
I just wanted to satisfy all the most capricious artists ( like me ^^ ).
And It resumes how is all the rest of the toolset and how it has been thinked by myself. ( Zbrush spirit )
What I 'd like it happens now like for the new year resolution for 2017, is that pixologic will attempt to establish the contact with me. give me contact i can reach and so i prepare a special Edition of my toolset for them to play and test it.
I could also restart the beta program eventually. ( send me a sign ^^)
djorzgul > I just can’t to make a wide public beta, because some would only get the resources and use them without any permission out of the plugin.
Which is nothing i want to happen at the moment , i mean till i hadn’t release anything.
And i might release my tangent normal map matcap separatly at same time i release the TEXTURER module.
Well after you second reply Ignacio, i would have a lot to say and i have a lot of idea on what Pixologic should focus on.
One that illustrated greatly your purpose Ignagìo : all Zbrush plugins simply can’t to communicate together.
or about the CGF file that are binary data , whichi never seen tht before, a cfg file should always be human readeable.
What I like Pixologic apply on next Zbrush build is :
-
to port all their plugins like uvmaster, decimation, FBX exporter, decimation, and Subtools Master as Api function that we can use with Zscripting.
-
Even better I like Pixologic share a SDK for third party developers not that goz sdk that none of us has been capable to work with or just to read it :
Access to mesh/uv/morph,
A class that we can use to rebuilt the Viewport/Canvas completly and use DX/OGL API.
A herited class that can extend the default Viewport/canvas of Zbrush
A Shader SDK with some examples of the current shader types that exists already in zbrush. (A way to just extend the current shaders.)
A way to create our own Shader Classes with our own viewport/class class.
Access to input Classes, so someone would try to add VR support in zbrush 
Another really important requests for me :
- Increase the number of matierials in the material picker and Zproject ( let the zscripter handle what is best for the performance within Zbrush).
- Add material to the picker
- Delete a Material from the picker
-
Save BPR render passes ( shaded ) as RGB 16/32 Bit for PSD and TIFF format. ( mainly we can bake a normal map in RGB32bit, but we can only export to rgb8bits which is really annoying
(eventually a button that send the BRP pass into the Texture Picker, so we could save as EXR file.) -
A Shader with the one we can load a texture sampler on into BASE / A / B / COLOR slots
The purpose all these requests is to make possible to handle several variant of the normal map matcap on the same rendering pass( with different intensity per subtool ).
The development of Zbrush is so slow that it would be great to get access to all this.
What you describe would be a dream but I think you are maybe too ambitious with those requests. I would be happy if they would simply release what it’s already available now that could make our lives easier. I can’t tell them to spend their limited time to do what I want. ZScripting has always required to find “creative ways” to achieve goals through hacks, cheats, tricks and other indirect, sometimes overcomplicated methods and I get the feeling that it’s intentionally limited. I don’t think it was conceived with the idea of developing very sophisticated Plugins but automatize and help with tedious tasks. That’s pretty much all.
Good luck. I admire your enthusiasm I hope they will listen to you.
I will like to know if anyone had a close look at the complete Test i made comparing Allegorithmic and ZGametools algorithm of normal mapping ?
And if you got some feedback concerning it.
It’s possible you may had missed my previous message at the end of the page 2, as i posted two messages in a short timelapse 
Now concerning the bridge between ZBrush and Photoshop CC with the layer building support, i like to tell you that i started to script something to build a JSX file out of the rendering process.
Which means that it will check the rendering options and create a psd file accordingly to what is enable and what is not.
it will be faster than output the file during the rendering process, so you can after you export the first time to photoshop, to simply edit the
file into a none destructive approach, if you do additional rendering, it will update the PSD file in real time.
Also if you change the project name, you can rebuilt JSX file on the fly , grouping rendered passes as you wish etc…
You it will be possible to create layer group to have old Diffuse workflow, and PBR workflow, and if you enable both, you could have both into the same file.
Also this way i can apply a crop on the texture depending of the canvas size,to remove the margin, and all this can be invisible process for the user
I gonna make the code easy to port through all the other toolsets ( Renderer and Baker, i still working on the Texturer for now)
Hey Guys, not a long time, and i come back to you with my own solution to work with Zbrush/ZGametools and Photoshop.
Smart and limitless features, you control the entire build process in Photoshop and automate all the task you want.
you can create your own library of functions so easily and its portable for easy reuse.
Now please guys spread the word around you with the link
Here is a video i made few days ago to show how to use the AppendSDk function and hook the Main script process to extend, customize and automate the loading process in photoshop.
fceless ! Wow, what a nice tool !
Where can i get it ?
In_head >
I’d like to give you a quick answer about the pricing
At the moment the all the Zgametools Toolsets are still in development ( Renderer, Texturer and Baker).
The product on Gumroad, has the biggest price as possible to prevent any people to buy the product at the moment.
In middle term period i like to use Gumroad to manage the licensing, and all the activation process
Gumroad help me to distribute the beta version of all ZGametools toolsets.
Lately it will be available with indie pricing
the option will be :
or you bought the full toolsets at once ( texturer, baker and renderer),
or you can get the toolsets one by one and time after time, depending of your needs.
There will be a studio pricing with license per seat, which is also the none indie version if tthe annual revenue exceeds 100k.
Hello guys, any feedback on this ?
Does it gives a global understanding of what the toolset is capable of ?(TEXTURER)
they are all illustrated as icons on bottom of the screen ( just under the zb canvas)
OMG I just found this thread and I am speechless with all the stuff available. This is incredible work and I’m very keen to get my paws on it.
thank you dillster it’s such of comment that keep me motivated