Distance Estimated Menger Sponge Normal Calculation

[Geometrian]

Hi,

I can raytrace Menger sponges using the distance estimator:

Code:

//http://www.fractalforums.com/ifs-iterated-function-systems/revenge-of-the-half-eaten-menger-sponge/15/
float mengersponge_de(int n, vec3 pos) { //by recursively digging a box
	float x=pos.x, y=pos.y, z=pos.z;
	x=x*0.5+0.5;y=y*0.5+0.5;z=z*0.5+0.5; //center it by changing position and scale

	float xx=abs(x-0.5)-0.5, yy=abs(y-0.5)-0.5, zz=abs(z-0.5)-0.5;
	float d1=max(xx,max(yy,zz)); //distance to the box
	float d=d1; //current computed distance
	float p=1.0;
	for (int i=1; i<=n; ++i) {
		float xa = mod(3.0*x*p,3.0);
		float ya = mod(3.0*y*p,3.0);
		float za = mod(3.0*z*p,3.0);
		p*=3.0;

		//we can also translate/rotate (xa,ya,za) without affecting the DE estimate

		float xx=0.5-abs(xa-1.5), yy=0.5-abs(ya-1.5), zz=0.5-abs(za-1.5);
		d1=min(max(xx,zz),min(max(xx,yy),max(yy,zz))) / p; //distance inside the 3 axis-aligned square tubes

		d=max(d,d1); //intersection
	}
	//return d*2.0; //the distance estimate. The *2 is because of the scaling we did at the beginning of the function
	return d;
}

. . . however, when calculating the normal:

Code:

vec3 calculate_normal(vec3 pos) {
	return -normalize(vec3(
		_DE(pos-vec_epsx) - _DE(pos+vec_epsx),
		_DE(pos-vec_epsy) - _DE(pos+vec_epsy),
		_DE(pos-vec_epsz) - _DE(pos+vec_epsz)
	));
}

. . . the calculation is not accurate for diagonal cuts (that is, any diagonal face has an inaccurate normal). For example, the above code renders the following image, showing a diagonal cut through a Menger sponge. Notice that the horizontal and vertical faces are okay, but the diagonal face is wrong:


This normal calculation works just fine for other fractals.

-G

[makc]

right, but you can't seriously expect smooth normals from code that has "min" and "max" in it

[Geometrian]

Mmmm; the above was more by way of asking, what can be changed about how the DE or normal are calculated so as to get the correct effect?

[Syntopia]

If the distance estimate is correct, I can not see why the normal calculation should fail?

If I do it, I get this:.



This was done by placing this at the end of the DE-calculation:

Code:

dist = max(dist, dot(inputPoint,normalize(cutPlaneNormal)));

[makc]

aye but your normal comes from cutting plane; what he did, I think, was using DE as if whole sponge was there.

[eiffie]

I think if he accurately put the cut plane in the DE function then he would get Syntopia's result - he doesn't show how he cut the sponge???

[Geometrian]

aye but your normal comes from cutting plane; what he did, I think, was using DE as if whole sponge was there.

Indeed.

The algorithm begins with a cube, with 3D texture coordinates defined for each vertex corresponding to the 3D position. The ray tracer shades each pixel on the cube by computing a ray from the camera through that pixel based on the texture coordinates of that point. So when the rasterizer draws a fragment with texture coordinate (1,1,1), the fragment program traces an eye ray from the camera through the virtual point (1,1,1).

To achieve cutting, I simply cut the cube. This naturally changes the texture coordinates, and thus the fractal produced.

I would like the planes to be arbitrary and unlimited in number. In particular, in order to draw with the camera inside the fractal, the cube must be clipped by the camera' near plane. It occurs to me that any such irregular normal is necessarily on the surface of the clipped cube (the ray has traveled zero distance). Yet, as far as the distance estimate is concerned, any point on the diagonal is "inside" the sponge!

It's pretty easy to just specify the surface normal of the clipped cube at each surface point, so perhaps is the distance estimator is negative, one immediately stops and uses the surface's normal?

Edit: the result of doing so is the quite lovely:

However, shadow calculation is now broken. Since points on the diagonal start "inside" (according to the distance estimator), shadow rays are automatically occluded!

[David Makin]

You simply flag the cut point as "cut to plane" (which plane or other cutting surface if necessary) and calculate the normal of the cutting surface at that point (which should be incredibly simple compared to getting a normal for the actual uncut fractal surface).

Or you don't use the DE at all and use the nearby adjacent surface point method - which is guaranteed to work whether it's a cut point or part of the fractal surface.

Anything else is only useful in the sense of artistic license

[cKleinhuis]

ehrm, people ? those star structures happen to be just the cuts through the menger spone ? interesting....

[tit_toinou]

Awesome star & cube structure ! 3D Print this !

[kram1032]

Nice cut-throughs indeed.
I wonder, can somebody come up with a direct 2D description to obtain this?

[Geometrian]

Is there a better, special way to calculate normals for the Menger Sponge in particular? I'm finding that sharp corners are incorrectly handled by the gradient calculation above.

[makc]

you would need to change DE to return direction vector instead of distance. then old DE = length of that vector, and normal = -that vector.

[tit_toinou]

I've created this model for 3D printing since nobody was doing it !



Étoile de Menger 8cm



Triangle de Menger



Losange de Menger

http://www.fractalforums.com/format-printing-and-post-production/3d-printed-cross-sections-of-the-menger-sponge/.

Nice cut-throughs indeed.
I wonder, can somebody come up with a direct 2D description to obtain this?

Why "2D" ?
I didn't use any distance estimation thing.
I created all the faces of the littles cubes and the faces intersecting with the plane. (is that what you mean by direct description ?)

[kram1032]

I simply meant, I'd like to see a purely 2-dimensional iteration formula that exactly describes the Menger Star cut.
Awesome 3Dprintables