xrayez / godot-anl Goto Github PK

Module version:
2.1

Issue description:
It would be nice to quickly experiment with various noise parameters through so called mutation where each parameter gets slightly modified to produce similar yet different result.

Possible features:

• restrict mutation to nodes that are not locked
• allow to set mutation amplitude for each parameter (?)

The module uses C++11 features. Compiler spits some errors despite -std=c++11 flag enabled:

modules/anl/libs/anl/Expression/expressionbuilder.cpp:129:44: error: no member named 'stod' in namespace 'std'
            stk.push(kernel_.constant(std::stod(i.GetToken())));

I wonder what flags should be turned on for the Android toolchain...

I've noticed the underlying library has methods for generating normal/bump maps:

void calcNormalMap(CArray2Dd *map, CArray2Drgba *bump, float spacing, bool normalize, bool wrap);
void calcBumpMap(CArray2Dd *map, CArray2Dd *bump, float light[3], float spacing, bool wrap);

I'm not proficient in 3D but I think many would benefit from these, so it's worth to bind them.

Value, gradient, gradval, white and simplex noise generators are not exposed to the module:

...
double value_noise2D(double x, double y, unsigned int seed, interp_func interp);
double gradient_noise2D(double x, double y, unsigned int seed, interp_func interp);
double gradval_noise2D(double x, double y, unsigned int seed, interp_func interp);
double white_noise2D(double x, double y, unsigned int seed, interp_func interp);
double simplex_noise2D(double x, double y, unsigned int seed, interp_func interp);
...

I'm not sure whether they're needed since the noise can be obtained from constructed kernel. But I think having those wouldn't hurt.

Module version:
2.0-alpha

Issue description:
Currently it might take too long for the noise preview to get generated with lots of visual noise nodes, especially with mapping modes set to SEAMLESS_XY or SEAMLESS_XYZ, which causes the editor to freeze. Some very long noise chains may take up to 10-20 seconds to generate a seamless image.

The solution would be to generate noise previews in a thread instead, possibly with ability to cancel noise preview generation for a particular node.

Currently it's only possible to define mapping ranges for 2D case as Rect2, it would be beneficial to map noise including Z axis defining AABB to potentially generate 3D textures. The underlying library supports it.

I was thinking embedding mapping ranges as property, but not sure whether it should be defined both for 2D and 3D, or separate:

mapping_ranges_2d = Rect2( Vector2(-1, -1), Vector2(2, 2) )
mapping_ranges_3d = AABB( Vector3(-1, -1, -1), Vector3(2, 2, 2) )

Related to #4.

Module version:
2.0 (tested in 3516b01)

Issue description:
Attempting to duplicate a noise node leads to duplicating all nodes, including those that weren't selected.

Steps to reproduce:

1. Create some nodes
2. Select a node (or don't select at all)
3. Ctrl+D to duplicate nodes.
4. See how all nodes get duplicated.

Module version:
2.1-dev

Issue description:
Docs format need to be updated for Godot 3.2, seems like the format got changed a bit:

ERROR: Invalid tag in doc file: demos
   At: editor\doc\doc_data.cpp:946

On the http://accidentalnoise.sourceforge.net/minecraftworlds.html page, the autocorrect module is used to map ranges to 0..1, by iirc first sampling values to determine ~ min max.

Is this present in this module, or am I missing something?

I had an idea to make a tensorflow image scaler, do you think it'll fit with the visual node paradigm or should I do it another way?

Module version:
2.1

Issue description:
Oftentimes, when you're in a deep experimental noise creation, you don't really care about making your noise modular, but at some point the nodes pile up quickly. While it's possible to create a component node individually, there has to be a quick way to turn a connected chain of nodes (or selected group of nodes) into a node component. This would allow for convenient refactoring of nodes.

Module version:
2.1

Issue description:
In 2.0, noise functions like multiply_sequence, add_sequence etc. weren't exposed as those only make sense in code, but still remain a desired feature. Currently a workaround would be to add many ScalarOp nodes in a chain, but that can pile up and clutter the editor.

Implementing #13 might already give a foundation to make this happen.

Provide Texture and Texture3d resources and if possible refactor the engine so both Texture and Texture3d opensimplex and anl classes can coexist from the same parent class.

Module version:
2.1

Issue description:
A selector node would be similar to transition node in animation blend tree that can be used to quickly choose what noise chain to pass to other nodes. This would serve as a replacement to manual connecting/disconnecting multiple nodes to the same node.

Module version:
2.1-alpha

Issue description:
ERR_EXPLAIN macros are better to be replaced at some point for performance reasons: godotengine/godot#30893.

But this will have to wait for Godot 4.0 to preserve potential compat.

Module version:
2.1-stable

OS/device including version:
Windows 10 x64

Issue description:
Mono binding wasn't generated.

Steps to reproduce:

1. Download 2.1-stable.{zip/tar.gz}
2. Download Godot 3.2-stable sources.
3. Unpack 2.1-stable to "modules" folder of Godot 3.2 source code.
4. Compile with Mono, but without glue.
5. Try to generate Mono glue.
6. Catch a generator error to your face.

Creating noise with ANL can be quite a spaghetti:

var f0 = n.constant(2)
var n = n.zero()
var basis = n.cellular_basis(
	f0, n, n, n, n, n, n, n,
	n.zero(), n.constant(seed_id)
)
var scaled = n.scale(basis, n.constant(1.25))
var scale_offset = n.scale_offset(scaled, 0.5, 0.1)
var select = n.select(
	n.zero(),
	n.one(),
	scale_offset,
	n.constant(0.45),
	n.zero()
)

So there needs to be a way to design noise more visually, like Godot's VisualShader editor plugin does.

Also, see a nice use case already implemented in other engine by original author of Accidental Noise Library:

Example designing noise using graph nodes in Urho3D engine.

This feature is a possible prerequisite for #4 to get implemented so that noise can be saved as a resource.

Module version:
2.1+, Godot 3.2 and 4.0+.

Issue description:
As you may know, Godot is currently undergoing major rewrite for 4.0. Some changes has already introduced compatibility breakage which need to be resolved in the module.

Currently, the module's master branch aims to be in sync with the latest development changes in Godot as noted in README. That worked well up until now, because rewriting the module means that:

• new features are going to end up to be only 4.0-compatible;
• new features need to be ported to 3.2 manually for each.

Given that the engine won't be usable nor stable for quite a long time (and most people would be actually using the released version of the engine which is Godot 3.2), I think it would be reasonable to change the branching model. Cherry-picking features from 4.0 to 3.2 is just going to be double work, and it's expected that new features can be added against Godot 3.2 too.

Instead, I propose that for each major engine version, there should be a separate branch. Namely:

• rename master branch to <module_version>-<engine_major_version>;
• create a new branch for the next major engine version in development.

Some examples of how it would look like:

• 2.1-gd3 (2.1 as of now)
• 2.1-gd4
• 3.0-gd3
• dev-gd3 (master as of now)
• dev-gd4

For stable releases (by stability I define that no new features are added to that version), the version tags would look like:

• v2.1-gd3-stable
• v2.1-gd4-alpha

It also means that each engine-specific version can diverge and have different set of features (ideally they shouldn't), and depending on community needs they can be cross-ported between versions (bumping the major component of the module itself for each branch, if necessary). Once Godot 4.0 is released to the public, any Godot 3.x-specific features can be finally moved to 4.0.

I'm just announcing this publicly and perhaps people can suggest something better, especially the naming prefixes/suffixes to encode engine major version for branches. I think this kind of distinction will work better in the long run. I'm not that familiar with other branching models out there.

Note that there will be no master branch anymore, and the default branch is going to be dev-gd3 for "nightly" versions, and there will be another dev-gd4 branch similarly.

Also note that the module is currently imitating the branching/versioning model similarly to Godot, for consistency. So might be worth naming development branches as master-gd3 branch similarly instead of dev-gd3.

Module version:
2.1+

Issue description:
Godot 3.2 should have a new interface broken down into categories which replaces the Add Node menu:

godotengine/godot#26164

The task would be to bring in the same or similar interface with drag'n'drop functionality. Visual noise interface is already partly based on visual shader so this should be relatively easy to do. 😄