Texture looks different in cycles and EEVEE

Support Materials and Textures
, , , ,
1

I recently downloaded a train model of the internet that came with a texture map and UV unwrapped. The train looks fine in EEVEE, however the texture looks completely different when switching to a cycles render.

Render comparison here:

[Album] imgur.com

Here is my node setup for the train:

image
image1163Ă—706 99.3 KB

Is there any solution to this issue?

2

Since they are different rendered the results may vary… this may be for example be a different lighting differently used in the differrent engines ??
( docs.blender manual 3.6 render eevee lighting )
…or any other global light…

You may have to elaborate this to get a more suited answer.

3

EEVEE is shader based (OpenGL) render engine and results never can good as Cycles.

4

Nonsense. Eevee can look as good or better. Also, that has nothing to do with the issue at hand

5

Can you post the .blend? It would help if we could experiment.

edit: A link to the original train model could also be helpful.

6

Never say never :wink:… they are initially made for different purposes… (… but all this does not help the OP ).

7

A lot of the difference in your examples is due to lighting. In Eevee Hdri’s and environment textures do not cast shadows, (only actual light objects cast shadows), in Cycles they do, it looks like your Cycles render is in the shadow of the environment lighting.

If you are using an hdri then the cycles render is in the shadow (has the sun behind the train), the Eevee render will not have that shadow.

A simple example;
Eevee;

Eevee
Eevee833Ă—550 19.6 KB

Cycles;

Cycles
Cycles1010Ă—596 36.7 KB

1 Like
8

While I hope that @DNorman’s response is adequate enough to explain why there is a difference between your scene in Eevee and Cycles, I just wanted to share a couple resources to keep in mind when working with both engines so that you can foresee and, hopefully, work around the engines’ differences.

First, here is the manual page for known Eevee limitations:
https://docs.blender.org/manual/en/latest/render/eevee/limitations.html

Second, the section on Eevee Shader Nodes in the manual lists where shaders differ in Eevee compared to their Cycles implementation:
https://docs.blender.org/manual/en/latest/render/eevee/materials/nodes_support.html#shader-nodes

Hope this helps!

9

No. I am graphic programmer, and Eevee never can look better, it is impossible. Eevee result can looks good, if it uses right, but never look better than Cycles, if Cycles does not use very bad.

10

I think it’s pointless to use terms like, “better.” These two built-in renderers are very different in their entire concept and approach, “soup to nuts.” You can, with suitable care, get very good results from either one. But, do not expect to “simply, take” a setup that is designed for one renderer and use it in the other. Because, you will indeed “design it.” You have to know how each render engine approaches the same objective, and give it what it needs.

I routinely use EEVEE because my computer overheats when I use Cycles. I’ve learned to produce "easily good enough" renders with it, and I get the work done at a reasonable pace. My goal isn’t to fool you into thinking that you are looking at a photograph. My goal is to depict something using a visually-pleasing (and, accurate) image. Which EEVEE very easily does, and fairly quickly, and without overheating anything.

It’s called: “choice!” :slight_smile:

1 Like
11

Thanks to everyone for your help.
Just clarifying some information:

  • My goal isn’t to figure out which one looks better, as I already plan on using Cycles
  • I’m trying to understand why when I’m looking in the material preview/EEVEE, it seems as though the image texture is mapped completely differently. (Look at the copper rim on the EEVEE render, which doesn’t seem to exist on the Cycles render, or at the wood on the right of the render, which looks black in Cycles)
  • After checking the UV Map, the EEVEE map seems to be the correctly mapped one.
  • I don’t think it’s just a lighting thing, because I tried doing the Cycles render with much brighter lighting on the wheel to test, and still couldn’t get it to look remotely similar.
  • The train uses a simple UV texture where all of the parts are UV mapped onto one tile image.
  • The only thing I can think might cause the problem is that I separated the train model that was originally one Mesh into all of the separate objects, however I don’t see why that would work in EEVEE and not Cycles
12

If you place a point light next to those elements, do they become visible in Eevee? If the copper and wood stay completely black even with a light directly shining on them, you will know the problem is actually in the material.

However, I am thinking it could also be because of Eevee’s lack of indirect light and accurate reflections.

1 Like
13

I’ll check when I get home, but thanks for the tip.

1 Like
14

It could be something with the recognition of the UV attribute, I remember that sometimes between eevee and cycles there are errors there. If you can, could you share a part of the model (perhaps the wheel with the error) and a texture to better see the problem?

15

Okay. I just tested it, and the problem definitely isn’t coming from the lighting.

16

Ok wait I figured it out. The metallic value on the shader was set to 0, setting it to 0.5 seems to fix the problem. Thank you everyone for your help! :slight_smile:

17

Well, something is weird here, because I don’t see why the material would react that way even as a non-metal. I would probably need to see the scene to understand.

Also, the “metallic” is usually intended to be set either to 0 or 1, not in between .

18

Try specifying the UV map to use with a UV map node. The texture coordinates node just uses the object’s active UV map by default