OverviewFilesCommitsIssuesDocsReleasesPeers

proc-nodes commits / 7feabba

volume: "no consumers" was wrong -- the importer factory is a consumer
Correcting the commit before this one. It said, and put into volume_nodes.h: "It has NO CONSUMERS. grep across proc-nodes, dc-terrain and hyper-tps finds VolumeToMesh only in register_types.cpp and in glsl_golden_gate.gd's refusal case." That grep was truncated at six lines per directory, and the line it cut off was the one that matters: graph_importer.cpp:161 if (p_type == "VolumeToMesh") return memnew(...) which is the FACTORY. Any imported or serialized graph naming "VolumeToMesh" instantiates one, reaches the placeholder execute(), and bakes to nothing. So the node is unused, not unreachable -- and the reachable path is exactly the one that fails silently, which makes the warning added in the previous commit load bearing rather than decorative. Re-run untruncated across proc-nodes, dc-terrain, hyper-tps AND blender-bridge, what is actually true: * no graph ON DISK uses it -- .tres, .tscn and .json searched across all three repos, zero hits * nothing constructs a meaningful ProcVolume anywhere; execute() is a stub * blender-bridge deliberately does NOT map it, and says why (geometry_serializer.py:151): "ours takes a Density FIELD, Blender's takes a volume GEOMETRY" -- different operations sharing a name, so a Blender graph can never produce this node * ISSUES_TO_CREATE.md:8 still describes the volume nodes as emitting undefined density_N_input variables, which the emitter rewrite fixed; that file is stale, not touched here THE DECISION IS UNCHANGED -- supports_gpu() stays false, for reasons 1 and 2, both of which were verified by measurement rather than by grep. Only the evidence for reason 3 was overstated, and it is the reason that needed the least support. Recording it because a false statement in a header is worse than no statement: the next reader would have taken "no consumers" as licence to delete the node, and the factory line would have turned that into a graph that fails to import. 27/27, all three targets carry the change (checked by string). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7feabba5e7bc2dfec6cd60ba92f45e44439d1e48
by plankatron <fleeky@gmail.com> · 2026-09-06T15:23:41.000Z

Changed files (1) +20 -4

src/nodes/volume_nodes.h +20 -4
……@@ -99,10 +99,26 @@ public:
9999 // this node is not, and cannot become, because it hands on geometry
100100 // rather than naming a float.
101101 //
102 // 3. It has NO CONSUMERS. grep across proc-nodes, dc-terrain and
103 // hyper-tps finds VolumeToMesh only in register_types.cpp and in
104 // glsl_golden_gate.gd's refusal case. Nothing builds a volume through
105 // it, which is consistent with execute() below being a placeholder.
102 // 3. NOTHING BUILDS A VOLUME THROUGH IT -- but it IS REACHABLE, and the
103 // first version of this note said "no consumers", which was wrong. It
104 // came from a grep truncated at six lines, and the line it cut off was
105 // the one that matters:
106 //
107 // graph_importer.cpp:161 the FACTORY. Any imported or serialized
108 // graph naming "VolumeToMesh" instantiates
109 // one, and then bakes to nothing.
110 //
111 // What is true: no graph ON DISK uses it -- searched .tres, .tscn and
112 // .json across proc-nodes, dc-terrain and hyper-tps, zero hits -- and
113 // nothing constructs a meaningful ProcVolume anywhere. So it is
114 // unused, not unreachable, and the reachable path is exactly the one
115 // that fails silently. That makes execute()'s warning below load
116 // bearing rather than decorative.
117 //
118 // blender-bridge does NOT map it, deliberately, and says why
119 // (geometry_serializer.py:151): "ours takes a Density FIELD, Blender's
120 // takes a volume GEOMETRY". They are different operations that share a
121 // name, so a Blender graph can never produce this node.
106122 //
107123 // Turning this true would require it to emit something, and there is
108124 // nothing for it to emit. The debt here is not the flag -- see execute().