lukas-toenne / blender Goto Github PK

Decide if Asset libraries are a good fit for managing scripts on a higher level:

• The actual assets might be source code, or an intermediate representation that can be serialized. Perhaps IR code is stored and the source is only referenced, much like Image data blocks can have an optional source file reference.
• Source/IR code will need to be compiled at runtime before being usable. The final generated code should not be serialized. IR will be faster to compile.
• The asset library might work as a namespace to prevent name conflicts. Using functions from an asset library in a script will require "using " or similar.
• Capabilities and restrictions could perhaps be added per asset library. This enables the use of specialized functions that are only available in specific contexts (shaders vs geometry nodes etc.) This way such dependencies don't have to be specified for each individual script.

      if (error_count++ > 100) {
        push_error("Too many statement errors.", suite);
        break;
      }

This should be at least a #define.

Check for both num_errors and num_warnings to determine if the parser or compiler failed.

This is a placeholder originally from Godot, in Blender a GArray can be used instead.

Right now all node socket inputs are declared as "support_field" while outputs are "dependent_field". This will need to be refined a bit when internal functions of the script can

1. Have implicit field inputs, meaning their inputs in turn will be implicit fields (semantic difference, just indicates it will never collapse to a constant)
2. Have field source nodes that always output a field and never a constant. Any output using these will also become a field source.

Needs special case handling in assignments to create a temp value with the operator result before assigning.

This is a bad match for Godot defines that are disabling warnings. These should always be emitted and then optionally muted if necessary.

Currently the first function where all arguments can be implicitly converted will be chosen, which may not be ideal. E.g. if there are two variants

foobar(int a)
foobar(float a)

and the caller uses a float argument, the int variant might be selected (based on arbitrary order in the map) because float a can be converted to int a even though it loses precision.

The CustomMF_*** function classes don't specify parameter names (all params are named ""). Find a sensible solution to specify parameter names.

The tokenizer currently detects a number of tokens that have been copied from gdscript but are not used in Blender. Some will eventually get implemented, but its easy to add tokens when needed. Remove the unused tokens for now to avoid confusion.

UserCounter was needed initially for storing in node storage data, because it is intrusive and can be stored in a simple void*. This isn't needed any longer and shared_ptr should be user instead.

This describes a function/procedure as part of a script, with additional metadata such as a function name and parameter attributes for UI integration. The name is easy to confuse with the actual MFProcedure, and the variables names used for it are inconsistent: "proc", "script", "code", etc.

Need to come up with a distinct name for this thing and clean up its usages. Also consider potential future function types that are not necessarily MFProcedures, such as geometry "node" networks, fields, etc.

Currently special block types such as Loop and Match are used to delimit the variable stack and ensure contine and break statements destruct the correct amount of stack variables. This works but it's not very elegant. E.g. we need a secondary block for loops to ensure that the condition variable is destructed: unrolling stops at the Loop block, so the condition variable would not be destructed at the end of an iteration.

The concept of stack delimiters should be separate from Blocks which are used to indicate variable scope. Maybe its just a matter of making unroll inclusive, so the matching block is also unrolled and extra blocks can be avoided.

This should be possible:

func A(out x: float):
  ...

func B():
  var v : Vector
  A(v.x)

Currently emitted code contains many instructions whose outputs are never actually used, such as default parameter initializations.
Basic optimization passes should be able to remove these quite easily. It should also be possible to avoid some de-facto noops, in particular when copying values that are not used anywhere else.
Defining procedure instructions in terms of static single assignment form (SSA) should help with creating these optimization passes.