Adding an Image-based Cellular Sampler for the Image-Library addon

[ItsJuls]

Pull Request

Description

This adds an NoiseSampler "CELLULAR_IMAGE" Where the image parameters can specify the feature points to create a form of customizable Worley Noise

Changelog

Adds CellularImageSampler and its template based off CellularNoiseSampler and the other image samplers
Adds a K-D Tree utility class for it (Should be faster and more appropriate than the brute force method the cellular sampler currently uses)
Keeps all of the Cellular return types for compatibility

TODO:

• Check if it actually creates proper spot biomes/supplants Cellular noise (Currently don't know how to properly test it) Tested https://discordapp.com/channels/715448651786485780/820420254727274556/1394673432234295357
• Proper Input Parameters and changes to the image parameter (Might use a ColorSampler instead) Decided to keep the image parameter and added an alignment configuration akin to ColorSampler instead
• Performance and cache improvements to the KD Tree and how it loads the image (Need to make KD-Tree initialize first before noise function doing anything else judging from the logs) should initialize first now
• Proper testing of the sampler
• an actual default value for Lookup parameter due to the sampler being in image-library and not config-noise-function Done

Server logs with debug of the output of the sampler:
(https://mclo.gs/axT2iDq)

Checklist

Mandatory checks

• The base branch of this PR is an unreleased version branch (that has a ver/ prefix)
  or is a branch that is intended to be merged into a version branch.
• There are no already existing PRs that provide the same changes.
• The PR is within the scope of Terra (i.e. is something a configurable terrain generator should be doing).
• Changes follow the code style for this project.
• I have read the CONTRIBUTING.md
  document in the root of the git repository.

Types of changes

• Bug Fix
• Build system
• Documentation
• New Feature
• Performance
• Refactoring
• Repository
• Revert
• Style
• Tests
• Translation

Compatibility

• Introduces a breaking change
• Introduces new functionality in a backwards compatible way.
• Introduces bug fixes

Documentation

• My change requires a change to the documentation.
• I have updated the documentation accordingly.

Testing

• I have added tests to cover my changes.
• All new and existing tests passed.

Licensing

• I am the original author of this code, and I am willing to
  release it under GPLv3.
• I am not the original author of this code, but it is in public domain or
  released under GPLv3 or a compatible license.

This was tested in a modified Overworld 2.0 pack in which spot.yml was modified to have the CELLULAR_IMAGE sampler and large spot biomes have been removed from the pipeline

worldX = 4173 - 2500 = 1673
worldZ = 2500 - 348 = 2152

Spot Image in which each white pixel is a feature point(They're really tiny so you've got to zoom in)

the formula for world coords if align: CENTER

[ItsJuls]

I might have put the wrong log file at the moment but it should have outputted all the return types with valid outputs

[ItsJuls]

Also added an alignment value either NONE or CENTER

[ItsJuls]

Is there any way to get a BufferedImage out of the dfsek Image interface?

[solonovamax]

this is kinda awful tbh

why does treeFutures need to even exist at all?

there's also a probably race condition waiting to happen here.

[ItsJuls]

I've been trying to figure out how to only create the Tree once per image on pack load, as I've observed multiple instances of the sampler gets called which bogs down my server. This is jank rn and I'm trying to figure out what soluton can be done as I need some sort of check if the tree has been made already and maps to an image in an efficient way

[solonovamax]

Is there any way to get a BufferedImage out of the dfsek Image interface?

what do you need it for?

because an image can either be a real BufferedImage, or multiple images stiched together

[ItsJuls]

Ah I see. I was wondering how to extract a specific color faster from the images as I've been trying to solve 2 things

• Faster creation of KD-Tree as the selection of white pixels seems to be slower the larger the image and being called multiple times by multiple instances
• Image hashing, to only create a Tree once per image, solving No. 1 by preventing another instance from making another expensive call

[ItsJuls]

I don't know where I could put the enums, should I put it under api?

[ItsJuls]

Should we trade performance for absolute safety on startup or just let the user do their own hashing in the config? I'd be pissed if the image takes a really long time to render if it was me trying to render maps with huge images like what i'm doing

[solonovamax]

I don't know where I could put the enums, should I put it under api?

most definitely not. imo they should stay where they originally were.

[ItsJuls]

Will try to re-target this pr for 7.0 and Seismic later when I move in my apartment