Path-Tracing | Simple C # 2D Path Traced Global Illumination | GPU library

by TheNishishiro C# Version: PTGI_pre1.0_GPU License: No License

X-Ray Key Features Code Snippets Community Discussions(2)Vulnerabilities Install Support

kandi X-RAY | Path-Tracing Summary

Path-Tracing is a C# library typically used in Hardware, GPU, Unity applications. Path-Tracing has no bugs, it has no vulnerabilities and it has low support. You can download it from GitHub.

Path traced global illumination is used to illuminate the scene by sending multiple rays from pixels and bouncing them around until it hits the light source or it reaches bounce limit. The light is then calculated based on informations collected by bouncing ray. Following project tries to replicate this behaviour in order to light up a 2D environment.

Support

Quality

Security

License

Reuse

Support

Path-Tracing has a low active ecosystem.

It has 2 star(s) with 0 fork(s). There are 1 watchers for this library.

It had no major release in the last 12 months.

Path-Tracing has no issues reported. There are no pull requests.

It has a neutral sentiment in the developer community.

The latest version of Path-Tracing is PTGI_pre1.0_GPU

Quality

Path-Tracing has no bugs reported.

Security

Path-Tracing has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

License

Path-Tracing does not have a standard license declared.

Check the repository for any license declaration and review the terms closely.

Without a license, all rights are reserved, and you cannot use the library in your applications.

Reuse

Path-Tracing releases are available to install and integrate.

Installation instructions are not available. Examples and code snippets are available.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of Path-Tracing

Get all kandi verified functions for this library.

Path-Tracing Key Features

No Key Features are available at this moment for Path-Tracing.

Path-Tracing Examples and Code Snippets

No Code Snippets are available at this moment for Path-Tracing.

Community Discussions

Trending Discussions on Path-Tracing

Path tracing: how to ensure the new direction vector is a valid direction vector with respect to a BSDF?

OpenCL ray tracer works fine on CPU but not (always) on GPU

QUESTION

Path tracing: how to ensure the new direction vector is a valid direction vector with respect to a BSDF?

Asked 2021-Feb-03 at 14:36

Given the BSDF function and the Normal vector of the intersection point in world space, how can I generate a new direction vector wi that is valid? Does the method for generating valid wis change based on the BSDF?

Here's an example of what I'm thinking to do for ideal diffuse material the BSDF: I generate a new direction vector wi as points on a unit hemisphere as follow and then compute the dot product of the produced vector with the Normal vector. If the dot product result is positive the direction vector wi is valid. Otherwise I negate wi as suggested here.

Here's how I get a random wi:

...

ANSWER

Answered 2021-Feb-03 at 05:29

You are generating your wi in tangent space, with z pointing along the normal. It is neither world nor object space, and you will have to transform into world space or do all your calculations in tangent space (or shading space, they're both the same).

What you should be doing, as it will make your life much easier when doing other calculations, is to transform your wo to tangent space, and do all calculations in it. Over here, you would choose z to be your normal, and generate x and y vectors orthogonal to it.

A function for generating the coordinate system like this would be:

Source https://stackoverflow.com/questions/66021096

QUESTION

OpenCL ray tracer works fine on CPU but not (always) on GPU

Asked 2020-Oct-15 at 15:29

[Please look at the edit below, the solution to the question could simply be there]

I'm trying to learn OpenCL through the study of a small ray tracer (see the code below, from this link).

I don't have a "real" GPU, I'm currently on a macosx laptop with Intel(R) Iris(TM) Graphics 6100 graphic cards.

The code works well on the CPU but its behavior is strange on the GPU. It works (or not) depending on the number of samples per pixel (the number of rays that are shot through the pixel to get its color after propagating the rays in the scene). If I take a small number of sample (64) I can have a 1280x720 picture but if I take 128 samples I'm only able to get a smaller picture. As I understand things, the number of samples should not change anything (except for the quality of the picture of course). Is there something purely related to OpenCL/GPU that I miss ?

Moreover, it seems to be the extraction of the results from the memory of the GPU that crashes :

...

ANSWER

Answered 2020-Oct-15 at 15:29

Since your program is working correctly on CPU but not on the GPU it could mean that you are exceeding the GPU TDR (Timeout Detection and Recovery) timer.

A cause for the Abort trap:6 error when doing computations on the GPU is locking the GPU into computation mode for too much time (a common value seems to be 5 seconds but I found contradicting resources on this number). When this occurs the watchdog will forcefully stop and restart the graphic driver to prevent the screen being stuck.

There are a couple possible solutions to this problem:

Work on a headless machine

Most (if not all) OS won't enforce the TDR if no screen is attached to them

Switch GPU mode

If you are working on an Nvidia Tesla GPU you can check if it's possible to switch it to Tesla Compute Cluster mode. In this mode the TDR limit is not enforced. There may be a similar mode for AMD GPUs but I'm not sure.

Change the TDR value

This can be done under Windows by editing the TdrDelay and TdrDdiDelay registry keys under HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Control -> GraphicsDrivers with a higher value. Beware to not put a number too high or you won't be able to know if the driver has really crashed.

Also take note that graphic drivers or Windows updates may reset these values to default.

Under Linux the TDR should already be disable by default (I know it is under Ubuntu 18 and Centos 8 but I haven't tested on other versions/distros), if you have problems anyway you can add Option Interactive "0" in your Xorg config like stated in this SO question

Unfortunately I don't know (and couldn't find) a way to do this on MacOS, however I do know that this limit is not enforced on a secondary GPU if you have it installed in your MacOS system.

Split your work in smaller chunks

If you can manage to split your computation into smaller chunks you may be able to not surpass the TDR timer (E.G. 2 computations that take 4s each instead of a single 8s one), the feasibility of this depends on what your problem is and may or may not be an easy task though.

Source https://stackoverflow.com/questions/64258611

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install Path-Tracing

You can download it from GitHub.

Support

For any new features, suggestions and bugs create an issue on GitHub. If you have any questions check and ask questions on community page Stack Overflow .

Find more information at: