Generate Texture while KEEPING UV's from Retopologized Mesh?

Answered

Comments

36 comments

  • Avatar
    chris

    Have you been bringing files back in already from zbrush?

    just make sure you copy the rcinfo file from the model you export, and then renaming it to add in your new zbrush models name.

    this will let you re-import it to the correct location.

    then it should be just a matter of hitting texture. it will ask you if you want to keep uv's or make new ones.

     

     

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    In my experience, re-importing works without the info file if you select Grid Plane as coordinate system for export transformation.

    I'd be curious to know if it worked with the custom UVs.

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    Thanks for the replies!! And yeah It turns out that apparently it keeps the UV's from the imported model by default I guess. I should have tried it before asking I suppose. I was just worried about wasting time generating many textures they may not have been correct. 

     

    But yeah, thank you for your replies :) Greatly appreciated! 

     

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    Travis, I agree that it's smart to unwrap in Mudbox/Z-Brush/Maya, rather than RC.  As witnessed by many posts in this forum, UV tile allocation is often suboptimal in RC and the number of small patches created makes it difficult to paint in post.

    I'm sure the community would love to see a side-by-side example of a texture tile from RC and one from your unwrapping settings in Z-Brush.  If you can post a couple images I'm sure it would make the value of this clearer to many of the users who don't have a production background in CGI.

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    @Kevin Cain: That's a great idea, I should have done that in the very beginning. Here's a before and after as well as a "rendering" from RC of the actual object. 

    Straight from RC after processing: 

    UV Unwrapped: 

    Final Model (Note: Rendered low res, but the model looks quite nice): 

     

    I bring the RC model and textures into Z-Brush and use automated methods to retopologize, UV Unwrap, project and save multiple LOD's through a plugin I created. Basically I just click "Load" - pick as many models as I want up to 99, then click "save" - choose a save location, and finally click "Process" after selecting the desired settings (texture output resolution, desired lowest LOD poly count, number of LOD's and projection distance). The plugin does the rest. It will go through and process all models and save them into subfolders according to their original names (saves LOD obj's and diffuse, normals and displacement maps). 

    ^I'm not advertising or anything here. Just explaining the process I go through and that I've made it easier by creating my own plugin :) So far I'm loving RC btw! So faaaaast. It's making my job a lot easier :) 

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    Also here's a before and after retopologizing. 

    Before: 

    After: 

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    Wonderful to see, thanks Travis!

    As you show, RC exports a bag-of-triangles, in contrast to the nice structured quads you show here, so that alone is a strong argument for your approach, even before the decimation benefits.

    I have Z-Brush 2018 and would to try out your plug in, if you're amenable.  I have a large interior model that I was planning to take to Mudbox to convert to quads, but would be excited to try Z-Brush instead!

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    I also think that the example is quite nice - not least the quality of the scan itself!

    But I feel it is necessary to point out that the ZBrush model has a significantly lower poly count (I would say at least factor 10), so it is not quite the same. Also, we see here a highly ordered quad mesh, which is not really comparable to a tri mesh to begin with.

    I understand that a quad mesh is important for many post processes, but there are just as many uses for which thr RC tri mesh is just fine. The same is true for the unwrap you started with - no doubt the second one is MUCH better for post processing. Bt the texture ON the model should not be affected by the RC distribution in the unwrap.

    How about you simplify the model in RC to a number about twice the surface count of the quad mesh and post it here too? Would be greatly appreciated!

    PS Been a while since there was such an interesting thread...  :-)

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    Naturally a quad mesh is not intrinsically superior to triangles, but it does tend to make hand editing much easier.  ;-)

    I agree with Götz that it would be interesting to compare a simplified RC triangle model to the sub-D surface from Z-Brush.

    My general willingness to leave UV operations to other software comes down to two things:

    • When RC computes a texture atlas, it doesn't always use the available tile space well -- which is a real problem when we need optimized tiles for real-time projects.
    • I've seen RC generate non-manifold output, lamina faces (all vertices shared between two faces), and other kinds of geometry problems that causes other software to cough and sputter when edited a RC mesh.

    Some of you may be tempted to repeat the oft-expressed idea that we are best off when we use software for its core strengths -- and for RC, that of course is MVS, not unwrapping. 

     

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    Kevin, I agree with you absolutely. No doubt about the need for resurfacing for VR etc. Also about the point of using each software for its main purpose.

    But me for example, I mostly do this for orthophotos generated within RC, and for that the meshes are totally sufficient.

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    Hey guys, 

    Good to see this thread has some interest :) Gotz: I mainly retopologize to generate multiple LOD's that can be interactively interchanged whit each other as you get closer to the object for use in video games and other 3D software. It is also essential for me to be able to edit/paint the unwrapped textures easily. Also I just like having clean mesh so I don't mind the retopology process :) With the original model straight out of RC, it tends to have many small artifacts like overlapping faces. The retopology process eliminates those. Additionally, with the texture that comes out of RC, it would be nearly impossible to paint in 2D, although you could paint in 3D in something like Z-Brush but that wasn't what I was looking for. 

    So bottom line: This is something I have to do for my particular workflow. Again, this doesn't mean that RC is doing any sort of bad job or anything, in fact, it does a fantastic job and it does it quickly! It's just that again, for my workflow, I need to do a little bit of post work. 

    Another thing is that I can actually generate a retopologized mesh that is just as dense as the original scan or even twice as dense or more as the original so I would still get all of those little details in the actual model.

    HOWEVER: Because my Z-Brush plugin also generates a highly detailed (from a very dense mesh), UV-Unwrapped displacement and normals maps, it is not necessary for me to have such a dense model to get all of those little details. Here's an example of what I mean. Below you can see the original mesh from RC, rendered in 3ds Max, and then below that, the retopologized mesh with normals and displacement rendered in max. 

    NOTE: This is a model that I still have not cleaned up just yet, as you can see there are some artifacts on the horns and stuff like that. I rushed through without cleaning it so I could show you guys examples of what I was talking about. 

    Here's the original RC object rendered in Max - super dense mesh (~4,000,000 polygons): 


    Here is the retopologized modelfrom ZBrush with cleanly UV-unwrapped textures (diffuse, normals and displacement) and clean, quad mesh: 

    And here's that same retopologized mesh noted above in wire render (with displacement and normals still enabled):

    Same mesh as above but in clay render: 

    So as you can see, I still get all the little details of the original mesh from RC but with a much cleaner, quad mesh with clean, UV-unwrapped textures. 

    I guess I should probably also do a clay render of the original mesh so you can compare and see the difference. I'll do that next. I'll also try decimating the mesh in RC to compare but again, I wouldn't be able to use that in my work due to the UV map that it outputs. 

    Kevin, I'm not sure if we can PM on here but try to PM me on here and if you can't, let me know and we'll find some other way to chat privately about you trying out the Z-Brush plugin I made. 

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    This is the clay render of the original mesh from RC for you to compare to the retopologized mesh: 

    Except for maybe some really microscopic details, I think it looks exactly the same. 

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    BTW the retopologized model above is 200k polygons - lowest LOD model I did, though I could have gone lower if I needed to. That was generated from the 4 million polygon model from RC. I like to generate my LOD models from a high poly model like that so I get all the fine details when the normals and displacement maps are generated. 

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    Wonderful to see these, thanks Travis!

    I don't think this system allows me to PM you but you can email me:  kevin (at) insightdigital (dot) org.

    0
    Comment actions Permalink
  • Avatar
    Götz Echtenacher

    Very nice! Thanks a lot!

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    I made a round trip from RC to Z-Brush and back as shown below, via these steps:

    • Reconstruct model in RC, export as .obj
    • Import in Z-Brush then decimate, retopologize as quads, lay out a symmetric uv atlas, then export as .obj
    • Import mesh in RC, texture and export as .obj

    My question: RC has no trouble importing the quad geometry from Z-Brush (below, left), but after texturing RC's export is as triangles (below, right).  I edited the .mtl sidecar for the .obj mesh to point to the texture RC exports, which is simple enough.  But I wanted to see if you're handling the texture assignment in a different way.

    Or are able to get RC to export quads directly?

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    @Kevin Cain: solution: apply the newly generated texture to the retopod model from z-brush. The models have the same uv's so the z-brush model should be able to use the new texture just fine.

    0
    Comment actions Permalink
  • Avatar
    Kevin Cain

    Hello, Travis -- yes, that's exactly what I did above, as I wrote.  My question is just a detail on specifics:

    I manually edit the .mtl file from the .obj Z-Brush outputs (quads) to reflect the texture RC exports.  That is, ignoring the .obj RC exports (triangles) but using its texture.  Is there a better way to do that?

    So far as I know there's no way to export just the texture from RC, only the 'Export:Mesh' option in the 'Reconstruction' ribbon section.  It seems a little silly to have to export a large mesh as triangles from RC when already have the quad mesh from Z-brush, but I don't see a way around that.

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    Oh I see. Yeah texture export from RC is something that has been requested for a couple of years apparently but hasn't been implemented yet. I hope it does get implemented because that would be really useful to me and I'm sure, many others. 

    In terms of quads: Yeah RC is a triangle system and I don't think it can use or display quads so the method you're using is probably the best for now. 

    I do something similar whenever my Z-Brush texture (diffuse) isn't up to par. I bring the ZB model back into RC and generate textures. Then export the model from RC (which exports a mtl and texture map) and then I go into the folder and delete the obj and mtl, just keeping the texture for use on my retopologized ZB models (as the diffuse, in place of the diffuse rendered from ZB). 

    0
    Comment actions Permalink
  • Avatar
    Kruzma

    @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

    0
    Comment actions Permalink
  • Avatar
    Gerrit Schulze

    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).

     

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    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 :) 

    0
    Comment actions Permalink
  • Avatar
    Gerrit Schulze

    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?

    0
    Comment actions Permalink
  • Avatar
    DotScott1

    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 :) 

    0
    Comment actions Permalink
  • Avatar
    Bill Isenberger

    Cool stuff Travis!

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    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

    0
    Comment actions Permalink
  • Avatar
    JM Turner

    @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.

     

    0
    Comment actions Permalink
  • Avatar
    JM Turner

    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.

    0
    Comment actions Permalink
  • Avatar
    Benjamin von Cramon

    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!

    0
    Comment actions Permalink
  • Avatar
    JM Turner

    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.

    0
    Comment actions Permalink

Please sign in to leave a comment.