Tiled Path Discussion

General project and community related discussions and offtopic threads.
User avatar
Odilkhan Yakubov
Posts: 208
Joined: Fri Jan 26, 2018 10:07 pm
Location: Tashkent, Uzbekistan

Tiled Path Discussion

Post by Odilkhan Yakubov »

Split from viewtopic.php?f=5&t=1185&p=14310#p14268
- B.Y.O.B.

Luxart wrote: Tue Jul 02, 2019 5:45 am Shall we remove Light groups and Tile Path, Both are rarely used and of little use.
Moreover I'm using Tiled PATH
___________________________________________________________________________
LuxCoreRender Developer for Blender
___________________________________________________________________________
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: Transitioning from VRay to LuxCoreRender

Post by FarbigeWelt »

Luxart wrote: Tue Jul 02, 2019 5:45 am Shall we remove Light groups and Tile Path, Both are rarely used and of little use.
No. I am definitely against removing those. Light groups can be very useful and tile path too. Have you ever tried to render a 8k image? Sometimes pixels cannot be replaced but with even more pixels. Especially since OIDN knows tile denoising Tile path remains until there is another solution like cheap graphic cards with not less than 16 GB and largest available VRAM block is not much less than 16 GB. ( Even Radeon VII max block seems to be 4 GB).
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Transitioning from VRay to LuxCoreRender

Post by lacilaci »

maybe we could have a sort of tiled rendering similar to tiled denoising? split frame to parts and render them one by one, for special cases of really hires images?
kintuX
Posts: 809
Joined: Wed Jan 10, 2018 2:37 am

Re: Transitioning from VRay to LuxCoreRender

Post by kintuX »

lacilaci wrote: Tue Jul 02, 2019 5:50 pm maybe we could have a sort of tiled rendering similar to tiled denoising? split frame to parts and render them one by one, for special cases of really hires images?
Special case? Did you often fall on your head when you were a kid?
Flashback from 32bits and the Y2K (round that time we switched to x64, but before using 3GB of RAM was max) large images were mostly done with help of engineers scripting or for studios who couldn't get one, with a technique known as tiled/border camera animation (rendered per frame), then stitching the shit together in PS... hopefully everything matched
but now , two decades later, for BlendLux with a pixel twitch... yeah, have a go using your hardened head
sorry, just can't believe there are minds & characters having a limbo through a void ;) no hard feelings, i know you try hard
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Transitioning from VRay to LuxCoreRender

Post by B.Y.O.B. »

kintuX wrote: Tue Jul 02, 2019 9:32 pm Did you often fall on your head when you were a kid?
Make your point without resorting to personal insults.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Transitioning from VRay to LuxCoreRender

Post by lacilaci »

kintuX wrote: Tue Jul 02, 2019 9:32 pm
lacilaci wrote: Tue Jul 02, 2019 5:50 pm maybe we could have a sort of tiled rendering similar to tiled denoising? split frame to parts and render them one by one, for special cases of really hires images?
Special case? Did you often fall on your head when you were a kid?
Flashback from 32bits and the Y2K (round that time we switched to x64, but before using 3GB of RAM was max) large images were mostly done with help of engineers scripting or for studios who couldn't get one, with a technique known as tiled/border camera animation (rendered per frame), then stitching the shit together in PS... hopefully everything matched
but now , two decades later, for BlendLux with a pixel twitch... yeah, have a go using your hardened head
sorry, just can't believe there are minds & characters having a limbo through a void ;) no hard feelings, i know you try hard
Backburner for 3ds max has this feature, but rather than tiles it splits render to horizontal stripes. These can be rendered on different workstations or individually one after another and backburner then does the stitching. People use this even with corona when they do very large fine prints. So I don't understand what's your point.
marcatore
Donor
Donor
Posts: 463
Joined: Wed Jan 10, 2018 8:04 am

Re: Transitioning from VRay to LuxCoreRender

Post by marcatore »

I know it's another render engine but I think it's worth to share this

https://forums.chaosgroup.com/forum/v-r ... s-analysis

So, from my POV is difficult to say that tiled rendering is now useless.
Another point is, in terms of development efficiency, to decide one solution instead of another erasing the need to develop two systems in the same time.
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: Transitioning from VRay to LuxCoreRender

Post by FarbigeWelt »

lacilaci wrote: Tue Jul 02, 2019 5:50 pm maybe we could have a sort of tiled rendering similar to tiled denoising? split frame to parts and render them one by one, for special cases of really hires images?
EDIT: correction of Bytes per pixel

Code: Select all

						R, G, B			total
					[Bytes]	Channels	[Bytes]	[Bytes]
CHANNEL_RADIANCE_PER_PIXEL_NORMALIZED	4	3		12	
CHANNEL_RADIANCE_PER_SCREEN_NORMALIZED	3	3		9	
CHANNEL_ALPHA				2	1		2	23
Calculating with 11 Bytes per pixel one get

Code: Select all

			23			
	[GB]		[Bytes]		[Pixel]		[Pixel]	[Pixel]
2k	0.044417381	4.77E+07	2.07E+06	1920	1080
4k	0.177669525	1.91E+08	8.29E+06	3840	2160
8k	0.710678101	7.63E+08	3.32E+07	7680	4320
16k	2.84E+00	3.05E+09	1.33E+08	15360	8640
I guess resolution of the image is not the main reason a render fits not into VRAM. For a 16K you save about 2.9 GB if you do e.g. horizontal rendering but this would have a big backside you would loose stochastic 2D distribution of this means a stripe requires a height of at least 8 pixels but then you loose at least 2 pixels, better is a height of 64 to 256, minus 2 times 2 pixels to warrant stochastic 2D distribution. In many cases 2.9 GB to free could save a project. If one takes in account that LuxCoreRender supports many AOV, each adding more Bytes per pixel with at least up to 81 Bytes per pixel (including the standard 23) then 8K rendering could also lead to running out of VRAM.

On a larger scale efficient textures and objects (very high polygons) handling regarding memory usage, packing, swapping to RAM, pipelining (not all textures are used simultaneously for calculations), kernel swapping and so on could improve memory management even to the point where render jobs can be distributed to several GPU of different types. This way leads directly to a network management renderer and to what I think would be a welcome solution for real production needs, e.g. high resolution animations or supremes 16k stills.
Last edited by FarbigeWelt on Wed Jul 03, 2019 10:37 am, edited 10 times in total.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Tiled Path Discussion

Post by B.Y.O.B. »

FarbigeWelt wrote: Wed Jul 03, 2019 7:42 am Calculating with 11 Bytes per pixel
How do you arrive at 11 Bytes per pixel?
If I just assume 3 floats per pixel, I get sizeof(float) * 3 = 4 * 3 = 12 Bytes per pixel.

However, in production scenes it is rare to render without any AOVs.
You can see the size of each AOV here (scroll down a bit): https://wiki.luxcorerender.org/LuxCore_ ... ka_AOVs.29
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: Tiled Path Discussion

Post by FarbigeWelt »

B.Y.O.B. wrote: Wed Jul 03, 2019 9:07 am
FarbigeWelt wrote: Wed Jul 03, 2019 7:42 am Calculating with 11 Bytes per pixel
How do you arrive at 11 Bytes per pixel?
If I just assume 3 floats per pixel, I get sizeof(float) * 3 = 4 * 3 = 12 Bytes per pixel.

However, in production scenes it is rare to render without any AOVs.
You can see the size of each AOV here (scroll down a bit): https://wiki.luxcorerender.org/LuxCore_ ... ka_AOVs.29
My apologies, was not awake enough this morning. I calculated with 1 Byte per color instead of 4 Bytes. What leads to 44 Bytes per pixel instead of 11 (RGB, alpha, and others, wrongly calculated with 1 Byte).
I will correct my former post soon considering your linked information.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
Post Reply