kidoman / rays Goto Github PK

Currently, we get different field of view (FOV) image when we set -width and -height. So when increase resolution, almost all rays go straight to sky or ground. And amount of computation is not increase properly.

Following change resolve this problem :

// original
dir := t.Scale(-1)
    .Add(
        a.Scale(rnd(seed) + float64(x))
        .Add(b.Scale(float64(r) + rnd(seed)))
        .Add(c)
        .Scale(16)
    ).Normalize()

// modified
dir := t.Scale(-1)
    .Add(
        a.Scale(rnd(seed) + float64(x*512) / float64(*width))
        .Add(b.Scale(float64(r*512) / float64(*height) + rnd(seed)))
        .Add(c)
        .Scale(16)
    ).Normalize()

This solution make different problem

• Break compatibility with old benchmarks
• Break aspect ratio

I haven't investigated this much, but I think the last pass of cleanup seems to have broken the Go version.

Reverting around Line 137 fixes it for me.

Using Clang from LLVM toolchain may yield different results which should be used instead if it turns out to be faster.

C++ = min( clang , gcc )

In the Java code there are a lot of ThreadLocalRandom.current().nextFloat() calls. Random float number generation is quite slow in general. If this is used a lot in the loops it may create a bottleneck.

So Instead, creating a large global random number array beforehand and use the values afterwards would be faster. According to my not-so-reliable test it is around 7-8 times faster than ThreadLocalRandom nextFloat(). Below is an example class for this. Probably using this one instance per thread is a good idea. This can apply to all languages.

Of course this is not exactly random so it may not work at all. But it still may worth a shot when look-up is large enough (hundreds of thousands?).

something like

public class RandomFloatSequence {

    public final int size;
    private float[] data;
    private int sequence; 

    public RandomFloatSequence(int size) {
        this.size = size;
        data = new float[size];
        Random r = new Random();
        for (int i = 0; i < data.length; i++) {
            data[i] = r.nextFloat();
        }
    }

    public float getNext() {
        sequence++;
        if (sequence == size)
            sequence = 0;
        return data[sequence];
    }
}

(This issue is also related to @tkalbitz's PR #13)

In bc029c5, @kid0m4n has changed lazy computation for bounce. I think this project is not a serious optimization contest, so this change itself is okay.

But should we write more strict code ? I'm confusing about following things:

• This unoptimization seems opposite to "Why optimize the base algorithm?" section in readme.md
• This (not) ''making it easy for "not so good" compilers to play catch'' principle leads to further unoptimizations
  • For example: Series of p33 to Math.Pow(p, 99)

Example: Go's case

Things to ponder about:

• Accommodate platforms/runtimes which have a non-insignificant startup time
• Compare different compilers available for languages like C/C++
• Publish these results in way so that we can see trends occurring
• Automated runs?

We can see many black dot in highlights. This is caused by overflow. We should implement proper pixel format conversion.

Maybe clamp to [0,255] is enough for this project.