Yes, the goal of ongoing research is to discover possible greatest common denominator (GCD) solution for any bipedal humanoid pedestrian, independent from the style.
The skeleton is ready, but there was an idea to replace realistic male basemesh with another one by its author, this is why the skeleton does not fit as tightly as it should (for example, ribs).
So its mesh is ready but its shape is under question.
I keep trying to analyse the sculpting version of a face.
Second, it required so dense mouth topology, that oral cavity from the original stylized female head fit just perfectly (15 to 15 vertices), so I just borrowed this part from it. It also allowed to eliminate an ngon in the nostril.
Third, it still directly connectible with LP body since topological changes didn’t influenced the neck loop somehow (it is still 6 to 6 vertices).
Here is the file (Bundle Skeleton+Blockouts+Head+LP_v09.blend)
I also kept a couple of heads from my topology research in case if they could be interesting.
On that, anybody mind if I rename the vertabras GEO-skeletion.vertebrae.L05 etc, like on
The current GEO-skeletion.vertebrae.000 is bouncing up’n’down the thing, and it’s messing with my head a bit.
Edited to add: There’s an issue: GEO-skeletion.vertebrae.020, GEO-skeletion.vertebrae.021, and GEO-skeletion.vertebrae.022 all have GEO-skeletion.vertebrae.022’s mesh data. Some others are sharing mesh data as well, haven’t gotten thru them all. When I try “Make Single User” I’m getting a “Not Yet Implemented” message – this happens in both 4.0 alpha and 3.6.3 rc.
This is causing problems with the UV mapping – for example, I can’t apply the Mirror modifier (even when I’m gonna delete-and-mirrormod afterwards, some UV tools work a lot better on a whole mesh).
You can try to copy them into new file, unwrap and paste back deleting the original.
Sounds weird though, make single user is pretty much essential operator.
At the time we made a special “filter instances” function which allow to detect what is instanced in the selection by filtering out all the unique objects from it, but yes, by default they has to be searched manually. We also made instancer - a function for analysing the selection and autoinstancing objects that has matching geometry.
But such kind of a functions was designed mostly for architecture (tens of thousands of objects), I think that something like skeleton is affordable to proceed manually.
I think renaming spinal cord will be useful.
But I would recommend to replace .dots with _underscores in names for compatibility with the other software which has sensitive object naming, like maya.
Renaming the objects sounds good! Making all objects single user in the end is fine by me. I kept the object data linked for now to reduce work for marking seams and doing the first pass on unwrapping.
Turns out that’s just when I right-click from the outliner – doing it from the top-menu works fine. I selected the whole thing, Object > Relations > Make Single User > Object & Data (if that last isn’t the option I should be using for this pls speak up!).
Much as I’d like these to be as versitile as feasable, I’m leary of feature-creep (no pun intended) – these are Blender assets. But for this I don’t see any reason not to, either:
The initials on the end are to discourage Blender from incrementing L05 into L06 etc, they’re mo for mesh object and md for mesh data (I know Blender’s supposed to be okay with them having the same name, but it’s sometimes been incrementing them, and differencing is keeping that from happening while I’m renaming the spine). If I see no objections I’ll keep on with this.
That’s a single-vertebrae breakout, current version of the UV unwrap that I intend to use for all the vertebrae (scaled down, of course). Are we using UDIMs on the skeleton? If so, how many? Go nuts? One for the body & one for the skull/teeth? Somewhere in between?
Looks good, much more readable. Underscore delimits words almost as nice as spaces, but space symbol is also prohibited and better be avoided.
Are there cases when Blender increments the initial number without adding numeric suffix?
It is a widespread maya system design error, as far as I remember Blender’s numeration always has been bulletproof in this area. If it is not, we has got an else one issue to worry about.
Skull has been taken from the bundle, it is ready made. I pasted its initial form to shape the spinal cord more properly.
Meanwhile I’ve joined the head to the LP body and tried to shape the resulting mesh.
The result is… achievable
No idea, I just know that when renaming both the mesh object and the mesh data the same ending-in-a-number name, sometimes one of them gets incremented (like one of the GEO-skeletion_vertebrae_C12 becomes GEO-skeletion_vertebrae_C13). Intermittent, when it happens doesn’t seem to matter which I renamed first, can’t be typos (I’m pasting from a text file in Notepad++ ), but using suffixes to both prevent ending in a number and prevent identical mesh object / mesh data renames keeps it from happening.
If it gets found/fixed before 4.0 goes main then I’ll try to clean out the suffixes before this version of the assets are released.
Ah, I didn’t realize! So I’m not UV mapping the skull yet. No problem, there’s plenty to do on the rest of the skeleton! Still need to know (eventually, I can get pretty much all of the mapping done before getting into organization) 'bout UDIM usage on this, whoever’s call that is.
I think you can take final Realistic Skull asset from the bundle to check how exactly it was unwrapped.
I guess the skeleton UV is supposed to be similar.
Use as many UDIMs as you like. Go nuts
I think the seams can be placed pretty freely. On the skull I placed them primarily at the creases between major separations (same as the face sets). But the rest of the skeleton doesn’t have them defined that much, which is fine.
The skull already has UV maps. If not then those can be transferred from the original asset.
The only difference between the skull and skeleton asset is that the skeleton has a slightly downscaled skull.
I am going over all the head asset scales atm and adjusting them to fit each other more realistically.
Okay, at the next step I decided to reconcile both parts of a Sculpting Base.
I has got a couple of ideas how to reach that - to borrow Realistic sculpting head topology and refine LP body.
At this time I made an important decision to not to reinvent a wheel and it actually worked out well.
The result was a better hand topology, which very usefully required an extra loop between the thumb and palm.
Then I spread the resulted topology across the other shapes and it fit nicely.
I especially enjoyed transferring palms and foots, it is so easy to transfer box-shaped fingers.
I uploaded a male counterpart to the female to the repo in case it’s useful. Topo and UVs should be consistent (need to double check vert order as well to be safe) As always, feel free to tweak and modify as needed.
As the next step, I decided to give a test to the resulted Sculpting base.
Planar head model was pretty good example, but testing better be quite stressful so this time I decided to draft an Écorché.
Mutires level 6 gives 10mln vertices while remain fast enough, but I decided to use Multires level 4 which gives ~600 k vertices.
I made a sketch of a realistic male shape following different anatomic guidelines, then I assigned shapekeys, and here is how it looks like.
In my opinion the topology works pretty nice, but I am not sure if I am confident enough in this area.
So here is a separate file with the resulting sculpt and shapekeys (Sculpt_base_Ecorche_v01.blend)
In the background I explore the compatibility of a sculpting base with different stylization and do some polishing.
For instance, TF2 style (engineer model).
It really shows how versatile these topologies are as base meshes!
But I’d say it’s not that helpful to include the shapekeys on the ecorche sculpts. It’s skews the sculpted displacement so much that it’s no longer accurate enough to be reflective enough of the base shapes.
