Proof of concept of using Godot for UI
Zireael07 opened this issue · comments
This is but a proof of concept made during the weekend in Godot 3.5.
- uses GDScript instead of GDNative
- uses a different data structure
- the layout/format of the GUI is slightly different (e.g. the spreadsheet is a popup panel instead of a constant panel at the top, the displayed data is not the IDs but the positions, the model is only shown after clicking a button - this is to gain more space for the graph itself)
- basically a MRP, only two nodes are really implemented (a quad and a transform)
- only one input and one output work for now
When making the PRs, I found that even for a little PR that amounted to adding a wrapper function in Rust and editing the Lua file, compilation was significantly slow on my Dell Vostro 5581 (enough that I'd tab away to do something else while waiting for it to be done - something around 10, maybe 15 seconds)
I strongly suspect this is due to the amount of dependencies, when I first ran the project the part of getting and compiling all the crates was really long, I think the number quoted was around 150-ish
Using Godot for the GUI would significantly cut down on them (wgpu, egui, rend3, fontconfig package).
WASM is also an option for Godot so this would not block #14
Even if this is not accepted (at least not accepted in the immediate future) I plan to use this little project to brainstorm things like #70 and #55 and also subgraphing (combining two or more nodes to e.g. save space or to use them in combination with a loop - see #70 )
Interesting! I will be looking at this in depth 😄 But in the meantime, care to share a screenshot?
Sure!
Hi! Still haven't had time to look seriously at the code, but I have a few comments as for why I picked my current tech stack. Godot was one of the first options I considered for this, I am building a Godot-Rust game after all 🙂. But I didn't go for it because the node editor in Godot is not up to the UX standards I am seeking for blackjack. A good example of that is Material Maker. Don't get me wrong because it's an amazing tool and I love it (❤️!), but there's unfortunately a lot of tiny UX papercuts that tool is stuck with due to building on top of Godot's node graph. Here's some issues with Godot's node editor:
- Zooming blurs text in a way that makes it almost unreadable. Especially zooming out.
- When zoom level is not 1.0, it is almost impossible to grab a connection / port (I believe this one has been sorted out during the past few months).
- A clunky API, that ties together inputs and outputs with the inner widget into "rows".
This frustration is what lead me down the path to create what would become https://github.com/setzer22/egui_node_graph, and I am happy with that decision. The Rust gamedev ecosystem is still very young, and there was need for a tool to build node graphs in other parts of the ecosystem. I like Godot, but at the end of the day, blackjack is a more Rust-centric project, so I value being able to contribute to the Rust community as a whole.
compilation was significantly slow on my Dell Vostro 5581 (enough that I'd tab away to do something else while waiting for it to be done - something around 10, maybe 15 seconds)
I don't distribute this file with the repo because it is bad for portability, but I use this config to significantly boost incremental compile times on Linux. Times for me have been closer to 2-5 seconds. It's still not great, but a significant improvement:
./cargo/config.coml
# Bevy's "fast compile times" recommended setup from:
# https://bevyengine.org/learn/book/getting-started/setup/
[target.x86_64-unknown-linux-gnu]
linker = "/usr/bin/clang"
rustflags = ["-Clink-arg=-fuse-ld=lld", "-Zshare-generics=y"]That said, I totally hear you that blackjack has too many dependencies and I agree. It's just that right now I think it is not time to focus on that, it is time to focus on building a feature set that can create a useful tool for artists. Once we reach that milestone (so close, yet so far!) we can think about trimming down that dependency tree.
Now, none of my comments here are meant to discourage you from this project, please don't take me wrong! 😄 I believe an alternative blackjack UI for Godot would be something pretty cool, and also allow making the tool feel more integrated into the engine beyond what is possible with the current model. The new GDExtension API for Godot 4 will make this sort of editor extensions even more viable, and I'm looking forward to that.
Tbh I never zoom the graph :P
Considering the problems, I'll either look at Material Maker to see their workarounds, wait for a Godot fix, or disable zoom functionality somehow :P
I agree that out of the box, the Godot API is quite clunky - I spent half of the weekend reading up papers trying to figure out what data structure to use, and another half trying to figure out how the API works :/
EDIT: Disabling zoom turns out to have been stupid easy.
Proof of concept for multiple-to-one connections in graph and for subgraph (note that you can't view the subgraph visually yet, it's a big hack for now :P )
That looks nice! 😄 I see you have some WIP code in the mesh folder 👀 I haven't had time to look into it myself, are there any advantages to WingedEdge over HalfEdge?
That's what I was trying to explore :P - what mesh representation is the best and whether it's possible to expose some universal interface that wouldn't care which exact representation is used. That part is totally WIP, as you probably noticed I focused on GUI first and actual code second :P since the code's already here in blackjack if this gets adapted OR Godot Rust bindings finally get mature enough in 4.0