Redstone dust faces are duplicated

[leduyquang753]

When exporting a Wavefront (.obj) model, horizontal redstone dust blocks each have two identical faces at the same position, creating a classic Z-fighting situation, for example on Blender 3.1.0 (Cycles):

After removing one of the two faces rendering works properly:

(Other export formats should also be checked to see whether the issue is also present.)

[erich666]

Thanks, I'll look into it tomorrow

[erich666]

Ah, I just looked at it now. What's happening is that (similar to grass and other cutouts) these redstone objects are made double-sided by drawing the top face pointing up and the bottom face pointing down. So, two faces are formed. I guess both of these are being treated as double-sided by your renderer - I wonder why this hasn't been reported earlier.

I'll look into it more tomorrow, testing with various renderers. I may need to add a "export double-sided" option...

[erich666]

I'm trying to reproduce this problem on Blender 3.0.1 with Cycles. In Edit | Preferences I set the Cycles renderer to None, to CUDA, and to OptiX, and then hit F12 to render. I tried rendering without and with MCprep 3.3.0 applied. I always get a correct render for redstone - see below.

Is there something special you set on your end? I can't reproduce this error, so cannot figure out what I need to do on my end (add an option to Mineways, document this problem, etc.). Any help appreciated!

[leduyquang753]

I just exported with the default settings, created a new Blender 3.1.0 project based on the default template, then imported the .obj file. The issue is present without any tweaks.
I just downloaded Blender 3.0.1 and indeed the issue is not present there, so there must have been some changes to Blender.

[erich666]

Ah, thanks! I'll give this a try.

[erich666]

I cannot reproduce your error in Blender 3.1.0, which I just installed. I get the same image as above, with no z-fighting, etc. So, I think I need your output files. Could you please attach here or email me at erich@acm.org:

1. a zip file with the .obj, .mtl, and three *.png files generated by Mineways
2. a .blend file save of the scene in Blender

With these in hand I can attempt to figure out why your scene is different than my default import. If you can think of any special import settings you use, that would be a help.

[leduyquang753]

Here are the exported files and the Blender project: Blender – Duplicated faces from Mineways.zip.

I don't tweak any import settings either, everything is left to default.

[erich666]

Thanks!

If I import test.obj into Blender 3.1.0, I don't see the problem:

The cutout objects do not cast shadows properly, but the redstone is reasonable. However, I'm guessing that this might have to do with how shadows are handled and epsilons there.

Once I apply MCprep (select world's data, then "Prep Materials"), the shadows are fixed:

I do recommend applying MCprep to the model, as Blender's OBJ importer has a clear flaw (bad shadows) - I think you did so for your .blend file, but I'm not sure. If you prefer fixing shadows manually, change the Grass Material Properties, under Settings, for Shadow Mode from "Opaque" to "Alpha Hashed."

I do see the problem you found with your test.blend file:

Looking at your material settings for any of the redstone wires, they look like the MCprep material. Here is what I see with your test.blend:

This is interesting, in that it looks like the MCprep Principled BSDF material is applied, but maybe not - your textures are not blocky, as done normally with MCprep, but rather are linearly interpolated.

I had chosen OptiX for Cycles. If I pick CUDA or None, your file looks terrible in real-time:

So, it's something that is set in test.blend that I am not setting when I import your OBJ and apply MCprep to the materials.

Aha! This shows my incredible ignorance about Blender: I see that I must pick the scene and pick Cycles as the renderer. I thought I just had to set the preferences... Anyway, doing that, I get the bug!

One other thing: if I apply MCprep to your test.blend scene, it does not fix the black surface acne we both see. It does change interpolation to "closest," so I know it did something. Also, I tried playing with the near and far clip distances of the camera - no real effect. Finally, aha, it doesn't have to do with MCprep - if I turn on Cycles after just importing the OBJ file, I also see the blackness.

So, interesting - I guess Cycles requires single sided? It still hits me as weird, however. Why is there z-fighting in areas where the texture is entirely transparent, alpha == 0? And note my black areas are different than yours. So I feel like I don't fully understand the source of this bug. One fix is for me to spend tens of hours adding an option for single-sided export of cutouts. Another is to figure if there's some setting within Blender than would avoid this problem, or if this is a bug with Cycles itself.

Here's my .blend file, similar to yours, which shows the problem:

my_test_mcprep_cycles.zip

Thanks for all the help. I'm glad that I can reproduce the problem, finally. (Hey, until you wrote, I didn't know CUDA or OptiX could be chosen in Blender (and I work at NVIDIA).)

[erich666]

StandingPad on the MCprep Discord server found a fix! What you do is select the whole model, go into Edit Mode (pick it by changing Object Mode to Edit Mode in the upper left of Blender):

then press M and select merge "By Distance". The problem goes away - magic. Here's an intermediate view:

and the render on your original model:

Wow. I honestly don't understand why this merge operation (documented here) would fix this problem - I would have thought it would cause z-fighting - but this seems to work for Cycles rendering.

[erich666]

He notes:

The following Python code seems to work:
import bpy
import bmesh as bm

if bpy.context.mode != 'EDIT':
bpy.ops.object.mode_set(mode='EDIT')
bm.select_mode = {'VERT', 'EDGE', 'FACE'} # to avoid an extra refresh

bpy.ops.mesh.remove_doubles(1)

[StandingPadAnimations]

Code with indentation:

import bpy
import bmesh as bm

if bpy.context.mode != 'EDIT':
    bpy.ops.object.mode_set(mode='EDIT')
    bm.select_mode = {'VERT', 'EDGE', 'FACE'} # to avoid an extra refresh 

bpy.ops.mesh.remove_doubles(1)

[StandingPadAnimations]

I've reported it as a Blender bug: https://developer.blender.org/T96744

[erich666]

I put a fix in the code to force all redstone to export only a single rectangle. If you could, @leduyquang753, please give this beta a try and let me know if it works for you: http://www.realtimerendering.com/erich/minecraft/public/mineways/downloads/Mineways_BETA1_V914.zip

[leduyquang753]

The issue is indeed resolved with the patch.

[erich666]

Great, thanks for testing it out. I think I should look more carefully at other cutouts - rails, ladders, etc. - and see if they need the same fix before releasing a new version. Anyway, I'll consider this particular case fixed.

And, thanks again for taking the time to carefully report this problem.

[erich666]

Fixed in 9.14.