What's One Thing Poser could include in the next version...



  • @F_Verbaas I look forward to this utopia :)



  • I've just been reminded of the need for arbitrary parameters which can display their value in the units selected by the UI preference, or some other, user-defined units, with an associated string to identify the units in the Parameters palette, without the need to make them dummy translation parameters. I've had to make use of a hidden variable containing a scale factor to be valueOp multiplied into such parameters, which I have been using for camera manipulation, that really need to display in the selected units and not just PNU.

    For example, if your units are metres, the UnitScaleFactor will be 2.62128. If they're PNU, the UnitScaleFactor is 1.0.

    The existing Focal length parameter of camera actors already displays 'mm' after the value, so you know that it has fixed units and will not be converted to PNU when saved to the library. Rotations all display the degree '°' symbol, so you know that they are degrees, not radians, for instance. We need the option to have other parameters display a units string after the value, and keep an internal value as PNU, if they represent a distance, to keep them usable in valueOperations, since there is no way to automatically include a preference sensitive unit conversion factor in ERC which calculates translations, without using Python scripts to read the preferences and save the UnitScaleFactor as a hidden parameter, as I currently do.



  • @anomalaus That would also help when people share snapshots of settings and don't say what their UI unit is, if the ytran said 0.254 inches or even " to keep it small like m and mm



  • OK, here's another in my wish list of missing Python API features. I need a way to change the animating state of an actor's internal properties, such as Visible (formerly OnOff), when they have not yet been set to animating, and thus exposed as an accessible parameter.

    The particular scenario I'm looking at is a script to grow hair on selected body parts of a figure, and then have the grown hair be able to have its visibility animated, by linking each hair growth prop's 'Visible' parameter via valueOperation to a master valueParameter on the figure. Since working with dynamic hair is a big load on the system's memory resources, being able to make the hair temporarily invisible to speed up workflow on underlying body parts for posing or texturing is important. (Yes, I know that I could just toggle the Show Populated flag, but that's a property stored in the adjunct hairGrowthGroup block, and is inherently unanimatable).

    The problem is, for a figure already in the scene, Python scripts cannot replicate the user's ability to double-click on an actor to access it's properties and then click on the key icon beside the Visible property to render it animatable and expose it's equivalent Visible parameter. Once that's done, Python scripts can create the valueOperations on the Visible parameter to slave it to the figure's master 'Show Hair' valueParm.

    I'm not, in this case, going to resort to having the script edit the CR2 file for the figure, and/or the hairProps, because they haven't been saved to the library yet. I could, of course, just have a script which toggles the visibility of all hairProps on the figure, but having visibility slaved to a master parameter, means the hair's visibility can be included in animations, which it currently cannot, unless the user manually enables it. I need a python method to AnimateVisibility(1) for the actor, even if AnimateVisibility(0) needs to remove the previously created Visibility parameter.

    The whole process is excessively tedious when having to deal with animating visibility of the hairProps for 30 phalanges, on top of the main torso and limb actors (or worse if the figure has individually articulated toes).

    [EDIT] I should add, that currently, hairProp actors do not give the option, in their Properties tab, to enable animating the visibility. I assumed, and was proven correct by manually adding a visibility parameter to hairProps I'd saved to the library, that the feature would be supported. So that's another missing feature that deserves implementation. User selectable, animatable visibility for hairProp actors.



  • @anomalaus:

    I've (manually) edited all the "prop figureHair" in my .hr2 files in my library to "prop //WhateverInternalName//".
    Poser handles "prop figureHair" objects in a special and sometimes annoying and unpredictable way.

    By declaring it as a normal prop you get rid of a lot of these headaches:

    • You can now load several "Hair Props" onto the same figure without the new hair deleting the previous one. This makes changing the hair style for a figure much easier.
    • It also facilitates swapping hair between characters.
    • And as you already mentioned, the limitations re. "visibility" state won't apply since now it's a simple prop, without the secret "Poser Voodoo" of handling a "prop figureHair".

    Cheers!
    K



  • @karina Ah, I was not actually referring to the library style hair props which use "prop figureHair" and will replace it with the next hair prop you load in the same way, but to the dynamic strand hair props created in the Hair Room, and grown from selected facet groups on existing props or body parts in the scene. Dynamic hair has a "hairProp" actor type, rather than just a "prop", and includes an adjunct hairGrowthGroup block containing all the dynamic hair properties such as length and density, which gets added after the figure block at the end of a cr2 file, if you save it to the library.

    I already use the scheme you mentioned to have multiple hair props simultaneously loaded on a figure, and control visibility with valueOperations from master parameters on the figure, so prop hair styles are animatable and selectable at will. I'm struggling to do the same with dynamic hair with quite the same ease. :-)



  • @karina said in What's One Thing Poser could include in the next version...:

    @anomalaus:

    I've (manually) edited all the "prop figureHair" in my .hr2 files in my library to "prop //WhateverInternalName//".
    Poser handles "prop figureHair" objects in a special and sometimes annoying and unpredictable way.

    By declaring it as a normal prop you get rid of a lot of these headaches:

    • You can now load several "Hair Props" onto the same figure without the new hair deleting the previous one. This makes changing the hair style for a figure much easier.
    • It also facilitates swapping hair between characters.
    • And as you already mentioned, the limitations re. "visibility" state won't apply since now it's a simple prop, without the secret "Poser Voodoo" of handling a "prop figureHair".

    Cheers!
    K

    Ah. So THAT is why some vendors put their hair in the Props folder. I'd been wondering what the benefits might be. Now I know. It's still a little awkward. I KNOW where to find these specific hairdos, but mostly I'm just browsing my Hair folder when I am looking for some ... well ... hair. And then those get overlooked (same with conforming hair, but I am not sure you could edit those to be a .hr2? )

    I like to keep things in their logical places. Conforming clothes .. well to me it DOES make sense to put those in Characters, but that's mostly because "it has always been that way" - but hair in the Props folder... has confused me until now :)



  • @trekkiegrrrl yeah, Sometimes I like to load a couple of hair models and rather turn one off in the hierarchical editor instead of deleting it.I spent time getting it to look right and if the new one doesn't tickle my fancy then I wan't to go back.



  • Hello @ trekkiegrrrl:

    You can move any hair to the "hair" library, be it conforming, "figureHair", or prop hair. All will load without problems.

    The only difference is that you can't determine in advance which hair is a figure and which one is a prop, but else all load without problems.

    Only when SAVING any hair to the "hair" library it will invariably get the .hr2 extension (which means if you want to save a hair FIGURE or a hair PROP, you must save them to either the "character" or "prop" library and then move the resulting files manually).

    So there's always a bit of "fiddling" involved. On the plus side you have all hair in one place.

    Mange hilsner,
    K



  • @karina Actually, on a Windows computer you can tell the file extension if you hover your mouse over the png file. That will give you a visual on the file name and extension.
    0_1525378958806_FilenameDisplay.jpg



  • Ah! I never noticed that!
    Thank you for the hint, very appreciated!
    K



  • ooh nice. Time for some spring cleaning. Tomorrow. Or the day after :P

    But great that it IS possible. Then again .. why not. You can have poses in the Camera and hands library after all L



  • @trekkiegrrrl The hands library is a pose library.



  • @karina said in What's One Thing Poser could include in the next version...:

    Ah! I never noticed that!
    Thank you for the hint, very appreciated!
    K

    You're welcome. All my hair is is one folder and materials for each hair in the folder with the figure/prop/hair file. I hate jumping all over my runtime for stuff. :-)



  • @trekkiegrrrl I re-arranged my library years ago. You could do that since Poser 8.

    I hate jumping from figures to props to poses to materials so my runtimes are all arranged with the supporting files with the character in one folder.



  • @eclark1849 said in What's One Thing Poser could include in the next version...:

    @trekkiegrrrl The hands library is a pose library.

    OK OK . MAT Poses then ;)

    Back in t'days before the library supported more than 256 folders, people got used to putting MAT poses all over the place. I still have some left in both hands and camera and even light XD
    Makes it interesting to find anything. BUT I cling to my old and frankly BLOATED Poser 4 Runtime. I just can't see myself reinstalling everything. And moving things .. sure. But with great caution.



  • @ trekkiegrrrl

    yes, there's a slight problem when moving content, especially if it doesn't adhere the "textures to the Texture Folder and geometries to the Geometries folder" rule,
    I've seen enough content where textures and/or .obj files were stored in the same folder as the proper figure/prop/injection.

    As long as you move the ENTIRE folder elsewhere, it shouldn't be a big problem. Problems start when you relocate single files from within that folder elsewhere because you have to be careful to keep the file links working.

    Poser likes to read (and write!) relative paths to files needed for any item in the library. As soon as the relative paths don't find the file(s) needed Poser will start an (often unsuccessful but VERY time consuming) search through all your registered runtimes.

    A "relative" path (the file(s) requested must be in the same folder as the loaded item):
    "Aleksandra Face.jpg"
    An "absolute path" (the file must be at the precise location, preferably even in the same registered runtime):
    "runtime:textures:Karina:Sandra:Aleksandra Face.jpg"

    However, things can get really awkward when there are "wrong" absolute paths in the files (like, the texture files are in the same folder as the figure/prop/character/whatever):

    The character is (wrongly) placed in the "Figures" library:
    "runtime:libraries:character:Aleksandra:Aleksandra.cr2"
    but the texture in that .cr2 file references to (absolute path):
    "runtime:libraries:character:Aleksandra:Aleksandra Face.jpg"

    Now at first glance everything looks fine and appears to work - UNTIL you move the folder from the "Figures" library to the "Pose" library!
    (Because "Aleksandra" is a character morph and should be in the "Pose" library instead of the "Figures" where only figures should be)

    And even though you've copied the complete folder over to the "Pose" library, the product suddenly stops working...
    Of course it does because there is still the reference back to the (now moved and thus no longer existing) folder:
    "runtime:libraries:character:Aleksandra"

    This is really difficult to fix without editing the files manually!
    What I do as a quick fix is to mark such content with a .cm2 file and a thumbnail with RED text reading "FUBAR" :D

    Like this I am warned when trying to load those, and while my next render is cooking I can examine the content closer and fix it! (yes I LIKE to tinker!)

    Whew!
    After looking at my text again I hope it's not TLDR;
    However I had a little time while my current render is cooking, so I thought I'd spend "a few minutes" for a reply :D

    Karina



  • @Glitterati3D
    Same here, at least for the items I build myself.
    I distribute referenced files to 'Geometry' or 'Textures' folders makes sense only if they are generic and I intend to systematically and frequently reference these files from other content. For an incidental reuse I simply make a local copy.



  • @fverbaas Same here, too. Geometries and Textures are left as the original creator designed them. All others are fair game and moved where I want them into a single folder in my runtime. It's just so much more convenient.

    Ken Gilliland has started distributing his Songbirds the same way, BTW. It's nice not to have to move them all around during installation.



  • If only people in general would always keep the geometries in the geometries folder and the textures in the textures folder, everything would be a lot easier.

    MOST people do, but then there's the occasional "rebel" who'll think rules don't apply to them ;)

    And it makes for FUBAR wen you move stuff.

    I recently consolidated to ancient PBooosted Runtime into one. At least I can find my stuff without having to manually swap folders.

    But OMG you collect a lot of stuff over the years. The oldest parts of my Runtime is from 2002 -_- and I'm a hoarder ...

    The good part is when you find something you bought perhaps 10 years ago and forgot about. It's kinda like Christmas XD