2
$\begingroup$

So I have very recently began to mess around with Geometry Nodes in Blender and since my scene required the usage of a Menger Sponge Fractal, I followed a YouTube tutorial to make sure I learned some of the basics (https://www.youtube.com/watch?v=TP_PfRGnVds, this tutorial specifically if you want the reference).

It worked really nicely, the fractal worked just as intended when I originally saw it and began using it in a scene. However, when I began reviewing the fractal cubes once more when adding textures, I began to notice that in the Cycles render engine, the generated cubes creates a weird, repeating outline covering the faces. On the Eevee render engine, there is no such problem, only on Cycles.

enter image description here

Most of the Menger Sponge art I've seen online doesn't have any of these weird, shadowy outlines so I assumed that there was something I have done wrong. The first few attempts I did to try and solve it myself was to just tweak the parameters I was using in the Geometry Nodes and see what would come out of it.

enter image description here

enter image description here

The most note-worthy change that is worth talking about here is when I changed the number of vertices in the cube from 3,3,3 to 4,4,4, which ended up improving the cube's faces to some extent, removing some of the weird outlines but showcasing them in a different way instead.

enter image description here

Removing their marble texture isn't solving it, tweaking the parameters here and there doesn't seem to fully fix it and I'm more or less at a loss for what to do here now. If all else fails, I would end up using the 4,4,4 vertices version or just start from scratch with creating the fractal. But before I make that decision, I would still want to learn what went wrong here. Does anyone have an idea for what could cause this graphical oddity to only happen in Cycles but not Eevee? My on-going theory would be that the cube's faces are clipping into each other but I wouldn't have a clue on how to approach resolving that if so.

$\endgroup$

1 Answer 1

6
$\begingroup$

Well, the answer is quite simple since you made a deviation from the tutorial. The different appearance in Cycles and EEVEE is a result from the Z-fighting caused by overlapping geometry, which is less (or no) problem when rendering in EEVEE.

The overlapping geometry comes from the fact that while in the tutorial they use a Mesh > Primitives > Cube node as input for the first custom instancing nodegroup, you are using the Group Input which I assume feeds the default cube object into the instancing group.

nodetree comparison

Now those are both simple cubes made of 8 corner vertices, however the default cube has a size (edge length) of 2 m, while the cube in the tutorial is set to a size of 1.5 m on all axes.

If you now look at the instancing group setup, they use a cube size of 1 m with three vertices on all axes as base for instancing on points. So you have three vertices per 1 m, one at each end and one in the center making the distance between them 0.5 m.

The instances are getting scaled down to 1/3 of their original size. This means, if you instance a cube with a size of 1.5 m it will be scaled down to 1.5 m / 3 = 0.5 m, which is the distance between the points of the base cube.

But if you take the default cube with a size of 2 m, the instances will be 2 m / 3 ≈ 0.667 m, which is more than the distance between the points and therefore they are overlapping. Of course your nodetree would also work if the cube you get from the Group Input would be 1.5 m, too.

Here a visualization of what is happening:

method comparison

By the way, inside the custom nodegroup there is a Realize Instances node, I don't know why they put it there because it is not necessary for it to work. And in current versions you can of course just put this nodegroup inside a Repeat Zone and set the Iterations to the desired number instead of adding more and more nodegroups. (//EDIT: At least I found a reason for the Realize Instances node... although I was used to hear claims that instances would be less computational expensive, my computer is much more responsive when the instances are realized.)

$\endgroup$
2
  • $\begingroup$ Yep, that did it, thank you for the in-depth explanation, the cubes no longer have overlapping geometry and just require some small adjustments so there are no gaps between the cubes in the scene. $\endgroup$
    – Stormfly
    Commented Jun 12 at 14:59
  • $\begingroup$ @Stormfly When you use the same values there should be no gaps...(?) $\endgroup$ Commented Jun 12 at 15:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .