2.0/2.1 Significant SPS loss with water

[jackjt8]

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

1.4.6beta2 water

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]

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]

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

---

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

2.0beta4

	Render Time	SPS
1.4.6beta2	2m39s	512,817
2.0beta4	6m17s	216,767

[llbit]

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]

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

[jackjt8]

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%