UE Toolbox FAQ

Pricing?

In it’s current primordial form, I’m releasing binary versions of this plugin for free. This can’t continue indefinitely, as significant (read: expensive) C++ engineering effort is involved. I intend to have pricing similar to other plugins that substantially enhance UE, like VoxelPlugin or Mesh Morpher. With options for custom licenses for large studios, and an low-priced option for indies and low-income countries.

What about Source Code Access?

Only large entities with significant legal resources like Epic Games can make their source freely available while still enforcing their copyrights (and even they struggle with regions where copyrights enforcement is lax). As an independent developer, the risk of having parts of my plugin cloned is very high, and an existential threat to it’s continued development. So I have to be much more careful with code access.

I intend to make UE-dependent code available to paid licensees, ie so you can include the plugin in custom Editor/Engine builds, similar to a UE Marketplace plugin. Core parts of the Toolbox are independent of Unreal, and these will be provided as binary dependencies (similar to how UE already includes many binary third-party dependencies), with an option for source access to those libraries under custom license.

Unreal Marketplace? Fab?

The Unreal Marketplace has been deprecated, and Fab seems to be quite limited in comparison. Although the pricing is very fair, personally I found the UE Marketplace to be less than ideal as a distribution mechanism for serious Engine/Editor “middleware” extensions, and I don’t expect Fab to be any better in this respect. The Gradientspace UE Toolbox already includes it’s own auto-update functionality, and one of our future plans is to include an alternate plugin manager that is not dependent on Epic infrastructure.

Future Plans?

I rely heavily on user feedback when deciding what features and improvements to pursue. In addition to email and social media (Twitter, Mastodon, YouTube), the plugin includes an in-Editor Feedback Tool you can use to send bug reports and feature requests. That said, I do have many plans, here is a high-level brain-dump of directions I might pursue, given your funding and encouragement:

ModelGrids: As a standalone Actor/Component/Asset type, I have many ModelGrid features in the prototype phase, like multi-frame animated grids (see a demo here) and multi-grid assemblies. I’m also developing infrastructure that will enable ModelGrids to scale as a large-scale world representation (see brief demo here). This could be used “behind-the-scenes”, ie as the coherent physical/simulation representation of a high-resolution mesh environment, or directly as an Environment/Landscape system. This doesn’t necessarily mean little blocks - with procedural meshing, those blocks can be turned into smooth surfaces on-the-fly, providing the benefits of meshes but still retaining the dynamic runtime editing capabilities of a coherent volumetric-cell-based world (here’s a very basic example of what I mean by that).

Procedural Asset Generation: Geometry Script is now the standard method for procedurally generating mesh assets inside UE, however baking your live DynamicMeshes into shippable StaticMesh assets is left as an exercise for the reader. In UE5’s Lyra project I helped the team build a quick-and-dirty prototype system for automating that process, but it was never turned into a real Engine feature. Similarly, although Geometry Script is great for BPs, it’s not actually that easy to do similar procedural generation with C++ (which can be wildly more efficient). And there are textures and materials to generate, too…

Placement and Transform Workflows: The Editor’s “Placement Mode” and “Foliage Mode” are both ancient, and extremely basic compared to what is trivially possible by leveraging the infrastructure available in Modeling Mode (the Pattern Tool I initially built in Modeling Mode is a basic example). The QuickMove Tool is a first step towards an overhaul of Editor Selection & Placement that will be focused on efficiency and flexibility for expert users. Game Design via “Part Kits”, like Fortnite walls/floors/ramps, is also increasingly common and yet there is inexplicably no interactive toolset that specifically supports this kind of workflow.

Advanced Instance Workflows: PCG is a cool way to populate huge worlds, but it’s rarely the endpoint, because inevitably artists want to manually edit the results. And although (H)ISM’s are critical to UE performance, the Editor toolset for directly working with ISM Components & Instances is abysmal. I created the ISM Editor tool in UE’s Modeling Mode to help Matrix Awakens artists fix up the huge numbers of procedural placement bugs that crop up in a 4km-wide city, and the Harvest ISM tool to help optimize UEFN games. But these were emergency side-projects, where what is actually needed is an ISM-focused Editor toolset.

Optimization Workflows: Every internal demo and game I worked on at Epic involved teams of expert UE Engineers working closely with artists to optimize the content to hit game and render-thread targets. The Engineers had to be involved because so many of the modern UE features involve complex dependencies between project settings, cvars, and opaque checkboxes on meshes, textures, materials, actors, and components. Increasing amounts of “invisible” asset data like Lumen Cards, Nanite Fallback Meshes, Collision Mesh overrides, etc, have made it difficult to even know exactly what you are seeing in the viewport. The bar is pretty low here, and proper tooling would make these advanced techniques much less complex to manage and tune.

Import/Export Pipelines: Unreal has an very powerful toolset for procedural asset modification (ie geometry script), but inexplicably there is no connection between geometry script and the UE Editor’s import/export systems like Interchange or Dataprep. I’ve also observed that many non-games users of Unreal struggle with trying to get the semantics of their external data to co-exist with the deep game-asset assumptions that are baked into UE. I think these are tractable problems that can be addressed with end-user-programming.

LOD Workflows: Despite the hype, Nanite mesh assets seem to be accumulating LODs, rather than shedding them. You’ll still need render-mesh LODs for low-end and last-gen platforms, as well as fallback meshes, custom collision and distance-field meshes, shadow imposters, and so on. And with huge instance counts, the need for high-quality HLODs is more critical than ever. I introduced several of UE’s state-of-the-art LOD technqiues, like the AutoLOD Tool in Modeling Mode, and the Approximate Actors HLOD method, but they only scratch the surface of what is possible.

Editor Scripting: We are in a weird place right now in Unreal Engine, where Blueprints are wildly popular with users, but Epic only wants to talk about Verse, a language which is heavily focused on gameplay scripting. So I am hesitant to invest heavily in new Blueprints-based tooling. It’s a bit far-out-there, but as a side-project I have been developing a new C#-based node-graph programming environment, that easily integrates nodes and code, and can already talk to the UE Editor (check out some tweets here and here). I think there is a lot of potential here both as an Editor Scripting solution, as well as a general engine-agnostic “pipeline” scripting environment.