Warning: I don't know how exactly Material Maker works internally, so any assumptions I make about texture generation may be wrong.

Feature/enhancement description:

When working with complex node graphs, performance can quickly drop while tweaking parameters, especially with float values. These are some possible solutions I could come up with:

1. Only generate the preview after the user stopped editing the float. This would make it less laggy, but also less interactive.
2. Optimize the generation of textures by storing the result of each node as a texture, and using that instead of integrating the node into a shader. This is simillar to using a Buffer node, which greatly improved performance for me.
3. The 2D preview could be optimized, as my FPS is low when I have it open. Maybe it could only be updated when the result changed.
4. I noticed was that textures where recalculated even if no preview was opened. It would be nice to generate these previews on demand.
5. The generated shaders could be cached and only the shader_params could be changed when a value is tweaked. Shader generation probably causes one of the biggest performance hits.

I know this is could be a huge task and may require lots of restructuring of the codebase, but I am opening this issue to start a discussion about possible approaches.

I usually have a hard time switching from different preview, so I made this to avoid having to read a small text:

I had to use a hack to show the default cube after generating the previews so any help/feedback about that (and anything of course) is welcome.

You already have an inverse map and object normal map generator. I think it would be logical to have a curvature map generator too. With this, you'll be able to create some more effects, especially when it comes to creating a "wear and tear" look for materials.

The implementation is a near direct port of blender's code here.

Material Maker version: Version 0.97, this build: https://github.com/RodZill4/material-maker/actions/runs/1431815396

OS/device including version: Ubuntu Linux 20.04 GPU: RTX 2060s

Issue description: OpenEXR generated from MaterialMaker has mismatching colors.

Testing colors, it seems that color channels got shifted like that

Alpha → Red
Red → Green
Green → Blue
Blue → Alpha

Steps to reproduce: Just export OpenEXR from Viewport2D and check the result.

I prepared something which might be useful. Load test_colors.ptex file from there … https://drive.google.com/file/d/1xlusZCEib_18czDcPqSpfDDlG5re3D-_/view?usp=sharing

There are float nodes for 0.0 and 1.0, which could be connected to a Combine node. Plug floats to different inputs of the combine node, and export an EXR file from the Preview2D of the Combine node.

Use Gimp (or other software which supports OpenEXR) to examine result EXR file.

Hi! I've started doing some work in Material Maker and I love it.

Here's one of the materials I've made recently - I release it under CC-0 - enjoy!

unfa-Concrete_Wall.ptex.zip

My overall feeling is that it's very powerful, but the UI and UX need work - I find it especially difficult to work with large node graphs. Just panning and zooming the node graph is difficult. I know a lot of these limitations come from Godot - maybe material Maker could become a driving force in improving it upstream?

I think I can manage much more complex node graphs in Blender than in Material Maker, because:

• I can zoom in and out without much limitation
• I can use dot (no-op) nodes to create visually readable DAG paths (like PCBs) instead of getting tangled in unwieldy noodles that cross each other in every direction
• I can use panels to group nodes visually and make it easier to move these groups around
• I can drag a node onto a noodle to insert it between two other nodes
• I can duplicate a node with it's original inputs staying connected
• I can cut the noodles instead of disconnecting them one by one
• I can create groups and re-use node groups much more easily, with finer control still being there

I think one of the easiest ways to improve this node editing experience is by allowing the users to zoom out far more. Right now I feel like hitting my head on a low ceiling all the time when I try to zoom out more.

Also - a mini map of the node graph with the ability to pan with it would be very helpful.

I'm excited to see he Workflow nodes, trying to implement a way of merging sub-materials together - it'd be way easier to work this way instead of manually affecting every PBR map of my material by hand for every layer of detail. However I was unable to understand how these are supposed to work and how to use them.

Now - these are pretty fresh notes, I've been using Material Maker for about a week now - I am very, very excited for it, and it already can do amazing things, but I feel there's a need for many quality of life improvements and helping users manage large graphs.

Thank you for creating this software, and making it free for everyone. This is wonderful!

PS: I'm sorry if this is a wrong place to post such a letter. I'll happily move it somewhere if need be.

Hi, what about updating the Theme to the modern Godot one? It's only a couple clicks. Shall I make a PR with something like this or you are fine with the current one? Thanks!

This project crashes with (at least) 3.2RC2 and 3.2RC3 under Windows. Did not test under Linux (@Calinou ?). Didn't start investigating yet, but I doubt it's a Godot problem (all my other projects just run fine).

I store only source materials (*.ptex files) in my project repository, but not generated by export images, because storing them is redundant and consumes a lot of space (several MB against several KB). But if i want to produce material images, i needed to launch Material Designer for every material and manually export it. It will be better, if Material Designer will have special console mode only for export. For example: MaterialDesigner.exe --export -i in_material.ptex -o output_directory/ This command opens input material and exports it. If such options will exist, it will be easy to write script, that automatically exports all materials in project build process.

There are some patterns, based on random values - bricks, voronoi, perlin noise, color noise truchet, scratchers, etc. Result of such patterns changes after each change of pattern node, even if only position changed. Sometimes, final result may looks either good or bad, dependent on random seed. So, if you selected good seed, you need to quickly export result, because after any change or after program restart you may not receive good seed again. To fix such issues, it will be good to control randomness. I see two options how to do this:

• Add one global random seed and allow user to change it and save in result material file.
• Add random seed option to any node, that uses random generator.

Fixes #481, #482, and #483

I've tested this on various nodes, trying to make sure it would work cleanly with any type of parameter. This is my first contribution, so apologies if there are any conflicts with design or code style.

On macOS Catalina (10.15.6), Material Maker runs fine in Godot engine but fails to load resources after export to MacOS.

When run inside Godot engine, the app stats up fine and I can create materials. Run as a compiled app, it starts up, but with an empty library.

when I start the compiled app from the command line, I get the following errors:

./Material\ Maker 
arguments
0: ./Material Maker
Current path: /Users/[___]/Downloads/Godot/Material Maker.app/Contents/MacOS
Godot Engine v3.2.2.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: AMD Radeon Pro 580X OpenGL Engine
 
Registered camera FaceTime HD Camera (Built-in) with id 1 position 0 at index 0
ERROR: load_source_code: Condition "err" is true. Returned: err
   At: modules/gdscript/gdscript.cpp:829.
ERROR: load: Cannot load source code from file 'res://addons/material_maker/engine/gen_iterate_buffer.gd'.
   At: modules/gdscript/gdscript.cpp:2285.
ERROR: _load: Failed loading resource: res://addons/material_maker/engine/gen_iterate_buffer.gd.
   At: core/io/resource_loader.cpp:278.
SCRIPT ERROR: GDScript::load_byte_code: Parse Error: The class "MMGenIterateBuffer" was found in global scope, but its script couldn't be loaded.
   At: res://addons/material_maker/engine/loader.gdc:135.
ERROR: load_byte_code: Method failed. Returning: ERR_PARSE_ERROR
   At: modules/gdscript/gdscript.cpp:801.
ERROR: load: Cannot load byte code from file 'res://addons/material_maker/engine/loader.gdc'.
   At: modules/gdscript/gdscript.cpp:2281.
ERROR: _load: Failed loading resource: res://addons/material_maker/engine/loader.gdc.
   At: core/io/resource_loader.cpp:278.
ERROR: start: Can't autoload: res://addons/material_maker/engine/loader.gd
   At: main/main.cpp:1749.
SCRIPT ERROR: _ready: Invalid call. Nonexistent function 'get_nodes_paths' in base 'Nil'.
   At: res://addons/material_maker/engine/io_types.gdc:9.
ERROR: create_from_image: Condition "p_image.is_null()" is true.
   At: scene/resources/texture.cpp:199.
ERROR: texture_set_size_override: Condition "p_width <= 0 || p_width > 16384" is true.
   At: drivers/gles3/rasterizer_storage_gles3.cpp:1528.
SCRIPT ERROR: generate_preview_shader: Invalid get index 'f' (on base: 'Dictionary').
   At: res://addons/material_maker/engine/gen_base.gdc:223.
SCRIPT ERROR: set_generator: Invalid set index 'code' (on base: 'Shader') with value of type 'Nil'.
   At: res://material_maker/preview/preview_2d_panel.gdc:35.
SCRIPT ERROR: generate_preview_shader: Invalid get index 'f' (on base: 'Dictionary').
   At: res://addons/material_maker/engine/gen_base.gdc:223.
SCRIPT ERROR: set_generator: Invalid set index 'code' (on base: 'Shader') with value of type 'Nil'.
   At: res://material_maker/widgets/histogram/histogram.gdc:33.
SCRIPT ERROR: generate_preview_shader: Invalid get index 'f' (on base: 'Dictionary').
   At: res://addons/material_maker/engine/gen_base.gdc:223.
SCRIPT ERROR: set_generator: Invalid set index 'code' (on base: 'Shader') with value of type 'Nil'.
   At: res://material_maker/preview/preview_2d.gdc:35.
SCRIPT ERROR: MMGraphEdit.new_material: Invalid call. Nonexistent function 'create_gen' in base 'Nil'.
   At: res://material_maker/graph_edit.gdc:198.
SCRIPT ERROR: generate_preview_shader: Invalid get index 'f' (on base: 'Dictionary').
   At: res://addons/material_maker/engine/gen_base.gdc:223.
SCRIPT ERROR: set_generator: Invalid set index 'code' (on base: 'Shader') with value of type 'Nil'.
   At: res://material_maker/preview/preview_2d_panel.gdc:35.
SCRIPT ERROR: generate_preview_shader: Invalid get index 'f' (on base: 'Dictionary').
   At: res://addons/material_maker/engine/gen_base.gdc:223.
SCRIPT ERROR: set_generator: Invalid set index 'code' (on base: 'Shader') with value of type 'Nil'.
   At: res://material_maker/widgets/histogram/histogram.gdc:33.
SCRIPT ERROR: generate_preview_shader: Invalid get index 'f' (on base: 'Dictionary').
   At: res://addons/material_maker/engine/gen_base.gdc:223.
SCRIPT ERROR: set_generator: Invalid set index 'code' (on base: 'Shader') with value of type 'Nil'.
   At: res://material_maker/preview/preview_2d.gdc:35.
ERROR: ~List: Condition "_first != __null" is true.
   At: ./core/self_list.h:112.
ERROR: ~List: Condition "_first != __null" is true.
   At: ./core/self_list.h:112.
WARNING: cleanup: ObjectDB instances leaked at exit (run with --verbose for details).
   At: core/object.cpp:2135.
ERROR: clear: Resources still in use at exit (run with --verbose for details).
   At: core/resource.cpp:477.

Where are the resources supposed to be located?

Overview

When selecting and then dragging the comment node, wrong nodes might be selected depending on the current zoom level of the graph. When zoomed out, nodes outside of the comment node will be wrongly selected. When zoomed in, only nodes close to the top-left corner of the comment node will be selected.

This PR fixes this problem so that comment node selects the correct nodes regardless of zoom level.

Reproduction steps

(Zoom Out)

1. Create a comment node around some nodes
2. Place one or more nodes outside of the comment node, but very close to it
3. Zoom out
4. Left-click on comment node once, then left-click drag the comment node so contents are also selected and moved
5. Notice that nodes outside of the comment node that are very close to it will be also selected

(Zoom In)

1. Create a comment node around some nodes
2. Zoom in
3. Left-click on comment node once, then left-click drag the comment node so contents are also selected and moved
4. Notice that nodes far from the top-left corner of the comment node won't be selected, even though they are inside the comment node

Implementation Details

Cause

It seems that the get_rect function always returns the same size for the GraphNode regardless of zoom level, but position is correctly updated to reflect the current zoom level.

Fix

On graph_edit.gd, instead of checking the contained nodes by using the get_rect function directly, a new Rect2 is calculated and multiplied against the current zoom level so that the correct node size for the current zoom level is used for the encloses function check.

Calls a new function export_files_and_find_leaks() that runs export_files() over and over again with the same arguments, and reports an error if memory usage grows too much.

Can theoretically be thrown into CI, but godot-headless doesn't appear to support rendering yet, so triaging will have to rely on git-bisect instead of CI for now.

Can probably be made into an EditorScript, but the way this interacts with the filesystem definitely needs to be changed first - right now the output directories need to be manually removed before every run

Required by #559 , split into its own PR so it can be separately reviewed, merged, and tested ahead of time and minimize the chances of merge conflicts.

Material Maker version:

1.1

OS/device including version:

Windows 10 GTX 1060 6GB

Issue description:

If you have a Remote node with Named Parameters, as well as Linked Controls and/or Configurations, and you delete all nodes that a Linked Control or Configuration is linked to, all Named Parameters will be removed from the Remote node in addition to the Linked Control or Configuration.

Steps to reproduce:

1. Add a few nodes
2. Add a Remote Node
3. Add a few Named Parameters to the Remote Node
4. Add some Linked Controls or Configurations to the Remote Node
5. Delete all nodes that are linked to from one of the Linked Controls or Configurations
6. That Linked Control or Configuration will be removed from the Remote node as expected, but also all Named Parameters will be removed. Linked Controls or Configurations that still have nodes linked to them should still be there.