ZBrushCentral

3.5R3 (Import/export Scale issues with subtools and transpose master)

Just have to jump in here as I’ve been seeing and dealing with this issue since 3.5 was released. Was really hoping R3 would fix the issue, but sadly no.

It’s a serious deal breaker, and has forced me to move back to 3.1 every time.
I’m curious if this whole export/import issue is linked to GoZ changing the way things work?

As 3.1 and before was rock solid, and have never experienced such issues.

During work and testing, the mentioned issues arose with both .obj and .ma files. Tested in maya and softimage.
Sometimes it will occur straight away, others a few days into work. (As has happened for other people).

This issue needs an official explanation and work around, or to be fixed.
As it completely stops the usability of such a great release that is 3.5

I finally figured out what was going on for us yesterday. To make a long story short (I spent abut 12 hours Saturday working on this), it turns out that our Maya settings are all in inches (because we do a lot of 3d printing). Zbrush is in cm. Once I set maya to cm, bingo, .ma files go back and forth without a problem.

Now if only .ma files included polygroup info…:wink:

I have the same issue, things worked rock solid in 3.1 and models always aligned right.
Now with 3.5R3, new imported models don’t line up with model.

Moreso, If I use floor grid, it shows it properly relative to models, but then the grids don’t align between models (?) very confusing …

Edit: Whoop it suddently worked, I was able to append a new imported model as a subtool and things were lined up … very random, officially witchcraft :X

zb3.5 R3
Max 2010
Win 7

Exporting decimated .obj from zb settings 1,0,0,0 Import to max and the .obj comes in at an unusable scale. System units for max centimeters, unit measure 1 centimeter. Actually makes no difference meters or centimeters any combo yields the same results. Exporting the tiny mesh allows it to come into zb at perfect coordinates and size.

Importing the mesh and converting measurements to meters give a too big mesh but workable, exporting that mesh back into zb and its enormous. Leaving max system in inches and converting that into meters on import gives the right size for max but fubars the mesh on export for use in zb. I really dont want to scale stuff in max as I am sure pivot point hell will ensue. Its important that all tools and subtools come in at the correct position and size. Subtool scale function doesn’t help.

Been at this all day,… damn!
My biggest mesh is the top tool.
Will keep looking.

Ok my findings are these. Importing a mesh from max at the correct scale and importing to zbrush shows exact coordinates in the export dialogue, not 1,0,0,0. ReExport out of zbrush back into max and add geometry to be appended as a subtool. Export that geometry and import, place original tool in zbrush and append imported object. Note the crazy numbers are in the export dialogue. Everything fits like a glove.

I must have screwed up between versions but the holy workflow is safe :slight_smile:

My problem is a bit more simplistic but just as annoying. I created a mesh in Maya and exported it as a .obj. The mesh was centered in Maya but when I imported the .obj file into Zbrush 3.5R3 it is off center.
I am still quite new to this entire polygon modeling thing so I don’t understand a lot of the technical talk going on here. So can anyone tell me in plain simple language why this is happening or what I can do to fix it? Or things I need to check to prevent this from happening?

Chris
http://www.youtube.com/user/iamkidzero#p/a/u/2/ONgw9VSsl_I

Chirs

Are you talking about the values in the export sub-palette is different or that the tool you are adding is off centered? Are you appending this Maya model to another model that is already in ZBrush?

If you could record a video of what is going on using Jing at www.jingproject.com or something that would help as well.

Try exporting from Maya as a .ma file and importing that on top of the Polymesh Star.

Paul

Is the pivot of the mesh in the centre in maya? If it isnt zb will place the pivot at the centre not necessarily the model.

Let me explain a little bit more. I have created the following mechanical device. It has many different objects, and I export them one at a time as OBJ files. They are centered perfectly in Maya. I took extreme care to ensure this. However when I import any of these OBJ files into Zbrush it is off center from left to right. See attached files. I did not know that Zbrush would import a .ma file. But I will try doing that tomorrow.Walker3.jpg

Thank you for your help!

p.s. I have been trying to work with the .MA files as suggested above, but every time I try an import one into Zbrush it says it is missing vertex XYZ data. Maybe that is part of the problem?

Attachments

Walker4.jpg

Walker5.jpg

man. are we gonna see a proper fix for this or what ?

Basically, production here has ground to a halt. This is a show stopping bug and we need some sort of support to address this issue. Is there any way to get someone from Pixologic on the phone or somewhere to upload files to find out what in the hell is going on here or to somehow address this problem of the scale being off?? Any help would be GREATLY appreciated.

Hello Iamkidero

The reason you are getting this error “but every time I try an import one into Zbrush it says it is missing vertex XYZ data” is because you have to delete all the history first before exporting the .ma file from Maya.

The image of ZBrush did not show a good example of the issue. Would it be possible to show more ZBrush screenshots. Actually it would be best if you could share your model with me so I can test for you.

What is the workflow when bringing everything into ZBrush? What I mean by that is are you selecting the Polymesh Star first and importing ontop of that? Then appending a Polymesh Star to that new obj then importing the next piece on top of that?

Thanks.

Paul

If a SubTool’s scale is thrown off somehow, here’s how to fix it:


  1. Select a different tool, such as the Simple Brush.
  2. Import your original model again.
  3. In the Tool>Export menu, note the values for the Scale and Offset sliders.
  4. Select your problem SubTool and set the Export sliders to match the original.
  5. Export your model and then import it again.
This will reset the scale and offset to the correct values for the model.

Thanks for your message Nick - BTW Your message box is full which is why I’m posting here !

I’d say its a near show stopper on the characters I’m working on as well. There are a lot of nice features with 3.5R3 but this crazy scale offset thing, makes it incredibly painful. So in my current workflow I make my high res in zbrush, bring in to max, retopologize, rip the normals, apply the maps to the realtime model. Then correct the scale and offset of the model. Then hand off to the rigger.

The scale and offset problem seems to pounce randomly. Its hard to tell when and why it will show up. As someone else said its witchcraft. But myself and my co-worker have had the same problem come up. It showed up in 3.2 and its still here. It was not present in 3.1 . So its some bug pixologic added into the software.

Here are some definite times I and my co-worker have found the problem occuring:

  1. Using the transpose master. After going from the transpose single mesh to multiple subtools something happens. Scale and offset is incorrect. But those export values are the same:
    1 scale
    x offset 0
    y offset 0
    z offset 0

  2. I’ve found if i edit a mesh in max(the program our company uses), and remove a row, or add a row, or any mesh modification it will cause the scale offset problem.

-thanks, kip

man. i’m at my wits end. please. for !@#%$ sake. release a patch or something. that we should have to attempt ANY kind of hack ( auricks last did not bring any success ) to SIMPLY IMPORT A DAMN MESH is really quite absurd

Wouldn’t be possible for Pixologic to release a plugin to simply copy/paste these values from one subtool to another ?
It’s a real pain in the bum when you have to import/export a lot of subtools on a day to day basis… :confused:

That’s a fix. But really it would be preferable if they would fix the issue at the fundamental level. This is a very big problem, and it makes it so the user has to adjust to the program rather than the program adjusting to the user.

I remember in early iterations of Zbrush there were little specific things one had to do in order to do this or that particular operation. This seems to be a return to that counter-intuitive, time wasting workflow.

Realistically the only reason I might use 3.2-3.5r3 over 3.1 is the huge number of polys one can seem to use now. But I think a lot of game developement assets could probably do fine without these millions/billions/whatever number of polys. Certainly all the hits of last year were either done with 3.1 or mudbox.

I would expect a more robust mature application wouldn’t introduce these “walking on eggshells” type problems into their latter iterations of the application.

The company I work for has literally lost thousands of dollars because I have not been able to find a solution for this issue. Thank you for your temp solutions for the problem, but I really hope this will be addressed in future releases…

I just wrapped up my 5th character model since the release of R2 and R3 and have encountered significant problems with scale and offset with each character. I haven’t been able to nail down exactly when the settings are getting hosed but it seems to occur when moving data back and forth with my host application. With this most recent character, when I imported and appended new subtool geometry, I noticed they were huge and offset when compared to the rest of the subtools, so when I checked the export settings the scale and offset had been changed by zbrush. Setting these to 1 0 0 0 and re-appending the new subtool fixed this but then I had to open an old version of the ztool before I exported and manually enter in all the original scale and offset settings. This is a really pipeline hostile workflow. Is there a reason this has been established? If there is an under-the-hood reason it should really be transparent to the user.