Видео

You’re absolutely right that there are many ways to create textures, and baking details from high-poly sculpts or generating procedural maps can be effective methods. In fact, procedural textures are particularly advantageous for close-up shots because they offer virtually infinite resolution when created and rendered within the same system. This can be incredibly efficient and yield high-quality results. However, the context of my video is specifically focused on the standard, downloadable, or scanned textures available on platforms like Polyhaven, which are most commonly used by the Blender community. My point is about how these types of textures function and the most efficient way to use them. The issue I’m addressing is the common practice in many Blender tutorials where normal and displacement maps are mixed in a way that doesn’t align with how these pre-baked textures are meant to work together. While custom and procedural methods are entirely valid approaches, they fall outside the scope of the specific workflow I’m discussing.

Thanks for your input. However, I’m not entirely sure how you’re interpreting the blue channel in normal maps. In PBR (Physically Based Rendering) workflows, the blue channel typically represents the Z-direction of the normal vector and is a calculated result based on the X and Y channels. If the normal map is baked correctly, the blue channel should not contain any information that couldn’t be derived from the other two channels. The sum of these calculations must align correctly, otherwise, the map itself is faulty. Regarding your point about the domain specificity: The video and the thumbnail clearly indicate that the context here is Blender. The issue discussed is directly related to Blender’s shading and rendering process, not just baking. If you’re referring to a different software or scenario outside of Blender, that would be important to specify, as this video is strictly focused on how Blender handles these processes. As for your second point, I agree that you could bake additional details into a normal map based on the already displaced surface. However, this only makes sense if the resolution of the displacement map and the normal map differ. If both are 4K, for example, the normal map wouldn’t add significant new details if the displacement map already contains the same information. The normal map would only be beneficial if it had a higher resolution or contained finer details that weren’t captured in the displacement map. Additionally, it’s important to consider the memory impact. Adding a high-resolution normal map on top of an already high-resolution displacement map significantly increases memory usage. For example, a 4K normal map can easily take up 50 MB or more, which adds up quickly in larger projects. Regarding your example of using displacement and normal maps for metallic paint textures, that’s a valid technique. There are indeed specific cases where using a different normal map than the displacement map makes sense, especially if it’s crafted to add specific or finer details that the displacement can’t capture. It’s a valid approach, and I agree that it can work well, particularly for smoother surfaces or materials like metallic paints where normal maps can effectively control the surface’s appearance without the need for excessive geometry. In fact, for smooth or reflective surfaces, I personally prefer using normal maps over displacement maps as well, as they are more efficient and provide better control. So, I understand your example and agree that it’s a viable technique, even if it didn’t make it into the video. It’s something I’ve considered, but I ultimately decided to keep the video focused on a different approach. Thank you again for your detailed and thoughtful comment. I really appreciate the time you took to elaborate on this, and it’s great to have such an in-depth discussion on the topic.

@@cgmechanics5855 "The sum of these calculations must align correctly, otherwise, the map itself is faulty." For applications that expect the normal-vector the be of unit-length. But that is not a requirement and i have seen the channel used for various other means, including having the resulting vector not being of unit-length and needing re-scaling to 16bit floats resulting in slightly higher accuracy than would be possible with just the 2 8bit channels. It is an assumption that many programs make but as there is no one definition of normal-maps there also is no correct or wrong way as can be seen with rendering-software having different conventions for the texture-coordinates and thus textures that were designed for say Maya need to be converted to be used in 3dsmax - both autodesk-products. "Regarding your point about the domain specificity: The video and the thumbnail clearly indicate that the context here is Blender. " The title does not mention it and in the video you often make it sound as the information you presented would be of general validity (even making such claims directly). if you intended to portrait it otherwise then that really doesn't come through as such. "However, this only makes sense if the resolution of the displacement map and the normal map differ. If both are 4K, for example, the normal map wouldn’t add significant new details if the displacement map already contains the same information." No, as already mentioned if the resolution is identical then the information contained in those 2 is still different as a displacement-map does not have any normal-information at the coordinates where it has height information. As a worst-case example take a simple 4x4 texture representing stairs with 3 steps: Calculating the normals from the displacement-map would result in a perfectly flat ramp, where as a normal-map would give you a flat level surface. Combine those 2 and you would get stairsteps as now you have the information of the elevation + that at the point of that elevation the surface is level (not pretty but visible). "Adding a high-resolution normal map on top of an already high-resolution displacement map significantly increases memory usage." Sure. But that is the same for any high-resolution high-information textures you provide. A displacement-map has inherently poor surface-normal accuracy. With reflective or transparent materials normals calculated from displacement-maps lack precision and accuracy -

Thank you for your input. I acknowledge that different software and workflows might implement normal maps in varying ways, and not all adhere to the convention of unit-length vectors. The video specifically addresses the common use case seen in Blender and other PBR workflows where this assumption holds true. In those cases, the blue channel simply represents the Z-direction of the normal vector, and the expectation is that it aligns with the calculated result from the X and Y channels. I understand that this may not apply universally, but the focus was on the most frequently encountered implementation. Regarding the clarity of the context, I appreciate your feedback. I did mention Blender in the video and on the thumbnail, but I understand that it may not have been clear enough. That was not my intention, and I will update the title to make it more explicit to avoid any misunderstandings. I’ll also be more mindful of this in future videos to ensure the context and scope are clearly defined. As for your example with the staircase texture, I understand your point, and you make a valid case that there are scenarios where combining displacement and normal maps can result in specific visual effects. However, in the context of modern workflows, especially in Blender, using displacement maps at 4K or higher usually provides enough detail, even when objects are close to the camera. When the geometry is sufficiently subdivided, the stepping issue you mentioned is rarely a problem because Blender smooths these transitions automatically. The video was meant to address the use of these textures in Blender specifically, focusing on the most common applications rather than specific edge cases or other software. I could have certainly gone into more detail, but I kept the video concise due to its length limitations. I understand that there are other software, texture types, and procedural textures, as well as specific angles where both methods could face challenges. However, I’m curious to know if you would actually disagree with the examples presented in the video itself.

Thank you for your detailed comment. However, I have to disagree. When applying displacement in most modern 3D software, including Blender, the normals are always recalculated because it’s essential for correct shading. If the software didn’t recalculate the normals, it wouldn’t have the information needed to determine the height changes from the displacement accurately. This is crucial as the mid-level and the displacement height must be adjusted accordingly, which requires a calculation. Even if you use a normal map in addition to displacement, it wouldn’t fix the issue if the normals from the displacement aren’t recalculated. The software needs to know the updated surface angles to calculate the light and shading accurately. The only time something similar might happen is with parallax mapping, which isn’t true displacement, but rather a trick to simulate depth. Out of curiosity, could you specify which software or engine you are referring to that doesn’t automatically recalculate the normals when displacement is applied? This seems quite unusual, as it would be difficult to achieve accurate shading without this step.

@@cgmechanics5855 "When applying displacement in most modern 3D software" That entirely depends on the actual shading used - and mostly is only a problem with some 3D render engines that are designed for artistic image/video production. The architecture software i have used have all had options to tweak those settings - like recalculating surface-normals on tesselation, recalculating them with displacement-maps, or using the normal-maps and ignoring all other inputs. And then there is the vast world of realtime-rendering (including game-engines). "could you specify which software or engine you are referring to that doesn’t automatically recalculate the normals when displacement is applied" Maya, 3dsMax and many more have the option for that. And often it is quite useful. "as it would be difficult to achieve accurate shading without this step." Quite the opposite.

@@cgmechanics5855 I would like you to check your own video again, at 5:14 and 5:19. In your video you mark in red the region where the displacement occurs. Before the displacement happens you can see that the texture in that region is darker than the brick's color. That's a "shadow" in the texture, because, I presume, the cleaning of that texture was not very good so there is still shading information in that texture. When the displacement occurs, that's the region of the texture that is stretched, giving the impresion that a shadow is formed in that specific point, but I don't think it does. If you check other parts of the texture that are displaced (not the brick edges because all, more or less, have the same "shadow") you'll see that there is no change in shading. Could you do an experiment? Disconnect the texture from the shader and put just white color, then toggle the displacement on and off, and see what happens? Does the "white texture" gets shaded by the displacement?

Artificial generated textures can contain different informations. But baked textures like scans will always have the same data. It’s just the truth.

​@@cgmechanics5855 I agree though the title is not good. It's not like someone forbids you using them together and u may make a point for artistic choice. Also writing your own shaders in games you may use height map to displace vertices without recalculating the normals and relying on normal map for correct shading. Other uses like for parallax occlusion mapping using normal together with height is actually crucial. Nevertheless in blender using disp map u are correct it makes normal obsolete in theory

import bpy def replace_shaders_with_principled_bsdf(obj): for mat_slot in obj.material_slots: mat = mat_slot.material if mat and mat.use_nodes: nodes = mat.node_tree.nodes links = mat.node_tree.links # Désactiver le backface culling mat.use_backface_culling = False # Trouver le node Material Output output_node = None for node in nodes: if node.type == 'OUTPUT_MATERIAL': output_node = node break if output_node is None: print(f"Material {mat.name} has no output node.") continue # Conserver les noeuds Image Texture et supprimer les autres noeuds texture_nodes = [node for node in nodes if node.type == 'TEX_IMAGE'] for node in nodes: if node != output_node and node not in texture_nodes: nodes.remove(node) # Ajouter un noeud Principled BSDF principled_bsdf = nodes.new(type="ShaderNodeBsdfPrincipled") principled_bsdf.location = (-300, 0) # Définir la rugosité à 1 principled_bsdf.inputs['Roughness'].default_value = 1.0 # Lier le Principled BSDF au Material Output links.new(principled_bsdf.outputs['BSDF'], output_node.inputs['Surface']) # Ajouter et configurer un noeud Bright/Contrast bright_contrast_node = nodes.new(type="ShaderNodeBrightContrast") bright_contrast_node.location = (-600, 0) bright_contrast_node.inputs['Bright'].default_value = 0.2 # Connecter les noeuds Image Texture à la base color via le Bright/Contrast if texture_nodes: for tex_node in texture_nodes: links.new(tex_node.outputs['Color'], bright_contrast_node.inputs['Color']) links.new(bright_contrast_node.outputs['Color'], principled_bsdf.inputs['Base Color']) else: # Si aucune texture n'est trouvée, connecter la base color existante (s'il y en a une) base_color_input = principled_bsdf.inputs['Base Color'] for link in mat.node_tree.links: if link.to_node == principled_bsdf and link.to_socket == base_color_input: continue if link.to_socket.name == 'Base Color': links.new(link.from_socket, bright_contrast_node.inputs['Color']) links.new(bright_contrast_node.outputs['Color'], base_color_input) mat.node_tree.links.remove(link) # Utilisation obj = bpy.context.object # Assurez-vous de sélectionner l'objet avant d'exécuter le script replace_shaders_with_principled_bsdf(obj)

Like i'm so done with your channel best of luck and thanks for wasting so much of my time!

THANKS

Thank fucking lord. <3

check my comment

check my comment

Can this animation be overlayed in Google Earth?