Feature request: more graceful BVH import
Because the original BVH specification doesn't include fingers, toes or movable head parts (eyes, jaw), a number of BVH files use their own conventions for naming those nodes which don't match most Poser compatible figures.
Currently the only thing Poser does when encountering them during import is throw up a dialog per unknown node (up to 28 dialogs or more just for finger joints), and then discard the data after each "OK" click:
What would be more helpful is a dialog box like this:
Clicking 'Choose…' would pop up a hierarchical menu of the figure's elements with [None] at the top or bottom.
[What isn't obvious from this mockup is that for the user's convenience, the default selected menu position for each node's button menu would be determined by the closest recognizable parent node of the unknown node: in other words, because "Right Thumb 2" is hierarchically inside "rHand" in the BVH, clicking the menu button would highlight the first element below rHand instead of making the user start from the menu's 0 index position every time. In the unlikely case the right hand also had a nonstandard node name in the BVH, the menu would walk up the BVH's node tree, then default-select the first figure element with a matching nodename.) If the UI toolkit Poser's made with can't handle preselecting child menu options, make the menu flat and use leading spaces / greyed out divider items to visually split up the hierarchy.]
The substitution table the checkbox refers to would have 3 columns; foreignNodeName, replacementNode, targetFigure. The next time Poser encounters a BVH with foreignNodeName in it it substitutes replacementNode – except in the side case of a different target figure being used where there's no element named replacementNode. Jaw, for example where Poser rigged figures don't standardize the element name and it matters to have figure-specific conversion rows. The above dialog would appear again and the chosen substitution would get its own row with the target figure's base name.
'[None]' as an option exists to cover the remainder, genuinely untranslateable BVH nodes that appear to be specific to proprietary rigs: examples I've been made aware of are 'hair', 'vt1'-'v12' (thoracic vertebrae, in some dance mocaps), and metatarsals (seen in files where fingers have 4 joints). It leaves 'null' as the replacementNode and silently ignores it the next time Poser encounters that node. Leaving a menu button at 'Choose…' leaves no entry in the table so the user will be alerted the next time they import the BVH.
@duanemoody That actually looks like something that could be done with a python script.
@eclark1849 Most things could be coded in PoserPython. Writing code that duplicates basic functionality already provided by Poser just to correct UX mistakes in the original function isn't a good use of developer time, unless there's a path for that code to eventually become part of Poser itself.
The existing function wastes peoples' time with multiple dialog boxes and at the very least shouldn't do that. If the devs are going to rewrite the code for how the UX interacts with the user during the import process, it makes as much sense for them to make the parser able to cope with hundreds if not thousands of BVH files that just won't conform to conventions MetaCreations invented 20 years ago.
@duanemoody One of the problems I've noticed about the developers though, and considering what was said regarding an earlier question I asked, the developers don't consider fixes like this a high priority, so it could be a while before they ever get around to it. So if a python script can fix this problem, they'll most likely leave it for a python scripter to write.
I think Duane's proposal is definitely worthwhile. It improves both functionality and workflow.
On the other hand the BVH file is incorrectly configured for use in Poser. Since BVH files are text I have in the past opened them up (using a text editor) and changed the names of the problem parts to standard Poser naming. That way when I go to use the BVH file again it will import with no complaints about missing parts. This of course assumes that there is a matching Poser body part to match up to. Not saying there is no merit to the problem, just that getting a computer to guess what the proper location/name should be is not an easy task since there is no standard on what body parts should called.
@richard60 I don't mean to imply my mockup would have Poser attempt to guess mapping; it depicts a user in the middle of doing the mapping. The element with '[None]' is a user choice where there's no possible equivalent value and the element with 'Choose…' is one where the user hasn't yet selected an equivalent or '[None'].
I agree that Poser shouldn't guess.
The main reason I'd prefer this be dynamically translated is because there still exist body parts where there's no consistently followed naming convention (e.g. jaw, lowerJaw) and a static search/replace on a BVH file leaves you with the same problem the next time you try to apply that BVH to a new figure where yet again the body part has a different name.
Make BVH import as transparent as possible.