Welcome to Fractal Forums

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?

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? :D

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.

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 (http://www.fractalforums.com/index.php?topic=22598.msg88345#msg88345) 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.

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

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).

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.

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.

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


and added FudgeFactor for floor

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

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.

here? (http://www.fractalforums.com/index.php?topic=22721.msg88850#msg88850)
Not exactly understand what to do for clean aliasing  :hmh:

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

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

http://www.fractalforums.com/fragmentarium/problem-with-maps/msg89110/#msg89110

...but I don't think this will cure the aliasing  :hmh:
you are using v1.0.0
this wasn't added until v1.0.10 so after this version you should see all of the available texture parameters in the menu...

Edit->
         Insert Command->
                                      Host Preprocessor Commands

the default is no mipmaps if user has not set it in the frag as above

So i downloaded last fragmentarium and played with TexParameters. They do worse. All height-mapped area has artifacts... GL_LINEAR_MIPMAP_LINEAR, GL_LINEAR_MIPMAP_NEAREST...GL_NEAREST_MIPMAP_NEAREST... - nothind helps. Any ideas?

Added a lot of dither noise  :banginghead: :headbatting: but still aliasing  :hmh:
:help:
And another thing - in this image i used white pic with red squares. But heightmapped image has red-black-white transition (not from AO). I think that black is from dither noise. How to correctly use dithering?

for the heightmap texture I think "no mipmaps" is correct because the texture represents an object of fixed geometry, unless you are accessing the mipmap layers directly for something

the aliasing artifact I see is on the columns under the "height" pixels, someone correct me if I'm wrong on this please, this part of the image/object is generated by the heightmap frag code and would not have anything to do with how the texture is wrapped, clamped or mipmapped, but has everything to do with how the facet is calculated between height pixels. In the case of using a mipmapped texture, when reading pixels to use as a heightmap you would still see these artifacts between pixels of varying height, you just wouldn't see single pixel columns unless the texture is accesed @ 1/1 scale

the mipmap settings do exactly what they are supposed to do regarding texture rendering, left = no mipmaps, right = mipmaps

All that I understood - these texparameters have no relation to the subject.

Crist, I think we pointed out the problem earlier. Height-maps rendered within DE function will not be clean because "de = p.z + something" is not a true DE, but a rough approximation. The more height you add, the more artifacts you'll see. You'd need to go for bruteforce or other raymatching instead of DE.

I was hoping to solve the problem exactly to DE...

perhaps this issue would best be served by introducing a geometry shader instead of piling more (unnecessary) work on the fragment shader :dink:

heightmaps usage https://www.youtube.com/watch?v=v2b4yQ61lKI

I would like to users will see something like this in Fragmentarium  88)

Sounds like a way to go. I don't see a point doing 'normal' terrain in fragmentarium.

We need GLSL-guru  :D