pipeline: published

_posts/2024-09-01-pipeline.md

@@ -1,5 +1,5 @@
 ---
-published: false
+published: true
 title: 'Production pipeline'
 ---
 
@@ -9,9 +9,9 @@ Previsouly I talked about [our](/workflow-1/) [workflows](/workflow-2/) or [auto
 
 ## Requirements
 
-The first thing needed to get started is an Unreal project. But since we have [hundreds](/marketplace/) of [Marketplace](https://www.unrealengine.com/marketplace/en-US/store) assets, we don't really want to start from a blank Unreal project.
+The first thing needed to get started is an Unreal project. But since we own [hundreds](/marketplace/) of [Marketplace](https://www.unrealengine.com/marketplace/en-US/store) products, we don't really want to start from a blank Unreal project.
 
-Also we'll need a [RoadRunner](https://www.mathworks.com/products/roadrunner.html) project. And as with Unreal, we also have quite a lot of custom assets (e.g., markings, road types) that we'd need to import in any new blank project.
+Also we'll need a [RoadRunner](https://www.mathworks.com/products/roadrunner.html) project. And as with Unreal, we also have quite a lot of custom assets (e.g., markings, road types) that we'd need to import to any new blank project.
 
 And depending on the experiment, we might also need other projects in other tools, or have some dependencies to internal tools or frameworks. That could include for example custom [LabStreamingLayer](https://labstreaminglayer.org/) apps, tools to manage our clusters or a [framework](https://github.com/uge-lescot/CADisp) to interact with in-car displays.
 
@@ -40,7 +40,7 @@ For us, the actual first step to start a new project is to fork this template su
   * Since our template projet is ~500GB, having multiple instances of that would quickly add up in local space and bandwidth
 * Synchronize with the upstream superproject, both ways
   * You can merge new features/fixes coming from upstream
-  * The upstream repository can cherry-pick specific changes from the fork
+  * The upstream repository can cherry-pick specific changes from the forks
 
 This is really useful since we're working on multiple projects per-year, each having a lot of similarities ("*they're all racing games*") while still requiring very specific features. And since we're working with very experimental stuff, having the ability to propagate any new development from one project to another is really beneficial.
 
@@ -62,11 +62,11 @@ A big part of my job therefore is to maintain this template superproject
 
 Let's jump over the fun part, which is using Unreal to create our virtual worlds, and go to the boring part, which is generating a usable end-product from that. By this, I mean either an executable for interactive experiment, or videos for non-interactive.
 
-Thankfully, Unreal is pretty of good at both [packaging](https://dev.epicgames.com/documentation/en-us/unreal-engine/packaging-unreal-engine-projects) and [offline rendering](https://dev.epicgames.com/documentation/en-us/unreal-engine/rendering-high-quality-frames-with-movie-render-queue-in-unreal-engine), so as usual, most of the heavy lifting is handled for us. But we still need do complete the last mile ourselves, to tune all of those pipelines to our needs.
+Thankfully, Unreal is pretty of good at both [packaging](https://dev.epicgames.com/documentation/en-us/unreal-engine/packaging-unreal-engine-projects) and [offline rendering](https://dev.epicgames.com/documentation/en-us/unreal-engine/rendering-high-quality-frames-with-movie-render-queue-in-unreal-engine), so as usual, most of the heavy lifting is handled for us. But we still need to complete the last mile ourselves, to tune all of those pipelines to our needs.
 
-We wrote a bunch PowerShell scripts that handles all of that, from bundling other dependencies (e.g., sensors acquisition tools) alongside Unreal packages, to efficiently robocopying all of that to our deployment servers.
+We wrote a bunch PowerShell scripts that handle all of that, from bundling other dependencies (e.g., sensors acquisition tools) alongside Unreal packages, to efficiently robocopying all of that to our deployment servers.
 
-And I say server*s* plural, because we have a specific one for each of our simulator (hardware), because each one of those has its own local network. So usually, each fork will also have to create its own main entry-point PowerShell script to at least specify which server the product should be deployed to (along with other possible specific requirements). But that's usually a one-liner.
+And I say server*s* plural, because we have a specific one for each of our simulator (hardware), because each one of those has its own local network. So usually, each fork will also have to create its own main entry-point PowerShell script to at least specify which server the product should be deployed to (along with other possible specific requirements). But that's usually a one-liner, and nothing other than this is preventing the project from running an another simulator.
 
 We also have similar scripts for other "side-build" stuff, like static lighting (but now  [Lumen](https://dev.epicgames.com/documentation/en-us/unreal-engine/lumen-global-illumination-and-reflections-in-unreal-engine) exists...). Maybe in the future we'll also add HLOD builds for example.
 
@@ -88,4 +88,4 @@ And we also have Discord bots for deployment of builds into each of our nDisplay
 
 The production pipeline outlined above allows us to really focus our work on what's important: building immersive worlds and scenarios, tailored made for each research subject we're working on. The template superproject means we can start working immediatly, without any other requirements than clicking the *Fork* button. And the build scripts included within the template, along with the Discord bots, make it so that what you see on your desktop can be running on any of our simulation platform in just a few minutes, with just a Discord message needed to trigger the process.
 
-This pipeline works really well for us, and we're constantly looking for new ways to improve it. What works for us might not work for you, but understanding your overall process and making it as smooth as possible for all parties goes a long way to making everyone's job that much better.
+This pipeline works really well for us, and we're constantly looking for new ways to improve it. What works for us might not work for you, but understanding your overall process and making it as smooth as possible for all parties involved goes a long way to making everyone's job that much better.