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



  • For me what I would like to have in next version:

    1. Physical camera with tonemapping option, ISO control etc

    2. Update or upgrade SuperFly to latest Cycles which supports AMD GPU as well, many of Apple users do have AMD GPU and this would make big difference to these users and can make bigger impact on sales as well in my opinion

    3. Ask AMD if they can include their ProRender in Poser as next renderer or speak with Corona developers if they can include their renderer which is CPU only but still is faster than SuperFly in CPU mode

    Hope this helps

    Thanks, Jura



  • @jura11 If you want to use the Corona renderer, you don't have to wait on SM. the renderer is available as a standalone application at https://corona-renderer.com/download



  • Let me chime in and mention my one thing:

    • 'Save figure with current setting as new zero'.

    produces geometry as-is of course, all joints become zero as they are rotated, all keyed dependencies are moved accordingly.



  • @F_Verbaas good luck with JCM's, especially in the clothing if that were implemented.



  • @amethystpendant That would be a complete cluster**** on anything rigged. It might work fine with dynamics, but not with rigged items.


  • Poser Ambassadors

    LOL.
    I have a sticker on my Delete button that says: "JCM".
    End LOL.

    I wrote in the past, I write now, and will write in the future; "You don't need JCM to correct rigging."
    Rig properly in the first place and start by deleting all bones that are NOT in a human.

    OK, OK, we needed these helper bones in the "old style conventional rigging system".
    => We DO NOT need rigging helper bones in a weight- bulge- map rigged figure.
    Set the Joint centers properly and paint the weight- and bulge maps properly.

    Again, a weight- bulge- map rigged figure does NOT need JCM's to correct the rig if done properly in the first place.



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

    @jura11 If you want to use the Corona renderer, you don't have to wait on SM. the renderer is available as a standalone application at https://corona-renderer.com/download

    I use Corona renderer in 3DS Max or in C4D and I don't think there is standalone version,they're plugins for C4D,Blender is in works,3DS Max etc and would love something like is Corona Alpha which is free plugin which doesn't offer some features like full version,its great plugin and and is very fast renderer without the question

    Hope this helps

    Thanks,Jura



  • Forgot to add,please add denoiser which is available in newest build of the Blender and Cycles

    Thanks,Jura



  • @jura11 The download page says there's a Corona standalone included in the download. I think it may just be a demo though.



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

    Forgot to add,please add denoiser which is available in newest build of the Blender and Cycles

    Thanks,Jura

    I'll second that suggestion.



  • @vilters I'm sorry, I have to take issue with the implied assertion that rigging in Poser's currently available releases can eliminate the need for JCM. Rigging effects apply continuously over the range of joint motion. There is no current rigging mechanism which can delay the onset of the application of bulges or weight maps. They are always on. JCM, on the other hand, can take advantage of valueOperations which can have their effects limited to specific ranges of the input joint rotation. The only other option to apply the same effect without JCM is to have dummy bones (as many, popular weight mapped figures use), drive additional weight maps or bulges over limited ranges of the original input rotation. So, anything like a tendon, that only becomes visible in the latter stages of a joint bend, requires valueOperations, which are the core functionality of JCMs. When we can use valueOperations to drive weight maps or bulges, then your original assertion will be true. Until then, Nope.



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

    @F_Verbaas good luck with JCM's, especially in the clothing if that were implemented.

    Sure the saved figure would be a new figure and corformers will no longer match their original conformees and vice-versa, (unless both get the same treatment of course). Fun of the idea is the user can choose the new shape as he sees fit, including his favorite donor or, if the 'new zero' is a conformer, to suit his intended target figure.
    As far as morphs are concerned: yes, the deltas need to be rotated and scaled, and key values for JCM's need to be shifted. These are things computer programs happen to be very good at.
    Result (with some matching of joint centers): refittted clothing with original morphs and (with copy morphs) morphs for new target. I expect this will in many cases have a better result than the fitting room, where the weightmaps are copied from the target figure.



  • @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.