Hi all,
I know the Displacement Exporter 3 isn’t out yet. I have a project due Wednesday and I need to generate a displacement map. I can’t bring it back to 2 for obvious reasons and the displacement generator under the tool pallete just generates a gray image. If anyone has any advice for me, I’d greatly appreciate it. Thanks
I understand you have urgent needs but until now we dont have any official announcment for the release of the various plugin.
Andreseloy
What are obvious reasons of not getting this model into Zbrush 2? Export highest level to .OBJ than import it to Zbrush 2 and recreate subd. levels. Being on the first one - generate Displacement map. It’s really not that hard, especially in your situation, where you don’t have other options.
Try using the Adaptive scan mode or set a DpSubPix of 0, that worked for me For some reason when I increase the DpSubPix above 0 I also get just a grey image, with very little displacement information. Hope this helps
Im having the same problem, can’t seem to figure out how to solve this.
S3r3, your method worked, though the displacement map is still not good enough. Is it same for you? When i use the maps in maya they turn out really bad, no matter how much i play with the settings.
Anyone found a way to export the displacement maps in a propper way with good result?
Cheers
/Fa
Ok got another question, when the heck is Displacement map exporter 3 releasing? They mentioned that it was about to release the first week in june, if im not wrong. It passed… would love some information about how it’s going.
You can generate displacement maps in ZB3. You can’t do normal maps, yet. You have to install the old Displacement map plug-in, and use the interface under Tools>Displacement, and not in ZPlugins. If you want a normal map from that generated displacement map, check out this thread.
http://www.zbrushcentral.com/zbc/showthread.php?t=46231
There is no need to install the old MultiDisplacement 2 plugin. That should NOT be installed in ZBrush 3.
For ZBrush 3, here are the steps that you need to follow:
This will be a 16-bit grayscale displacement map. As such, you’ll need to set the displacement values manually in your rendering engine. 32-bit displacement maps will once again be possible once we release the MultiDisplacement 3 plugin.
I’m going to try out these steps, but it seems like alot more work than I was suggesting with the old plug. You got morph targets, and fliping the results, and I didn’t do any of that. Simply goto a lower level, and press the “Create DispMap” button under Tools>Displacement, to get a 16bit map. As long as you don’t use the interface in Zscripts, it works so easily. I can even make a normal map from the results.
Definitly, not 9 steps, for sure. 4 at most.
His extra steps refer to the fact that the displacement map generated is based on the changed mesh. Which is why he says to store a morph target before you ever start sculpting. Using your method, there are still a few more steps, because if you want to use the displacement map generated, you must also export your changed mesh (and be sure the UV’s havent stretched as a result of the sculpting).
GM770:
You should also add “make a backup of your ZBrush directory” and “install the outdated and unsupported plugin” to your list. So, that’s eight steps now, but who’s counting? 
Anyway, I’m not comfortable with any of that for day-to-day use, but if you’re on deadline, by all means do what you have to.
…and then learn from that mistake.
Fahim:
“Really bad” doesn’t identify the problem. Members of theis community have doubtless encountered and solved exactly what you’re going through, but if they don’t know what that is, they can’t help. Provide screenshots?
“Make a backup of my Zbrush Directory?” What are you talking about Ctrl-Z?
Anyway, I just un-installed the old Displacement map plugin, and finally got it to work without it. Very odd, since I tried like 10x when I first got ZB3, and it didn’t work without the plug-in. I always got a flat grey image, and people on the forum were echoing my situation.
Very odd, oh well.
So for a normal map, it’s only 3 more steps in addition to the 4 I listed.
5) Set your Material to “NormalRGB” (not included with base package)
6) Select your new Displacement Map in the Alpha list, and press “Crop and Fill”
7) GrabDoc the resulting texture, and export it.
Try to follow my logic.
You’re installing something more sophisticated than other plugins. Maybe it plays nice in the new version, maybe it even works, and maybe it uninstalls cleanly. Or maybe it doesn’t. I have no way of knowing, and unless you’ve studied the source code, neither do you. Not 100%.
Now, what we do know is that the support staff has explicitly stated this was a bad idea.
Should this stop you? That’s not for me to say.
But if you’re going to discount advice from the only people fully qualified to judge whether this is truly harmless and reversible, I feel pretty strongly that you should back things up first.
Call me paranoid, but no one’s ever regretted making a backup.
Can you say the reverse?
Ctrl-Z, yeah you do sound a bit paranoid. Many scripts from ZB2 don’t work, but that should not stop you from experimenting. I’ve added scripts that prevent ZB from running. You remove it, and all is well again. They are not integrated into the Zbrush code, so no you won’t have ill effects. They don’t modify ZB files. The plug-ins are not true plug-ins, but just compiled versions of scripts, that have a GUI interface. If we were talking about dll’s and win-32 calls and so on that directly interface with Zbrush, I would say, you are right, but not in this case. There is no harm involved with things that are script based, since they are already in a sandbox of sorts.
A real plug-in that could have ill effects, would be C or COM based, compiled outside the target app, and integrate directly with the internals of that target app. No need to fear ZB scripts. Without an API, there is no way to directly integrate with the internals of an app, unless you are a hacker.
If we were talking about dll’s and win-32 calls and so on, I would say, you are right, but not in this case.
Let’s test that theory. :lol:
The very plugin we’re discussing ships with ZBrushDLL.dll and ZBrushDLL.lib in the DisplacementExporterData directory. It is, by your definition, a true plugin which additionally happens to use the compiled version of a script to provide a GUI interface.
Umm, you conviently forgot about the “directly interface with Zbrush” part. So yeah those are dll’s, but they don’t talk to Zbrush directly. The ZSC file does, and that’s a script. If you check out the Zscript language, you would find that you can call a function in a DLL inside a script, and return a value. It’s called “FileExecute”, look it up. So the DLL is actually not working inside of Zbrush. No API, no direct communication. I’ve made stand-alone EXE/DLL files that comunicate via script to apps. My latest is for Modo. In no way can I interface with the app, due to no API. But they offer scripts that can externally call functions. Totally different. The purpose is to do things that Zbrush can’t such as OS specific stuff, but it’s still running outside the Zbrush app. So no it’s still not a “True Plug-in”, dispite having a dll and lib file.
It wasn’t so convenient. Perhaps you failed to communicate it?
(The statement I responded to had to do with “real plugins” vs “script with GUI”. The statements I didn’t respond to drew further distinctions to seperate “real plugins” from “real (and potentially harmful) plugins”. You’re saying now that I should have merged these ideas, and I’m saying you should have structured your presentation differently if you wanted that result.)
We’re getting further and further off track, though.
I don’t believe that it’d have to be a “real” plugin in order to cause problems, with or without direct communication to the host app. But rather than disect what a plugin can or can’t do, we should probably make sure we’re on the same page as to what all constitutes a problem.
What was going through my head when we started this conversation was really just the theoretical possibility that one or more parameters (whose default value or base functionality in 2.0 might be different in 3.0) could be programatically altered and saved by an older ZScript. That’s it.
Yes, ZScripts know what version they were compiled in, and their behavior is processed for backwards compatibility. But, if that were 100%, we’d have no broken ZScripts. But there are some with every version.
I suppose it’s a special kind of paranoia, but I have to treat unknowns as a threat. Strangely, I don’t think you disagree on that – we’re just conflicted as to whether or not there are any unknowns.
(I think “fileExecute” is a whole other discussion, which most likely culminates in me explaining that this command alone is why I won’t run scripts from unknown authors unless the source code is provided, and you declaring in exasperation that there will never be a need for that kind of distrust here. And you won’t be wrong. But then, neither will I.)
Just to leap in here 
As to what constitutes a real plugin, I think you can be fairly certain that any Pixologic released plugin can interface with ZBrush directly (if it wants) beyond what is available to the community zscripters. Take, for example, ZMapper. When launched, the model is displayed using OpenGL. There’s no way to access the individual vertex positions using standard zscripting (other than the lengthy process of writing and reading an OBJ for each subdiv level), so either the zscript code accesses the relevant memory and passes data to the dll, or the dll accesses it directly.
Just my two penn’th,
Finnaly, something we agree on. We’re getting further and further off track!
This whole discussion started over the use of the old version of the Displacement Exporter. Many people have used it. If you want to be paranoid, that’s fine, but to advocate that view without reason, is something else. You said you wouldn’t trust the author. The author, works for Zbrush. In that case don’t use Zbrush. This is a public forum, if a plug-in is malicious, you would find out fairly quickly from other users. You don’t need to be first in line to try something out, if you are paranoid, since under your description, any software is possibly malicious. And while that is remotly possible, to tell people to backup thier copy of Zbrush, for a plug-in that is almost 2 years old, published by Zbrush, has over 95,000 views and almost 200 replys. I don’t get it at all. I was hoping you’d qualify your paranoia by telling me about some malicious zscripts that has caused problems, but not even that has occured, instead blanket statements. OK, Zbrush said it was a bad idea to install it, but others already have, without injury. In addition, if ill effects were involved, Zbrush would have said, “It can do that and that problem, if you install” and placed huge warnings on thier forum. I was not the first to install, nor the first to say intalling it is fine.
If you want to be paranoid, that’s fine. It’s a personal decision. But if you want to tell others the same, you should back it up with reasons to do so. And of all the scripts to tell people to be paranoid about, you pick one published by Zbrush, and used by flocks of ZB users.
Stop there.
You’re so far out of context now, it’s not even funny. What part of “that’s a whole other discussion” flew past you?
What I said in -this- discussion is that if Aurick says we shouldn’t install a particular Z2 plugin and we choose to do so regardless, we should respect the fact that he’s closer to the source than us, and treat that with more weight than anything you or I have to say.
Installing this plugin appears to be safe. I understand that. But I don’t trust it. Because I do trust Aurick, and Aurick clearly doesn’t trust it.
Acknowledging that some people may still need the plugin, which I don’t personally believe (given the alterate instructions which you yourself have since acknowledged work fine) but I still try to respect, I suggested the compromise of “do what you have to, but make a backup first.”
Your posts in this thread are slowly escalating from “Aurick is silly” to “CTRL-Z is the antichrist”. Why are you this worked up over it?
In addition, if ill effects were involved, Zbrush would have said, “It can do that and that problem, if you install” and placed huge warnings on thier forum.
In what universe?
If ill effects were involved, Aurick would pop up in threads where its use is advised to say “That should NOT be installed in ZBrush 3.” and offer an alternative.
Again, I’m not saying there are ill effects. I’m saying that ill effects are possible. You’re saying they aren’t possible, and that it’s also impossible you wouldn’t know by now if there were. That’s ridiculous.
We do agree that ill effects are not likely. But, if the effects are subtle, if they’re difficult to track down, and if the current release isn’t 100% stable without it, they would absolutely slip past the other users. I don’t care how many users are on it, it would slip past them.
If you want to be paranoid, that’s fine. It’s a personal decision. But if you want to tell others the same, you should back it up with reasons to do so. And of all the scripts to tell people to be paranoid about, you pick one published by Zbrush, and used by flocks of ZB users.
“There is no need to install the old MultiDisplacement 2 plugin. That should NOT be installed in ZBrush 3.”
That was my reason. I don’t need any others.
If you want to be reckless, that’s fine. It too is a personal decision. But if you want to tell others the same, you should expect to have people qualify your advice with the occasional cautionary warning.
…and not be offended by it.
I’m walking away from this conversation. You’re welcome to keep insulting me, but it’ll have to be behind my back.