Mesh to Volume flip normals for mesh when exported and wrong dislpace modifier texture coordinates #82074

New Issue

Peter · 2020-10-25T21:17:13+01:00

Peter commented

2020-10-25 21:17:13 +01:00

System Information
Operating system: Linux-5.4.0-42-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-10-20 21:07, hash: 7167a57197
Worked: (newest version of Blender that worked as expected)

Short description of error

Volume Displace Modifier seems to Displace with wrong Coordinates. Displacement is not even. Looks to me like there is a problem with Coordinates used for Volume displacement.
Volume to Mesh creates a Mesh with flipped Normals.
- maybe the the first problem causes the second or vice versa.----

Exact steps for others to reproduce the error
#82074.blend

Create a cube. Set a subdiv modifier.(no mater if you apply that subdiv or not)
Create a Volume Empty.
Ad a Mesh to Volume Modifier to the Volume.
Select the Cube
Add a Volume Displace Modifier and create a new Texture.
You see the new Volume moving out of center,
Set the Mid Level for x,y and z to 0 (this centers the displace texture back from 0.5 to 0)
set the texture to maybe clouds ( this moves the texture again out of center)
set the texture back to 0.5 for mid level to 0.5 like the original setup
set the voxel amount of the volume to a higher value. 128 is enough to see the problem. (the displacement is not even).

take the setup above.

add any mesh for example a cube.(it is now Cube.001)
add a Volume to mesh modifier and select the previous created volume.
now you see the not even displacement better but anyways....

I belive that problem with flipped normals causes the problem with not even displacement... or maybe the old procedural textures cause the problem of the displacement. there is no way to setup texture coordinates for them. don know. just what i think...

**System Information** Operating system: Linux-5.4.0-42-generic-x86_64-with-debian-buster-sid 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-10-20 21:07, hash: `7167a57197` Worked: (newest version of Blender that worked as expected) **Short description of error** 1. Volume Displace Modifier seems to Displace with wrong Coordinates. Displacement is not even. Looks to me like there is a problem with Coordinates used for Volume displacement. 2. Volume to Mesh creates a Mesh with flipped Normals. - maybe the the first problem causes the second or vice versa.---- ![Volume_Bugs.jpg](https://archive.blender.org/developer/F9091589/Volume_Bugs.jpg) **Exact steps for others to reproduce the error** [#82074.blend](https://archive.blender.org/developer/F9116669/T82074.blend) - Create a cube. Set a subdiv modifier.(no mater if you apply that subdiv or not) - Create a Volume Empty. - Ad a Mesh to Volume Modifier to the Volume. - Select the Cube - Add a Volume Displace Modifier and create a new Texture. - You see the new Volume moving out of center, - Set the Mid Level for x,y and z to 0 (this centers the displace texture back from 0.5 to 0) - set the texture to maybe clouds ( this moves the texture again out of center) - set the texture back to 0.5 for mid level to 0.5 like the original setup - set the voxel amount of the volume to a higher value. 128 is enough to see the problem. (the displacement is not even). take the setup above. - add any mesh for example a cube.(it is now Cube.001) - add a Volume to mesh modifier and select the previous created volume. now you see the not even displacement better but anyways.... ``` ``` I belive that problem with flipped normals causes the problem with not even displacement... or maybe the old procedural textures cause the problem of the displacement. there is no way to setup texture coordinates for them. don know. just what i think...

Peter commented

2020-10-25 21:17:13 +01:00

Added subscriber: @PeterHahmann

Richard Antalik commented

2020-10-28 10:31:24 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Jacques Lucke commented

2020-11-03 13:31:23 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2020-11-03 13:31:23 +01:00

The texture used for displacement should not be greyscale, because the individual color channels are used as displacement in the x, y and z direction. This is just how the displacement algorithm works currently. There are alternative algorithms that can be explored in the future that can also displace in all directions based on a greyscale texture.

I can reproduce the issue with the "incorrect" normals. I'm working on that now.

The texture used for displacement should not be greyscale, because the individual color channels are used as displacement in the x, y and z direction. This is just how the displacement algorithm works currently. There are alternative algorithms that can be explored in the future that can also displace in all directions based on a greyscale texture. I can reproduce the issue with the "incorrect" normals. I'm working on that now.

blender-admin commented

2020-11-03 13:59:33 +01:00

This issue was referenced by 3c953a1b09

This issue was referenced by 3c953a1b09c9025086f38afdb60b02ba1b7d5970

Jacques Lucke commented

2020-11-03 14:01:37 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2020-11-03 14:01:37 +01:00

Jacques Lucke self-assigned this 2020-11-03 14:01:37 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Mesh to Volume flip normals for mesh when exported and wrong dislpace modifier texture coordinates #82074