Daz Studio Pro BETA - version 4.22.0.15! (*UPDATED*)

13468930

Comments

  • barbultbarbult Posts: 24,244

    Saxa -- SD said:

    barbult said:

    However I reloaded my "bad" scene, and the same problem occurred. Maybe there is something strange about that scene or the keyframes in it. If you have time, will you check this scene? I have attached it. Thanks.

     Finally back here at DAZ forums with a little time.

    Tried your scene. Loaded like in 3 seconds or less.  And Lol, finally installed G9 essentials thanks to your scene.  And your duf worked perfectly and so fast.  Clicked Play and animation looped just fine. 

    Here is your duf resaved on my PC.  A chance that cleared out something wierd maybe? Seems upload is not working for now. So no resave RN.

    Thank you for trying it. There must be something conflicting on my computer then, if you can't reproduce it. Maybe when I get a chance I'll disable all plugins and see if that makes a difference.

  • Saxa -- SD said:

     re: Greying of skin

    Would guess with all the Nvidia changes for Iray, that light interp is changing.  Just a guess.

    So quick workaround is go to ToneMap and change white-point from pure white to something like R220 G222 B255 (lighter blue-purple).  Each user may need different tone-map setting depending on what they settled on for skin settings.

    DAZ skin has many so layers and settings.  So not too surprising if this changed.  Nvidias priority is Iray.  Daz can only do so much.  They aren't Nvidia in size and resources.  Not even close.

    Is this greying of skin happening with spectral rendering on or off? What about guided sampling on or off? What rendering quality level?

    Changing the tonemapping white point will affect all white objects and light sources in the scene, not just skin so it doesn't sound like a very good workaround to me.

    Finally, regarding "Did you mean restore instead of zero?" Clippy wants to have a Word with Daz developers ("It seems like you want to zero the figure pose, would you like some help with that?").

  • ImagoImago Posts: 5,158

    @ Saxa:

    Why all I get are workarounds when we need is fix the bugs? I'm not making crazy requests, I'm just asking for bug fixes! Just make things work correctly, nothing more! sad

    Why I have to keep using an old version with less features to make things or waste lots of time using workarounds in newer versions?

  • takezo_3001takezo_3001 Posts: 1,979

    Imago said:

    @ Saxa:

    Why all I get are workarounds when we need is fix the bugs? I'm not making crazy requests, I'm just asking for bug fixes! Just make things work correctly, nothing more! sad

    Why I have to keep using an old version with less features to make things or waste lots of time using workarounds in newer versions?

    I agree, as workarounds with this community usually mean that the original bugs won't be addressed, as we commonly treat workarounds as a solution when it is not.

    The problem with this is when a bug affects one component, it may also affect other systems/processes not yet noticed with the original bug, but are still related as they may affect something similar that hasn't been noticed yet, so it is best to cut it out before it is compounded by other bugs not taken care of from earlier workarounds!

  • johndoe_36eb90b0 said:

    Saxa -- SD said:

     re: Greying of skin

    Would guess with all the Nvidia changes for Iray, that light interp is changing.  Just a guess.

    So quick workaround is go to ToneMap and change white-point from pure white to something like R220 G222 B255 (lighter blue-purple).  Each user may need different tone-map setting depending on what they settled on for skin settings.

    DAZ skin has many so layers and settings.  So not too surprising if this changed.  Nvidias priority is Iray.  Daz can only do so much.  They aren't Nvidia in size and resources.  Not even close.

    Is this greying of skin happening with spectral rendering on or off? What about guided sampling on or off? What rendering quality level?

    Changing the tonemapping white point will affect all white objects and light sources in the scene, not just skin so it doesn't sound like a very good workaround to me.

    Finally, regarding "Did you mean restore instead of zero?" Clippy wants to have a Word with Daz developers ("It seems like you want to zero the figure pose, would you like some help with that?").

    Agree.  There are tons of variables that contribute to overall rendering.

    For sure, the white point changes everything else.  But it is super quick and easy.

    But that can be issue with any scenes changing lighting.  Renders alot of scenes and soon  one setup may work well with this light setup but not so good in another. 

    So overtime found few light setups (incl HDRIs) that work as crit test for some texture settings.

    Restore vs Zero syntax.  Have had a few issues with DAZ syntax.  Decided like local dialects - to just adapt.  Don't have time or energy to fight that.

  • Imago said:

    @ Saxa:

    Why all I get are workarounds when we need is fix the bugs? I'm not making crazy requests, I'm just asking for bug fixes! Just make things work correctly, nothing more! sad

    Why I have to keep using an old version with less features to make things or waste lots of time using workarounds in newer versions?

    Sorry if i seem like am not taking you serious. I totally am.  Respect alot some of the anims you lovingly crafted and posted here.  Share your love of details.

    So getting back to issue.  Some i see as work-arounds.  Like process to move keyframes. Agree with you.  Speed is somethging DAZ could improve.  But do recognize the current process of moving keyframes does work and helps avoid sudden accidental moves.

    Others i don't see as workaround.  Like make a duf, and right click and make custom action.  DS is based on node based.  To me that process fits.  And it works. And quick.  So don't see that as a workaround given how quick it is after you do a few times.

    Having been a part of the world of 3D software options for  good while, have just come to accept that if I want to get things done fast - and not fight all the time - that I have to figure out how DEVs make their program work, which features are more popular and adjust my workflow to just get it done.

    If 4.12.*.86 has features that work better, then please post here!   Seriously want to see them.  Which is why i seriously and honestly asked "what do you mean?"  Was meant as wanting more elaboration.  And will add my DAZ feedback to request if I prefer too.

  • Saxa -- SDSaxa -- SD Posts: 872
    edited January 2023

    takezo_3001 said:

    Imago said:

    @ Saxa:

    Why all I get are workarounds when we need is fix the bugs? I'm not making crazy requests, I'm just asking for bug fixes! Just make things work correctly, nothing more! sad

    Why I have to keep using an old version with less features to make things or waste lots of time using workarounds in newer versions?

    I agree, as workarounds with this community usually mean that the original bugs won't be addressed, as we commonly treat workarounds as a solution when it is not.

    The problem with this is when a bug affects one component, it may also affect other systems/processes not yet noticed with the original bug, but are still related as they may affect something similar that hasn't been noticed yet, so it is best to cut it out before it is compounded by other bugs not taken care of from earlier workarounds!

    Bugs are bad.  But are all of these issues actual bugs? Or just some?

    Bear with me please as i try to explain.

    When it is posted that:
    (1) pupeeteer dots don't work in timeline.  That's not a bug. It's a feature that is not available AFAIK.  DAZ internal decision. Arguably monetary? Maybe not.  My 2 cents would guess it partly is.
    (2) Can't save custom actions. Yes you can.  Works pretty fast when you get process familarized.  Just not the way that some users might want. Get that. But, so doesn't seem like a bug.
    (3) Moving keyframes. Should be a second option for easier and faster. But works fine with option one. So it's not a bug. Again a feature that is not made to work like many users might want ot expect. But not a bug.
    (4) Grey renders for skin now in lastest beta. Odds of DAZ devs being able to correct Nvidia's Iray new features to make skin render the same with all those variables and light changes too is pretty much not to good.  Would be nice surprise if wrong.  This isn't a bug for me. Its just another unfortunate feature as IRAY develops and in turn affects another software version release.
    That said, Identifying this issue is cool and important.  Maybe DAZ can address?  Am not counting on it though. So just adapted again.

    next new Daz Studio version = new changes, some of which will impact your workflow in a new way
    Such as render tints changing possibly based on new IRAY kit.

    What some may see as a workaround may actually be how it's intended, for now, and maybe for a long time.
    DAZ Mods have stated many times if you don't like something open an honest thread and discuss and see what extent of issue is and see if other users feel the same.
    That is suggest an option 2 for doing something better by sending DAZ feature requests when well and carefully reasoned.  To me that means show DAZ that your idea and workflow adds enough to costs to warrant change. It has to be a rationale process with best chances to succeed. 

    Saying something is a workaround doesn't mean necessarily enough users and devs will agree with this.  And for the record, sympathize with any animators who want to work a certain way. It's why i have little to do with Blender after having used it alot for a year and not findin it synced with me.

    Some may say these seem like workarounds.  (sorry forum TOS makes me have to write this as idea focussed)
    I see them more as this is how software works.  
    With each next verison possibly changing how things work.
    Each user decides if good or bad.
    Seems choice then is adjust or fight. I'd rather adjust.  
    But that's a whole another thread to discuss.  Don't want to derail this thread anymore.

    Post edited by Saxa -- SD on
  • Saxa -- SDSaxa -- SD Posts: 872
    edited January 2023

    barbult said:

    Thank you for trying it. There must be something conflicting on my computer then, if you can't reproduce it. Maybe when I get a chance I'll disable all plugins and see if that makes a difference.

    Wish i had seen that issue before and could share a fix.  But that really is a new one for me.  Any chance you had some kind of screen overlay going?  That's the closest can think of.

    Post edited by Saxa -- SD on
  • barbultbarbult Posts: 24,244
    edited January 2023

    Saxa -- SD said:

    barbult said:

    Thank you for trying it. There must be something conflicting on my computer then, if you can't reproduce it. Maybe when I get a chance I'll disable all plugins and see if that makes a difference.

    Wish i had seen that issue before and could share a fix.  But that really is a new one for me.  Any chance you had some kind of screen overlay going?  That's the closest can think of.

    I have more info the mysterious timeline animation stopping. I discovered that if I enable Play All Frames in the Timeline pane menu, it plays fine in DS 4.21.1.26. That was not required in DS 4.21.1.05. Do you have Play All Frames enabled?

    Post edited by barbult on
  • barbult said:

    I have more info the mysterious timeline animation stopping. I discovered that if I enable Play All Frames in the Timeline pane menu, it plays fine in DS 4.21.1.26. That was not required in DS 4.21.1.05. Do you have Play All Frames enabled?

    Well that's an easy fix smiley

    Yes. Play All Frames is enabled.
    Disabled it and tested your scene again. And now have same issue as your video.

    Never Merged Menus on this update.  Not sure if related.
    So my timeline stayed as always at Play All Frames.

    Suppose this is a way to make anims without manual toggling play on/off.  Think I'll incorporate that. Nice!  Thanks!

  • barbultbarbult Posts: 24,244

    barbult said:

    I have more info the mysterious timeline animation stopping. I discovered that if I enable Play All Frames in the Timeline pane menu, it plays fine in DS 4.21.1.26. That was not required in DS 4.21.1.05. Do you have Play All Frames enabled?

    Well that's an easy fix smiley

    Yes. Play All Frames is enabled.
    Disabled it and tested your scene again. And now have same issue as your video.

    Never Merged Menus on this update.  Not sure if related.
    So my timeline stayed as always at Play All Frames.

    Suppose this is a way to make anims without manual toggling play on/off.  Think I'll incorporate that. Nice!  Thanks!

    Thanks for confirming the issue. I submitted a help request when I first posted about the problem. I haven't received any response from CS.
  • outrider42outrider42 Posts: 3,679

    Tone mapping changes the entire scene, and considering that skin is the only thing effected, changing tone mapping is going to make the whole image off. That is not acceptable, no matter how easy it is. This is an SSS change, so it requires playing with SSS settings to try to get as close as possible.

    It doesn't matter what Nvidia's priorities are. Daz-Tafi chose to use Iray. They could have chosen any other render engine, or attempted to make their own and not be bound by Nvidia's whims. So this absolutely is in Daz-Tafi's control, because they were the ones who chose to contract with Nvidia in the first place. Nvidia has been tweaking Iray from the very beginning. Changing how SSS works is nothing new, they changed SSS in 4.9 and that directly caused some characters designed for 4.8 to look like gray corpses. (Poor Genesis 3 Tenshi is a victim of this.) It was significantly worse than what was posted here, I am talking zombie skin color. They later changed how translucency works, which threw more old skin setups out the window. Then Chromatic SSS had bugs, Daz even released core characters with skin settings for different versions of Daz because of this bug.

    It seems like every few years they do something that causes Daz customers problems. And any time they "fix" something, they seem to break something else.

    Just ponder this for a moment, have you ever seen humans rendered with Iray outside of Daz models? The vast majority of commercial Iray use comes from environmental designs or the automotive industries. Human skin is already hard enough to do, it is even harder when your render engine of choice seems to not be focused on skin at all. When you search for Iray and filter out the Daz results, you will not find any humans in the renders. I dare anybody to try this.

    Also, this doesn't excuse Daz-Tafi from denying users to roll back their software when they wish to. Even if Daz is somehow under contract to only use the latest version of Iray (which I personally believe is not the situation,) Daz-Tafi is the one who agreed to sign that contract under such terms in the first place. So once again...it is their fault. And if by chance Daz is not bound by contract, then they have no excuse at all. I can already predict the next response will be that "Daz cannot offer support for older versions"...so? Downloads can be marked as depreciated. Currently, if customers running older versions have issues they may be told that those are not supported, so there is no policy change here, LOL. I am not sure how that can even be a question at all. Nvidia provides old drivers going back many years, that doesn't mean they offer support for old drivers. The downloads are provided without any warranty. But they still offer consumer choice, and that is important. Can you imagine how bad things would be if Nvidia stopped providing downloads for previous drivers?

    And Daz can still choose by ending their relationship with Iray. It would break a lot of things, but a lot of things have already been broken by changes Iray made anyway. So I am not sure it would be such a bad thing. Plus PAs would be ready to sell customers new shader conversion products. 

    So Daz can do a lot of things and they certainly are not blameless.

    Look, what artists want is consistency from their render engine. Speed is obviously important, but consistency is probably even more important.

  • Saxa -- SDSaxa -- SD Posts: 872
    edited January 2023

    @Barbult. Glad you got it figured out! And added another tool for me!

    outrider42 said:

    Tone mapping changes the entire scene, and considering that skin is the only thing effected, changing tone mapping is going to make the whole image off. That is not acceptable, no matter how easy it is. This is an SSS change, so it requires playing with SSS settings to try to get as close as possible.

    If anyone posts an easy solution or DAZ addresses, I'm all ears. smiley

    Slight changes in tone mapping are not deal-breakers for me.    Am not going to start micro-playing with all the SSS.  If SSS works better for other users, that's great to have options!

    Issue remains for many scene renders. Change scene lights aka global sun positions,+spotlights+ hdri+ghost-lights = render-appearances change for everything.  So not a biggie for me.  Don't see a way around that.

    As for opinion discussion on DAZ choices.  Said my thoughts before.  Still unchanged for me.  Lotsa voices are good.  Happy rendering!

     

    Post edited by Saxa -- SD on
  • marblemarble Posts: 7,500

    Every time I view these Beta Release threads there seems to be a reason to avoid updating. This issue with the skin tones sound like a no-go again for me because I use and re-use characters with skins set up the way I like them. If my settings are going to be messed up by installing a new Beta, I just can't risk it. Yet there may be fixes to earlier versions that I am missing out on which is why I keep reading this thread. I am presently using the 4.21.0.5 Beta which, I believe, is the same version number as the current General Release. I have no idea whether there is a difference between the beta and the GR but, if not, it might be an option to update my General Release to 4.21.0.5 and then try the new Beta. Such a pity that DAZ do not allow us to revert to a previous version - I can't think of another software I have installed on my PC which has that restriction.

    Any thoughts?

  • frank0314frank0314 Posts: 14,059

    You can install and use the Beta without it interfering with the version of DS you have now. The Beta doesn't overwrite/uninstall the release versions. You can run them both on your system. If you don't like it you can then uninstall it.

  • @Saxa -- SD Sorry, but every character skin rendering grayish instead of the intended color is breaking a ton of products which people purchased so in my book it is definitely a bug that has to be fixed.

    @outrider42 Good point about no human characters in any other Iray demos. I will talk to NVIDIA about that.

     

  • johndoe_36eb90b0 said:

    @Saxa -- SD Sorry, but every character skin rendering grayish instead of the intended color is breaking a ton of products which people purchased so in my book it is definitely a bug that has to be fixed.

    A bug is soemthing not working as intended. It may be that the skin chnage is not that but a deliberate change, possibly correcting a previous bug. That isn't to imply "Oh well, that's all right then" - you can certainly deplore the chnage, adn that there is no toggle to switch the behaviour around for those with materials set up under the old behaviour, but it would not then be a bug as such.

    @outrider42 Good point about no human characters in any other Iray demos. I will talk to NVIDIA about that.

     

  • marblemarble Posts: 7,500

    frank0314 said:

    You can install and use the Beta without it interfering with the version of DS you have now. The Beta doesn't overwrite/uninstall the release versions. You can run them both on your system. If you don't like it you can then uninstall it.

    But does a later Beta overwrite and earlier Beta? Or can there be two beta versions? With Blender, I can have as many versions as I like. In fact I occasionally have to delete some of the older versions to rescue some disk space.

  • marble said:

    frank0314 said:

    You can install and use the Beta without it interfering with the version of DS you have now. The Beta doesn't overwrite/uninstall the release versions. You can run them both on your system. If you don't like it you can then uninstall it.

    But does a later Beta overwrite and earlier Beta? Or can there be two beta versions? With Blender, I can have as many versions as I like. In fact I occasionally have to delete some of the older versions to rescue some disk space.

    Only one from each release channel.

  • Richard Haseltine said:

    johndoe_36eb90b0 said:

    @Saxa -- SD Sorry, but every character skin rendering grayish instead of the intended color is breaking a ton of products which people purchased so in my book it is definitely a bug that has to be fixed.

    A bug is soemthing not working as intended. It may be that the skin chnage is not that but a deliberate change, possibly correcting a previous bug. That isn't to imply "Oh well, that's all right then" - you can certainly deplore the chnage, adn that there is no toggle to switch the behaviour around for those with materials set up under the old behaviour, but it would not then be a bug as such.

    And in this particular case, Iray Uber shader everyone used for character skins does not seem to be working as intended anymore.

    In this case, the "intent" is to "render character skin correctly", and "correctly" is "without requiring changes to existing character materials, scenes, and lighting setups" because even if what was rendered before the change was physically incorrect it has already been compensated for by material settings provided by the vendors who created the characters to produce realistic skin color.

    If Microsoft pushed latest NVIDIA driver through Windows Update to all Windows users without the ability to rollback, and if said driver required that all games ever released for Windows be updated to DirectX 12 in order to work, then from NVIDIA's point of view that might be "working as intended", but from the Windows users' point of view Microsoft would still be on the hook for damages and for solving the problem because Windows users are Microsoft's customers, not NVIDIA's.

    What I am saying is, people here are not NVIDIA's customers, they are Daz's customers. If products bought in Daz store break after an update, then it should be on Daz to handle that regardless of the intent behind (or source of) the changes in said update.

  • Saxa -- SDSaxa -- SD Posts: 872
    edited January 2023

    upgraded to 4.21.1.29 because i use guided sampling, and that got fixed in this beta along with new IrayVersion out (http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log#private_build_channel).  DS beta working fine so far.

    In case anyone is wondering about quick toggle to render engine - iray vs viewport.  I know i was.  Only thing could find was scripts for 3dl.  Found this just by trying things.  Save Render Presets storing engine Iray vs  viewport(Filament) do work.  Do have a certain image dimension with that.  Then save as custom action and can add to toolbar for quicker switching.  Rendering filament frame is instant. Like less than one second.  Handy for icons for example.  Did get Dreamlights Filament render guide along with changed lighting in the past.  Default filament lighting was too bright for me.

    Edit: Speaking of rendering icons.  Found this handy script.  http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/rendering/render_to_asset_icon/start
    shortcuted and added script to toolbar and changed to my prefered image size the 91,91 to 800,800
    oRenderOptions.imageSize = new Size( 91, 91 );
    now if only could figure out the syntax to add to this script to delete the orig *.duf.png.  Manual delete after browisng to menu adds more time again.  Can anyone suggest?

    Post edited by Saxa -- SD on
  • You should not render icons to 800x800 -- for asset.duf you should render asset.png at the icon size (91x91), and asset.tip.png at the size you want (say 800x800). That way icon doesn't have to be resized to be displayed in the user interface, and when you mouse over the icon you get shown larger image as a tooltip.

  • marblemarble Posts: 7,500
    edited January 2023

    johndoe_36eb90b0 said:

    You should not render icons to 800x800 -- for asset.duf you should render asset.png at the icon size (91x91), and asset.tip.png at the size you want (say 800x800). That way icon doesn't have to be resized to be displayed in the user interface, and when you mouse over the icon you get shown larger image as a tooltip.

     

    I don't understand the point of the 91x91 image. Why not just render out the larger image instead of creating an extra .tip.png? I always save my icons at larger resolutions precisely because I want something my old eyes can see when I hover over them with the mouse.

    Post edited by marble on
  • Saxa -- SDSaxa -- SD Posts: 872
    edited January 2023

    johndoe_36eb90b0 said:

    You should not render icons to 800x800 -- for asset.duf you should render asset.png at the icon size (91x91), and asset.tip.png at the size you want (say 800x800). That way icon doesn't have to be resized to be displayed in the user interface, and when you mouse over the icon you get shown larger image as a tooltip.

    /re-wrote below as had more time to say why doing this.

    DS protocol with that has been a great management addition.

    I went straight to 800x800 .png,  skipping/deleting .duf.png years ago already.

    Have 100s and 100s of such 800px x 800px.  Zero issue.  But have 128gb ram, and watching ram use.  May have to adapt my usage depending on plans going forward.

     

    ***Important reason: When first set-up this image improvement, i liked this process, because any resave of the duf and DS  auto-makes a new .*duf.png.  Delete this and my custom *.png is still there and not auto-replaced.  This way the grainy non-iray .duf.pngs are avoided.

     

    That said, the 91x91 seems partly a remnant where old computer systems had way less computing power.  Though that protocol is there for good reasons, especially for less ram systems.

    Lots less ram, like 8-16gb should still be careful depending how many icons they make at higher res, and what else they usually have open at same time on PC.

    For those with 64gb ram, would guess lots of images at 400px x 400px for *.png would be fine.   Or just keep using .duf.png for tips.

    @Marble.  Guessing the .tip.png only gets read into ram when you hover over it.  Whereas all *.pngs are part of DS load.  Just a guess though.  Haven't micro-tested that.  So guessing eventually could add up depending on how many and size.  Something to monitor if not following protocol.  In a good way, the .png vs duf.png is a helpful system for many users.

     

    Edit: Just Win 10 default with a few background processes on and DAZ forum tab &DAZ store tab = 6.4GB ram.

    Edit 2:  Decided just to make time and test.  
    Opened DS. Firefox closed.   RAM = 6.0GB
    High-lighted over 150+ high-res icons to preview quick without opening any scene.  Ram = 6.1GB
    With system rounding and pc changes to ram within +- 0.1gb anyway, am not really concerned.
    Performance is instant. But have a high-end machine. So user mileage may vary.

    Post edited by Saxa -- SD on
  • marble said:

    johndoe_36eb90b0 said:

    You should not render icons to 800x800 -- for asset.duf you should render asset.png at the icon size (91x91), and asset.tip.png at the size you want (say 800x800). That way icon doesn't have to be resized to be displayed in the user interface, and when you mouse over the icon you get shown larger image as a tooltip.

     

    I don't understand the point of the 91x91 image. Why not just render out the larger image instead of creating an extra .tip.png? I always save my icons at larger resolutions precisely because I want something my old eyes can see when I hover over them with the mouse.

    Speed and efficiency - while it will depend on system specs and the number of items to load and adjust using larger images and downsizing on-the-fly for thumbnails will have a performance impact.

  • Saxa -- SDSaxa -- SD Posts: 872
    edited January 2023

    Richard Haseltine said:

    marble said:

    johndoe_36eb90b0 said:

    You should not render icons to 800x800 -- for asset.duf you should render asset.png at the icon size (91x91), and asset.tip.png at the size you want (say 800x800). That way icon doesn't have to be resized to be displayed in the user interface, and when you mouse over the icon you get shown larger image as a tooltip.

     

    I don't understand the point of the 91x91 image. Why not just render out the larger image instead of creating an extra .tip.png? I always save my icons at larger resolutions precisely because I want something my old eyes can see when I hover over them with the mouse.

    Speed and efficiency - while it will depend on system specs and the number of items to load and adjust using larger images and downsizing on-the-fly for thumbnails will have a performance impact.

    Suppose question can be asked, that now with new powerful systems more common, is that performance impact of any signifcance.  But with DAZ having to account for all systems, that system is still relevant in my mind.

    Edit: See post just above re: performance and ram usage.  Edited and updated.

    Post edited by Saxa -- SD on
  • marblemarble Posts: 7,500

    Richard Haseltine said:

    marble said:

    johndoe_36eb90b0 said:

    You should not render icons to 800x800 -- for asset.duf you should render asset.png at the icon size (91x91), and asset.tip.png at the size you want (say 800x800). That way icon doesn't have to be resized to be displayed in the user interface, and when you mouse over the icon you get shown larger image as a tooltip.

     

    I don't understand the point of the 91x91 image. Why not just render out the larger image instead of creating an extra .tip.png? I always save my icons at larger resolutions precisely because I want something my old eyes can see when I hover over them with the mouse.

    Speed and efficiency - while it will depend on system specs and the number of items to load and adjust using larger images and downsizing on-the-fly for thumbnails will have a performance impact.

    I still don't get that. What do icons have to do with performance? I can't imagine why icons would be loaded into a scene although scene loading can be really slow but I understand that to be due to morph loading. Certainly, G8F loads far slower than G8M for me and I figure that's because I have many more G8F morphs and characters.

     

  • marblemarble Posts: 7,500
    edited January 2023

    Can anyone say whether the animation timeline key deletion works in the later beta versions? I'm on 4.21.0.5 and I can't delete some keys (they are hand pose keys but I don't know if the problem is more general). I select them so they are highlighted and either use the minus button or right-click and "delete selected keys".

    [EDIT]

    Ok so I did install this latest beta (4.21.1.29) and I still can't delete the keys.

    Post edited by marble on
  • marble said:

    Richard Haseltine said:

    marble said:

    johndoe_36eb90b0 said:

    You should not render icons to 800x800 -- for asset.duf you should render asset.png at the icon size (91x91), and asset.tip.png at the size you want (say 800x800). That way icon doesn't have to be resized to be displayed in the user interface, and when you mouse over the icon you get shown larger image as a tooltip.

     

    I don't understand the point of the 91x91 image. Why not just render out the larger image instead of creating an extra .tip.png? I always save my icons at larger resolutions precisely because I want something my old eyes can see when I hover over them with the mouse.

    Speed and efficiency - while it will depend on system specs and the number of items to load and adjust using larger images and downsizing on-the-fly for thumbnails will have a performance impact.

    I still don't get that. What do icons have to do with performance? I can't imagine why icons would be loaded into a scene although scene loading can be really slow but I understand that to be due to morph loading. Certainly, G8F loads far slower than G8M for me and I figure that's because I have many more G8F morphs and characters.

    Performance in browsing the content libraries - if larger thumbnails had to be downsized every time the view chnaged it might, depending on system and number of items, have a noticeable impact which would annoy at least some users.

  • Saxa -- SDSaxa -- SD Posts: 872
    edited January 2023

    marble said:

    Can anyone say whether the animation timeline key deletion works in the later beta versions? I'm on 4.21.0.5 and I can't delete some keys (they are hand pose keys but I don't know if the problem is more general). I select them so they are highlighted and either use the minus button or right-click and "delete selected keys".

    [EDIT]

    Ok so I did install this latest beta (4.21.1.29) and I still can't delete the keys.

    OK now i think i get what you were using re: hand poses.

    They are most likely aliases to make that one pose.  So right-click time, go to Clear Animation > Clear Selected Item Pose(s).  And my keyframe for that special alias for hand pose is now gone.

    Post edited by Saxa -- SD on
Sign In or Register to comment.