Gradientspace UE Toolbox FAQ

Pricing?

Currently Gradientspace Toolbox is available on FAB (https://www.fab.com/listings/0588e89f-d6fe-482d-882c-bd0e62d8e1d6) for $25 USD for a personal license seat, and $50 USD for a professional license seat.

What about Source Code Access?

The FAB plugin comes with all UE-dependent source code. However the core of the plugin depends on C++ libraries that are not dependent on linking to UE and are only provided as precompiled binary DLLs. The code for those libraries is available for a higher fee, negotiable depending on your project budget (my motivation here is mainly to prevent cloning and unauthorized redistribution of the plugin, not to try to squeeze small developers).

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.