Using the new multires reshape tool we can -almost- import zbrush files into a multires object.
However we need a script to reorder the vertices obj files, so that they match the order that blender creates when it subdivides.
If we had this, we would be able to import full zbrush files into blender, including all the levels of subdivision.
Here is the method so far.
1 In zbrush export as objs all the zbrush levels of subdivision.
2 Import the objs into blender.
3 Select the base mesh “bottom level of subdivision” and make it a multires object.
4 (missing step) reorder the vertices of the obj objects so that they match how multires will subdivide the base mesh.
5 Subdivide the base mesh and use reshape to match the shape to the corresponding zbrush object.
6 repeat 5 with all the levels.
I’ll attach a file to show how it looks with the order wrong. A lot of people have said this is impossible. But we know the positions of the starting vertices and we must know how blender orders the verts when it subdivides so…
Hey, what your are asking is definately possible, however It seems very redundent to build it for each smooth level, as the information propegates anyway. So your workflow should look more like this:
1 In zbrush export as objs the top and bottom level subdivisions.
2 Import the objs into blender.
3 Select the base mesh “bottom level of subdivision” and make it a multires object.
4 Subdivide the base mesh until it has as many polys as the high rez mesh with a multirez modifier.
5 Iterate all the vertices in the multirez (with any remapping needed for different vertice order) as part of the algorithm. Move each vert in object space to match that of the high rez obj file.
The difficult part is definately working out the way zbrush subdivs things, and will take a fair bit of trial and error, and a reasonable amount of time.
Two things. I’ll take the last first.
The issue isn’t how zbrush subdivides. Once we have the objs we can forget about zbrush.(It is the obj exporter that has ordered the verts).
What we have to work out is how blender subdivides. We have have to reorder the obj verts to the multires verts. This means that the order of the obj verts is irrelevant because we are overwriting them anyway. We just need to know how to reorder them so that they match the multires, so we need to know the multires order.
Second, you might be right about only needing the top and bottom subdivs but I think, though I’m not 100%, that the subdivs in between each contain information so you need them all. At least I think you would to get it o be exactly like the zbrush model (I could very well be wrong about that. It might just turn out to be a linear interpolation between each vertex. But I just get the feeling that you will have to load each subdiv into the meshres “slot”)
Yeah I’m trying to figure out how to do this too, I have the feeling that a solution is in front of us, right now.
But is this so important? hm, OK, maybe it is.
Meanwhile, read this tutorial carefully (second page). Its not mentalray only. http://www.zbrushcentral.com/showthread.php?t=83524&page=1&pp=15
I have it on very good authority that because of inevitable issue with uv co-ords and texture resolution you won’t ever get great results doing that way.
makes sense to me, with all the folds of skin it be very difficult to do this with a map.
OK tmcthree, I found it.
Have a look. You have to import the two (lo_hi) messes in same position, its easy, its the default. Scale at 1.00 please (ZB). Now subdivide (3 times here) the low poly mess and…
BTW, tmcthree you didn’t say anything about my new sculpt here. LOL
OK its not finished anyway.
When I’ll finish it, this will make a good adventure story. This started as a voxel 3DC model. Retopo there, turned to a complete meshing (don’t want to speak about it lol). In the end It came as a (unfortunately) 45k in zbrush. Now I have to retopo once again (I hate retopo) and do some sculpture in blender! why not? I should write a tutorial (or a story) about what you have to avoid when meshing with 3-4 apps. But two retopo, this is too much for me.
I am a bit concerned that at very high detail shrinkwraps projections or vertex selection might not be quite accurate enough. I would still like a vertex re-orderer so that we would know for sure that we had nailed it using reshape.
We’ll test this. Meanwhile, it works with 3dCoat too. Here’s a 2.5k model (retopo etc). I projected a 1M voxel made model and here it is. A multi res portrait of a roman. Some small artifacts but edit them easily in sculpt mode. I’m using some SSS (another new trick) BTW. What do you know about 3DCoat tmcthree? You can’t have multires models there but here comes blender LOL. You gave me a great help, you know. Really.
Sorry I couldn’t get back sooner, been at work all day. So I did a quick test with the multirez modifier:
1 Add multirez to the default cube in the scene.
2 Set the subdiv level to about 8
3 Sculpt random detail on the cube
4 Set the sculpting level to 4, and notice how the sculpting propagates down through the levels
5 Sculpt more random detail on the mesh
6 Set the sculpting level back to 8, and notice how the work you’ve done propagates up the levels
This is pretty solid evidence that you only need the top and bottom details from zbrush.
Michalis has come up with a very impressive work flow considering this, nicely done :). However, the main problem is anything that translates the mesh when sculpting has potential to cause problems. IE, the pinch tool, at the highest level in zbrush will result in a loss of sharpness when shrink wrapped in blender, and the subdivided base mesh will have polys in the wrong place to pick up the details. Also, the move tool in zbrush will cause problems as well(try this yourself by pulling out verts on one sphere in blender in a hook shape at a fairly large arc, and watch the shrink wrap struggle).
The best solution is, as you say, to re-order the verts of the high rez from zbrush. I was chatting to a graphics programmer about this at work today, and he pointed out that it isn’t really as simple as it sounds. He also pointed out, that without proper testing it would be incredibly difficult to know which part of the process is changing your vertex order. It could be that zbrush orders the verts differently when subdividing the mesh as part of its algorithm. In addition, it could also be when zbrush exports the mesh as an obj file. Further more, it could also occur when blender imports the same obj file. So the vertex order has potential to get shuffled at a few different points. I don’t claim to know where the problem comes from as I haven’t run any tests.
At least you have a couple of decent workflows you can now use, and hopefully at some point, somebody with the time and knowledge will further improve things.
PS, I also did a few tests with reshape in alpha 2, and it seems kinda screwy even with stuff created in blender. The mesh devistation may not be entirely zbrush’s fault. Although, they were only really quick tests, and were nowhere near as bad as the sample you provided.
My concern about shrinkwrap method (which was an undeniable stroke of genius) is that when you get down to the very very fine details such as pores and blemishes in the skin, if you use project or surface method it may miss the verts and if you choose vertex method you will likely get clumping of verts all onto one vertex which happened to to be closest. Sorry to be pessimistic.
I would love a simple script which would work like this.
select the base multires mesh (a) and then select the next obj mesh in the series.(b)
2 click “reorder” and the script identifies the parent verts in (b) by comparing (a) with (b) and finding which verts are in the same place (parent vertices don’t move when you subdivide.)
3 Now the script knows which verts are the parents it copies the vertex numbers directly from (a) to the parents in (b) (thats the easy bit)
4 now the script has to look at the new verts (the child verts) in (b) which surround the parents verts. and order them in the way blender orders them when it subdivides in multires.
5 we repeat 1-4 using the newly reordered obj as mesh (a) (the mesh with the parent verts) and the next obj in the series as (b)
I’m not sure you read my previous reply nut the reordering has nothing to do with zbrush.
We know exactly when the reordering occurs its when we subdivide in multires.
Forget zbrush. Once we have the objs, they could have come from anywhere. (I could have made them by typing the coordinates into a text editor for all it matters )
The reordering happens when we subdivide the base obj in blender.
Remember that actual order of the verts when we get the models from zbrush is entirely, utterly and completely irrelevant. We are not copying the order from the objs we are copying TO. That is overwriting them!
This sounds like you’d need to “edge walk” out from the “parent vertices”… we cannot use spatial connections or indices… only edge connectivity… which is harder than it sounds!
so I think lived is right… but i also know that it’s zbrush is subdividing in a different order to blender… not an export or import issue messing with the vertex order…
anyway… off i go to check!
I think it would be “easier” to reverse engineer the differences between a subdiv in blender and a subdiv in z-brush then remap vertex index to vertex index…
there’s a script to show the vertex indices in the viewport I’ll have a look at a 1 quad plane subdivided once then twice in blender and the same in z-brush then try and compare!
)