A well written browser based node graph editor that can create procedural 3d meshes _and_ export as .obj _and_ you've permissively licensed it. This could be the seed for a whole host of procedural tools. Thank you Jim.
I'm impressed with the complexity here. For folks wanting to take it for a quick spin... The tutorial is great but takes a few minutes to get to the fun. Instead just play with the sliders in the right pane and see how it modifies the fern. Also click library and load some other models to see what it can do.
You can tell this is brand new because there are no penises to load in the user submitted models yet.
Looks very nice, one small problem - when I change the values, the camera seems to "shake" because the shape of the plant changes, so it has to constantly readjust, and it's kind of annoying (at least for me). Maybe it could be possible to freeze the camera while the parameters are being changed?
I did something similar a year ago where I wanted to try out Rust as a webapp engine (compile to wasm -> host on rust webserver): https://blomma.lorentz.app. Although yours is miles better on the productification station, cudos!
The real selling point is the nodegraph editor, blends really well to the workflow and brings it down from a debugging tool to a product which may be used by anyone.
Only improvement mine has is bezier curves, for both the leaf shape and stem shape. It was (to me) quite a challenge to get both the topology and triangulization right, but a great intro to quaternions and nice refresher on trigonometry. I'd recommend giving a bezier curve node a go.
A couple of suggestions for usability improvements:
1. Drag handling is buggy when I accidentally move the mouse outside of a box and then release. In that case it doesn't notice a mouse-up and the parameter gets stuck in the mouse-down state. Makes it difficult to draw in the leaf editor or to modify parameters by dragging them like sliders. Probably just need to register the mouse-up event handler on a common ancestor instead of the graph node editor boxes.
2. The little parameter "port" circles for dragging connections are a bit small, especially when zoomed out where you can see a significant portion of the whole scene. Usability would be improved by making them bigger (at least 25%?). It might just be the hit area that needs to be larger, not necessarily the graphical element.
Note: I'm using Firefox. Just tested in chromium and the mouse handler problem happens there as well but dragging to connect nodes seems a bit more usable in chromium.
Fantastic. I can't wait to see a whole forest of crowdsourced algorithmic plants. Is this connected to any scientific projects? A cool feature would be an AI botanist that tells you how likely your plant would survive, what's the closest taxonomic reference, a nice recipe to go along with boiled rice,...
One of my ideas is to build a virtual garden where your plants can grow and you have to take care of them tamagotchi style :)
Not connected to any scientific projects, just a nerd that likes plants. But projects can have a gbif.org id and then some extra information is loaded through the gbif api :)
That is a nice idea! The tricky part is going to be how to integrate animations without having to rebuild the entire mesh every frame... Though, I think it would be very easy to export a skeleton from the generator and then use that to animate the plant.
Yup, I use github.com/oframe/ogl, which makes webgl a bit mor usable for the average programmer. You could also probably achieve the same thing with webgpu, but for the time being i have not yet had a reason to switch :)
Awesome. I think I will switch from rust to typescript on the front end and do something similar in WebGPU. Before I did some wasm stuff with the wgpu crate but the fact that wasm can't reach the DOM is a bit of a headache and the gains in performance from WASM seem to be offset by the fact that I still need to create a sort of communication channel between wasm and js if I want my 3D app to talk to a websocket.
Your project is very motivating thank you for making this!
Update: I'm I'm just gonna use webgl too. WebGPU seems to be nowhere near a usable state if you're a Linux user, they seemed to have focused more on ChromeOS, MacOS and Windows first so far, with Linux support to be released sometime in the future. Apparently with WebGPU you're better off on native now, and the wasm target just uses the webgl backend ;D
You're right that it is procedurally based; however, I have not yet implemented L-Systems. I am a long-time Blender Nerd, and if you look in the GitHub repository, there is an ideas/blender-plugin.md file since last year. Unfortunately, I haven't found time to start building it since I spend most of my time trying to get my startup off the ground.
I teach 3D modeling, and also procedural animation and simulation. The last two I would class as being the same.
3D modeling I would define as being fundamentally intentional. Want a particular form? Make it as according to your intention!
Procedural modeling animation/simulation I would define as being 'overseen' by a mathematical algorithm.
In the case of the former, the artist has complete control over every aspect of the outcome.
In the case of the latter, the artist has limited control. Want to change the direction of that simulation-defined particle? Or that branch of that L-system generated tree? Good luck.
The advantage of a procedural approach is that it can realistically emulate the complexity of nature (which is beyond an intentional approach). Hence it's favor in those artists who are interested in nature.
"Simulation" is a term that has been appropriated by artists but it refers to something much more rigorous in the parlance of the domains featured here on HN. Unless your plant is growing, uptaking nutrients, inhaling CO2 and exhaling O2... unless it can die from dehydration it is not being simulated.
What is presented in OP is a model of the morphology of plants implemented in an L-system. Model has no such fealty to actual physical dynamics. To call them simulations however either grossly misunderstands computational science or the very nature of how plants grow.
I think you would be right that simulation was a bit misleading. In my experience, a simulation is related to time, and updated in discrete time steps. Maybe "Procedural Generation" would be a better term...
A well written browser based node graph editor that can create procedural 3d meshes _and_ export as .obj _and_ you've permissively licensed it. This could be the seed for a whole host of procedural tools. Thank you Jim.