Live data from Hacker News

Show HN: Simulate 3D plants in the browser

plant.max-richter.dev

41–50 of 51 posts

Re: Show HN: Simulate 3D plants in the browser

#41
post #27
post #21

Earlier quoted context omitted.

I guess because it is procedurally based, likely using an L-system. https://en.m.wikipedia.org/wiki/L-system We use things like this in 3D art and animation. For example the paint system in Maya. This was used to create the forests in Shrek. Question to OP… have you considered making this available as a Blender plugin?

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 have not yet implemented L-Systems.

Regardless, what you have produced is kick ass. L-syetm or not, it demonstrates the complexity of nature.

Re: Show HN: Simulate 3D plants in the browser

#43
post #40
post #33

Earlier quoted context omitted.

That wouldn't make it a simulation, it's just a different way to generate 3D representations.

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 aspec…

"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.

Re: Show HN: Simulate 3D plants in the browser

#44

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 ha…

That's super cool! And thank you for the nice words :)

A rust/Wasm rewrite of the geometry generator is very much on the roadmap. Currently getting my feet wet with rust during advent of code.

Re: Show HN: Simulate 3D plants in the browser

#45

Brilliant ! If you could also add a "time" node , it would even allow for some basic animations. Lovely project overall.

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.

Re: Show HN: Simulate 3D plants in the browser

#47
post #43
post #40

Earlier quoted context omitted.

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 aspec…

"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 t…

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...

Re: Show HN: Simulate 3D plants in the browser

#49
post #30

Earlier quoted context omitted.

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…

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

Re: Show HN: Simulate 3D plants in the browser

#50
I really love this!

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.

Post reply on HN