Artifacts when rendering a cubic map by hand, supporting lux in a cool tool :)

[juangea]

HI there.

First I want to show you this: Layama (a new tool) is getting LuxCore support, I'm implementing it myself in the addon just because I want Lux to get more attention and support, my implementation will be included in the official addon when I finish it

https://bone-studio.com/bs_360L4/

The cool thing about this is that it creates a "virtual walk" in the style of "Google Street View" without effort, in a very automatic way, and it's getting support for Max (Corona, Vray) and Blender (Cycles, LuxCore)

But it can work only with Cube maps, in Corona you can do a cube render, and this has the leverage that the GI Cache don't have trouble with the different angles, in Blender what is done is to automate the cubic map rendering process, so it's one render per face of the cubemap, but in Lux there is a problem, check this image:

As you can see the stich between faces of the cube map are visible, and I think it's because of the GI Cache, since they are different renders the Cache is different each time, so it delivers a slightly different result, it's my suspicion.

Then this technique is not usable, the other technique would be tu use equirectangular rendering process, but this has a big caveat, that is that with the render each camera needs to extract the Visible render (the Image or Denoised pass) and the DEPTH and GEOMETRY_NORMAL in EXR, and this makes very difficult to post-process the output render to convert it into a cubic map in a efficient way.

The most optimal solution to this would be to have a cube map rendering process like in Corona, I'm not sure how difficult could it be to implement, I see it as an extra step after an equirectangular render to get the output image as a cubic map, that could be one option, the other option would be to have a new camera projection type that really renders everything as a cubic map, like in Corona.

I'll leave the link to the corona documentation regarding the cubic map info, right now I'm referring to what is named "Single cubemap panorama - correct 6:1 aspect ratio" in this link:

https://coronarenderer.freshdesk.com/su ... fferent-as

I think this could be great for Lux, because it would be compatible right away with one very interesting tool for ArchViz, again, not sure how hard could this be.

[Dade]

As you can see the stich between faces of the cube map are visible, and I think it's because of the GI Cache, since they are different renders the Cache is different each time, so it delivers a slightly different result, it's my suspicion.

I think if you use persistent cache, the problem should go away:

1) create the PGI cache using a environment camera (so all the environment is visible and filled with cache entries).

2) render the cube map faces using the created persistent cache.

Indeed, the right solution would be to add the support for a new cube map camera but it is more complex to do.

[juangea]

Interesting, the persistent cache could be fine, it's not a big problem unless we need a different PGI for each camera, because this renders all the cube maps at the same time, but with what you describe I imagine that it won't be a problem.

How can I enable the environment camera?

EDIT: I only see options to have Perspective, Ortographic and Panoramic, no clue on where can I enable an environment camera to generate the PGI cache.
If the environment camera you refer is the panoramic camera, then if the PGI can be additive it could be enough, but if it's exclusive for each camera, it's not a workaround, because we have to render between 45 to 75 positions (each position is a 360 camera) for this to work correctly, so we need to have a consistent PGI along all the camera path, I have a possible solution in mind, but if you think about other one, please tell me.

Also, is there a way to enable a PGI generation option to fill all the path of a single camera with cache? I mean all the possible frames, I know Lux is not aware of animation, but what I mean is the same as an additive mode for the PGI, were we can add more cache points in the places where we don't have enough, is how we used to work with cache in the old days with mental ray, vray or corona, like for example for a fly through.

[Dade]

How can I enable the environment camera?

It is the "Panoramic" camera in BlendLuxCore.

EDIT: I only see options to have Perspective, Ortographic and Panoramic, no clue on where can I enable an environment camera to generate the PGI cache.
If the environment camera you refer is the panoramic camera, then if the PGI can be additive it could be enough, but if it's exclusive for each camera, it's not a workaround, because we have to render between 45 to 75 positions (each position is a 360 camera) for this to work correctly, so we need to have a consistent PGI along all the camera path, I have a possible solution in mind, but if you think about other one, please tell me.

Also, is there a way to enable a PGI generation option to fill all the path of a single camera with cache? I mean all the possible frames, I know Lux is not aware of animation, but what I mean is the same as an additive mode for the PGI, were we can add more cache points in the places where we don't have enough, is how we used to work with cache in the old days with mental ray, vray or corona, like for example for a fly through.

If you generate the persistent cache with a panoramic camera motion blur with 75 keys, PhotonGI cache will be generate for all 75 positions (and in between). It is a tricky way to pass to LuxCore camera animation information. Motion blur is the only kind of animation related information LuxCore can receive.

In general, it is the most efficient and optimal way to generate PhotonGI persistent cache for fly through animations.

Another possible trick is to use very long PhotonGI paths, so the light will bounce around a lot and likely cover all surfaces but it is very inefficent.

[juangea]

Ok, understood, so the trick is to use a long motion blur value, I’ll test it, thanks!

[juangea]

The results I get from this technique is a darker GI result than if I do a normal render with the cache calculated in that specific camera at that specific frame, I'm not sure if this is normal, is there any other setting I have to configure?

[Dade]

The results I get from this technique is a darker GI result than if I do a normal render with the cache calculated in that specific camera at that specific frame, I'm not sure if this is normal, is there any other setting I have to configure?

You may have to increase the max. photon count because, with 75 positions, you have to cover a lot of space but if you post a simple test scene I can check exactly what is going on.

[juangea]

Ok, I will post a scene tomorrow

Thanks!