cewein / nerv_pathtracer

a pathtracer with physically based rendering in mind

Nerv engine - physically based rendering

This is a 3D engine for light simulation in mind.
The goal of this engine is to implement a real-time raytraced physically based renderer with the pixar material model.

The engine use OpenGL, GLFW and GLM, but in the future we plan to remove the need of GLM.
Nerv's core is generalist and can render object in a rastered way but heavly use shaders and a single quad to make "realtime ray based application".

showcase

Depths of fields

Nerv engine status

core

• config file
• I/O for mouse and keyboard
• file reader
• windows manager

engine

• shader support
• transform controle
• FPS camera
• basic objects
• textures (kinda)
• USD loader
• GUI
• BVH
• material model
• scene descriptor

rendering

• raytracing
• reflection mat
• refraction mat
• lambert mat
• camera lens (Depths of fields)
• shadow
• light
• Pixar BSDF model
• progressive sampleling

nerv_pathtracer's Issues

Compilation under Linux and MacOS is not possible

At the moment only windows is supported.

we need to find a way to compile under linux and MacOS.

FreeLook is not working properly

Should logs file still be included in the repo ?

As of now the log file is 24 lign long. (see referenced commit)

should the still be included in the repo ?

GPU Progressive Renderer

Display refrence for the issue : 1920*1080 running at 60Fps

this would be great, sending 20 sample per pixel per frame is heavy.
Quick maths give us for a screen a total of : 2,5 GRay/s

if we allow a mode for progressive rendering only 124 MRay/s are send and one new ssp each frame, allowing better portabilty and in the end a better looking render when not moving.

Why ? because after one second, 60 ssp are process whereas the none progressive render while stay at 20 ssp no matter the number of frame who as been process.

so when not moving better switch to a progressing renderer.

No GUI

as of now, there is no GUI in the renderer. I will soon add support for ImGUI for frame counting and render time, depth of fields, ray shoot, fov.... ect

all commit that refer to this issue are related to the implementation of the GUI

Need to fix shader issue

As of now Glah.h can't be added to a header file, thus making inline function impossible and need to be fix.
Please reference this issue in commit where you try to fix the issue.

cannot load transparent texture

as of now we can't load texture with a alpha channel ? why i'm look for it. I might be related to this part of the code :

          ```
            glGenTextures(1, &(this->id));
	glBindTexture(GL_TEXTURE_2D, this->id);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

	switch (this->nbChannels)
	{
	case 3:
		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, this->width, this->height, 0, GL_RGB, GL_UNSIGNED_BYTE, data);
		break;
	case 4:
		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, this->width, this->height, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
		break;
	default:
		break;
	}
	glGenerateMipmap(GL_TEXTURE_2D);
	logger.initLog("uploaded texture to GC");
	stbi_image_free(data);
	logger.initLog("cleaned texture's data");

Better BVH

Since the rewrite of the renderer the engine had a poor acceleration structure. we should swap to a better BVH (i.e switch to a BVH-SAH).

Please refere to this issue when improving the bvh.

BVH acceleration

it's been more than a month since 2b5fb40

so here a run down of the actual state of the BVH acceleration :

• Computed on the CPU
• Flatten and sended to the GPU
• traversal is down inside the shader

normally it should boost the performance but, it doesn't. the problem is heavly worked on before touching at anything else like shadow or light because it will be a great help in the and.

as of know a bug come in when the is a interaction with the bouding boxes, on the other hand the BVH tree is ok because when doing a stack traversal the model is fully rendered.

More info will come since it the holiday and now i have time to work on it. University put a harder stop than I trough to this project.

Raytracer doesn't have throughput setup

Yes, still on it even after two years

Since now have far more experience than 2 years ago many things pop to my eyes. One is the lack of throughput of the raytracer.

This should be look into, throughput is the ability to know when a ray output color or not (i.e when energy is released or not )

This can be tackle with two variables.

camera in the shader got swaped up and front verctors

No idea why but front and up are inverted in the shader up and front are inverted but not in the raster environment.

refractoring and clean up

There is a lot of things in the path tracer as of now.
We want to add data optimisation with a bvh and also add the Pixar BSDF with his own scene loader.
but everthing is need to be clean before.

CPU code

we need to clean up every class and change the way everyting work, some name are not rigth and are missleading.
there is even some unused classes (cf frame buffer) and maybe some ugly code.
Since the BVH will take a lot of place and the scene loading too we need to improve everthing before.

Shader code

the shader is really heavy and the refractoring, and a #include.
the #include will need a bit of parsing and testing.

please reference all the commit about the cleaning.

🧹 🧹 🧹

hello!When I finished compiling, whether I was running debug or release mode, the interface was pitch black. What was the reason? The mouse couldn't move

Document the code

Self-explanatory title, Discuses about documenting the code here.

Camera shader info

To fix the problem with the camera sending the info to the shader we must use layout and not uniform with names .

In our case uniform with names need program linkage before sending the info to the shader program, thus using layout solve the problem because if we say :

in GLSL

layout (location = 10) uniform float pi

in C/C++

glUniform1f(10, 3.14f)

at the adress 10 it will always be the variable for pi and no linkage need!