Yes, that’s what I meant. I used to setup my packages/bundles in sperate content roots when installing manually. Those installed through installers or download manager went all into the default content root.
There are several oddities (like automatic V4 uvmap and textures, no others available) when I import say, base female figure, that I will need to dig up my content (and acquire zips as exe replacement packages) for clean single root directory for hopefully fault-free behavior.
I believe DS does just that. There are so called scale_weights which are used for scaling but I don’t think these can be used in Blender.
Believe me, I’m not asking you to do it, bit I’m naturally curious about what prevents this. What prevents some (code behind) custom slider to apply those “scale weight” transforms on vertices associated with selected bones ? Obviously I don’t know and hence my question.
At the moment the only way to “connect” a vertex group to a deform bone is to give the vertex group the same name as the bone. Then all transformations (scale, rotate, translate) of the bone will deform parts of the mesh according to the weights in the vertex group. But there is no way to limit the deformation to only one specific transformation (like scale in this case).
DS has this system called TriAx where they have one weight group for rotation on the X axis, one for rotation on Y axis and another one for rotation on the Z axis. But for the same reason as above I can’t use this directly in Blender. That’s why I’m calculating an average weight per vertex out of the DS weight groups (these are called local_weights btw).
Interestingly with Genesis 3 DS is not using local_weights anymore but only one weight group (this time called node_weights) which obviously translates better into Blender. They seem to compensate having less weights with having more bones.
So my question is then: if blender (more precisely bpy) provided support for event listeners/handlers (which I think bpy doesn’t ? I came back to blender/3d 2-3 weeks ago, so I don’t know), in this case for bone transformations, would that solve the problem ? Although 3D is not an area I know much about (beyond the elementary vector properties), I think you would then be able to listen for bone tranformations and then apply the relevant vertex transformations based on the those “scale weights” ?
Also, I just realized as I was typing and editing; if such event listeners aren’t supported, wouldn’t drivers be able to solve it ? Having scripted drivers take bone tranformations as input and apply “scale weighted” transforms on the assigned vertices.
Again, not requesting you should do this (if technically possible), I’m just being curious about the technicalities. Just curious if there is a true limit in blender for custom algorithms, or if drivers provide everything for “event listener” needs to various kinds of projects.
It might be possible to do this with drivers. But I think the only thing that could transform the mesh would be a shape key which would mean one would have to somehow calculate a shape key out of the weight group. Actually an interesting idea…
I’m not sure why you suggest shapekeys (and that’s because of my lack of sufficient knowledge about bpy). Can’t python code just transform vertices directly ? I realize that blender internal agorithms, written in native static typed code, are far faster than python code, is that the only reason ?
What I however would like to see implemented, if you get the time to do it at some point (no hurry at all): I changed my mind regarding content directory trees. I really would appreciate if your addon (in the future) would support not only one, but limitless content directory trees. A plus (+) icon to create new fields to fill in the preferences addons tab would be nice. Yesterday as I was filling a single directory tree, I remembered why I created multiple ones (one for each package) 2 years ago. It’s a mess with a single one:
You see, all these asset files when created by their authors, locate their dependencies by pointing to the path of each of those dependencies. This means any, say, character morph of basic female, points to: basic female, (and then it’s own) materials, textures, etc (uvs too if it has own ones, I think they can). So because they are allowed to do that, any kind of directory structure may be imposed by every asset; any of it’s deps can be in any directory of the asset’s (author’s) choice, anywhere in the content directory tree. And so having a single content directory tree quickly becomes a mess. If any package with it’s own crazy idea of directory structure is instead installed in different content directoriy tree, then no matter how ugly and illogical directory structure it imposes, you will easily know that whatever exists there belongs to that package and will be safe to simply delete in one go (unless of course they are depended on by user’s own custom assets, but that’s ok). Like I wrote, no hurry (if you ever consider it).
No, you can’t do mesh deformations from a Python addon. I think speed is the main reason why there is no API for that.
About multiple content roots, I might do that later. But it could get pretty slow when you have tons of content roots as the addon would have to check a lot of directories to successfully resolve one file path.
About multiple content roots, I might do that later. But it could get pretty slow when you have tons of content roots as the addon would have to check a lot of directories to successfully resolve one file path.
That’s ok, perhaps someone could in the future make your internal content directory API implement some JSON/Dict based file/content index for far faster finding. No beneficial point in traversing the directory tree(s) for each and every file when such an index is blazingly fast in comparison. Doesn’t really need a filesystem listener for any change in those directory trees either, and instead when user installs/removes content he/she can press a “Rebuild content index” button in the addon preferences tab, which of course would traverse the tree(s), but that’s only one time per package install/removal. I’m sure you already know all this, but I wrote down FWIW anyway.
HELP!!
I keep getting this error? I’ve changed the directory in User Preferences to where my proper directory is. But I still get this error, what am I doing wrong??
PS this is such a great add on I just wish I could get it to work.
The addon can’t open the file /Users/…/Genesis3Male.dsf. Are you sure it is at the exact shown path and readable?
The addon also can’t handle directories with the same name in different case. For example if you have somewhere a directory “data” and a directory “Data” that might cause problems. Usually this should not happen on MacOS though.
No, I always considered it to be more of an importer than an exporter.
At the moment I’m not doing any further development. I realized that DS just has too many concepts that are extremly hard or impossible to translate into Blender.
Can you elaborate on what bits are impossible? I could definitely see full material support being problematic (Iray, etc), but I think what you already have is likely good enough. Folks can tweak the material for Cycles themselves. I just ran across this addon and have to say it’s pretty amazing. People elsewhere are jumping through a ton of hoops to try to get a decent rigged import (involving exporting Collada and FBX, etc), and this approach just seems so much better. Right now I’m having a problem where it doesn’t seem to find the armature at all most of the time, though it has worked on some files. I’ll try to see what’s going on there (2.78a), but maybe you have ideas? Anyway, I think the main thing missing from other DS import hacks is the lack of drivers to apply the corrective shape keys. Without that, poses look pretty terrible, but it seems like it should be possible through your addon.
There is actually a long list of problems that I couldn’t solve (and I can’t even remember them all anymore…).
But the main reasons were:
I couldn’t get the armature import to work. I think my solution is close to being correct but there must be still something missing or just plainly wrong with it. Because there is no documentation I would import one file, fix the code and then try the next file. Problem was that there was always one more file with which the import didn’t work.
The morphs are a tangled mess. There are morphs that work exactly like shape keys, these are simple to implement. But then there are morphs that change when a bone rotates, and there are morphs that change when another morph is being changed. So to make this really work one would have to calculate a dependency graph to find out which morph depends one which other morph or bone. But wait there is more. A morph definition is like a little programming language where you can add, subtract and multiply values with other values. And these values can be anything which is defined anywhere in a dson file. This is all very complicated to implement. There are also operations that are not documented (like some spline interpolations) which I couldn’t figure out how they work.
Can’t import all types of clothing. I don’t know how DS does it but there seems to be some magic function that fits clothes to a figure even when that figure was released after the piece of clothing was released. I’m pretty sure that it is not shape key based, I assume it is some kind of specialized shrink wrap.
