search

chunky-dev / chunky

A path tracer to create realistic images of your Minecraft worlds.
https://chunky-dev.github.io/docs
GNU General Public License v3.0
653 stars 77 forks source link

2.0/2.1 Significant SPS loss with water #527

Open jackjt8 opened 5 years ago

jackjt8 commented 5 years ago

Comparing the performance of Chunky 2.0beta4 vs Chunky 1.4.6beta2 performance is expectedly lower however, the extent by which water affects the SPS in 2.0beta4 is somewhat alarming.

For testing purposes, I generated two superflat worlds in both MC 1.12.2 and MC 1.13.2 and placed a single block of glowstone at 0, 6(?), 0 and two blocks of stone to provide some shadow. In Chunky I set the camera at 0, 50, 0 and -90, 0, 0; Emitters on and at 1000, postprocessing none, CPU load to 50%, and RayDepth to 25 (otherwise default settings).

I then made two renders of both the MC 1.12.2 world and MC 1.13.2 world; one without water world enabled, and one with waterworld enabled[note1]. Below are the renders and the results...

1.4.6beta2 no water superflat_1 12_nw-1024

1.4.6beta2 water superflat_1 12_w-1024

2.0beta4 no water (See s1.4.6beta2 no water)

2.0beta4 water (would take too long to fully render... stopped at 8 SPP)

Render Time SPS
1.4.6beta2 no water 3m41s 2,955,200
1.4.6beta2 water 13m51s 788,364
2.0beta4 no water 4m32s 2,408,004
2.0beta4 water ETA21h 8618

[note1] This behaviour is not exclusive to the use of water world. The loss of SPS has been observed in many different cases.

llbit commented 5 years ago

In order to handle waterlogged blocks from Minecraft 1.13, I added a separate octree for water blocks. This water octree is supposed to contain all water in the world. It seems like the water that is added by the water world rendering mode is not being placed in the water octree and that leads to severe performance problems.

jackjt8 commented 5 years ago

Would I be correct in assuming that this would also account for the various behavioural differences between the water in the water octree and water world? ie hard water colour changes, etc. and this image

However I am still seeing a loss in performance when considering Chunky 1.4.5/1.4.6beta2 water and water in 2.0beta4 ignoring the significant loss with water world enabled.

I did some additional testing with a 1.12.2 world which I duplicated and ported into 1.13.2. Some of the chunks refused to load with 2.0beta4 so I had to make a small compromise with how many chunks I loaded with both; otherwise the settings between the two match, even down to the json files themselves- With the exception of the names, path, chunklist, etc.

1.4.6beta2 1 12_por-512

2.0beta4 1 12_por_13-512

Render Time SPS
1.4.6beta2 2m39s 512,817
2.0beta4 6m17s 216,767
llbit commented 5 years ago

Would I be correct in assuming that this would also account for the various behavioural differences between the water in the water octree and water world? ie hard water colour changes, etc. and this

Yes.

The slowdown from water is probably to a large part caused by having to find ray intersections in two octrees instead of just one.

Currently the water world option fills in all chunks with a water layer then overwrites them with whatever the loaded chunks contain. I'm considering to switching to just using a water plane instead. This will lead to some undesired effects but it's simpler overall and improves rendering speed.

leMaik commented 3 years ago

@jackjt8 Given the recent performance improvements regarding water and the way water is handled in the octree… Do the numbers look better now? :thinking:

jackjt8 commented 3 years ago

Updated metrics for a 1.12.2 Amplified world while testing a 16384 Chunk / 16 Region selection. Unfortunately unable to test any of the 2.0beta builds so I am having to infer times based upon past results. I have not got results for the cost of the water plane here but it seems to be minimal.

1.4.5 2.0beta4 2.2-349 2.3
NODE NODE NODE PACKED PACKED
Render Time 275 652 est. 437 394 389
Render Time rel to 1.4.5 100% 237% est. 158% 143% 141%