MRF issueshttps://gitlab.inria.fr/pacanows/MRF/-/issues2021-02-25T09:33:39+01:00https://gitlab.inria.fr/pacanows/MRF/-/issues/190fix rgb2spec2021-02-25T09:33:39+01:00MURRAY Davidfix rgb2specThere is some fixing to do here (apparently).There is some fixing to do here (apparently).Malia 1.0 patchPACANOWSKI RomainPACANOWSKI Romainhttps://gitlab.inria.fr/pacanows/MRF/-/issues/189NVRTC error when there is no lambert2021-06-28T15:26:24+02:00MURRAY DavidNVRTC error when there is no lambertThere seems to be a NVRTC compilation error when the scene does not contain any object with a lambertian material:
[FATAL] ======> Error Message: Invalid value (Details: Function "_rtGeometryInstanceSetMaterial" caught exception: Materi...There seems to be a NVRTC compilation error when the scene does not contain any object with a lambertian material:
[FATAL] ======> Error Message: Invalid value (Details: Function "_rtGeometryInstanceSetMaterial" caught exception: Material index out of bounds 0)Malia 1.0 patchMURRAY DavidMURRAY Davidhttps://gitlab.inria.fr/pacanows/MRF/-/issues/188refactor path_ray_data2021-02-22T15:31:49+01:00MURRAY Davidrefactor path_ray_dataCurrently the PRD contains some data that is unused/may be optimized:
```cpp
struct PerRayData_pathtrace
{
mrf::spectrum::COLOR attenuation;
mrf::spectrum::COLOR result;
optix::float3 origin;
optix::float3 direction;
#ifdef MRF...Currently the PRD contains some data that is unused/may be optimized:
```cpp
struct PerRayData_pathtrace
{
mrf::spectrum::COLOR attenuation;
mrf::spectrum::COLOR result;
optix::float3 origin;
optix::float3 direction;
#ifdef MRF_RENDERING_MODE_SPECTRAL_MULTIPLEXED
float wavelength_offset;
#endif
mrf::spectrum::COLOR_B ior; // **CAN BE REMOVED (replaced by an int) USING AN ALL-IOR BUFFER**
int id_wavelength;
int backface; // **Unused**
unsigned int seed;
unsigned int num_sample;
optix::float2 offset_sampling; //cranley patterson
int depth;
bool countEmitted;
bool done;
bool is_inside;
int shadow_catcher;
};
```
The `mrf::spectrum::COLOR_B ior;` is heavy and not really fully used. A better solution is to build a buffer containing all IORs (eta+kappa) and only store a indexed reference in the PRD. That implies additionnal "permanent" storage for the buffer but grealty reduces the memory bandwith usage for the PRD, which all thing considered, should significantly make the additionnal storage worth it.
Using such a buffer would also be useful for medium tracking, to store index of previous/futur medium in a memory friendly way.Malia 1.1.0MURRAY DavidMURRAY Davidhttps://gitlab.inria.fr/pacanows/MRF/-/issues/187Clean CI2021-01-19T17:50:40+01:00Alban FichetClean CINot strictly critical by a regular waste of time: CI is currently a mess (at least for me). When a runner stop working, I do not know which one it is.
I would suggest we restart from scratch:
- Refactor tags (win10, vs2017) (win10, vs20...Not strictly critical by a regular waste of time: CI is currently a mess (at least for me). When a runner stop working, I do not know which one it is.
I would suggest we restart from scratch:
- Refactor tags (win10, vs2017) (win10, vs2019) for Windows with relevant MSVC installed.
- Make a clear distriction between runners from BRDF explorer and runner from Malia
That said, having multiple runners with the same tags helps redundancy when one is crashed.
Proposed list of tags to characterize each runner: `os, compiler`
- `os`:
- win10
- linux (eventually distro variant in addition)
- macos
- `compiler`:
- gcc
- vs2017
- vs2019
- clang
For instance: `win10, vs2017, vs2019`, `macos, clang` or `linux, ubuntu-18-04, gcc`https://gitlab.inria.fr/pacanows/MRF/-/issues/186Bench using spf2021-01-14T11:47:51+01:00MURRAY DavidBench using spfTODO: test the impact of using "-spf" = max_samplesTODO: test the impact of using "-spf" = max_samplesMURRAY DavidMURRAY Davidhttps://gitlab.inria.fr/pacanows/MRF/-/issues/185Check multi-gpu performances2021-01-13T10:33:57+01:00MURRAY DavidCheck multi-gpu performancesProxy issue to remember to check if
https://forums.developer.nvidia.com/t/optix-6-5-multi-gpu/118375
https://forums.developer.nvidia.com/t/question-about-handling-buffers-when-using-multiple-gpus/54011
Can be useful for multi-gpu.Proxy issue to remember to check if
https://forums.developer.nvidia.com/t/optix-6-5-multi-gpu/118375
https://forums.developer.nvidia.com/t/question-about-handling-buffers-when-using-multiple-gpus/54011
Can be useful for multi-gpu.MURRAY DavidMURRAY Davidhttps://gitlab.inria.fr/pacanows/MRF/-/issues/184Malia Optix 5.1 and Gcc 8.2 on Plafrim2021-01-08T13:50:33+01:00PACANOWSKI RomainMalia Optix 5.1 and Gcc 8.2 on PlafrimTHIS is on Sirocco19 with RTX8000
Cuda 10.2
GCC 8.2.0
Execution on interactive mode
(base) [pacanows@sirocco19 bin]$ ./malia -scene scenes/demo.msf -samples 1000 -wr 380:830:10
Malia Rendering Engine Started
!!!!!!!!!!!!!!!!!!!!!!!!...THIS is on Sirocco19 with RTX8000
Cuda 10.2
GCC 8.2.0
Execution on interactive mode
(base) [pacanows@sirocco19 bin]$ ./malia -scene scenes/demo.msf -samples 1000 -wr 380:830:10
Malia Rendering Engine Started
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
WARNING:
You should always run with libnvidia-ml.so that is installed with your
NVIDIA Display Driver. By default it's installed in /usr/lib and /usr/lib64.
libnvidia-ml.so in GDK package is a stub library that is attached only for
build purposes (e.g. machine that you build your application doesn't have
to have Display Driver installed).
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[FATAL] ======> Optix EXCEPTION. SOMETHING WHEN WRONG !!!! SORRY
[FATAL] ======> Unknown error
[FATAL] ======> Optix Exception CAUGHT !!!
[FATAL] ======> Error Message: Unknown error
[FATAL] ======>
[FATAL] ======> If your error is related to Optix Library that could not be loaded
============================> DO YOU HAVE A NVIDIA CARD ???
[FATAL] ======> If you have a nvidia card CHECK YOUR DRIVER VERSIONS
(base) [pacanows@sirocco19 bin]$https://gitlab.inria.fr/pacanows/MRF/-/issues/183Malia does not compile with Optix 6.0.0 and GCC 8.2.02021-06-28T15:29:44+02:00PACANOWSKI RomainMalia does not compile with Optix 6.0.0 and GCC 8.2.0[ 88%] Building CXX object
libmrf/backends/optix/CMakeFiles/mrf_optix_spectral.dir/mrf_optix/optix_geometry_handler.cpp.o
In file included from /home/pacanows/MRF3/libmrf/backends/optix/mrf_optix/optix_material_handler.hpp:20,
...[ 88%] Building CXX object
libmrf/backends/optix/CMakeFiles/mrf_optix_spectral.dir/mrf_optix/optix_geometry_handler.cpp.o
In file included from /home/pacanows/MRF3/libmrf/backends/optix/mrf_optix/optix_material_handler.hpp:20,
from /home/pacanows/MRF3/libmrf/backends/optix/mrf_optix/optix_geometry_handler.hpp:18,
from /home/pacanows/MRF3/libmrf/backends/optix/mrf_optix/optix_geometry_handler.cpp:13:
/home/pacanows/NVIDIA-OptiX-SDK-6.0.0-linux64/include/optixu/optixpp_namespace.h: Dans l'instanciation de « optix::Handle<T>::Handle(const optix::Handle<U>&) [with U = optix::GeometryTrianglesObj; T = optix::GeometryObj] » :
/home/pacanows/MRF3/libmrf/backends/optix/mrf_optix/optix_geometry_handler.cpp:356:108: requis depuis ici
/home/pacanows/NVIDIA-OptiX-SDK-6.0.0-linux64/include/optixu/optixpp_namespace.h:109:46: error: « optix::GeometryTrianglesObj* optix::Handle<optix::GeometryTrianglesObj>::ptr » est privé dans ce contexte
Handle(const Handle<U>& copy) : ptr(copy.ptr) { ref(); }
~~~~~^~~
/home/pacanows/NVIDIA-OptiX-SDK-6.0.0-linux64/include/optixu/optixpp_namespace.h:174:8: note: déclaré privé ici
T* ptr;
^~~
/home/pacanows/NVIDIA-OptiX-SDK-6.0.0-linux64/include/optixu/optixpp_namespace.h:109:49: error: ne peut convertir « optix::GeometryTrianglesObj* const » en « optix::GeometryObj* » dans l'initialisation
Handle(const Handle<U>& copy) : ptr(copy.ptr) { ref(); }
^
make[2]: *** [libmrf/backends/optix/CMakeFiles/mrf_optix_spectral.dir/mrf_optix/optix_geometry_handler.cpp.o] Erreur 1
make[1]: *** [libmrf/backends/optix/CMakeFiles/mrf_optix_spectral.dir/all] Erreur 2Alban FichetAlban Fichethttps://gitlab.inria.fr/pacanows/MRF/-/issues/182libnrtc.so copied but missing2020-12-15T10:08:51+01:00PACANOWSKI Romainlibnrtc.so copied but missingOn master branch.
After a make install on Linux or Plafrim
- > (base) [pacanows@devel01 bin]$ ls -ailht
- > total 89M
- > 33187397 drwxr-xr-x 6 pacanows manao 4,0K 15 déc. 10:03 .
- > 33628380 lrwxrwxrwx 1 pacanows manao 18 15 dé...On master branch.
After a make install on Linux or Plafrim
- > (base) [pacanows@devel01 bin]$ ls -ailht
- > total 89M
- > 33187397 drwxr-xr-x 6 pacanows manao 4,0K 15 déc. 10:03 .
- > 33628380 lrwxrwxrwx 1 pacanows manao 18 15 déc. 10:03 liboptixu.so -> liboptixu.so.6.5.0
- > 33628378 lrwxrwxrwx 1 pacanows manao 17 15 déc. 10:03 liboptix.so -> liboptix.so.6.5.0
- > 33628377 lrwxrwxrwx 1 pacanows manao 28 15 déc. 10:03 libnvrtc-builtins.so.10.2 -> libnvrtc-builtins.so.10.2.89
- > 33628375 lrwxrwxrwx 1 pacanows manao 25 15 déc. 10:03 libnvrtc-builtins.so -> libnvrtc-builtins.so.10.2
- > 33628373 lrwxrwxrwx 1 pacanows manao 16 15 déc. 10:03 libnvrtc.so -> libnvrtc.so.10.2
---------------------------------------------------------------^
libnrtc.so is pointing to a missing library.
BUT it Malia is not using it. So why is it copied ?
> - (base) [pacanows@devel01 bin]$ ldd -v malia
> - linux-vdso.so.1 => (0x00007f3336004000)
> - liboptix.so.6.5.0 => /home/pacanows/bin/./liboptix.so.6.5.0 (0x00007f3335af4000)
> - liboptixu.so.6.5.0 => /home/pacanows/bin/./liboptixu.so.6.5.0 (0x00007f333572e000)
> - libgomp.so.1 => /cm/shared/modules/intel/skylake/compiler/gcc/9.3.0/lib64/libgomp.so.1 (0x00007f33354f8000)
> - libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f33352dc000)
> - libnvrtc.so.10.2 => /usr/local/cuda-10.2/lib64/libnvrtc.so.10.2 (0x00007f3333b2f000)Alban FichetAlban Fichethttps://gitlab.inria.fr/pacanows/MRF/-/issues/181Compilation fails with GCC 8.2.02020-12-15T10:00:49+01:00PACANOWSKI RomainCompilation fails with GCC 8.2.0> [ 13%] Building CXX object libmrf/core/CMakeFiles/mrf_core_rgb.dir/mrf/image/envi_spectral_image.cpp.o
> cd /home/pacanows/MRF3/build/libmrf/core && /usr/bin/c++ -DMRF_WITH_EIGEN_SUPPORT -I/home/pacanows/MRF3/libmrf/core -I/home/paca...> [ 13%] Building CXX object libmrf/core/CMakeFiles/mrf_core_rgb.dir/mrf/image/envi_spectral_image.cpp.o
> cd /home/pacanows/MRF3/build/libmrf/core && /usr/bin/c++ -DMRF_WITH_EIGEN_SUPPORT -I/home/pacanows/MRF3/libmrf/core -I/home/pacanows/MRF3/build/libmrf/core/mrf_rgb -I/projets/deeplayers/include/eigen3 -I/home/pacanows/MRF3/libmrf/externals/.. -O3 -DNDEBUG -Wall -Wextra -Wpedantic -fopenmp -std=gnu++1y -o CMakeFiles/mrf_core_rgb.dir/mrf/image/envi_spectral_image.cpp.o -c /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp: In lambda function:
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:502:76: erreur: no matching function for call to ‘regex_replace(std::string&, std::regex, const char [3])’
> param_value = std::regex_replace(param_value, std::regex("^ +"), "$1");
>
^
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:502:76: note: candidates are:
> In file included from /usr/include/c++/4.8.2/regex:62:0,
> from /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:12:
> /usr/include/c++/4.8.2/bits/regex.h:2162:5: note: template<class _Out_iter, class _Bi_iter, class _Rx_traits, class _Ch_type> _Out_iter std::regex_replace(_Out_iter, _Bi_iter, _Bi_iter, const std::basic_regex<_Ch_type, _Rx_traits>&, const std::basic_string<_Ch_type>&, std::regex_constants::match_flag_type)
> regex_replace(_Out_iter __out, _Bi_iter __first, _Bi_iter __last,
> ^
> /usr/include/c++/4.8.2/bits/regex.h:2162:5: note: template argument deduction/substitution failed:
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:502:76: note: deduced conflicting types for parameter ‘_Bi_iter’ (‘std::basic_regex<char>’ and ‘const char*’)
> param_value = std::regex_replace(param_value, std::regex("^ +"), "$1");
> ^
> In file included from /usr/include/c++/4.8.2/regex:62:0,
> from /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:12:
> /usr/include/c++/4.8.2/bits/regex.h:2182:5: note: template<class _Rx_traits, class _Ch_type> std::basic_string<_Ch_type> std::regex_replace(const std::basic_string<_Ch_type>&, const std::basic_regex<_Ch_type, _Rx_traits>&, const std::basic_string<_Ch_type>&, std::regex_constants::match_flag_type)
> regex_replace(const basic_string<_Ch_type>& __s,
> ^
> /usr/include/c++/4.8.2/bits/regex.h:2182:5: note: template argument deduction/substitution failed:
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:502:76: note: mismatched types ‘const std::basic_string<_Ch_type>’ and ‘const char [3]’
> param_value = std::regex_replace(param_value, std::regex("^ +"), "$1");
> ^
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp: In member function ‘mrf::image::IMAGE_LOAD_SAVE_FLAGS mrf::image::EnviSpectralImage::readHeader(std::istream&)’:
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:510:79: erreur: no matching function for call to ‘regex_replace(std::string&, std::regex, const char [3])’
> line = std::regex_replace(line, std::regex("^ +"), "$1");
>
^
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:510:79: note: candidates are:
> In file included from /usr/include/c++/4.8.2/regex:62:0,
> from /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:12:
> /usr/include/c++/4.8.2/bits/regex.h:2162:5: note: template<class _Out_iter, class _Bi_iter, class _Rx_traits, class _Ch_type> _Out_iter std::regex_replace(_Out_iter, _Bi_iter, _Bi_iter, const std::basic_regex<_Ch_type, _Rx_traits>&, const std::basic_string<_Ch_type>&, std::regex_constants::match_flag_type)
> regex_replace(_Out_iter __out, _Bi_iter __first, _Bi_iter __last,
> ^
> /usr/include/c++/4.8.2/bits/regex.h:2162:5: note: template argument deduction/substitution failed:
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:510:79: note: deduced conflicting types for parameter ‘_Bi_iter’ (‘std::basic_regex<char>’ and ‘const char*’)
> line = std::regex_replace(line, std::regex("^ +"), "$1");
> ^
> In file included from /usr/include/c++/4.8.2/regex:62:0,
> from /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:12:
> /usr/include/c++/4.8.2/bits/regex.h:2182:5: note: template<class _Rx_traits, class _Ch_type> std::basic_string<_Ch_type> std::regex_replace(const std::basic_string<_Ch_type>&, const std::basic_regex<_Ch_type, _Rx_traits>&, const std::basic_string<_Ch_type>&, std::regex_constants::match_flag_type)
> regex_replace(const basic_string<_Ch_type>& __s,
> ^
> /usr/include/c++/4.8.2/bits/regex.h:2182:5: note: template argument deduction/substitution failed:
> /home/pacanows/MRF3/libmrf/core/mrf/image/envi_spectral_image.cpp:510:79: note: mismatched types ‘const std::basic_string<_Ch_type>’ and ‘const char [3]’
> line = std::regex_replace(line, std::regex("^ +"), "$1");
> ^
> make[2]: *** [libmrf/core/CMakeFiles/mrf_core_rgb.dir/mrf/image/envi_spectral_image.cpp.o] Erreur 1
> make[2] : on quitte le répertoire « /home/pacanows/MRF3/build »
> make[1]: *** [libmrf/core/CMakeFiles/mrf_core_rgb.dir/all] Erreur 2
> make[1] : on quitte le répertoire « /home/pacanows/MRF3/build »
> make: *** [all] Erreur 2Alban FichetAlban Fichethttps://gitlab.inria.fr/pacanows/MRF/-/issues/180Performance on V100,RTX 5000, 6000, 80002021-01-13T10:35:00+01:00PACANOWSKI RomainPerformance on V100,RTX 5000, 6000, 8000Offline Rendering Benchs (on Master)
Commandline for this bench
./malia -scene scenes/demo.msf -samples 1000 -wr 380:830:10 -wpp 46 -o test.hdr -logging 3
With Cuda 10.2 and Optix 6.5.x
|Scene | RTX 5000 | Dual RTX 6000...Offline Rendering Benchs (on Master)
Commandline for this bench
./malia -scene scenes/demo.msf -samples 1000 -wr 380:830:10 -wpp 46 -o test.hdr -logging 3
With Cuda 10.2 and Optix 6.5.x
|Scene | RTX 5000 | Dual RTX 6000 | Dual RTX 8000 | Dual RTX 2080S | RTX 2080S | RTX 2080 Ti | RTX 3070 |
|-------------------| -------- | -------------- | ------------- | --------------- | --------- | ----------- | -------- |
|CornellBox Official| 87.71s | 1442s | 1642s | 54.04s | 86.35s | 62.6797s | 44.82s |
- CornellBox Official : demo.msf + demo.mcf (512x512 pixels)
- RTX5000 an dual RTX6000 : IOA Cluster with GCC 8.3
- Dual RTX8000 : on Plafrim
Probably better to launch this directly from a script!
**Bench for Branch Optix 5 With GCC 8.2.0 compiled for GPU sm_70 VOLTA**
|Scene| Dual V100 Optix 5.1.0 Cuda 10.2| Dual RTX 8000 Optix 5.1.0 Cuda 10.2 | Dual V100 Optix 6.0.0 Cuda 10.2 | Dual RTX 8000 Optix 6.0.0 Cuda 10.2
|------| ------ | ------ | ------ |------ |
|CornellBox Official | 56s | 39s| 87s | 39.8s|
RomainMURRAY DavidMURRAY Davidhttps://gitlab.inria.fr/pacanows/MRF/-/issues/179Dev build: kernels are not exported if modified2022-10-06T14:46:10+02:00MURRAY DavidDev build: kernels are not exported if modifiedWhen building target Malia/Malia_rgb, the kernels are exported only once in the build binary dir. Thus if the files in the MRF source dir are modified by the developper, they are not exported and used when running Malia.
I think we use ...When building target Malia/Malia_rgb, the kernels are exported only once in the build binary dir. Thus if the files in the MRF source dir are modified by the developper, they are not exported and used when running Malia.
I think we use something like this:
https://stackoverflow.com/questions/34799916/copy-file-from-source-directory-to-binary-directory-using-cmake
What do you think ?Alban FichetAlban Fichethttps://gitlab.inria.fr/pacanows/MRF/-/issues/178Refactor NEE& MIS2021-02-25T09:42:16+01:00MURRAY DavidRefactor NEE& MISReminder:
- NEE = Next Event Estimation;
- MIS = Multiple Importance Sampling.
Currently, our pipeline with NEE works like:
```
At each bounce:
sampleBSDFdirection
evaluateDirectLighting(light_dir)
if(MIS) evaluateDirectLighting(bsdf_...Reminder:
- NEE = Next Event Estimation;
- MIS = Multiple Importance Sampling.
Currently, our pipeline with NEE works like:
```
At each bounce:
sampleBSDFdirection
evaluateDirectLighting(light_dir)
if(MIS) evaluateDirectLighting(bsdf_dir)
propagateRay(bsdf_direction)
```
With:
```
evaluateDirectLighting(out_dir):
if(light_pdf(out_dir) <= 0) return // -> light_pdf = 0 if no intersection between the light and the direction.
shadowRay(out_dir)
if(not_in_shadow) return BSDF_value*mis_weight
```
When NEE is active, light source emission is disabled so than light are not counted on impact as there are theoretically already accounted for.
However, our current implementation sample uniformly one light source per bounce but deactivate ALL sources, even if current point is in shadow, which is a problem. Also, light sampling is currently uniform. It would probably be more efficient to use a light power-based distribution for the sampling.
Finally, I am not sure that the direct evalutation for the BSDF direction is useful as we propagate the ray with this direction in any case. Thus, we may have an extra shadow ray that seems useless.MURRAY DavidMURRAY Davidhttps://gitlab.inria.fr/pacanows/MRF/-/issues/177Handles Thin film internal reflections2021-06-28T15:31:20+02:00MURRAY DavidHandles Thin film internal reflectionsWhen using a glass defined as a thin film (modeled with only plane with a specified thickness), we only apply a simple refraction (in and out refraction), thus ommiting internal reflections (either caused by TIR or simple reflection when...When using a glass defined as a thin film (modeled with only plane with a specified thickness), we only apply a simple refraction (in and out refraction), thus ommiting internal reflections (either caused by TIR or simple reflection when the glass is not totally transmissive).
The impact of these internal reflections can be described as geometrical serie of reason:
- T x R (the transmittance T and reflection R (Fresnel) coefficients) in case we allow the transmitted ray to emerges on the same side as it entered. T x R must be applied for each traversal of the thin glass.
- (TR)² if considering the ray always emerges on the other side than the one it entered the glass. (TR)² must be applied for each back and forth traversal.
There would be two ways to correctly handle both of these scenarii:
- As the geometrical serie converges, we can use its limits as the effective transmission rate. In this case, we would not simulate any "physical" lateral shift, despite accounting for it in the transmission rate. That is to say, the ray will always emerge at the same point for a given incoming direction.
- We can sample the number of internal reflections occuring, and thus shift the emerging point accordingly. The transmission rate is also straightforward as it still is a geometrical serie.
Note that these two approach can also be applied to a reflection occuring at the entry point. Currently at this point, we either apply a reflection (using only the R fresnel coefficient) or a simple refraction (T coefficient). We could also account for a "reflection" being the results of internal reflections followed by a refraction on the entry point side.
In my opinion, sampling the number of internal events to allow for a physical shift and an exact transmission/reflection rate may be more accurate for the propagation of the ray. However it is obviously more computationally heavy than always using the limit of the serie without shift. We can also implement both solutions and use either one on demand ?
EDIT: corrected "fresnel transmission T" by "transmittance T", the latter was I thought about when writing this. The serie reason is the fresnel refecletion coefficient R time the amount of absorption along a traversal (aka, transmittance T here equivalent to beer-lambert).Malia 1.1.0PACANOWSKI RomainPACANOWSKI Romainhttps://gitlab.inria.fr/pacanows/MRF/-/issues/176Blender bridge creation probably fails2022-10-06T14:46:11+02:00Alban FichetBlender bridge creation probably failsFile hierarchy changed in MRF. Blender bridge creation script cannot locate .cu for instance.
Shall probably be generated threw the `CMakeLists.txt` in the future.
https://gitlab.inria.fr/pacanows/MRF/-/jobs/858965#L1761File hierarchy changed in MRF. Blender bridge creation script cannot locate .cu for instance.
Shall probably be generated threw the `CMakeLists.txt` in the future.
https://gitlab.inria.fr/pacanows/MRF/-/jobs/858965#L1761Malia 1.0.0 Beta 1https://gitlab.inria.fr/pacanows/MRF/-/issues/175Support for ANalytical IOR2021-07-05T11:29:17+02:00PACANOWSKI RomainSupport for ANalytical IORMalia 1.1.0https://gitlab.inria.fr/pacanows/MRF/-/issues/174Hosek Wilkie sky model2020-12-04T00:08:09+01:00Alban FichetHosek Wilkie sky modelAdd an Hosek Wilkie sky model to the environment map collection.
Convey incredible realism to even simple scenes.
https://www.shadertoy.com/view/3ddBD8 (here in RGB without any turbidity nor albedo stuff, full code is available with th...Add an Hosek Wilkie sky model to the environment map collection.
Convey incredible realism to even simple scenes.
https://www.shadertoy.com/view/3ddBD8 (here in RGB without any turbidity nor albedo stuff, full code is available with the paper here: https://cgg.mff.cuni.cz/projects/SkylightModelling/ )Malia 1.1.0https://gitlab.inria.fr/pacanows/MRF/-/issues/173Malia GUI camera change & resize2021-07-12T18:59:05+02:00Alban FichetMalia GUI camera change & resize![Screenshot_from_2020-11-04_23-54-51](/uploads/37b0cdb49f91c24c0ee74196bdb5cd29/Screenshot_from_2020-11-04_23-54-51.png)
To reproduce this,
1. Open Malia in interactive mode with a scene
2. Maximize the window
3. Change the camera
Is...![Screenshot_from_2020-11-04_23-54-51](/uploads/37b0cdb49f91c24c0ee74196bdb5cd29/Screenshot_from_2020-11-04_23-54-51.png)
To reproduce this,
1. Open Malia in interactive mode with a scene
2. Maximize the window
3. Change the camera
Is that an expected behaviour?
Alternative possible behaviour:
- Have a flag `_user_specified_window_size` set to `false` when the scene is loaded
- Set this flag to `true` when the user resize the window
- When changing camera:
- Change the window size if the flag is set to `false`
- Change the sensor size to fit the viewport if the flag is set to `true`
A bit overkill though...Malia 1.0 patchMURRAY DavidMURRAY Davidhttps://gitlab.inria.fr/pacanows/MRF/-/issues/172Fix epsilon / ray offset after a bounce2021-02-25T09:44:17+01:00Alban FichetFix epsilon / ray offset after a bounceCreating an issue to remind us to fix that after our discussion.
For the record, the current state creates some visible artifacts:
![cornellbox_official_bug](/uploads/afa7567da04c0b8f3d01068e50eca4ff/cornellbox_official_bug.png)
(top ...Creating an issue to remind us to fix that after our discussion.
For the record, the current state creates some visible artifacts:
![cornellbox_official_bug](/uploads/afa7567da04c0b8f3d01068e50eca4ff/cornellbox_official_bug.png)
(top of the Cornell box)
Increasing the epsilon fixes the problem but not necessary the best solution. We have to discuss that.Malia 1.0 patchhttps://gitlab.inria.fr/pacanows/MRF/-/issues/171Infinite loop argument parsing2022-10-06T14:46:10+02:00Alban FichetInfinite loop argument parsingNot sure if that happen on other executables but, this gives me an infinite error message displayed:
```
malia -i -i
```Not sure if that happen on other executables but, this gives me an infinite error message displayed:
```
malia -i -i
```