thanks for the insight.
but i wonder why no one ever thought to use a system like that before. there are situations where that sort of thing really comes in handy. i don’t think even maya and co have that sort of thing
+1
Saving the file but the work not being saved is terrible user design. The justification it should be done because it makes Blender’s internal treatment of datablocks consistent is similarly bad.
Probably because there are simpler ways of handling those problems using driven bones and simple weighting. The vast majority of bones in a vast majority of rigs don’t need different weights per axis. For those areas that do, you can always create a driven bone that only takes the master bone’s rotation along one axis and weight onto that.
Utility bones have been used like this for over ten years (e.g. in example-based skinning) and don’t need additional processing for every bone (at least, not at animation/pose time like Poser/DAZ does). It’s mostly a matter of efficiency. DAZ & Poser must, due to limitations imposed on their skeleton, process three axes different for each and every bone. Whereas, for applications without those skeletal restrictions, they need only process a single transform for each bone in the rig.
For linked assets, I would like to see one to be able to turn modifiers on or off for animation in the viewport, things like particle hair on or off in the linked scene file. This would make it easier to animate in the scene file file without having to return to the source file numerous times. Don’t know if it is possible, but I would like to see a way to proxy more than one thing in a linked assets. It would be nice to bring in a simulation like particles and then manipulate it in a scene file to fit the timing of the animation in that file.
Yes please.
The close blender confirmation dialogue could also say:
Code:
" You have the following Animation Actions that have no Fake user assigned to them.
<clip1 name>
<clip2 name>
<etc etc>
Closing blender will purge them. Are you sure you want to do this?
>Keep Actions (Assign fake user) and close
>Purge Actions and close
>Cancel
That is the least that any other software would do
that is a good idea.
I just thought that with most 3d packages not being self-sufficient, driven bones would run into trouble during exports due to the fact that interchange formats do not support drivers… unless of course, they bake the animations
curiously though, daz studio (even in texture display mode with huge textures and transparency and corrective morphs) plays back animations much faster than blender in solid display mode. This suggests there are other areas where blender could squeeze out performance and still use triax rigs
Exporting baked animations to renderers and the like is pretty standard practice. In fact, being unable to do so would be the kiss of death for most software.
The thing is, you don’t NEED Blender to provide triax functionality as it already supports driven bones. Not to say that Blender’s playback shouldn’t get improvement (it is already getting that through the viewport & DAG changes), but enabling triax weighting for all bones will triple the cost of calculating a vertices transform when running through an animation - three different vertex weights, three different transformations, etc.
I’m sure, if there is a major need for an all triax rig, a script could be made to create three driven bones for every bone in the rig. Thing is I doubt anyone really needs that. A few driven bones on the trouble spots like shoulders and the like would work just fine whilst keeping the performance benefits of “one bone, one transform”.
During Tears of Steal, they had an add-on called PowerLib that gave you that basic functionality. You can find it on the Tears of Steel blog. At one point, we even considered consolidating effort between that add-on and the Edit Linked Library add-on, but for some reason (probably my fault) there was no follow-through on that.
Thank you
I added it to the bug report here:
I am still against the whole fake user design. Users should not have to tell software to keep their data. Instead they should only tell software when to delete it. Saving a scene should save everything and purge nothing. You purge only when specifically told so by the user.
It is stated best in this document:
Data Handling
The “fake user”, and not used data vanishing when closing Blender, is not very intuitive. More intuitive would be if the data, along with unlink (the X at the moment), would have a delete data option (with a “Are you sure?” confirmation).
The necessity to set a fake user for a material, or other data, for it not to vanish, and data vanishing without a confirmation, is against all UI design principles - where an action is required to not do an operation.
That would allow, for instance, remove a material that is no longer needed, from all objects that are using it in some material slot. At the moment, you have to manually remove the material from each slot.
Shift-click on X won’t remove the materials in the current session.
It is also bad design to use th e closing and opening of the program as an interface element. Currently, when you delete for instance, a high-poly object, and save the file, the file’s size won’t change. You have to save the file, close and reopen the program, and save the file again, to get the reduced file size.
+1 I have to agree.
FYI, I just committed a new “Auto View” feature for the Graph Editor which automatically sets the view based on the current selection. Think this is what you requested earlier blurymind? More info plus a .gif here.
Can’t agree more. It is a terribly backward design and, honestly, the reasoning provided for keeping it this way simply sounds like “programmer preference is more important than good user interface design” the more I hear it.
I honestly cannot think of any other program that acts this way… and it’s not the good kind of “unique” that Blender wants to be known for.
The gif isnt working for me. Do you know where i can test it? is it in a daily build?
EXCITE!
Thanks for this!
It will be in trunk? Or gooseberry (or both, lol)?
In both. (The name in the UI may change though, maybe to something like “View Lock Selected” instead of “Auto View”)
Considering that this way of handling data has been in Blender since the NaN days, it may or may not be difficult to convince Ton that Blender needs a major change in how it handles datablocks.
I’m not sure how deep the ‘fake user’ system goes, but I don’t think changing it out will be trivial.
It’s highly likely NOT trivial since it’s such a core part of blender, and it’s not that hard to understand and get used to. HOWEVER, I do agree that clips should have a fake user enabled by default. Simple as that. It’s easy to forget to enable the fake user and lose countless hours of work.
It be really neat if they added a way to solve arm twist.