MRF issueshttps://gitlab.inria.fr/pacanows/MRF/-/issues2021-07-13T08:46:42+02:00https://gitlab.inria.fr/pacanows/MRF/-/issues/209Camera change behavior2021-07-13T08:46:42+02:00MURRAY DavidCamera change behaviorFrom #173 regarding the behavior when switching between multiple cameras with different sensor resolution.
# Current behavior:
The initial resolution is that of the sensor (or the user commands).
When switching camera, we keep the curre...From #173 regarding the behavior when switching between multiple cameras with different sensor resolution.
# Current behavior:
The initial resolution is that of the sensor (or the user commands).
When switching camera, we keep the current resolution.
# Alternative possible behavior:
* 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`Malia 1.1.0https://gitlab.inria.fr/pacanows/MRF/-/issues/203Automatization of adding a new Material2021-06-28T15:27:23+02:00PACANOWSKI RomainAutomatization of adding a new MaterialWrite a python Script that generates a template
- MyNewMaterial.hpp .cpp
- MyNewMaterialParser.hpp .cpp
- mynewmaterial.cu
from an XML file that describes the new material.Write a python Script that generates a template
- MyNewMaterial.hpp .cpp
- MyNewMaterialParser.hpp .cpp
- mynewmaterial.cu
from an XML file that describes the new material.Malia 1.3https://gitlab.inria.fr/pacanows/MRF/-/issues/196Better release asset management2021-07-05T15:44:43+02:00MURRAY DavidBetter release asset managementCurrent release assets directly link to artifact.
Meaning old release artifact are no longer accessible once a new version is released. Only the source code remain consistent with the version. We have two solutions here:
- remove the l...Current release assets directly link to artifact.
Meaning old release artifact are no longer accessible once a new version is released. Only the source code remain consistent with the version. We have two solutions here:
- remove the links to artifacts for older release.
- try a better management with version specific permalink as specified:
https://docs.gitlab.com/ee/user/project/releases/#permanent-links-to-release-assets
I'd recommend the later as the former does not really make sense with the concept of releases. But it may require a bit of work and planning. It should be discussed/debated when we have the time, and IF necessary.Malia 1.1.0https://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/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/152Support for Spherical Envmap2021-07-05T11:32:10+02:00PACANOWSKI RomainSupport for Spherical Envmap- Support spherical envmaps- Support spherical envmapshttps://gitlab.inria.fr/pacanows/MRF/-/issues/150How to integrate Beer Lambert LAW for some Materials?2020-04-22T22:11:42+02:00PACANOWSKI RomainHow to integrate Beer Lambert LAW for some Materials?- Fresnel glass extinction ? beer lambert ?- Fresnel glass extinction ? beer lambert ?https://gitlab.inria.fr/pacanows/MRF/-/issues/149ThinLens in OptixBackend2020-04-22T22:10:50+02:00PACANOWSKI RomainThinLens in OptixBackend- Support other cameratype -> thinlens: DOF- Support other cameratype -> thinlens: DOFhttps://gitlab.inria.fr/pacanows/MRF/-/issues/136Light transport improvememt2020-04-22T21:56:25+02:00PACANOWSKI RomainLight transport improvememt
> - Implement another light transport algorithm (only Path Tracing for now) for better caustics
> - Russian roulette instead of recursion bias ?
> - Implement another light transport algorithm (only Path Tracing for now) for better caustics
> - Russian roulette instead of recursion bias ?https://gitlab.inria.fr/pacanows/MRF/-/issues/131[Idea] RNG Number2021-02-25T09:32:03+01:00PACANOWSKI Romain[Idea] RNG NumberFrom the previous documentation
> Use libcuda to generate random numbers
> Hammersley + micro-jitter for non interactive backends (fixed number of samples) ?From the previous documentation
> Use libcuda to generate random numbers
> Hammersley + micro-jitter for non interactive backends (fixed number of samples) ?Malia 2.0https://gitlab.inria.fr/pacanows/MRF/-/issues/125Fix demo_scenes/ CONTENT2021-07-05T11:34:01+02:00PACANOWSKI RomainFix demo_scenes/ CONTENTPACANOWSKI RomainPACANOWSKI Romainhttps://gitlab.inria.fr/pacanows/MRF/-/issues/118[RGB] Add a check box for the user for iCC profile2021-07-05T11:34:53+02:00PACANOWSKI Romain[RGB] Add a check box for the user for iCC profilehttps://gitlab.inria.fr/pacanows/MRF/-/issues/116Making Malia less VERBOSE by default?2020-12-05T05:44:35+01:00PACANOWSKI RomainMaking Malia less VERBOSE by default?Currently Malia is set by default in info mode.
Should we switch to Warning mode by default but still we could output some information that are always required
Rendering Started
Rendering Completed in XXX seconds
Image saved to toto.foo...Currently Malia is set by default in info mode.
Should we switch to Warning mode by default but still we could output some information that are always required
Rendering Started
Rendering Completed in XXX seconds
Image saved to toto.foo
What do you think?https://gitlab.inria.fr/pacanows/MRF/-/issues/86Detect and handle rendering backend in Cmake2021-07-05T11:35:40+02:00MURRAY DavidDetect and handle rendering backend in CmakeTo be done after https://gitlab.inria.fr/pacanows/MRF/issues/2 and https://gitlab.inria.fr/pacanows/MRF/issues/85To be done after https://gitlab.inria.fr/pacanows/MRF/issues/2 and https://gitlab.inria.fr/pacanows/MRF/issues/85Malia 2.0https://gitlab.inria.fr/pacanows/MRF/-/issues/84port HDRSee shader2021-07-05T11:36:07+02:00MURRAY Davidport HDRSee shaderNeed to wait for https://gitlab.inria.fr/pacanows/MRF/issues/83Need to wait for https://gitlab.inria.fr/pacanows/MRF/issues/83Alban FichetAlban Fichet