Kloonattu: Sat 11 Apr 2020 01:50:28 PM EEST

Havaittuja ongelmia

TestCaveSampleSpace ei kääntynyt: beforeEach():n new CavePath():ista puuttuu toinen parametri.

Lisäksi seuraava testi meni virheeseen:

TestMarchingCubes > outputsExpectedAmountOfVerticesAndIndices() FAILED
    org.opentest4j.MultipleFailuresError at TestMarchingCubes.java:55

Javadoc:n generointi kaatui virheeseen:

$ ./gradlew javadoc

> Task :javadoc FAILED
/tmp/marching-caves/src/main/java/caves/visualization/rendering/mesh/Mesh.java:51: error: reference not found
     * #Mesh(DeviceContext, CommandPool, VertexFormat, TVertex[])}.
       ^
/tmp/marching-caves/src/main/java/caves/visualization/rendering/renderpass/RenderPass.java:103: error: unknown tag: implNote
     * @implNote it would be possible to skip the recreation in the common case where image
       ^
2 errors

SimplexNoiseGenerator

Olet varmasti tietoinen, että SimplexNoise on patentoitu. OpenSimplex noise voisi olla vaihtoehto. En tiedä mikä merkitys kyseisellä patentilla on tässä tilanteessa, mutta ainakin omasta mielestäni on kiva jos pystyy jotain tekemäänsä käyttää myöhemmin muissa yhteyksissä, omaa koodia on aina helpointa lukea, ja omasta koodista näkee mitä virheitä on itse tehnyt aikaisemmin eikä tule sitten niin usein toistettua niitä.

Aika paljon näyttää tapahtuneen mikrotason optimointia tuossa SimplexNoiseGenerator -koodissa. Olisi mielenkiintoista lukea minkälaisia vaikutuksia noilla optimoinneilla on ollut kokonaisuuden kannalta.

Siellä voisi vielä ainakin rivillä 52 koodin this.pMod12[i] = (this.p[i] % 12); korvata this.pMod12[i] = this.p[i - 256]; :)
Toisaalta, mikset vain hakiessa käytä p[n & 0xff] ja pMod12[n & 0xff] ja säästä 256 alkiota (voi vaikutttaa cpu-cachen kautta performanssiinkin) :)

Tuolla SimplexNoiseGenerator:issa olevan satunnaislukugeneraattorin voisi eriyttää omaksi luokakseen, jolloin sitä voisi testata yms. Ja maagisen numeron 32 evaluate():n lopussa voisi varmaan myös laittaa vakioksi/parametriksi.

Muuta

PathGenerator luokka sisältää yhden metodin eikä yhtään luokkamuuttujaa, se voisi hyvin olla staattinen metodi.

Suppresswarningit voi sijoittaa luokkamäärityksen sijaan rivikohtaisesti, jolloin muut kuin merkityt kohdat antaa herjaa aiheesta.

Vector3 luokka voisi olla geneerinen, jolloin IntVector3 -luokkaa ei välttämättä tarvitsisi.

SpatialPathIndex voisi muuttaa abstraktiksi luokaksi, ainakin siinä vaiheessa kun kokeilet sitä toista vaihtoehtoa.

Äkkiseltään katsottuna visualisointipuoli on mukavasti jaoteltu osa-alueisiin ja kohtuu selkeästi toteutettu, ottaen huomioon kuinka työlästä Vulkanin käyttö on :)

Olisi kiva, jos generaattorin parametrisointiin voisi vaikuttaa muutenkin kuin muokkaamalla lähdekoodia, esim. komentoriviparametrein.

Olisi ollut mielenkiintoista lukea kommentti siitä, miksi on käytetty float:ia double:n sijaan luolageneraattorin puolella.

Oli oikein mielenkiintoinen projekti, ja paria testausongelmaa lukuunottamatta toimi moitteetta :) Koodissa oli muutama Java-juttu joista en ollut tietoinen (esim. var).