LuxCoreRender Forums

lacilaci wrote: ↑Fri Mar 22, 2019 6:57 am guys... so no one comments on the fact that logpower+photongi+multiple lights is broken but logpower is still default option!? Am I missing something here?

The problems is:

1) if the sun/sky are more important than other lights for the scene to render, logpower is the right strategy. For instance in an exterior scene where you have sun/sky + some lamp;

2) if the sun/sky are less important than other lights for the scene to render, power is the right strategy. For instance in an interior scene where you have sun/sky + some lamp;

So each is good in one case and "broken in the other.

Dade wrote: ↑Fri Mar 22, 2019 10:46 am

lacilaci wrote: ↑Fri Mar 22, 2019 6:57 am guys... so no one comments on the fact that logpower+photongi+multiple lights is broken but logpower is still default option!? Am I missing something here?

The problems is:

1) if the sun/sky are more important than other lights for the scene to render, logpower is the right strategy. For instance in an exterior scene where you have sun/sky + some lamp;

2) if the sun/sky are less important than other lights for the scene to render, power is the right strategy. For instance in an interior scene where you have sun/sky + some lamp;

So each is good in one case and "broken in the other.

If this would be just about some small performance difference it would be ok. But logpower and multiple lights create black entries in cache and this brings performance down even more almost making cache useless.

This is a terrible bug and I wonder how a new user would come to understand that the he needs to change light strategy.

This is counterintuitive and most users even dont care about some light strategy settings as you don't have a setting like this in other renderers. Either cache should be fixed for logpower or power should be default.

Here is comparison between 2 different light sources.

Top image the infinity light that is efficient to sample bright pixels and the entire light map.
Bottom is mesh emitter split in 2 objects 50% + 50% importance, 1 sun (2 triangles) and another everything else (900 triangles).
This are around 7 hour renders on CPU.

Mesh emitter starts off with working more on all the triangle lamps, you can push the gain up and have brighter shadows.
Same time it does make nice caustics when it samples the sun, but a lot of noise that wont clean up.
I have rendered the mesh emitter far longer with Classic BiDir MLT and eventually it looked like infinity lamp where the brownish skin looks yellow, shadows and blue sky get darker because i have to back up light gain (no editable reinhard tonemapper in LuxCore standalone).

Saving/resuming the rendering now includes all PhotonGI cache information and entries. This was a preliminary step to have a persistent cache on file.

Dade wrote: ↑Tue Mar 26, 2019 10:53 am Saving/resuming the rendering now includes all PhotonGI cache information and entries. This was a preliminary step to have a persistent cache on file.

nice add. anyway the current evolution in alpha 1 of 2.2 is far enough to make a new tutorial .

I added the support for persistent PhotonGI cache. If
is defined, the cache will be loaded from the file (if it exists) or saved to the file (if it doesn't). A persistent cache can be used across multiple renderings/frames only if only camera has been edited. Note: no check is possible on my side so it is up to the user/application to delete the cache file if more than a camera edit has been done.

PhotonGI creates cache entries only on visible surfaces so we still need some additional step to render animations. I have 2 solution in mind at the moment:

1) load the cache and add the additional entries now visible with the new camera position. This is a kind of incremental building solution with a normal pre-processing time for the first frame and than a small pre-processing for each frame.

2) the first time, build the cache for all animation camera positions. This is a longer pre-processing for the first frame than no pre-processing for all other frames. VRay uses this solution.

I have the strong feeling #1 may introduce flickering artifacts across frames (but it is unknown at the moment without doing tests) so I would go for #2.

It is a bit fun but #2 can be already build by rendering all the camera animation as a motion blurred camera from the first to the last frame. Other wise we can introduce some way to export camera animation.

@B.Y.O.B. how can you export camera animation from Blender ?

Dade wrote: ↑Thu Mar 28, 2019 10:32 am @B.Y.O.B. how can you export camera animation from Blender ?

I can loop through all frames and evaluate the camera matrix at each frame, then do whatever is needed with the matrices (e.g. pass to LuxCore as a list).
Basically the same as I already do for motion blur.
Does this answer your question?

Great progress, thanks for making this possible!

Dade wrote: ↑Thu Mar 28, 2019 10:32 am PhotonGI creates cache entries only on visible surfaces so we still need some additional step to render animations.

In many cases interior rendering is done in only one room, would it be possible here to disable visibility/metropolis distribution and render a cache for the complete room that then would work with any possible camera position/animation inside?

AFAIK vray has an "walkthrough" option, so it either recalculates cache per frame or incrementally adds new cache entries depending if the user wants a "walkthrough/camera only animation" or animate objects (which might need full cache recalc.)...
And I guess this could be a way of solving animation and gi cache for luxcore too, unless you know how to create a cache that can inrementally add and replace entries based on object movements (maybe related to brute force radius) in this case you could add new entries baset on camera and replace entries based on object distance changes...

B.Y.O.B. wrote: ↑Thu Mar 28, 2019 11:24 am Basically the same as I already do for motion blur.
Does this answer your question?

But can Blender switch camera, camera type, FOV, etc. during an animation ? All that kind of camera changes would not be covered by the motion blur trick