I’ve been trying to build my geology mod on the basis of bicubic splines. Basically bicubic splines would form the surfaces of certain geologic formations and be contiguous with adjacent splines.
My first approach was to code a bicubic spline object from scratch. Using the Example on wikipedia, I made something which was pretty nifty, but suffered from a few drawbacks. The infinite nature of Minecraft’s world generation pushed me to divide up groups of blocks into “Regions”, a 1024x1024 x:z wide area that have their own cubic splines that define a surface. Adjacent Regions were supposed to be contiguous by sharing the random values, dx,dy, and dxy information at the edges.
Not surprisingly, it didn’t work that well. Splines were created, looked nifty, but did not appear congruent with adjacent regions. An edge checker that ensured random values, dx,dy, and dxy values were shared between neighboring regions was made, and it does seem like the appropriate values are being shared.
Since I can’t find anything wrong with the edge sharing portion of the code, perhaps its best to try and find libraries that give me similar functionality? Does anyone have advice on debugging, my algorithm design, or ideas of libraries that would be useful for me?
I can’t say I have any advice as this is out of my scope of knowledge, although what I can recommend on another note would be to checkout java’s naming conventions as I’ve noticed your packaging is a little wonky. You should follow this for naming as it helps when sharing public projects (especially since you’re trying to get help). As well, I would recommend sorting the packages properly under a namespace and categories.
If you take a look at any of the sponge projects you can get an idea of what I mean by this.
the ‘namespace’ would be ‘GeometryClasses,’ generally speaking, a namespace is a spot for a name, such as packages in java… so the location of your CubicSpline class (as read by java) is GeometryClasses.CubicSpline…
In java it is a convention to:
Have all parts of a namespace, lowercase, making your above class translate to ‘geometryclasses.CubicSpline’
Start class names with an uppercase letter and any proceeding word with an uppercase letter, ‘CubicSpline’ follows this pattern
Start all namespaces with a domain name you own, inverted, for example, if I own ‘www.example.com’ then my namespaces can/should start with ‘com.example’ this convention exists to ensure every class has a unique name.
Note: If you do not own a domain name, you can always use your email, if you have the email ‘[email protected]’ the namespaces should start with com.example.someone, for example, I use my email, and all my namespaces start with ‘com.gmail.neonblue858’
So lets say we want to make this CubicSpline class fit conventions, the package could be ‘com.example.someone’ and the class could be ‘CubicSpline,’ making the fully qualified name ‘com.example.someone.CubicSpline’
Ok That makes sense and should be easy to fix. Thnkxs!
Since I’m organizing my packages by related class type, should I just put all these packages into a super package with my namespace? It seems a bit redundant and extensive to put com.ex.asdf on every package I have.
Yes, you should have such a super package. Although it may seem redundant, it serves the purpose of guaranteeing unique class name. Having two classes with the same names causes errors, and having this ‘super package’ ensures that never happens.
NOTE: Elaborating on this may be redundant at this point, sorry if that is so.
As @meguy26 pointed out here:
Class names may be something such as MyClass, but its fully qualified name is <package>.<class>, ie: ca.loganspeck.myproject.MyProjectMain (note these are completely for example purposes, naming classes MyClass etc is poor practice IMO). Following these conventions, all packages all lower-case, and all classes are upper camel case.
Think about it in regards to using third-party software. If we didn’t have namespaces, whenever there was a duplicate naming of classes it would be a conflict. This allows us to avoid this, by importing (not saying that’s the only purpose of imports) and also by using fully-qualified class names when you need to use two classes with the same name in the same code-block.
You might find it harder to navigate in your IDE with all this “package clutter”. Luckily, this has been solved in some IDEs (only experience with IntelliJ Idea and Eclipse) where you should be able to change the view to a hierarchy view.
Hierarchical Packages in Eclipse (haven’t used Eclipse since Luna, some of Mars- shouldn’t have changed).
Flatten Packages in IntelliJ Idea (IntelliJ 15.x EAR used in this picture).
Lol no problem. Its been long enough that I’m pretty sure this is a problem I gotta figure out on my own. I do have another question that people may be able to resolve but It’s probably best left for another thread.