calls to missing resources

[macroing]

calls to missing resources

[macroing]

The code that you are referring to in this issue, relates to an unstable API called Simplex API. It is not used by any other parts of Dayflower and needs a lot of refactoring. In the future it should not refer to any resources.

Some folders, like resources/models and resources/textures, used to be part of the repository. They were removed because of potential copyright issues.

The generated folder (including its subfolders and files) should not exist by default. The files and folders are generated by various manual tests (not unit tests).

The src/test/java folder currently contains unit tests and other manual tests. The manual tests are not intended for general use. Most of them will be removed in the future. Many of them refer to files that do not exist in the repository.

[fafayqa]

Could you, PLEASE, provide ANY really functional example package so I can wrap my head around its code?
You see: this reminds me a bit of one very old but still great Java render engine called SunFlow that several yrs ago I highly modified for my own purposes, but it simply lacks the GPU acceleration part, thus my renders take like 2+ hrs to render in FullHD.
So if I understand how this Dayflower renderer works (and I am really willing to if it actually works at all) I am thinking of replacing my old SunFlow part of my renderer app with this one but as of now I still does not even was able to test to render anything cos all I get is this:

I do not want the app itself, just its render engine to understand so I can use it, so any other additional files like possible MANUAL would be great addition, so one would actually know how to set it all up, what to send to it in what form so that it would render it etc.

Also: after I try to test the very exact code for GPU renderer you are providing here as example and creted new test class like this:

package org.dayflower;

import org.dayflower.renderer.RenderingAlgorithm;
import org.dayflower.renderer.gpu.GPURenderer;
import org.dayflower.renderer.observer.FileRendererObserver;
import org.dayflower.scene.demo.Demo;

public class GPURendererExample {

    public static void main(String[] args) {
        GPURenderer gPURenderer = new GPURenderer(new FileRendererObserver("Image.png", true, false));
        gPURenderer.setScene(Demo.createCornellBoxScene());
        gPURenderer.setImage();
        gPURenderer.setMaximumBounce(20);
        gPURenderer.setMinimumBounceRussianRoulette(5);
        gPURenderer.setRenderingAlgorithm(RenderingAlgorithm.PATH_TRACING);
        gPURenderer.setup();
        gPURenderer.render();
        gPURenderer.dispose();
    }
}

...then he image file it creates is this black white noise nothing...???

On the other hand, if I use the CPU version like this:

package org.dayflower;

import org.dayflower.renderer.RenderingAlgorithm;
import org.dayflower.renderer.cpu.CPURenderer;
import org.dayflower.renderer.observer.FileRendererObserver;
import org.dayflower.scene.demo.Demo;

public class CPURendererExample {

    public static void main(String[] args) {
        CPURenderer cPURenderer = new CPURenderer(new FileRendererObserver("Image.png", true, false));
        cPURenderer.setScene(Demo.createCornellBoxScene());
        cPURenderer.setImage();
        cPURenderer.setMaximumBounce(20);
        cPURenderer.setMinimumBounceRussianRoulette(5);
        cPURenderer.setRenderingAlgorithm(RenderingAlgorithm.PATH_TRACING);
        cPURenderer.setup();
        cPURenderer.render();
        cPURenderer.dispose();
    }
}

...it at least get rendered somewhat, tho the quality is really bad, look:

So I try to open some pre-prepared files using GPU renderer Open option, choosing file called "BullseyeMaterial.java", but after almost 40 minutes and some 800+ passes it still looks megaterribly - there is definitely something wrong here, and I cannot think of what that is, sadly.

I get no errors whatsoever and I have quite good graphics card NVIDIA GeForce RTX 3060 12GB DDR5.

Where/what is the problem here???

BTW I am on Win7 x64 SP1, 6 core CPU 3.2Ghz, 16GB DDR

When I look at the image samples you are providing here as examples I can hardly believe it was made by this engine judging from my own experience with the Dayflower so far. :-)))
Would it be that of a problem to provide the very exact project that created those image examples to have really "something" to start with that actually do work? Just asking...

Also: why in the world is there so a lot of that noise??? For instance, with that SunFlow render engine all is beautiful and smooth, no noise at all even with extremely low AA values (actually even with negative ones!).

[macroing]

When you run the application, you can open one of the .java files from resources/scenes using File > Open > CPU Renderer or File > Open > GPU Renderer. This assumes that an implementation of the Java Compiler API is present on your class-path. In Java 8 or earlier, this implementation was provided in tools.jar.

The reason the plane is not showing in the top image, might be because you're trying to add primitives dynamically while running the GPU renderer. The GPU renderer does not have support for dynamic scenes yet. This is a feature that is worked on, but will take a while to finish.

The Cornell Box scene is using a point light as light source. This is because the GPU renderer does not have support for explicit area lights yet. The "bad" look might be because the example is only rendering once per pixel (a render pass). The render() method has an overloaded method render(int). The int parameter represents the number of passes to render.

I assume the test with the example GPU renderer fails because Aparapi was not on the class-path. Aparapi is responsible for decompiling the Java bytecode into OpenCL C99 and execute it on the GPU.

[fafayqa]

Everything is setup correctly on my side of the process: all needed jars are present and correctly added, also the aparapi native .dll is correctly added and present - if it was not I assume NO GPU RENDER would start at all right? But if you look I already provided example of supposed GPU render above. Definitely no problem on my side + also that primitive was not added during the render, but beforehand, before I hit to start the render...if it would be setup incorrectly there would be errors, see also pics below (as you will notice I created myself for me different, more logical folder structure - at least from my point of view, where jars are in separate folder, not the same as the natives).

BTW in the natives folder, there is just the one for the Aparapi, right?

Also: how can one set the rendering once per pixel (a render pass) for the render() in the alplication? Not possible - why?

[macroing]

The image with the ClearCoatMaterial scene you posted above looks like that for me when I remove aparapi_x86_64.dll. Aparapi also writes a message to standard output. When the GPU renderer fails, it falls back to a CPU renderer using a Java thread pool (JTP). However, I havn't had time to fix the JTP version, which needs some changes to work. Hence the weird artifacts.

It might be that you require a 32-bit version of the .dll file. I havn't been able to compile any other version though. Does your GPU have support for double-precision?

Dayflower only has one native file, the one for Aparapi. But Aparapi has other versions for different operating systems and architectures.

The application is rendering one pass at a time, until you stop it by closing the tab.

One thing that might be good to know. If you get the GPU renderer to work, the first time it compiles will take a while. Maybe a minute or so.

[fafayqa]

In fact, I used the dll you provided in the zip file. I will try to download the original actual Aparapi, change it and will let you know if that was the case.
Also, there should definitely be an option to set definitive number of passes and not passing constantly till the app/tab is closed. Just add an int as parameter to the appropriate method (I do not know which one that is) as you did with the render and samples number.

EDIT:
I just downloaded the latest Aparapi v3.0.0 files (jar + jni), and now your import of import com.amd.aparapi.Kernel; is wrong: there is no package amd anymore, it is import com.aparapi.Kernel; now, so I guess you should update your code to the latest Aparapi version.

EDIT 2 :
So now it cannot find method fmod in file AbstractKernel.java in its code:

protected final float positiveModuloF(final float x, final float y) {
	return x < 0.0F ? fmod(fmod(x, y) + y, y) : fmod(x, y);
}

[macroing]

A couple of years ago someone forked Aparapi and created a website for it. The version you're referring to is for that fork.

Dayflower is using a fork of the original version that includes a bug fix and some new functions.

The bug fix is necessary and Dayflower would not work without it. The problem is that functions in OpenCL C99 have to be declared or implemented at a location in the source code that comes before any calls to these functions. It was fixed by adding declarations for these functions before their implementations. I could not find this fix in the latest version of Aparapi.

I did contribute some of the functions to the forked version of Aparapi, though. But that was before the bug fix.

My version of Aparapi does not have any native source code changes. So maybe you could try the .dll file found in this repository (the original Aparapi): https://github.com/aparapi/aparapi

[macroing]

Aparapi native files for Linux, Mac and the 32-bit version of Windows have been added. They have not been tested yet, though.