Artifacts with DE rendering

[Patryk Kizny]

Hey,

I'm trying to nail down a raytracer rendering problem.
The problem is consistent across raytracers - I checked DE-Raytracer, DE-Kn2 and my versions.
I think some people already reported similar problems in other threads.
I have also deeply gone through the raytracer (de-kn2) to find any bugs, but wasn't able to fix the problem.

Have a look at a sample scene.
There's a simple plane with sin height applied.
When the amplitude is relatively low, it seems to render properly.
Wen you increase amplitude, it starts to break.

The artifacts respond mostly to tweaking fudge factor and dither.
To get a relatively clean render I need to go down really low with fudge factory, but it does not make clean image anyways.
Dither seems to affect how the artifacts look like.

I also added simple tweak in the test scene to produce some harder shapes (just rounding on the z input vector). These break the image even more.
I could suspect that normals are not calculated properly on edges, but not sure.

Do you have any ideas why all these things happen?
How can this be fixed?

[lycium]

I think the DE for the sin-plane isn't taking the displacement magnitude into account, so it needs to be scaled down.

Also lol "fudge factory", that's where Tom Cruise works right?

[Patryk Kizny]

I think the DE for the sin-plane isn't taking the displacement magnitude into account, so it needs to be scaled down.

It does not matter here in fact because I used lower values for amplitude.
You could take frequency into account to scale down amplitude, but it does not affect the rendering issue anyhow.
Once you approach amplitude to frequency ratio around 1.0 the render starts getting dirty.

[3dickulus]

I think CJR offered up a fix re:fudge factory and didder
you will have to search the threads for it yourself though

[Crist-JRoger]

I think CJR offered up a fix re:fudge factory and didder
you will have to search the threads for it yourself though

No no no ) I just fixed shadows with the same effect. Used FudgeFactor.

So the same problem was when i tried to create gnarl3D from DarkBeam's formula. Very very low FudgeFactor. This formula contains sin (or cos - don't matter) functions too.

[3dickulus]

image 2 shows artefact in shadows so... it might help

[Syntopia]

A DE must be the distance to the closest surface point on the object you are modelling (or a number less than this).

In your DE, you calculate the distance from a point to the surface directly below it (in the z-direction). This is not always the closest point (unless the surface is flat). When the magnitude increases, the probability that a nearby spike is closer also increases.

Calculating even the distance from a point to a sine curve is hard (no closed solution):
http://math.stackexchange.com/questions/514820/distance-between-point-and-sine-wave

However, in many cases you can use a coarse approximation together with a fudge factor (which will also work here, unless the variation is too fast).

[Patryk Kizny]

Mikael, many thanks for your reply. That sounds totally logical.
I started wondering what happens in other similar scenarios with height maps.
The Terrain (z.z - random noise) is prone to the same issues.
I ran a quick test with Mandelbulb and it looks like there are the same issues.

It would be interesting to find a more suitable way of flattening or bringing to earth surface some of these creatures.

[Crist-JRoger]

However, in many cases you can use a coarse approximation together with a fudge factor (which will also work here, unless the variation is too fast).

Can you show any example how it works in Fragmentarium?

[Patryk Kizny]

Can you show any example how it works in Fragmentarium?

I think that what Syntopia meant was using what we currently do as approximation.
So instead of having a proper DE we would have float DE(p) {return p.z + myfractalde}.
Which is essentially incorrect, but approximate and sufficient for smaller values.

Plus use dither and fudge to compensate.
A very low fudge factor is something like blending between DE rendering and bruteforce - i.e it increases the number of steps across the ray. Actually, I think that in some cases taking multiple constant small steps forward could be a better option both from the performance and clean results standpoint.

From my experience very low fudge factor (<0.3) dramatically increases computing time.
And there are examples with brute force method (julia quaternion) which run surprisingly fast (the power of GPU).

Perhaps a hybrid approach could be of use - i.e use DE for rough approximation say to travel 75-90% of the distance in 2-3 leaps and then switch to brute force method with a small step.

Would require serious rethinking and rewriting the raytracer (my modified version has grown very much and there's lots of calls to DE()}, but perhaps it's a good option.

[Crist-JRoger]

I played with dithering... at random, haphazard   Please correct me )

Code:

float hTextureIT(out vec3 q) {
	float dt = FDither*(rand(q.xy*(float(subframe)))/1000);

	vec2 horbittotal;
 	vec4 hcolor=vec4(0.,0.,0.,0.);	
	
	q.x+=dt;
	q.y+=dt;
	
	hcolor = texture2D(tex, htextoff+(q.xy)*htexturespeed)*hintensity;

	hcolor.w=length(hcolor.xyz);
	q+=hscale*hcolor.w;
	
	q = max(vec3(0.),q);
return q;
}

and added FudgeFactor for floor

Code:

float DEF(vec3 p) {
	float d = DE(p) ;
	if (EnableFloor) {
		floorDist = DEfloor(p)*Ffudge;
		return min(floorDist, d);
	} else {
		return d;
	}
	return d;
}

Result is not bad, but slow. And still has artifacts - parallel lines through pixel, i don't know where they from...  

[Patryk Kizny]

The aliasing issue you're having is inherent to mipmpas for textures.
Dig around, there was a thread a while ago here and 3dickulus nailed it and helped solve it.

[Crist-JRoger]

here?
Not exactly understand what to do for clean aliasing  

[Patryk Kizny]

here?
Not exactly understand what to do for clean aliasing 

The pixellated pattern you see is a result of mipmaps issue.

[Crist-JRoger]

So, what to do? When i use #TexParameter myTexture GL_TEXTURE_MIN_FILTER GL_LINEAR - nothing changes

upd.: On radeon this parameter turns off heightmapping fully