Loading...
> >

Carrara 8.5 Fast Mip Map DEGRADES all texture maps!

13

Comments

  • PhilWPhilW Posts: 5,145
    edited December 1969

    boojumbunn said:
    True, but that is if you want to change a selection of them. What I suggest you do is have a way to change the filter settings on ALL the maps on an object. There is a very good reason for this....

    If your wanting to render an object without loss of quality due to FastMipMap... then your almost always wanting to set all the textures on the object to not use fastmipmap. That includes the eyes, the lips, the fingernails, and everything else. You don't normally want one part of a model to be high quality and the rest to be less quality. Also, this gives a person a choice. If less than half the textures need to be changed, then they can do it individually. If more than have need to be changed then they can change them all and change the ones they don't want to use a different filter back.

    But honestly, I suspect everyone is going to want to be able to set all to a particular filter setting.

    Boojum the brown bunny

    I'd definitely agree with that.

    Spooky's question is a tough one, given that it is one or the other, we can't have both!

  • JonstarkJonstark Posts: 2,738
    edited December 1969

    DAZ_Spooky said:
    The problem is there is no information in the shaders that tell you what material zone they are supposed to apply to. It is strictly an index, where the first Material Zone on the object gets the first sub-shader, etc..

    So if the First Material zone, when you saved it was teeth, but the first material zone when it was applied the next time was face....

    BTW there is a reason you don't have this fix with 8.5 and that is because we haven't figured a way to avoid the incompatibility.

    What happens if there are more material zones on the original shader than on the new version (example, V4 and M4 have material zones for eye surface that Genesis doesn't have)? Do they just vanish, or is there must an extra material zone layer added that doesn't apply to anything? Personally even though it's a tough choice I would say just bite the bullet and go for it. Everyone who has a shader library for V4/M4 is already having to make new shader versions to fit with Genesis anyway, so the present is as good a time as any. Too bad they couldn't just organize them in the same order to begin with for all figures...

  • de3ande3an Posts: 915
    edited December 1969

    DAZ_Spooky said:
    de3an said:
    DAZ_Spooky said:
    Speaking of which, the Shader system in Carrara really should use the Material Zone name, instead of a straight index. We have been discussing fixing that, however, fixing that will break current multi-shader presets. The upside is that, for example, you could apply the same preset designed for V4 or M4, etc. to Genesis. It will also fix applying a preset to V4 regardless of whether V4 was loaded as part of a scene in a DUF or loaded directly as a CR2.

    Comments on this?


    While I don't completely understand the ramifications of what this change in the Shader system would have, I believe that it's important to maintain backwards compatibility with the vast library of Shader presets that are currently in use. Perhaps multi-shader presets could be automatically converted to prevent "breakage".

    The problem is there is no information in the shaders that tell you what material zone they are supposed to apply to. It is strictly an index, where the first Material Zone on the object gets the first sub-shader, etc..

    So if the First Material zone, when you saved it was teeth, but the first material zone when it was applied the next time was face....


    Well, my programming experiance is very modest, but it seems that if Carrara is currently able to correctly place the shaders on an object via relative indexing, then that same procedure could be used as a basis for assigning actuall material zone names in a conversion routine.

    At any rate, I'm pretty sure that a clever programmer could figure something out. Breaking the previous Shader version doesn't seem to be the right answer.

  • Boojum the brown bunnyBoojum the brown bunny Posts: 348
    edited December 1969

    Well, we have an options checkbox on some loaders. In theory you could have an options panel that opens and allows you to select at the time of load what texture map filter you would like to use for the map your loading. Forget completely about what object it is going on, just select it at load time.

    Another option would be to allow right clicks on the shader tree inside of the Textures Panel and set it there. Rightclick, select texture filter, select FastMipMap (or other filter type) and it will set it without having to open the entire texture panel dozens of time, find the texture map, change the texture map, and then Scroll back down because the part of the tree your editting is once again below the bottom of the screen because each time you open a texture panel it resets you to the top of the tree!

    Boojum the brown bunny

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Jonstark said:
    DAZ_Spooky said:
    The problem is there is no information in the shaders that tell you what material zone they are supposed to apply to. It is strictly an index, where the first Material Zone on the object gets the first sub-shader, etc..

    So if the First Material zone, when you saved it was teeth, but the first material zone when it was applied the next time was face....

    BTW there is a reason you don't have this fix with 8.5 and that is because we haven't figured a way to avoid the incompatibility.

    What happens if there are more material zones on the original shader than on the new version (example, V4 and M4 have material zones for eye surface that Genesis doesn't have)? Do they just vanish, or is there must an extra material zone layer added that doesn't apply to anything? Personally even though it's a tough choice I would say just bite the bullet and go for it. Everyone who has a shader library for V4/M4 is already having to make new shader versions to fit with Genesis anyway, so the present is as good a time as any. Too bad they couldn't just organize them in the same order to begin with for all figures...Because it is by name, the ones that don't exist get skipped.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    de3an said:


    Well, my programming experiance is very modest, but it seems that if Carrara is currently able to correctly place the shaders on an object via relative indexing, then that same procedure could be used as a basis for assigning actuall material zone names in a conversion routine.

    At any rate, I'm pretty sure that a clever programmer could figure something out. Breaking the previous Shader version doesn't seem to be the right answer.

    Sounds simple enough in theory, not so simple in execution. If it was that simple, it would have been done and you wouldn't have been asked about it. :) The problem is more the current data structure that defines the shaders, not as much the shader presets themselves, as I understand it. If it were just the saved presets we could simply set a flag on new shaders so if the flag exists do this, if the flag doesn't exist do it the old way and you would never notice the difference or have to make a decision.
  • araneldonaraneldon Posts: 712
    edited December 1969

    DAZ_Spooky said:
    Speaking of which, the Shader system in Carrara really should use the Material Zone name, instead of a straight index. We have been discussing fixing that, however, fixing that will break current multi-shader presets. The upside is that, for example, you could apply the same preset designed for V4 or M4, etc. to Genesis. It will also fix applying a preset to V4 regardless of whether V4 was loaded as part of a scene in a DUF or loaded directly as a CR2.

    Comments on this?


    Do whatever it takes to make this current system go away. In fact ditch all the current file formats, move to duf.
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    araneldon said:

    Do whatever it takes to make this current system go away. In fact ditch all the current file formats, move to duf.
    There is quite a bit Carrara does that DSON was never designed to handle. Even if it did handle it other programs that could handle DSON would choke miserably. LOL!
  • PhilWPhilW Posts: 5,145
    edited December 1969

    DAZ_Spooky said:
    araneldon said:

    Do whatever it takes to make this current system go away. In fact ditch all the current file formats, move to duf.
    There is quite a bit Carrara does that DSON was never designed to handle. Even if it did handle it other programs that could handle DSON would choke miserably. LOL!

    Then as .CAR files are able to cope with the most stuff, make DS save Carrara files! (Tongue firmly in cheek....;-)!)

  • araneldonaraneldon Posts: 712
    edited December 1969

    DAZ_Spooky said:
    araneldon said:

    Do whatever it takes to make this current system go away. In fact ditch all the current file formats, move to duf.
    There is quite a bit Carrara does that DSON was never designed to handle. Even if it did handle it other programs that could handle DSON would choke miserably. LOL!
    Assuming the devs haven't done a bad job designing the spec, there should be no problem extending the format to support Carrara's features whilst still keeping the common bits compatible between programs.
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    PhilW said:
    DAZ_Spooky said:
    araneldon said:

    Do whatever it takes to make this current system go away. In fact ditch all the current file formats, move to duf.
    There is quite a bit Carrara does that DSON was never designed to handle. Even if it did handle it other programs that could handle DSON would choke miserably. LOL!

    Then as .CAR files are able to cope with the most stuff, make DS save Carrara files! (Tongue firmly in cheek....;-)!)LOL, that was actually discussed before we settled on DUF. LOL.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    araneldon said:
    DAZ_Spooky said:
    araneldon said:

    Do whatever it takes to make this current system go away. In fact ditch all the current file formats, move to duf.
    There is quite a bit Carrara does that DSON was never designed to handle. Even if it did handle it other programs that could handle DSON would choke miserably. LOL!

    Assuming the devs haven't done a bad job designing the spec, there should be no problem extending the format to support Carrara's features whilst still keeping the common bits compatible between programs.
    Yes and no. The format would have to be revised, a new version put together, and put out. Which would allow a certain other company to say, see, this is why we don't natively support DSON, they keep moving the target, the format is not stable. :)
  • PhilWPhilW Posts: 5,145
    edited December 1969

    DAZ_Spooky said:
    araneldon said:
    DAZ_Spooky said:
    araneldon said:

    Do whatever it takes to make this current system go away. In fact ditch all the current file formats, move to duf.
    There is quite a bit Carrara does that DSON was never designed to handle. Even if it did handle it other programs that could handle DSON would choke miserably. LOL!

    Assuming the devs haven't done a bad job designing the spec, there should be no problem extending the format to support Carrara's features whilst still keeping the common bits compatible between programs.
    Yes and no. The format would have to be revised, a new version put together, and put out. Which would allow a certain other company to say, see, this is why we don't natively support DSON, they keep moving the target, the format is not stable. :)

    Yes, that's quite a poser...

  • Boojum the brown bunnyBoojum the brown bunny Posts: 348
    edited December 1969

    Yes, it's almost like someone sat down and said "Hey, lets design a completely new standard for one of our products without even considering our other products." It's right up there with "Lets add some new export features and deliberately avoid the formats that our other products use." *sigh* I'm sorry, but for the last week I have gotten nothing accomplished because of things like this. I spend an hour last night hand loading in a base texture onto each part of the Genesis Super Suit, and I'm still only halfway through loading in the base texture onto the hundreds of locations. Then I get the joy of hand editting every single one of those textures to point to the texture maps stored in the Runtime/Textures folder... and then I get to do the same with the specular maps and the bump maps. It's going to take me days of work just to get supersuit working for my character and it's leaving me rather bitter.

    Boojum

  • araneldonaraneldon Posts: 712
    edited September 2013

    The format wasn't designed to be extensible?

    To give a simplistic example: You can put all sorts of weird crap into an HTML document -- as long as it is well formed -- and browsers will simply ignore it, because that's what the specification tells them to do. Thus the format can be extended without breaking compatibility with existing implementations.

    Edited to fix a typo

    Post edited by araneldon on
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    araneldon said:
    The format wasn't designed to be extensible?

    To give a simplistic example: You can put all sorts of weird crap into an HTML document -- as long as it is well formed -- and browsers will simply ignore it, because that's what the specification tells them to do. Thus the format can be extended without breaking compatibility with existing implementations.

    Edited to fix a typo

    It is extensible, but to replace the CAR and CBR is more complex than simply extending the format.
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited September 2013

    Someone got a product, in our store, that gives you the seams? I am trying to recreate it quickly to show it to the lead Carrara dev, and I can't make it happen. (Typical.)

    And yes I have done it before, so I know it can be done. LOL.

    NVM I made it happen.

    Post edited by DAZ_Spooky on
  • DartanbeckDartanbeck Posts: 21,624
    edited December 1969

    de3an said:
    DAZ_Spooky said:
    Speaking of which, the Shader system in Carrara really should use the Material Zone name, instead of a straight index. We have been discussing fixing that, however, fixing that will break current multi-shader presets. The upside is that, for example, you could apply the same preset designed for V4 or M4, etc. to Genesis. It will also fix applying a preset to V4 regardless of whether V4 was loaded as part of a scene in a DUF or loaded directly as a CR2.

    Comments on this?


    While I don't completely understand the ramifications of what this change in the Shader system would have, I believe that it's important to maintain backwards compatibility with the vast library of Shader presets that are currently in use. Perhaps multi-shader presets could be automatically converted to prevent "breakage".Wow. This truly poses a conundrum, doesn't it?
    Fix compatibility forever more, but break all current multi-shaders, or leave the issue to keep compatible with what's been done in the past.

    I was initially going to post: "I'd be happy to go through all official*** multi-shaders and correct them so that users could download 'fixed' versions of those that they've bought, etc., and I would volunteer this."

    ***It was the word "official" that caught my mind sharply. For the vast majority of muliti-shaders that I have, I have made myself - and those would all, now be broken if this change was made...
    I really, in my gut, have to side with de3an on this one.

  • Boojum the brown bunnyBoojum the brown bunny Posts: 348
    edited December 1969

    DAZ_Spooky said:
    Someone got a product, in our store, that gives you the seams? I am trying to recreate it quickly to show it to the lead Carrara dev, and I can't make it happen. (Typical.)

    And yes I have done it before, so I know it can be done. LOL.

    NVM I made it happen.

    Changing the background of Elite Gabi skin from white to pink (the same color as the skin itself) fixes the problem. The problem occurs when using FastMipMap processing with a character 23' away, or an object accuracy of 2.

    Honestly, all the textures in the Morris folder have white backgrounds and result in this.

    Boojum the brown bunny

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    boojumbunn said:
    DAZ_Spooky said:
    Someone got a product, in our store, that gives you the seams? I am trying to recreate it quickly to show it to the lead Carrara dev, and I can't make it happen. (Typical.)

    And yes I have done it before, so I know it can be done. LOL.

    NVM I made it happen.

    Changing the background of Elite Gabi skin from white to pink (the same color as the skin itself) fixes the problem. The problem occurs when using FastMipMap processing with a character 23' away, or an object accuracy of 2.

    Honestly, all the textures in the Morris folder have white backgrounds and result in this.

    Boojum the brown bunnyThe other change to fix it is to increase the render resolution. (I knew I was missing something there. :) )

  • DartanbeckDartanbeck Posts: 21,624
    edited December 1969

    Jonstark said:
    DAZ_Spooky said:
    The problem is there is no information in the shaders that tell you what material zone they are supposed to apply to. It is strictly an index, where the first Material Zone on the object gets the first sub-shader, etc..

    So if the First Material zone, when you saved it was teeth, but the first material zone when it was applied the next time was face....

    BTW there is a reason you don't have this fix with 8.5 and that is because we haven't figured a way to avoid the incompatibility.

    What happens if there are more material zones on the original shader than on the new version (example, V4 and M4 have material zones for eye surface that Genesis doesn't have)? Do they just vanish, or is there must an extra material zone layer added that doesn't apply to anything? Personally even though it's a tough choice I would say just bite the bullet and go for it. Everyone who has a shader library for V4/M4 is already having to make new shader versions to fit with Genesis anyway, so the present is as good a time as any. Too bad they couldn't just organize them in the same order to begin with for all figures...I'm fairly certain that, if the multi-shader being loaded has more shaders within that the receiving figure has zones, the extra shaders are added to the shader tab. Obviously, they do not get added to the figure.

    You know, I personally wouldn't mind the "Go For It!" decision - simply because I have no difficulty using incompatible multi-shaders, and sorting them through on my own. This really is a tough call - but .... Argh!!!

  • DartanbeckDartanbeck Posts: 21,624
    edited September 2013

    So is Fast Mip Map the culprit or are the maps off slightly?

    EDIT:
    Well - not for it's intended purpose - I'm sure it looks great in DS - but someone should check - if they have DS installed.

    Post edited by Dartanbeck on
  • Boojum the brown bunnyBoojum the brown bunny Posts: 348
    edited December 1969

    I think that FastMipMap is the problem. When FastMipMap reduces the size of the texture on objects that are further away it performs a blending of pixes that are side by side. This is necessary to reduce the size of the map overall, sort of like when doing antialiasing. In the case of these skin textures, it is pink skin on a white background. When it blends the edge pixels between pink and white it ends up with light pink, a lighter pink than the skin texture in general. The further away the figure is from the camera, the worse this becomes, becoming a pale pink band across the top of the figures thigh.

    If you make the white backdrop the same shade of pink as the skin, then it blends pink with pink, which doesn't lighten that band of skin.

    Boojum the brown bunny

  • DartanbeckDartanbeck Posts: 21,624
    edited December 1969

    boojumbunn said:
    I think that FastMipMap is the problem. When FastMipMap reduces the size of the texture on objects that are further away it performs a blending of pixes that are side by side. This is necessary to reduce the size of the map overall, sort of like when doing antialiasing. In the case of these skin textures, it is pink skin on a white background. When it blends the edge pixels between pink and white it ends up with light pink, a lighter pink than the skin texture in general. The further away the figure is from the camera, the worse this becomes, becoming a pale pink band across the top of the figures thigh.

    If you make the white backdrop the same shade of pink as the skin, then it blends pink with pink, which doesn't lighten that band of skin.

    Boojum the brown bunny

    Makes perfect sense to me. I'll not even find it to be a PITA to pinkize texture borders. Thanks for that tip, btw.
  • Boojum the brown bunnyBoojum the brown bunny Posts: 348
    edited December 1969

    Oh, one thing to be clear on... I think this is a case of FastMipMap doing what it is supposed to do, but the texture map is poorly designed for work with a FastMipMap filter OR FastMipMap filter needs to not blend if the difference between two pixes is greater than a certain amount. So it is really a combination of a skin texture with a sharp divide at the edge of the uvmapped region and how FastMipMap reduces the texture to speed up renders.

    Boojum the brown bunny

  • kakmankakman Posts: 225
    edited December 1969

    DAZ_Spooky said:
    I caught it when Fast Mip-Map was introduced. :) Which is how i know that answer. The Devs and I had some long discussions about it. :) After all I am the Software QA Manager, not a dev. LOL. I have to look at software from a different perspective than they do.

    There was no poll, it was a large stack of requests and reports in the bug tracker and we still went back and forth on it.

    In most cases it produces faster and better results, note i said most cases. The default is the "80%" case and improvements were made in to make it work better than when we first sat down with it.

    You guys, who clearly know what you are doing, already know how to change it are more than welcome to change it. We expect you to. If you are modeling your own stuff, we figure you will set your shaders for the look you want anyway. For the person less experienced, this setting is believed to give a better, out of the box, experience in a wider number of cases.

    While my glasses are not as deeply rose colored, and my cheerleading is not as pronounced and constant as some others here in the forum, I am a huge fan of Carrara and want to see it continue to grow and improve.

    And yes this forum is full of very talented and knowledgeable people (unlike myself) that can figure out how to do all sorts of amazing things. But if Carrara is to grow it needs to attract new users (buyers) and a lot of those users are going to be beginners.

    Please note that Genesis (V5, M5, D5, etc.) and Genesis 2 Gia and V6 loaded “out-of-the-box” into a default scene with the default settings are all going to show the seams. I think that a new user without a lot of experience and knowledge is going to oft put by this. I think a lot of potential new users are not going to be thrilled about the prospect of having to spend a lot of time taking corrective measures to be able to use Carrara.

    It seems odd to me that it took over two years for C8.5 to be released and the emphasis of the changes to the software were to be able to seamlessly (pun intended) use the new Genesis and Genesis 2 models and the DUF file format.

    If it is not possible to offer a choice of Filtering methods as a preference setting or better yet on a scene by scene basis, in short order or at all, then I think at the very least DAZ should consider updating the offending shaders as per the method Boojum explained. This way the out-of-the-box initial renders will not have the seams and will not put off anyone new to Carrara.

  • DartanbeckDartanbeck Posts: 21,624
    edited December 1969

    kakman said:

    If it is not possible to offer a choice of Filtering methods as a preference setting or better yet on a scene by scene basis, in short order or at all, then I think at the very least DAZ should consider updating the offending shaders as per the method Boojum explained. This way the out-of-the-box initial renders will not have the seams and will not put off anyone new to Carrara.
    I agree. That or update the software to "Not" make Fast Mip Map the default, if that's indeed what's causing the issues. Which it seems it must.
  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    We have a dev looking at improving the performance on a wider range for Fast Mip-Map

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Dartanbeck said:
    Jonstark said:
    DAZ_Spooky said:
    The problem is there is no information in the shaders that tell you what material zone they are supposed to apply to. It is strictly an index, where the first Material Zone on the object gets the first sub-shader, etc..

    So if the First Material zone, when you saved it was teeth, but the first material zone when it was applied the next time was face....

    BTW there is a reason you don't have this fix with 8.5 and that is because we haven't figured a way to avoid the incompatibility.

    What happens if there are more material zones on the original shader than on the new version (example, V4 and M4 have material zones for eye surface that Genesis doesn't have)? Do they just vanish, or is there must an extra material zone layer added that doesn't apply to anything? Personally even though it's a tough choice I would say just bite the bullet and go for it. Everyone who has a shader library for V4/M4 is already having to make new shader versions to fit with Genesis anyway, so the present is as good a time as any. Too bad they couldn't just organize them in the same order to begin with for all figures...

    I'm fairly certain that, if the multi-shader being loaded has more shaders within that the receiving figure has zones, the extra shaders are added to the shader tab. Obviously, they do not get added to the figure.

    You know, I personally wouldn't mind the "Go For It!" decision - simply because I have no difficulty using incompatible multi-shaders, and sorting them through on my own. This really is a tough call - but .... Argh!!!The extra shaders, on the bottom of the list, are not added to the figure. So if you have 27 material zones on your figure but 29 sub shaders in your shader, the last two are not applied. IIRC, on a V4 shader eye surface is fifth, and eyesocket (which is also missing on Genesis) is 13? I should probably look. :) But the point is that even if the list had the same order, just removing two from the middle causes every shader below them to be wrong.

    LOL. Welcome to our world. :)

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Dartanbeck said:
    So is Fast Mip Map the culprit or are the maps off slightly?

    EDIT:
    Well - not for it's intended purpose - I'm sure it looks great in DS - but someone should check - if they have DS installed.

    If you set the shading rate to 1 or the default 2, the seams are at least as obvious in DS.
Sign In or Register to comment.