So, I’ve been tinkering with the notion of taking my mesh into another application, because while powerful, the toplogy tools are a bit on the frustrating side for someone who’s used to doing box modeling. What I quickly discovered however is that this isn’t quite so simple as it might sound. Basically my procedure would be this:
A couple general experiences that may or may not be useful.
-
I noticed you were using the set pivot command to manually assign a center. As you probably know, this will throw off the center of the particular subtool in relation to other subtools, and the pivot point will have to be cleared to match up again. Just throwing that out there.
-
I dont have this problem. I import and export subtool components and tweak them in multiple applications, and they always append back in to the proper position.
- Is it possible you have some errant bit of geometry somewhere or another, like a stray vertex, that keeps getting re imported with the mesh that throws off the center, or perhaps the errant geometry in in the Zbrush file, and the re imported components are in the proper position?
Just some random thoughts. Im afraid that based on the way things line up for me, barring one of these possibilities, I kind of have to assume it is an import /export setting in one or both of the applications involved that’s giving you trouble.
Sorry i couldn’t be of more help. If you cant figure it out, and want to post the file, I’ll be happy to take a look at it and see what it does for me, so you can be sure on whether its a local import/export issue or not.
I must have not made myself clear enough. The problem with the offset and the scale happens from Zbrush to Zbrush. No intermediate program. The settings for import and export are the defaults, as will be detailed below. I’ve attached screenshots of the preview window showing the offset of the the centroid of the ZTL and OBJ without any modifications done to the pivot. I only used S-Pivot to line to two models up after discovering this. And that was when I discovered that the scale of the two models was slightly off.
Also note, this doesn’t happen if the started mesh was an imported OBJ. If you use a base mesh from another application, then you will not likely have the problem because all OBJ’s seem to get their centroid put in the center of the mesh. My original ZTL was made with ZSpheres, which I grew up from the first, hence the pivot is at the bottom of my adaptive skin. This however doesn’t surprise me, as I said above, and a recenter of the pivot should accommodate for the problem. However, the scaling issue is another matter. Thanks for attempting to help, I will attach the tool as well so that other folks can confirm or deny the issue.
Yours,
Benjamin
Tool Preview of ZTL (Pre-Export):
Attachments
That is odd. Im afraid I don’t have any answers for you, as I rarely start working on anything in ZB that isnt an imported OBJ (even if the geometry was created in ZB, I still save it out as an OBJ first), so Ive never run across this behavior. Perhaps someone else has a better explanation/solution.
Of course, the good news is, you shouldn’t have any trouble as long as you start working from the exported OBJ as your “base” in the future. Then all future modelling and topology operations should line up without problem, in and out of ZB ( I do it all the time).
If your problem is, however, that you have work put into the original skinned mesh, in the form of sculpted detail, you should be able to recapture much of it by lining up the meshes and using projection. As you found, the “set pivot” function lines up the original ztl almost exactly with the export…close enough for projection purposes.
Its entirely possible Im still not grasping your problem, for which I apologize. There is a lot of information in your above posts. If you could narrow it down to a specific question, I might be less useless.
Nope, I think you got it just fine, Scott. I suspect that a lot of folks use OBJ to normalize this problem out, just as you do. As you say, I can do the minimal tweaking (scaling) to correct for the problem for transfer with projection. I just wanted to know if anyone else had the problem and or knew what I might be doing wrong to cause it. It sounds like it’s just one of those things that’s a quirk of ZBrush. Thanks for taking the time to look this over for me though. I really do appreciate your time.
Benjamin
?
I have the exact same problem, however I started with an imported obj.
Here’s what I’ve done:
- imported base mesh obj from maya
- sculpted up to 4 levels
- retopo (only one side and upper part so far)
- made adaptive skin at subdiv 1
- exported to obj
- imported the same obj without opening it in another program
- scale and position is way off
The idea is that I will retopo half the mesh, then import it to maya where I will mirror and cut off one arm before I take it back into zbrush and project the details.
any new ideas?
I think that your problem literally is the same problem as mine. Once you retopologize, your new mesh originates from a ZSphere, not your imported OBJ . So if you then go back out of ZBrush as OBJ and come back in, you’re doing exactly what I was. I think the scaling problem only doesn’t happen if you do all your topology work outside of ZBrush. So you would have to bring in your OBJ, do whatever sculpts you intend to do, then go back to your OBJ originating app, change topology, make a new OBJ, import that into ZBrush, then retopologize using the SELECT TOPOLOGY button . It would be a very round about way to work however. I myself would be inclined to simply deal with the scaling and fix it in ZBrush.
well, since they line up perfectly in my external app (maya in this case) I don’t think it would help to do the retopo in maya and then importing it. I think the problem is in the way you set up the topology editing in zbrush. If you could select a new topology without switching to a zsphere and using the rigging tools I think it would work just fine.
Perhaps, but you can’t, so it’s moot. Retopology is built on ZSphere primitives (even the topology mesh in Zbrush is really just a collection of Zspheres). If you’re going to retopo in ZBrush, you’re stuck with the problem. I tend to come from a “go around the obstacle” point of view, as opposed to a “move the giant boulder” out of the way PoV. If you can fix it with a few minutes of careful scaling, then I’d say cut your time losses, do it and move on with your work.
Hi guys.
I’m not here to help, the reason is i have exactly the same probleme…
I made a model with zsphere then clean it in maya to have a good base mesh.
I sculpt it and i realise i made a mistake on a finger so i begin to edit my lower subdivision level with the retopology tool, then i made an adaptive skin and export it to mirror it in maya an check it.
Back to zbrush, the imported mesh is a lot smaller and the pivot center is not the same …
I import the low poly from zbrush i used to make the mirror in maya, and same problem…
So it’s a zbrush export probleme, if anyone have a solution, I’ll give him a kiss on the ass!
Similiar problem here. I retopo’d a mesh (which wasn’t in the center) and exported it to Maya to create UVs. I then exported the obj from maya and imported back to ZB and it was scaled different and in a diferent spot.
I tried using the poser scaler but no luck. Any help would be great.
I’ve spent a number of hours puzzling over this, but have not found a solution to why ZB messes up the world coordinates. It messes up scale on a routine basis and it seems to be part of the transition to ZB’S internal representation of tools. My solution (especially for morph targets) has been to hand repair position/ scale in Modo or Silo. Once you get practiced at it, it isn’t so bad…
I found a workaround that worked for me in most cases, heres what I did:
-export the lowest res as “TOPOLOGY.OBJ” (to make an example of it) and change it anyway you want to get your new topology.
-export the highest res as “HIGHRES.OBJ”
-import both “TOPOLOGY.OBJ” and “HIGHRES.OBJ” into zbrush again (note that the highres mesh was exported and then re-imported with no changes made to it)
-select a zsphere, go to rigging and select mesh. choose “HIGHRES.OBJ”
-go to topology and select Topo. choose “TOPOLOGY.OBJ”
-go to topology and hit Edit Topology. If I remembered everything correctly it should line up correctly.
-turn on projection and crank up the “Adaptive skin - Density” to about the same level as your highres mesh and hit “Make Adaptive Skin”
like I said, if I remembered correctly this should work 
the trick is to do everything on new imported obj’s
One of the many resaons why a lot of people are getting really tired of ZBrush in general.
I mean this is just typical of the sloppy coding inside ZBrush and it is totally on the shoulders of the Pixologic team.
Instead of placating Mac users they should have concentrated on creating a FINISHED product and made sure that simple and basic needs such as import and export routines actually work.
I give Pixologic notice that they better get it right in their next release or they will lose a large number of users.
This is your final chance to get the job done right.
Stop trying to be cute and go back to the absolute basic of coding and make sure that the stuff that needs to work does work and then add the fancy stuff. I mean this should be obvious. Just look at all the posts from users that are complaining about what should never be a problem. Also do not blame other programs - its your mess so get it done and soon.
1 Like
Please don’t derail my bug thread with this sort of diatribe. I agree and appreciate your frustration, but I’m really more interested in solutions to problems with the tool as opposed to threats or complaints. The market can make whatever decisions are appropriate for Pixologic and such commentary is best directed in letters of complaint directly to the company itself, not here in a user to user support thread. Thanks for your understanding.
1 Like
Um . . . maybe since you started a new thread over what is a known defect in ZB (to wit, ZB’s .obj import/export which has been flaky since 1.55b and fussy with other apps) . . . perhaps Kirsz felt you were inviting comment. I’m not sure I agree that as thread starter, you are the owner of this thread any more than you’re the owner of this forum . . .
Since you have already identified a bug (and I’m sure you’ve file a bug report with your findings), what’s the purpose of Yet-another-.obj-isn’t-working-right-for-me thread? If you’re going to solicit input on what I presume is an open forum, then you’re probably going get some form of comment.
I find it quite germane to the conversation that Pixologic has turned their nose up at this problem as well–when I first reported the exact behavior you’re allluding to (via a phoned-in bug report), Pixologic denied it was a problem and claimed “it must be a problem in the other program.” Since I was able reproduce the problem in three other programs (that seem to read .obj’s just fine) it makes wonder is this a problem with ZB or all the other .obj readers/writers out there.
By process of elimination, it seems to be a clear problem with ZB (Pixologic’s denials not withstanding.)
I think it is fair for Kirsz to state his opinion (even if I don’t agree with polemic style) on this specific problem and how it relates to a pattern of sloppiness in coding pipeline specific issues (like .obj, displacement maps, normal maps, etc.) especially in the version he’s using, Mac 3.12. If my sole experience of ZB was based on the Mac versions, I would conclude the same he has, along with his view of the future of ZB.
-K
Why is asking folks to stay on topic always considered some sort of imposition on the internet? The thread is about a specific bug and yet it is somehow germane that the conduct of the company should be called into question in a series of threats and angry rants? No, I don’t agree with you that is the case.
I do not go to Pixologic with every problem I find, because I’m no expert and I am never sure this mistake is not indeed my own. In fact, I have NOT contacted the company on this matter as of yet. I opened the thread to see if it was in fact a problem with the software or a problem with my own workflow. It now appears to in fact be a problem with Zbrush itself, which I can work around.
Ah! So the strange moving pivot point is not just a Cinema 4d - ZBrush thing. I’m happy to hear that.
I used the same work around as Kotter.
As much as i love zbrush, i would switch to mudbox in a heart beat if it didnt suck so much as well. So there really isnt a good solution out there.