Let me kick off this section by asking the first question (@mods: if this is better placed in “Software”, feel free to move it)
This may be a trivial question to some, but it’s something that has been on my mind for a while now. Why are FSPMs so slow compared to modern game engines?
The way I see it, there are a lot of similarities in capabilities:
Both describe a dynamic 3d-environment
Both describe ‘hidden’ processes (FSPM: e.g. photosynthesis, resource allocation; game engine: real-time inputs for character movement, behaviour of NPCs, game checkpoints, etc.)
Both describe physical interaction (in the digital world) to some extent (e.g. volume collision)
There are instances of both FSPMs and game engines that use a raytracer
Yet my field of maize takes 10 minutes to grow to harvest, while Harry Potter zips around on his broom at 60 fps.
Could someone explain in plain English why this is the case, and why we cannot simply copy the techniques that make game engines so fast to FSP models?
That’s a great question. I absolutely don’t know the answer, but I wonder if it has to do with the precision of the ray-tracing simulation that is required by FSPM. Maybe video games need just a realistic aesthetic rather than realistic ray tracing, and maybe a realistic aesthetic doesn’t require precise ray tracing. I feel that @gaetanH might have a lot more to say about this topic.
It may also be related to the fact that behind video games there is a multi-billion industry - while the FSPM community is much smaller and mostly publicly funded. It might be that, in principle, those software for videogames could be adapted to FSPM, but no one has done it yet because of the work required. I might be wrong on this - this is just a guess.
Hi, I will preface this by saying two sentences about myself: I have worked in Visualization since 2014 and am primarily a visualization developer. I have been working with Unreal Engine since my teenage years and have professionally used it since 2019. Before that, we primarily used ViSTA.
I don’t quite get the question. To me there is little to no overlap between FSPM tools and Game engines. Harry Potter does not zip through mountains that are created on the spot. The moving of triangles on the graphics card is handled in a matter of O(1) depending on the amount of triangles. That does not even include optimization tricks like pixel-level displacement.
If you want to do a comparison, compare FSPMs to SpeedTree. That is, in my opinion, the only comparison that can be made. And there you already see all the “tricks of the trade” that the generator uses. This starts with using basically cardboard cutouts of leaf geometries, which is still used in modern game engines.
There is a lot of stuff that goes into programming a game engine, and most of it is just tricks to make the world appear as if it was real rather than striving for realism. While impressive, there is hardly any lesson that can be learned from Unreal Engine that realistically transfers to FSPM simulation, aside from maybe this: Put as much computation on the graphics card if the data can realistically stay there for as long as possible without needing to be transferred back to the CPU.
I think it all boils down to light interception. It is by large the one process that takes the most time to compute for both FSPMs and games. In FSPM the rest is pretty fast generally, when the radiation interception is computed, the energy balance + photosynthesis only takes a few milliseconds.
As @dhelmrich said, game engines takes a lot of clever shortcuts to render the scene for your eyes, and one of the most important probably is that it only considers the viewpoint of the player, i.e. the pixels on your screen. Basically you only render what you see, and discard every other object that is not in your direct field of view.
In game engines we also mostly use what is called z-buffering + rasterization. This is a very fast method compared to ray tracing (and other similar methods), but it makes a lot of simplifications so the rendering is good but not perfect. Now you can find some ray tracing in game engines, but not entirely because it’s too expansive. You can see a good explanation here: Ray Tracing: How NVIDIA Solved the Impossible! - YouTube
When you want to be as close to reality as possible, there is no better way than using ray tracing. That’s why we use it when we need high precision, but not real-time. That is what the film industry uses, a good video about this is this one: Disney's Practical Guide to Path Tracing - YouTube
If you’re OK with some simplifications though, you can still use the rasterization method, and this is what we do in our model, Archimed (kind of). But it is still way slower than a game engine. Why ? Because when we compute the scene, we compute every object in the scene, because we want to know how much radiation was absorbed by those objects.
To do proper light interception in a game engine like Unreal Engine (such as a setup of CPlantBox and Unreal Engine via our Synavis Project), it would still be of importance to use path tracing in combination with no optimization. It will not be as pretty on your local machine, but likely still okay to use in the cloud. Alternatively, moving the pawn to the correct location and then waiting a tick before reading the buffers off the GPU might also work. All of these methods have to be calibrated for them to make sense in practical applications.
Amazing answers above and they hit the basic confusion: FSPM is not just about rendering beautiful plants Just wanted to reinforce what was said earlier, our FSPM softwares are not as optimised as they could be per application. This is not only due to lack of investment compared to one of the largest industries, but also the fact that FSPM software is somewhat generic. There is a reason why there are so many game engines and games have to be optimised even for different consoles vs PC (and still can get a lot of bugs…). It’s all about throwing lots of engineering to fine tune one particular application in one particular context, we cannot afford that.
Oh yes, this is I think a very good point: Epic Games has a LOT of engineers partly just working on the engine, or working on parts of the engine for the benefit of a game. That is, if you compare that to how research groups work, an unfathomable amount of software engineers, and designers(!), and others.
Wow, didn’t expect this to get this much traction
Thank you all for your comprehensive answers! Haven’t had time yet to take a deeper dive into your replies, but will definitely take a look at the provided references.
(@mods: if this is better placed in “Software”, feel free to move it)
Just wanted to reinforce what was said earlier, our FSPM softwares are not as optimised as they could be per application. This is not only due to lack of investment compared to one of the largest industries, but also the fact that FSPM software is somewhat generic. There is a reason why there are so many game engines and games have to be optimised even for different consoles vs PC (and still can get a lot of bugs…). It’s all about throwing lots of engineering to fine tune one particular application in one particular context, we cannot afford that.
