Node Editor Widget

[The3dVehicleguy]

Spartan Node Editor System

This pull request introduces a new grid rendering and input handling system for node-based UI widgets in the editor, along with supporting math utilities for Bezier curves and vector operations. It also includes minor type improvements and integrates the new node widget into the editor's main interface.

Node Widget Integration & Grid System

• Added NodeWidget to the editor's widget stack, enabling node-based editing capabilities in the UI (Editor.cpp).
• Implemented a new Grid class (ImGui_ViewGrid.h, ImGui_ViewGrid.cpp) that handles rendering a customizable grid background, smooth zooming, panning, and coordinate transforms for node-based interfaces. [1] [2]

Math Utilities for Node UI

• Added imgui_extra_math.h and imgui_bezier_math.h for advanced vector, rectangle, and Bezier curve math, supporting features like curve sampling, subdivision, intersection, and projection—essential for node graph connections and layout. [1] [2]

Type Safety Improvements

• Updated DragPayloadType and ButtonPress enums in ImGui_Extension.h to use uint8_t for better type safety and memory efficiency. [1] [2]

Editor UI Enhancement

• Included the new NodeWidget header in the editor source to support its instantiation and usage.

---

Known Bugs:

• Right click context menu will not close by left click or clicking outside the Node Editor widget context. Use Escape for now.
• Node's don't contain assert's to verify correct input and output types properly.

[Copilot]

Pull request overview

This PR introduces a comprehensive node-based editing system for the Spartan engine, enabling visual shader/material editing through a graph-based UI. The implementation includes a complete node system architecture with rendering, interaction handling, and mathematical utilities for Bezier curve drawing.

Key Changes:

• Implemented NodeWidget with grid-based canvas supporting pan, zoom, and node manipulation
• Created node system architecture with NodeBase, Pin, Link, and template-based node creation
• Added Bezier curve math utilities and ImGui layout helpers for smooth connection rendering
• Integrated node editor into the main editor UI with toolbar icon support

Reviewed changes

Copilot reviewed 46 out of 49 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
ResourceCache.h/cpp	Added icon types (Flow, Circle, Square, Node) for node UI elements
NodeWidget.h/cpp	Main widget implementing node editor with grid, interaction, and context menu
NodeSystem/	Core node architecture: NodeBase, Pin, Link, NodeBuilder, NodeLibrary, Templates
NodeSystem/Nodes/	Concrete node implementations (Add, Subtract, Multiply, Divide, Branch, LessThan)
ImGui/ImGui_ViewGrid.h/cpp	Grid rendering system with pan/zoom support
ImGui/Nodes/imgui_bezier_math.*	Bezier curve math for smooth connection curves
ImGui/Nodes/imgui_extra_math.*	Vector and rectangle math utilities
ImGui/ImGui_Extension.h	Type safety improvements using uint8_t for enums
Editor.cpp, MenuBar.cpp	Integration of NodeWidget into editor UI

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Division by zero is handled but returns 0.0f, which may not be the desired behavior in all contexts. Consider whether NaN, infinity, or an error flag would be more appropriate, or document why 0.0f is the correct default for this use case.

[Copilot]

Magic numbers header_height = 30.0f and pin_spacing = 24.0f are duplicated across multiple functions (DrawNode, DrawLinks, FindPinAt). These should be class constants to ensure consistency and ease of maintenance.

[Copilot]

The link hit detection is overly simplistic - it only checks the midpoint distance. This will make it difficult to select links that are not near their midpoint. Consider using proper distance-to-curve calculation or the existing Bezier projection utilities (ImProjectOnCubicBezier).

[Copilot]

The condition checks if the link state needs updating (!IsPinLinked) before setting SetLinked(false), but this logic is flawed. After deleting a link, the pin should be marked as not linked. However, IsPinLinked checks if there are ANY other links still connected to this pin. If there are, the pin should remain linked. The current logic correctly handles this, but it should be done for both pins before erasing the link from the list to avoid checking a deleted link.

Suggested change

	// Update pin linked states
	Pin* start_pin = FindPin((*it)->GetStartPinID());
	Pin* end_pin = FindPin((*it)->GetEndPinID());
	if (start_pin && !IsPinLinked(start_pin->GetID()))
	start_pin->SetLinked(false);
	if (end_pin && !IsPinLinked(end_pin->GetID()))
	end_pin->SetLinked(false);
	m_links.erase(it);
	Pin* start_pin = FindPin((*it)->GetStartPinID());
	Pin* end_pin = FindPin((*it)->GetEndPinID());
	// Erase the link first so IsPinLinked reflects the correct state
	m_links.erase(it);
	if (start_pin && !IsPinLinked(start_pin->GetID()))
	start_pin->SetLinked(false);
	if (end_pin && !IsPinLinked(end_pin->GetID()))
	end_pin->SetLinked(false);

[Copilot]

The IconType enum is being extended after the Max entry. New enum values should be added before Max to maintain its role as a sentinel value for iteration and validation purposes. Adding entries after Max breaks any code that relies on Max to determine the enum range.

[Copilot]

Using const_cast to strip const-ness from m_hovered_pin is dangerous and indicates a design issue. If m_hovered_pin is const qualified, it should remain const. Consider either:

1. Storing Pin* (non-const) if mutation is needed
2. Separating the mutable link creation state from the hover state
3. Using a separate variable for link creation that is properly typed as Pin*

[Copilot]

Another use of const_cast to strip const-ness. This pattern appears multiple times in the code and represents a design flaw. The member variable m_hovered_pin should be Pin* instead of const Pin* if you need to modify it.

[PanosK92]

appreciate the work here, the ImGui node editor implementation looks really solid.

However, I assume this was built with the intention of allowing artists to create custom shaders (similar to Unreal/Unity). There is a fundamental architectural mismatch here, as Spartan Engine does not support dynamic shader generation.

Uber Shader vs. Shader Generation Spartan Engine utilizes a strict Uber Shader architecture (similar to id Tech). We rely on a fixed, pre-compiled set of Pipeline State Objects (currently ~29 PSOs).

How Spartan works: Materials define Data (uniforms, textures, flags) that feed into a fixed shader pipeline. We do not recompile shaders per material.

How Node Editors work: They generate unique HLSL/GLSL Code per material. This requires runtime compilation and results in a unique PSO for every single material graph, which defeats our optimization strategy.

Moving forward because the node editor implementation itself is high quality, I am going to keep this PR open. I want to evaluate if we can repurpose this UI for a different system that relies on logic flow rather than shader compilation (e.g., Sound cues, AI Behavior Trees, or Post-Process chains).

Thanks

[The3dVehicleguy]

appreciate the work here, the ImGui node editor implementation looks really solid.

However, I assume this was built with the intention of allowing artists to create custom shaders (similar to Unreal/Unity). There is a fundamental architectural mismatch here, as Spartan Engine does not support dynamic shader generation.

Uber Shader vs. Shader Generation Spartan Engine utilizes a strict Uber Shader architecture (similar to id Tech). We rely on a fixed, pre-compiled set of Pipeline State Objects (currently ~29 PSOs).

How Spartan works: Materials define Data (uniforms, textures, flags) that feed into a fixed shader pipeline. We do not recompile shaders per material.

How Node Editors work: They generate unique HLSL/GLSL Code per material. This requires runtime compilation and results in a unique PSO for every single material graph, which defeats our optimization strategy.

Moving forward because the node editor implementation itself is high quality, I am going to keep this PR open. I want to evaluate if we can repurpose this UI for a different system that relies on logic flow rather than shader compilation (e.g., Sound cues, AI Behavior Trees, or Post-Process chains).

Thanks

Thanks for reviewing! @PanosK92

Yes the original idea was to create a node editor to replace the existing text based shader editor already present in Spartan however over time I realized it would just be better to have a general node editor GUI base that can be utilized for different things and not just shaders. It was Once I began writing the node editor that by making it able to create and edit the shaders did I realize it would require an extensive refactor of the pipeline state objects for the Spartan Vulkan and DirectX 12 abstraction. So rather then do that, I decided to implement a basic node editor GUI that can be used for procedural asset creation, general asset management, scripting, AI interactions, in game events, etc.

I kept the GUI style the same with how Spartan looks and functions. It has the ability to add animation and custom nodes through a node template setup.

One part I left open for future development is the creation of node libraries which contain a preset of nodes and their functions which are to be loaded in runtime. This would be a minor refactor to swap the nodes from the Editor to the Spartan runtime so its not conflicting with user created nodes.

The node editor is a "Widget" like all the other ImGui widgets in Spartan with the difference being the Node Editor will pull the mouse position and selection data in a viewport that overrides the scene viewport.

Tasks/ items that can be done to further enhance the Node Editor:

• Create a new "Right-Click Action Panel / Context Window"
• Integrate the Node Editor into a material system.
• Integrate into a scripting engine.
• Setup a way to store the node data to the scene and object.
• Setup node serialization within the scene.
• Create more preset function nodes.
• Swap the nodes from the Editor to the Spartan runtime so its not conflicting with user created nodes.

I hope with some time some uses can be found for this!
I might end up writing some system for using the nodes in the editor.