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

1242527293033

Comments

  • The RED CrownThe RED Crown Posts: 247
    edited March 3

    DoctorJellybean said:

    The RED Crown said:

    DoctorJellybean said:

    Richard Haseltine said:

    DoctorJellybean said:

    The RED Crown said:

    I use Beta 4.20.0.4 , still can not detect HDR light in textures folder .

    It looks like \runtime\ is missing. What set is it?

    or has a double // or other invalid characters in fron tot he Runtime - the Sabby characters behaved in exactly the same way

    Correct. I had a look at the file, the line is

    //Runtime/textures/Laticis%20Imagery/LI%20Incandenscent%20-%20Portait%20Lighting/Incandescent_001.hdr

    i edit the file from :

    //Runtime/textures/Laticis%20Imagery/LI%20Incandenscent%20-%20Portait%20Lighting/Incandescent_001.hdr

    to :

    /Runtime/textures/Laticis%20Imagery/LI%20Incandenscent%20-%20Portait%20Lighting/Incandescent_001.hdr

    and it work .

    I was going to suggest that. You may have to edit the other presets if they also have the //runtime entries.

    i prefer not edit all files .
    i will locate file manually . not problem to me .

    Thank you .

    Post edited by The RED Crown on
  • barbultbarbult Posts: 19,377

    If you are fixing layout bugs, I wish you would look at this report I submitted in 2020. The problem persists for me in 4.20.0.4

    Request #333530

    Overridden keyboard shortcuts are lost when reloading a layout that assigned them

  • DoctorJellybeanDoctorJellybean Posts: 6,341
    edited March 3

    barbult said:

    If you are fixing layout bugs, I wish you would look at this report I submitted in 2020. The problem persists for me in 4.20.0.4

    Request #333530

    Overridden keyboard shortcuts are lost when reloading a layout that assigned them

    I've just tried it, works for me. I created a new keyboard shortcut, instead of overwriting an existing one.

    Post edited by DoctorJellybean on
  • nicsttnicstt Posts: 11,637

    mistycomic said:

    outrider42 said:

    Every time a new release comes out, we get a load of users who find something isn't right, and they BEG to go back to their previous version.

    Every single time.

    I guess it was their fault for not reading every post in the forums, and not seeing the handful of posts that might mention backing up their old install. It is totally their fault for not understanding that Daz doesn't offer a way to go back. Ever. Yep, it is totally the customer's fault for these things... <.<

    I find this exercise getting tiresome and stupid. This is objectively anticonsumer behavior. When you remove choice from the customer, that is anticonsumer. I can go to Blender and install any version I want going back years. I can also install as many versions of Blender as I want, right in the same folder even. I have 4 versions of Blender on my machine right now. Nvidia also allows users to install any number of drivers on their GPUs. I can go and install drivers from 2016 if I want to. But you cannot do this with Daz Studio.

    And before some chump jumps in and says "well so-and-so doesn't let you revert back", does that argument make what Daz is doing right? No, it does not. Two wrongs do not make a right, and just because some other company engages in anticonsumer behavior does not mean that every company is obligated to do so.

    So while Daz can blame Nvidia for killing how ghost lights work, this entire matter gets resolved by letting your customers download previous versions of Daz! This is a choice that is 100% on Daz themselves, and Daz refuses to give their own customers this simple basic choice. It is disgusting practice by any standard, and this ghost light ordeal exposes it fully for everyone to see how awful it is. Nobody can defend this. I am sure somebody will try, but they have no real defense. Daz's anticonsumerism is biting them in the ass real hard right now.

    Do you think the users who just had all of their scenes that used ghost lights are going to happily buy from you soon? I rather think they will be quite hesitant to support Daz anytime soon. And all Daz needed to do is give them the option to download a previous version. Problem solved. Angry customers go home less angry. Is this really so hard to do? Is this really asking too much of Daz?

    Give your customers the ability to download previous versions of Daz Studio.

    A very good point and a very reasonable argument. 

    I have spent the last week or so trawling Google to try and find the previous version for my Mac, as my previous back ups failed and i was not able to re-install the previous version after installing 4.20 through DIM.

    I contacted Support who very promptly replied (within 24hrs)  that they do not support any previous versions of the software, to which replied and have heard nothing back since (6 days ago).

    My reasons for trawling Google, and I believe the reasoning for other users, is that we would rather try and fix the problem ourselves (before contacting Support) and then just "get on with it". 
    As indivuals, we all have our own problems, time restraints, working conditions etc. and i strongly feel that Support should do everything they can to support this and in doing so alleviate the pressure on themselves. 

    outrider42 had a very valid argument.  I just wanted to add my personal experience to this.

    He did indeed.

    ... However, it is the customer's fault if they fail to make backups. Or alternatively, go to a product that is more customer friendly in their perception.

    Personally, I find Daz fairly customer friendly - just not as much as they used to be.

    I make backups; because it isn't other folk's responsibility but mine. I know Daz's stance, which is implied if not stated.

  • barbultbarbult Posts: 19,377

    DoctorJellybean said:

    barbult said:

    If you are fixing layout bugs, I wish you would look at this report I submitted in 2020. The problem persists for me in 4.20.0.4

    Request #333530

    Overridden keyboard shortcuts are lost when reloading a layout that assigned them

    I've just tried it, works for me. I created a new keyboard shortcut, instead of overwriting an existing one.

    This help request specifically addresses problems when overriding one of the built in (or perhaps they are called default) keyboard shortcuts. I have no problem assigning an unused shortcut to a custom action.

    To save you the time of looking up the actual help request, this is what it says:

    I believe this is a bug in the Daz Studio application:
    I created a custom action and assigned it the keyboard shortcut of Ctrl+S, overriding the default assignment of Ctrl+S. I saved a layout with Custom Actions, Menus and Toolbars. Everything works fine until I change to a different layout and then change back to my saved layout. When I change to my saved layout, Ctrl+S goes back to the default Save Scene action and is not assigned to my custom action anymore. Other custom action keyboard shortcuts that I had assigned are restored properly, but NOT the one that overrode a default action. It is as though the software loaded the custom keyboard shortcuts first and then loaded the default keyboard shortcuts over them.

    To reproduce this problem:
    1) Open Daz Studio. (I am using DS 4.12.2.6 Public Beta, but this problem is not limited to that version.)
    2) Select an item in the Content Library and right-click to create a custom action for it. Click Accept. (I used the V3D SSU Incremental Save Pro script from the Super Save product.)
    3) Open the Customize DAZ Studio dialog (F3).
    4) Expand the Custom item in the Actions column.
    5) Locate the item that the custom action was just created for (mine is at the end of the list).
    6) Right click on the item and select Change Keyboard Shortcut.
    7) Enter Ctrl+S as the keyboard shortcut (Hold Ctrl key and press S at the same time).
    8) When the dialog pops up telling you Ctrl+S is already assigned to another action, click the Yes button.
    9) Click the Accept button to close the Customize DAZ Studio dialog.
    10) Type Ctrl+S to verify that the keyboard shortcut invokes the custom action.
    11) Select Window>Workspace>Save Layout As...
    12) Give the layout the name Shortcut Test.
    For Actions, Menus, and Toolbars, leave them set to Custom.
    13) Click Accept.
    14) Select Window>Workspace>Select Layout...
    15) Change to a different layout, for example, choose the workspace City Limits.
    16) Select Window>Workspace>Select Layout...
    17) Choose Shortcut Test, to change back to the saved layout.
    18) Enter F3 again, expand the Custom section under Actions, scroll down and observe that Ctrl+S is no longer shown as the keyboard shortcut for the custom action.
    19) Click Cancel to exit the Customize Daz Studio dialog.
    20) Type Ctrl+S and observe that has been reassigned to the original action of Save Scene, and is no longer assigned to the custom action, even though we reloaded the layout that assigned that keyboard shortcut to the custom action.

    According to the help request, this was reported to the developers (bug tracker) on June 09, 2020 14:53. CS closed the help request and marked it "Solved", like they do for any request that goes to the developers, because (according to CS) the developers never respond to CS with any feedback about whether the bug report has been resolved. Users are expected to just watch the change log to see if anything is ever written there about their issues. This is a terrible system, in my opinion.

  • ImagoImago Posts: 4,213
    edited March 4

    jbowler said:

    The selection bugs in the timeline might have been fixed in 4.20, or maybe earlier

    Can you select and move the tringles in the timeline once you select them? Or they stay locked in place until you create a key on the "cast shadows" line?

    Before you ask, yes, I can move those triangles as soon as they are created in 4.12.0.86. It's a bug that DAZ Studio got since 4.14.

    Post edited by Imago on
  • jbowlerjbowler Posts: 582

    Imago said:

    Can you select and move the tringles in the timeline once you select them? Or they stay locked in place until you create a key on the "cast shadows" line?

    Before you ask, yes, I can move those triangles as soon as they are created in 4.12.0.86. It's a bug that DAZ Studio got since 4.14.

    The problem is the aliases; properties can be keyed via aliases but doing so makes unselectable key groups.  Specifically click select, drag select and move all work until I do a key on an alias and then I can't click select or move (but I can drag select) the key group without doing a full TRSOAH select.  Up to the alias key operation I can do partial selectes, e.g. just "T", and move the translate properties independently of all the others.

    Personally I think it is trying to be over-functional; I don't think I ever want to move just some of the properties, I want to move everything, or delete everything with Key-.  It's a PITA having left over H properties after a Key-

    Another bug: create primitive is not creating an undo entry and can't be undone.

  • IceCrMnIceCrMn Posts: 1,784

    Did everyone get the new beta this morning? 

    4.20.0.4

    Changelog doesn't show much activity.

    http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log

    looks like they are still working on getting the layouts to save correctly.

  • DoctorJellybeanDoctorJellybean Posts: 6,341

    IceCrMn said:

    Did everyone get the new beta this morning? 

    4.20.0.4

    Changelog doesn't show much activity.

    http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log

    looks like they are still working on getting the layouts to save correctly.

    Layouts and toolbars should save correctly now.

  • jbowlerjbowler Posts: 582
    edited March 4

    IceCrMn said:

    looks like they are still working on getting the layouts to save correctly.

    There are log messages now recording the save of the .dsx files:

    2022-03-04 10:30:30.020 [INFO] :: Saving Layout: %AppData%/DAZ 3D/Studio4 Public Build/ layout.dsx
    2022-03-04 10:30:30.040 [INFO] :: Saving Custom Actions: %AppData%/DAZ 3D/Studio4 Public Build/ customactions.dsx
    2022-03-04 10:30:30.048 [INFO] :: Saving Actions: %AppData%/DAZ 3D/Studio4 Public Build/ actions.dsx
    2022-03-04 10:30:30.071 [INFO] :: Saving Menus: %AppData%/DAZ 3D/Studio4 Public Build/ menus.dsx
    2022-03-04 10:30:30.101 [INFO] :: Saving ToolBars: %AppData%/DAZ 3D/Studio4 Public Build/ toolbars.dsx

    I asume based on the log details that they will now be created if they don't exist, as before; it looks like only layout.dsx was fixed in .3

    EDIT: Corrected the paths above.  All the files are now being created; I tested by deleting the Studio4 Public Build directory.

    Post edited by jbowler on
  • Richard HaseltineRichard Haseltine Posts: 83,941

    jbowler said:

    IceCrMn said:

    looks like they are still working on getting the layouts to save correctly.

    There are log messages now recording the save of the .dsx files:

    2022-03-04 10:30:30.020 [INFO] :: Saving Layout: %AppData%/Roaming/DAZ 3D/Studio4 Public Build/ layout.dsx
    2022-03-04 10:30:30.040 [INFO] :: Saving Custom Actions: %AppData%/Roaming/DAZ 3D/Studio4 Public Build/ customactions.dsx
    2022-03-04 10:30:30.048 [INFO] :: Saving Actions: %AppData%/Roaming/DAZ 3D/Studio4 Public Build/ actions.dsx
    2022-03-04 10:30:30.071 [INFO] :: Saving Menus: %AppData%/Roaming/DAZ 3D/Studio4 Public Build/ menus.dsx
    2022-03-04 10:30:30.101 [INFO] :: Saving ToolBars: %AppData%/Roaming/DAZ 3D/Studio4 Public Build/ toolbars.dsx

    I asume based on the log details that they will now be created if they don't exist, as before; it looks like only layout.dsx was fixed in .3

    The Roaming folder names is  suplied by %AppData%, only the Daz 3d folder on is additional.

  • jbowlerjbowler Posts: 582

    Richard Haseltine said:

    The Roaming folder names is  suplied by %AppData%, only the Daz 3d folder on is additional.

    Yes, my mistake: %AppData%\Daz 3D, then all the configuration stuff not in the registry (most of it) is in that directory.

  • ragamuffin57ragamuffin57 Posts: 105
    edited March 5

    Are anyone finding that you cannot dial out morphs?? Added Mousso morphs and Lainey morphs to 8.1  base female as I have done before but now cannot dial them out to the default ?? Anyone else experienced this bug?

    or you dial in a character and in all is messed up

    Post edited by ragamuffin57 on
  • takezo_3001takezo_3001 Posts: 1,564

    outrider42 said:

    Every time a new release comes out, we get a load of users who find something isn't right, and they BEG to go back to their previous version.

    Every single time.

    I guess it was their fault for not reading every post in the forums, and not seeing the handful of posts that might mention backing up their old install. It is totally their fault for not understanding that Daz doesn't offer a way to go back. Ever. Yep, it is totally the customer's fault for these things... <.<

    I find this exercise getting tiresome and stupid. This is objectively anticonsumer behavior. When you remove choice from the customer, that is anticonsumer. I can go to Blender and install any version I want going back years. I can also install as many versions of Blender as I want, right in the same folder even. I have 4 versions of Blender on my machine right now. Nvidia also allows users to install any number of drivers on their GPUs. I can go and install drivers from 2016 if I want to. But you cannot do this with Daz Studio.

    And before some chump jumps in and says "well so-and-so doesn't let you revert back", does that argument make what Daz is doing right? No, it does not. Two wrongs do not make a right, and just because some other company engages in anticonsumer behavior does not mean that every company is obligated to do so.

    So while Daz can blame Nvidia for killing how ghost lights work, this entire matter gets resolved by letting your customers download previous versions of Daz! This is a choice that is 100% on Daz themselves, and Daz refuses to give their own customers this simple basic choice. It is disgusting practice by any standard, and this ghost light ordeal exposes it fully for everyone to see how awful it is. Nobody can defend this. I am sure somebody will try, but they have no real defense. Daz's anticonsumerism is biting them in the ass real hard right now.

    Do you think the users who just had all of their scenes that used ghost lights are going to happily buy from you soon? I rather think they will be quite hesitant to support Daz anytime soon. And all Daz needed to do is give them the option to download a previous version. Problem solved. Angry customers go home less angry. Is this really so hard to do? Is this really asking too much of Daz?

    Give your customers the ability to download previous versions of Daz Studio.

    I agree with this 134%, but the fact of the matter is that Daz chose to restrict people's access to previous versions of their software, so there needs to be a sticky made, or large post in a new beta/gen release thread letting users know that they cannot revert their changes unless they have made their own backups! 

  • takezo_3001 said:

    I agree with this 134%, but the fact of the matter is that Daz chose to restrict people's access to previous versions of their software, so there needs to be a sticky made, or large post in a new beta/gen release thread letting users know that they cannot revert their changes unless they have made their own backups! 

    How is that sticky post in the forums going to help users who never install any Public Beta versions and never visit forums, but instead just update their Release version in DAZ Install Manager and then discover that half of their content no longer works as it did?

    Proper solution is to not allow users to update in DIM without reading release notes first. That would of course require that there are release notes available to begin with.

    Also, it wasn't you who said it, but the thinking that "it's users' fault for not having backup" is unreasonable because backups can fail.

    Daz Studio users are not IT administrators who know that the only real backup is if you store your files in at least 3 different places -- locally, online, and offline / off-site and then perform weekly tests to see if you can actually restore from those.

  • IceCrMnIceCrMn Posts: 1,784

    I'm probably grasping at straws here.

    Can an LPE be used to make ghost lights behave like they did before the opacity/luminance change?

    https://www.migenius.com/doc/realityserver/4.3/resources/general/iray/manual/concept/light_path_expression_grammar.html

  • jbowlerjbowler Posts: 582
    edited March 6

    IceCrMn said:

    I'm probably grasping at straws here.

    Can an LPE be used to make ghost lights behave like they did before the opacity/luminance change?

    https://www.migenius.com/doc/realityserver/4.3/resources/general/iray/manual/concept/light_path_expression_grammar.html

    Yes.  It's some combination of <RS> elements in the path involving something tagged as a ghost light.  What it is depends on what the precise definition of a ghost light is; indeed the description would be a precise description of "ghost light behaviour".

    Post edited by jbowler on
  • FalcoFalco Posts: 187

    Not sure if this has been noted already since I haven't gone through the 27 pages, but on 4.20 with Iray Server 3.44, my render times quadrupled.  I sent in a ticket for it but figured I'd post it here too.  This is with a small scene with an RTX 3090 on GPU only.  Final output was exactly the same, just way slower.  (ignore the compatibility message, I took the screenshot after switching versions)

  • jag11jag11 Posts: 864

    I found a problem in Iray. I expected a complete darkness interior but light keeps getting in.

    Light is expected to travel through volumes and transparent objects but not in solid objects.

    This might be the root cause that makes some figures to generate lots fireflies.

    Light leak.png
    1000 x 800 - 1M
    duf
    duf
    20220306 Light leaks.duf
    22K
  • Richard HaseltineRichard Haseltine Posts: 83,941

    Falco said:

    Not sure if this has been noted already since I haven't gone through the 27 pages, but on 4.20 with Iray Server 3.44, my render times quadrupled.  I sent in a ticket for it but figured I'd post it here too.  This is with a small scene with an RTX 3090 on GPU only.  Final output was exactly the same, just way slower.  (ignore the compatibility message, I took the screenshot after switching versions)

    Is the render using CPU or GPU? What is the driver version?

  • FalcoFalco Posts: 187

    Render is using the GPU, I verified Cuda cores were at 95+ percent the whole time, and both Daz and IS are set to GPU only.  There is a ton of new spam in the Iray Server command line about "sending chunks 1-300" that wasn't there before, but not sure if it's related.  

    Driver version is 511.65 from Jan, I see there is a new one from Feb, lemme grab that and see if it makes any difference.  

  • FalcoFalco Posts: 187

    Falco said:

    Render is using the GPU, I verified Cuda cores were at 95+ percent the whole time, and both Daz and IS are set to GPU only.  There is a ton of new spam in the Iray Server command line about "sending chunks 1-300" that wasn't there before, but not sure if it's related.  

    Driver version is 511.65 from Jan, I see there is a new one from Feb, lemme grab that and see if it makes any difference.  

    After updating the driver to the latest version, running the render again as a new job is matching the slow speed with only 100 iterations done after 10 minutes.   So updating the driver didn't seem to make a difference unfortunately.  

  • GordigGordig Posts: 6,990

    I can't help but notice that the screenshot for 4.20 says "incompatible" and "bridge protocol version not supported".

  • IceCrMnIceCrMn Posts: 1,784

    jag11 said:

    I found a problem in Iray. I expected a complete darkness interior but light keeps getting in.

    Light is expected to travel through volumes and transparent objects but not in solid objects.

    This might be the root cause that makes some figures to generate lots fireflies.

    hmm, there is a light leak.

    The smaller the outer cube the less leakage, but still it leaks.

    I tested outer cubes ranging in size from 10m-2000m in 10m increments.

  • jbowlerjbowler Posts: 582

    IceCrMn said:

    jag11 said:

    I found a problem in Iray. I expected a complete darkness interior but light keeps getting in.

    Light is expected to travel through volumes and transparent objects but not in solid objects.

    This might be the root cause that makes some figures to generate lots fireflies.

    hmm, there is a light leak.

    The smaller the outer cube the less leakage, but still it leaks.

    I tested outer cubes ranging in size from 10m-2000m in 10m increments.

    Let it converge fully; the convergence in the scene is only set to 95% (set quality to 0.1 to speed it up) and turn tonemapping off.  I also raised the inner sphere up 1cm - the inner and outer spheres bottom surfaces are otherwise coincident.  When I let it converge the pink fireflies disappeared at 94% convergence with the 0.1 quality, this is with tonemapping off so the EV for the scene was 0 (but the convergence still uses the tonemapping EV even when tonemapping is off).

  • FalcoFalco Posts: 187
    edited March 7

    Gordig said:

    I can't help but notice that the screenshot for 4.20 says "incompatible" and "bridge protocol version not supported".

    I addressed this in the original post, but let me clarify. This is a side effect of doing the job in 4.20, then switching back to 4.16 to run the new job, and leaving the results of both jobs in the archive so I could compare them.  Once the switch happened it marked the 4.20 render as incompabitle with the current 4.16 bridge, but has no relevance to the actual results.   Switching back to 4.20 then marks the 4.16 job as incompatible with the 4.20 bridge and clears the warning from the 4.20 job.  It's just a side effect of switching back and forth, but it wasn't incompatible when the job was run, this is just the results archive.  

    Post edited by Falco on
  • IceCrMnIceCrMn Posts: 1,784
    edited March 7

    jbowler said:

    IceCrMn said:

    jag11 said:

    I found a problem in Iray. I expected a complete darkness interior but light keeps getting in.

    Light is expected to travel through volumes and transparent objects but not in solid objects.

    This might be the root cause that makes some figures to generate lots fireflies.

    hmm, there is a light leak.

    The smaller the outer cube the less leakage, but still it leaks.

    I tested outer cubes ranging in size from 10m-2000m in 10m increments.

    Let it converge fully; the convergence in the scene is only set to 95% (set quality to 0.1 to speed it up) and turn tonemapping off.  I also raised the inner sphere up 1cm - the inner and outer spheres bottom surfaces are otherwise coincident.  When I let it converge the pink fireflies disappeared at 94% convergence with the 0.1 quality, this is with tonemapping off so the EV for the scene was 0 (but the convergence still uses the tonemapping EV even when tonemapping is off).

    I trying that out now.

    Looks like even more light is getting in after turning off the tone mapper.

    I'll let it finish.

    But here's the thing.

    IF the primitive cube is a solid object.

    Then wouldn't @jag11 be correct in saying there is a light leak?

    Seems reasonable that an enclosed cube should not have any illumination inside.

    So the render should be black for the lack on light penetrating the outer cube.

     

    edit:heres the finished test renders at quality 0.1

    leaktest j1.jpg
    2553 x 1033 - 937K
    ToneMappingOFF.png
    1000 x 800 - 1M
    tonemappingON.jpg
    1000 x 800 - 494K
    Post edited by IceCrMn on
  • jbowlerjbowler Posts: 582

    IceCrMn said:

    But here's the thing.

    IF the primitive cube is a solid object.

    Then wouldn't @jag11 be correct in saying there is a light leak?

    Seems reasonable that an enclosed cube should not have any illumination inside.

    So the render should be black for the lack on light penetrating the outer cube.

    Indeed; the physically completely correct result is clear (I tried to check the outer sphere surface for any possible transmission, I couldn't see any), but ray-traciing is an approximation and the result shows that it is pretty much all error.  It's not the pink inner cube and its curiously pink shadow (opaque objects do not cast pink shadows), rather it's the massive amount of the noise.  The EV setting in the original scene is 13, turning off tone mapping reduces it to 0, so it multiplies the light levels by 8192 (2 to the power of 13).  The fact that the top of the cube is mostly white is also indicative of errors (this is partly a result of setting the quality to 0.1, which permits pixel values with very large errors to meet the convergence limit.)  Somehow my test didn't produce the same result, I'm not sure why - I ended up with no light even though the render started off with similar errors.

    What I think is happening is that it is not a light leak, rather it is a consequence of the precise way Iray approximates the result.  It's reasonable to model Iray performance based on the real world but as has been observed wrt the ghost light issue Iray isn't real world - it's ray tracing.

  • IceCrMnIceCrMn Posts: 1,784

    Nvidia broke ghost lights in the pursuit of ray trace perfection, they can "break" this also.

    This isn't the only bug/deficiency, or whatever, in iray jag11 has found.

    He's got another thread discussing another issue concerning the way light behaves though a prism.

    Both seem worth of a bug report to Nvidia in my non-professional opinion.

  • jbowlerjbowler Posts: 582

    IceCrMn said:

    hmm, there is a light leak.

    The smaller the outer cube the less leakage, but still it leaks.

    I tested outer cubes ranging in size from 10m-2000m in 10m increments.

    That suggests the error is caused by the gap at the edges of the surfaces that make up the cube; it's not really a cube, it's six squares arranged as a cube.  Consequently the edges don't meet; sometimes they overlap, sometimes they underlap creating a gap.  The gap width is constant, but as the edge gets longer the gap area goes up linearly with the size of the cube.

Sign In or Register to comment.