Back in June, Ben shared some information regarding X-Plane’s next generation lighting pipeline. It’s now time to go back to the future and talk about another piece of the next generation: Vegetation. In case you have missed it, Chris and Thomson made an awesome preview video for this as well:
As you can see, vegetation got a big upgrade from what we currently have. Instead of one or two quads wedged into each other, we now have fully modeled and animated 3D trees, and lots of them. The vegetation animations are based on the current wind conditions, giving them a very nice and dynamic feeling. They also come pre-seasoned for extra flavour, so their look will match whatever local season you are currently in. Naturally this led to a lot of questions, so I’ll try to answer the two most common ones that I have seen:
How do the new trees work and what happens to my old ones?
While the vegetation engine is built from scratch, it uses the existing .for file format. Of course the .for file format received a few additions to be able to deal with 3D meshes as well as some additional parameters, but the key take away here is that if you already have custom forests, they will continue to work. It also means that if you are a scenery author, you will be able to extend your trees into the third dimension and provide updates to your users. All the vegetation that ships with X-Plane has already been enhanced with 3D versions–Petr has done an absolutely phenomenal job crafting these trees. So if you have scenery that is using the built-in forest library, you don’t have to make any changes to get them into your scenery.
The quad based trees will continue to work as before if you have a .for file that hasn’t been updated for 3D trees. They will however take advantage of the new vegetation engine for rendering. Since the forest system uses the same scenery lookup rules as before, it’s also possible to force old scenery with custom .for files to use the new 3D trees using a custom library.txt file. I’m sure there will be at least a handful of people who’ll want to do that. But the general take away here is that the new vegetation system should just work without any compatibility issues.
Lastly, the wind animations: These are done dynamically on the GPU, although they are driven by parameters provided through the .for file and additional vertex attributes on the mesh. This makes it easy to make the trunk of the tree very stiff and resist bending, for example, while the leaves can freely flutter in the wind. This means that you don’t have to rig trees in any way; as a scenery author you can just paint in the different parts of the trees in Blender for example, and let the system drive all the animations.
We will have both tooling and .for file specification updates available for scenery authors in the future, so adopting 3D trees should be very painless.
Surely this is going to be insanely slow, right?
When we set out to create the next generation vegetation engine, we knew that we’d have to build a system that can handle millions of trees. While it’s still too early to give you anything in terms of hardware requirements, I can say that the system is definitely built to be able to cope with a lot of trees. This is possible because the new vegetation engine is designed to use very little CPU processing, and instead moves the majority of the work to the GPU. A lot of the heavy processing for trees also happens very early in the frame, at a time when the GPU was mostly idle waiting for actual drawing commands from the CPU. For anyone curious about the technical aspect of this, we make heavy use of compute to cull the list of trees down to just the ones that are actually visible by the camera. We then use that information to prepare one or more indirect draw calls. This way the CPU can send forests that span multiple kilometers for processing and the GPU will generate the rest of the data all by itself.
Drawing lots of geometry is, of course, more expensive than not drawing it. Even if we only ever draw what is actually on screen, drawing anything isn’t free. So we also employ a classic LOD scheme here. Scenery authors can create multiple 3D LODs for their trees, and there is an additional billboard LOD generated at the end of the chain. The billboards are just flat tree quads that always face the camera, so they’ll still give the illusion of plenty of geometry complexity at a distance. This way we can fill the near view with maybe a few hundred or so complex 3D trees, and then fade over to the cheap billboard to fill the rest of the scene. LOD decisions are also done on the GPU on an individual, per tree basis, so the GPU is quite literally creating its own optimized workload.
The next generation tree tech makes heavy use of features that have only become possible for us thanks to Vulkan and Metal. In fact, it’s not just the tree tech, the new lighting and other next generation features make heavy use of features we finally have access to. The road to Vulkan and Metal wasn’t just to make the sim faster, but also pave the road for what’s to come next. So what does this mean for the venerable OpenGL rendering backend? Sadly, there is no next generation future for OpenGL, as it just isn’t possible to support it. But fear not, this is only the case for X-Plane’s own rendering. Plugins will continue to be able to use OpenGL, just like they are right now under Vulkan and Metal.
So if you have plugins using OpenGL that work with X-Plane 11.55 under Vulkan or Metal, it should continue to work in the next generation world as well. The one exception here being the modern3D drawing phase. Due to the new lighting engine being completely photometric, old school 3D drawing doesn’t work anymore because it’s not in on the joke that pixels aren’t plain rgb8 triplets anymore. I can’t talk about a replacement yet, but this is certainly something you might want to keep in mind if you are about to start writing a new plugin today.
Other than that, custom panel and GUI drawing will continue to work just like it does right now.