@Kevin Cain:
Hello,
I can confirm that RC works internally with triangles, so it triangulates any imported mesh.
Export of textures only is not implemented, but if you are interested in this feature you can vote here to rise its priority:
https://support.capturingreality.com/hc/en-us/community/posts/115001351232-Export-texture-only
Hello Travis,
thank you for describing your workflow in such detail! Exactly what I am up to.
(However it doesn’t work yet, for some reason).
I would be very interested to know more about your plugin and would appreciate if you would let me know where to get it (or purchase it).
Hi Gerrit Schulze,
The plugin is almost ready! I’m just adding a few more options before I release it publically! I’m not sure if you can PM me on here but if not, message me on facebook (Travis Scott Nobles) and you can be one of the first to test it out :)
Hi Travis,
many thanks.That would be great.I will visit your page on FB asap.
BTW:I had just discovered that the reimport to RC only works for me if I rename the formerly created rcinfo file during export to the new name of the mesh(obj) from ZBRush. Is this what you still do for each optimised/repaired model coming from ZBrush or does it work without this step in your case?
OH! Yeah wow this post is already a bit old I guess. I now use xNormals for that step, instead of bringing the model back into RC and recalculating the texture. It’s much faster :)
Cool stuff Travis!
I’m coming in a bit late ;^) great thread on round trip through ZB. I’m not sure what may have changed, but I had previously run a model through ZB for retopo, worked fine, but now I’m running into an up-axis issue. RC lives in z-up with no way to change that on export, aware obj can’t save such info, but I’m in fbx and was in fbx when roundtripping previously, when this wasn’t even an issue, my assumption being that ZB took whatever scale/coordinate system and up-axis that came with the file and left all that alone. I now see ZB lives in Y-up. I thought to pass through Maya to change the x-axis, but now a new issue, fbx is recognized in the directory, but won’t import, MEL just sits there doing nothing.
While my objectives in ZB differ from Travis, I’m most interested in returning to the retopo workflow and leveraging normal maps and displacement maps to optimize geo in UE4. Travis, I’d be so interested in your plugin to automate that, which would answer a big question for me how I’d apply retopo to a project involving large sets where I export my model in parts to leverage occlusion culling in UE4. I’m not on Facebook, but reached out to you via my wife’s page, hoping this finds you here in the meanwhile. If nothing more, I’m most curious what explains my issue with losing up axis.
BTW, I’m also scratching my head what to do about scale. If I don’t set scale in ZB, at least that goes unchanged on export, but as I understand it ZB can only perform well in certain functions when it knows the scale, which happens in Scale Master. ZB only supports mm, cm, inches and feet, so coming in with meters, especially large objects poses a problem, since setting those large scale takes ZB out of the 2 x 2 space to which many functions are optimized. I’m speaking to details in ZB that are over my pay grade, just passing along what I’m picking up from reading and colleagues more familiar with ZB.
Thanks for ideas.
Benjy
@Benjy, did you find any workaround on the issue of orientation when exporting FBX from RC to Zbrush?
I still don’t understand, why does an obj mesh works fine but not fbx??? FBX is much more common to use in the industry than obj format and add the fact that fbx gives you as 300% less of file size than obj!
My current workaround is to open the fbx file in blender and “apply” the rotation values in there, export to fbx (again) before I can finally use the mesh on Zbrush.
Here’s a screenshot of the difference between an RC’s OBJ and FBX file when importing to Zbrush.
You can see that the imported OBJ file looks weird and probably has an issue on the orientation, but that’s actually the correct orientation. That’s what RC’s orientation is (X-axis) while Zbrush and most other 3D programs are using Y-axis by default. But the real problem is, why does the FBX file has a different orientation with an OBJ file?? Shouldn’t be the same? What’s the reasoning behind this?
Now, there’s an FBXExportImport plugin in Zbrush where you can supposedly “change” the up-axis of the model. Well, it doesn’t work. I’ve tried all the options and combinations, but same result. The plugin doesn’t help at all.
It’s my understanding that while FBX records up axis into the file, OBJ does not, so since RC is Y-up and ZB assumes Z-up, the question turns to 1) why ZB isn’t using up-axis info in the FBX, 2) seems to only allow Z-up that is recorded into FBX? Is this even the case? If you create a mesh in Blender in Z-up and export, will ZB flip that axis again or does ZB interpret all FBX as Z-up, regardless? OBJ not storing up-axis, the Y-up axis from RC is allowed to pass through to ZB. What further makes me wonder about what’s driving this issue, I encounter the same flipped axis issue when importing an RC-originated FBX into Mari, makes me wonder if RC isn’t possibly to blame in how it writes this up-axis info into the FBX.
JM, try experimenting more in Blender, generate a simple primitive like a cone in Z-up, export FBX, see if ZB’s import pref allows control over up-axis to function as expected. We should isolate away from RC to rule out a possible bug.
And what happened to DotScott1 in this thread? His plugin for ZB to automate normal maps would be so valued. DotScott1, sign of life!
Yeah, it gets crazy. I think RC is X-up (right-handed) and Zbrush is Y-up (left-handed).
For number 2, I can confirm that when creating a mesh on blender (a cone in this example), and then import it to Zbrush as an fbx format - it reads the correct orientation. I mean, the Z-up axis of a cone in blender will be “converted correctly” / yes it flips, as a Y-axis in Zbrush. The cone will be sitting on the ground plane as shown on the screenshot below, thus zbrush fbx import is able to properly see the mesh’s up-axis.
And it’s the same thing, between RC and Zbrush, even though RC’s using a different up axis from Zbrush’s Y-up axis, Zbrush was able to properly orient the model so that it will be sitting flat on the ground plane (Y-axis).
I think the problem in here, is the different orientation between the two programs, specifically RC’s right hand and Zbrush’s left hand orientation. When the two programs are exporting their fbx models, it will “flip” the model based on its up axis and since they are using a different hand orientation and up axis, the model’s rotation will never matched. That is why, my current workaround is to open the fbx on blender, then apply (reset) all the rotation values, before importing it in RC.
Below is a sample screenshot of an fbx model that is export in RC and Zbrush, and then imported to blender. We can see on the transform properties that the models were rotated on different axes - RC model was rotated -90 on Z axis while Zbrush model is 90 on X. This is probably the reason why the orientation doesn’t match when importing the fbx model back to RC. Both program’s axis orientation is from north to south, a total mess.
The way I see it, RC should have an option to select the up-axis on model import and export as RC’s axis orientation is very uncommon compare to other 3D programs.
That makes good sense, thanks for taking it further pushing models from ZB and RC to Blender. I agree on the need for an option in RC to set up axis, but that only covers what happens after the roundtrip through ZB, or even more importantly to me, in Mari, where it’s nuts to paint on something lying on its side. If I got this right, you say ZB now supports setting up axis on import of FBX, but that because it’s unable to control for left or right-handed, this isn’t enough. No? I just poked around and found this in the Prefs:
Have you tried playing with whatever iSwitchYZ is or any other permutations of iFlipY and iFlipZ? None of these work? I’ll try to play with that here too when I come up for air. I should note, RC users aren’t alone in this lament, see posts from a Photoscan user in ZB complaining about the same issue. BTW, something else not making sense, you say you believe RC is X-up, which would be really off-map, but if this were the case I wouldn’t be able to import RC meshes into Unreal with correct up axis as I do, and Unreal is Z-up. I just used my hands to simulate Z-up and Y-up left and right-handed, playing out what should happen in Blender to predict those values you show, +90 on the X, -90 on the Z, can’t seem to get there from here ;^) Matters not. If we can get to a coherent view of the behavior and be sure about the proposed fix in whatever prefs in RC, that’s our strongest bet to affect change.
The import export preference settings is for obj format. I got no problem when using obj. Importing and exporting obj meshes between RC and Zbrush is straight forward, I actually don’t need Blender if I’m using an obj mesh. BUT, as everyone knows, obj is 3x the filesize of an fbx and fbx is the most common file format that is being used in a pipeline and plus fbx supports camera export which is necessary for manual projection of photos outside RC. Those are the main reasons why I’m pushing the developers for a solution when using an fbx format.
The default import export settings on zbrush 2018 and 2019 should work fine.
The actual fbx import export settings can be found on the Plugins -> FBXExportImport, but for whatever reason it doesn’t work at all. Any options that I select gives the same result everytime.
Well, now that you’ve said it, I’m not sure on the up-axis of RC. Yeah it could be Z. I actually based the up-axis on the color of the gizmo - red, which is X axis on all 3d programs.
JM, I just spoke a friend, lots of ZB experience, though he’s not sure about this, it being less relevant to his workflow for 3D printing. In any event, I see the pref in the Zplugin> FBX Export/Import for MayaUp, which is Y-up. This would seem to indicate that leaving it disabled defaults to Z-up, begging the question why a Z-up FBX from RC (if that’s indeed the case) would import appearing on its side. Nick claims the default perspective in ZB is “looking down the barrel of Z”, that is a top view, this because of the 2.5 D nature of ZB, an artist looking down on an artboard. This would also be like plan view for an architect. If this is the case, that would explain the behavior we’re seeing. A good test would be to export a Y-up FBX from Maya, import it under both settings, see if that’s consistent with this understanding. Nick claims there’s a pref setting to control the default camera/perspective.
What still doesn’t make sense, if RC and ZB are both Z-up, and if OBJ doesn’t record up-axis into the file, why would an OBJ from RC drop in with different up-axis than the FBX, you’d think with no up-axis needing changing the absence of a recorded up-axis would allow the default Z-up world to pass through to ZB. Have you posted this issue or question on the Pixilogic forum?
I did a few more tests on different scenarios but still getting the same results. I think I’m gonna stop on this and would just wait for RC update of having an option to change the orientation on mesh export.
Zbrush is definitely left-handed Y-up axis. Here’s a good discussion about this, including other 3d programs:
https://blender.community/c/rightclickselect/HGbbbc/
http://archive.zbrushcentral.com/showthread.php?5481-Zbrush-Coordinate-system
For RC, I would think its X-up right handed. This problem still exists for quite sometime (almost 3 yrs) and still happening today, and the way things are going right now, no one seems to know which side is the problem.
I’ll try to ask on zbrush forum, but I won’t count on it as I also tried zbrush 2018 and still got the same result. I doubt its just a normal bug. Something is probably broken in between these two apps that requires them to sit down and talk.
Hello!
Do not touch FBX! Even experienced 3DSMax and Maya users know how buggy FBX support in ALL apps. And zBrush was never had good support for FBX.
If you want use generate UV in external app, including zBrush, i highly recommend use OBJ. As proven interchangeable file format that using most of 3D scanning studios around the world.
JM, I think Vlad’s point may hit the nail on the thumb. Now that I think of it, I’ve heard this from other folks with way more time outside of RC about problems with FBX. I agree, it’s a real shame having to deal with bloated file size and not bringing cameras along. At the same time, I’m not one to easily let go of a problem, see no reason to dismiss a possibility here; might it be that Autodesk’s FBX format missed it on accounting for an important detail like left or right-handed in how that information is generated, passed through the file, and listened to on the other end? Vlad, when you say buggy, I hear problematic due to some random variable, but how certain are you that this couldn’t be a case of something masking as random behavior, but in fact is predictable and based on incompatibility between two programs, RC and ZB in this case, where failure of Autodesk to account for something like left/right-handed causes the issue flipped up-axis? This issue, while real, seems at least consistently off, not random. Maybe, artists working in 3ds, Maya, Mudbox, ZB experience yet other issues unrelated to up-axis that indeed are “buggy”, but it seems the only problem between RC and ZB in FBX is limited to up-axis, might be worth making a distinction? Appreciate your insights.
Hey All,
Great thread - Quick question
Export model
Open external software to edit and instead of editing the mesh I build a new mesh
Then export
Reimport into RC for texturing
Will this work? I have some fairly basic shapes that are part of a larger scan like cylinders, boxes, and tubes. RC missed some geometry on them and I would like to just replace the meshes with simple models.
Also, a similar question. Can you bring any model into a RC scene and then “texture” it at any location? I know this would casue some strange texturing but will the software do this?
Thanks all!
C