![]() ![]() It's a tool you just have to be cautious with, and I don't know if Andrew can improve it or not. This is why it is not as much of a problem when scaling outward, rotating, or just moving verts. When you scale inward, just like with a Shell modifier, each vert starts to lose real-estate and intrudes upon the space of other verts. What 3D Coat is doing is binding each retopo vert to it's nearest counterpart on the voxel model. At some point you will create self-intersection. I have to use the same precautionary measures when using the SHELL Modifier in 3ds Max. It may very well be a bug, but you have to be very careful scaling inward, and this is not a problem exclusive to 3D Coat. Meanwhile, I will position my objects in Houdini. Transform_conform_retopo_mesh_after_scaling_down.jpg Scaling up yields less severe, but also noticeable problems. It looks almost like their vertices were trying to snap to some invisible reference (and there's none present in the scene). It seems that scaling the object down breaks corresponding retopo groups. The problem I encountered can be reproduced with any pair of objects (with the default human figure and its decimated counterpart, for example). If you have other objects in the vicinity that you do not want manipulated, then you must hide it. Whatever is visible, that is what 3D Coat assumes you want to conform. The thing to remember is that you do not want any other retopo meshes visible. I think it works about as well as one can expect and has saved me a lot of work in the past. I was the one who requested it of Andrew after noticing that it was a real PITA to go back and make some sculpting/posing tweaks.only to have to do a ton of work trying to make either the original low poly mesh fit the change or your Retopo mesh, if you have gotten that far. Which makes sense I know as you're not literally hooking up sculpt layers to retopo layers, I don't blame the tool, I just think it's a bad tool for most scenarios. Also pretty annoying that it will conform whatever retopo verts are within the vicinity, regardless of layer. I can't be of any help, but yeah I tend to avoid the conform retopo function even on simpler assets as it tends to jig my verts around a bit and I'll have to go back in and correct it. The question is can it be done in 3D-Coat only. I know how to do this with the involvement of 3rd party software. I wish each object that we have in 3B files (be it retopo group or a VoxTree layer) held easily accessible numerical values of its current translation, rotation and scale values (and order of transformations) in relation to the world coordinate system. I had a thought of reimporting hipoly and lowpoly files, enabling conform to retopo and transforming each instance and its corresponding retopo group at the same time, from world's origin to destination, but I fear that the retopo geometry that is inside the light bulb will start to snap to nearest hipoly geometry on each, hmm. The thing is, that I do not have time ATM to study the new docs. I suspect, though I might be mistaken, that it might be possible with the new scripting classes that were introduced in the recent BETA version. So it would result in each of the retopo groups being in the EXACT same positions (and orientation) as their VoxTree counterparts that appropriate retopo groups need to cover. ![]() I have a retopo mesh already done, so what I want to do now, is to apply the exact same transformations, that I applied to my object's VoxTree instances, to my low-poly clones. Then, I created several of its VoxTree instances and transformed them into specific positions (their empty parent object was what I transformed). A complex object that has several sub-objects. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |