Announcement

Collapse
No announcement yet.

Identical materials rendering differently?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Identical materials rendering differently?

    So I have these two materials in two separate scenes. The materials are identical in every way except one. One of them has a brighter diffuse color than the other...except it renders much much darker. I can't make sense of this. Any ideas? Check out the attached image for reference.

    Click image for larger version

Name:	VrayShaders.jpg
Views:	1
Size:	323.0 KB
ID:	876866

    Notice how the one on the right has a much darker swatch and yet it has a brighter diffuse color. All the other sections are folded up because I haven't modified any of those additional variables.

    Thanks for the help!

  • #2
    I figured it out. Linear workflow was somehow turned on in one of the scenes and affect swatches was also turned off. Once I matched my color mapping settings everything works as expected.
    Thanks!

    Comment


    • #3
      Ok, very well then

      Best regards,
      Vlado
      I only act like I know everything, Rogers.

      Comment


      • #4
        I typically recommend to never use linear workflow checkbox unless your entire pipeline/work methods are based around it. If you try ti mix them together it will surely fail
        Dmitry Vinnik
        Silhouette Images Inc.
        ShowReel:
        https://www.youtube.com/watch?v=qxSJlvSwAhA
        https://www.linkedin.com/in/dmitry-v...-identity-name

        Comment


        • #5
          Yeah, the problem is as of the last version of vray we were using, there was no file format we could use to output files that could be read in 32 bits (or 16) on Autodesk's flame.

          EXRs are really fussy and basically don't work on a flame.
          TGA aren't 32bit or even 16bit really.
          TIFs that vray outputs aren't interleaved and so they aren't even recognized on a flame.

          So we don't really have a workflow together right now that works with higher bit depth images.
          We don't mix them. We usually just don't have it turned on at all.

          Comment


          • #6
            why not render exrs and run them through a post conversion?
            Dmitry Vinnik
            Silhouette Images Inc.
            ShowReel:
            https://www.youtube.com/watch?v=qxSJlvSwAhA
            https://www.linkedin.com/in/dmitry-v...-identity-name

            Comment


            • #7
              Well, we've certainly done that before. It's just a huge pain. Especially when you're tight on time. I mean, if you have a 300 frame animation, and you render out 6 or 7 different layer passes, your're talking 1800 - 2100 frames to convert. Even at 1 second a frame that's a minimum extra 1/2 hour added conversion time.

              Like I say, we've done it before, but we're still doing a non-linear workflow at the moment until we come up with a better system.

              Comment


              • #8
                It's somewhere on the "to do" list to add an option for interleaved tiff files; we'll see how that goes.

                Best regards,
                Vlado
                I only act like I know everything, Rogers.

                Comment


                • #9
                  Originally posted by evanerichards View Post
                  Well, we've certainly done that before. It's just a huge pain. Especially when you're tight on time. I mean, if you have a 300 frame animation, and you render out 6 or 7 different layer passes, your're talking 1800 - 2100 frames to convert. Even at 1 second a frame that's a minimum extra 1/2 hour added conversion time.
                  Have you tried to interleave the two jobs?
                  You can probably use the post frame render mel/python callback to convert the current rendered frame from exr to tiffs.
                  This way the added time will be the time needed to convert the last frame.

                  /Teodor
                  V-Ray developer

                  Comment


                  • #10
                    We haven't tried that but it's worth looking into.

                    Thanks for the idea.

                    Comment

                    Working...
                    X