Official Survey and Discussion - Built-in Mesh and Greyboxing Tools (ProBuilder)

Filling out the survey, this is very exciting!
Is this related to https://portal.productboard.com/dzcznunfgebtky7ipmhrc22z/c/1839-native-block-out-tools by any chance?

 

Does or will ProBuilder support non-destructive workflows (CSG)? If not, that would be on my wishlist.

 

Sure, I tried that and SabreCSG. They both felt somewhat offputting, at least one created broken geometry with rather simple boolean ops. Not having received any updates in >4 years makes them unsuitable for production use.

The devs actually teamed up to make a new CSG tool called Chisel but they warn it is far from production ready and sadly, there was barely any development done on it in the past two years.

Last option is to use TrenchBroom (Quake map editor) and import maps. Problem is: you end up with a single static mesh. Making doors, lifts, platforms would have to be done in Unity after importing, and matching them up with a mesh. Then go back and make changes to the map and ... ugh.

I just recently learned that Dusk was made entirely with ProBuilder without the use of CSG boolean operations. That reinforced my notion that ProBuilder is still the best option when it comes to making Quake-style maps (which is basically grayboxing, except you end up polishing and using that graybox). Together with (nested) prefabs I think this can work really well.

 

A good bevel and boolean solver like Blender would be great.

 

after 4 years of new prefab workflow, we still have this issue on unity 2021.3.11 using Probuilder latest version 5.0.6.
as others mentioned in this thread:
https://forum.unity.com/threads/pb-meshes-dont-play-nicely-with-improved-prefab-workflow.600166/
prefabs always thinking PB objects have overrides. It's making it hard to maintain prefabs and whether they're up to date. making it hard to find actual overrides if we use some proBuilder objs in our prefab.
This is annoying and has hindered the speed of our work.
this is requested by many to be solved.

 

It would be amazing to have the boolean operations as intuitive as in tools for vector editing (see gif below).



Typically, in 3D programs it's more like this:
- Select two objects
- Then select the correct type of boolean operation (there are several buttons)
- Apparently, I've selected two objects in an incorrect order, so I have to revert changes and do this correctly.

Then repeat for who knows how many times.

I understand this is much more difficult to do in 3D space than in 2D, still would be amazing to have that.

 

One thing I'd love to see is an improved selection workflow. Too many times when I do a box selection it just grabs random vertices, and as a result I have to go through all of them one by one

 

Levels should be able to be treated like clay -- as well as decent hard-ops stuff too.

This means free-form and flexible tools.

Boolean-style CSG operations are mandatory nowadays. At least some semblance of a voxel-based environment designing solution. But then also LOD and imposter generation options as well. Even the most simple geometry often needs to be able to be displayed in an open-world solution, so creating LODs for them is needed. Vertex-by-vertex editing is mostly outdated in the kind of pipelines modern games need.

Sometimes, I feel Unity's tool design pipeline -- especially for even _moderately_ open worlds -- is just completely out of touch.

I use Unity's recently touted "workflow" for "optimization" in "open world games" (such as the "optimization" in Alba, for example) -- I wasn't surprised that project nearly failed because of its "iterative" approach to geometry generation!


Coming from a game artist and researcher who is familiar with many procedural tools and workflows, the best way to tool geometry, from experience, is brush, sculpt, and chain / placement tools (all of which Blender is great at -- and I abhor in Unity, since they often require addons/assets).
As an added side-effect, these "better" approaches tools (sculpting, placement, chaining) are also applicable in VR as well, and ironically, this is a result of their more intuitive usage, leading to a generally better UX.

Additionally, being able to "program geometry" using tools like Blender's geometry nodes (which, if I'm being honest, you might do A LOT better by simply porting / mirroring blender's geometry generation and other tools' results (and even adding your own operation handles for some of them) into Unity itself to give more flexibility (similar to how Houdini Engine is used in Unity / Unreal), and would give LOTS of great tools and a truly decent pipeline option to Unity users, with a low amount of overall effort on Unity's part (aside from simply grabbing a resulting mesh and setting boundaries / placement options and perhaps some UI / UX features via an addon in Blender potentially), and letting Unity users do only basic operations natively in Unity itself (i.e. verts/edge/face manipulation, CSG operations), as its main goal would be sending and receiving assets/geometry to (and from) Blender automatically, making Unity Assets be a part of Blender's Asset Library when in-use in Unity, or performing CSG operations, etc.in Unity and sending those small updates back to Blender, leaving the heavy geometry processing on Blender -- and keeping Unity out of the business of developing more crappy art tools.

This approach, I think, would lend a much more future-proof tool (and require less buy-in from higher-ups) and since Blender is constantly evolving and becoming more user-friendly (and also free), many of its tools, as they improve, just make Unity better as a result. You can use networking to talk to / from Blender and synchronize its results (and also add results to Blender to keep things mirrored).

I've seen this done in Unity already -- so you've already got a bit of a base to work from. But it would make greyboxing levels much more intuitive and freeform (especially if you let users rely on Blender to implement a VR editor experience). Generating Unity Instances from points in Blender would work very similar to how Houdini Engine works for Unity already. And the best part -- it's free.

Unity + Blender (Pros/Cons)

Pros:

• Networking Interfaces can exchange data and changes in realtime
• Existing base for geometry mirroring between Unity already exists in Unity's github repo
• Using Blender would be similar to using Houdini Engine in Unity (fully working example already exists)
• Access to Procedural Geometry and Sculpting Tools out of the box
  
• This access includes CSG (and potentially material) workflows
• Blender is a free/open-source tool that is always improving, meaning its increased value adds value to Unity
• Unity is only responsible for the in-editor "handles" that chain and place any meshes generated
• Unity can provide very basic low-level mesh tools (vertex/edge/face editing, CSG boolean operations) and mesh/object/instance placement tools
  
• More complex mesh operations can be passed off to Blender and can return to be visualized without the time-consuming export process (which is currently required)
• Asset Libraries in Unity can contribute -- and benefit from -- Blender's Asset Libraries and art ecosystem
• Purchased assets / tools from the Asset Store can be used in Blender as well (and be added to its Asset Library as a new Collection to be used in a scene or other projects, and can come over as simply an "instance" in Unity (since it exists as a gameobject/prefab in Unity already) allowing one to create complex levels with repeated elements -- without the struggle of importing/exporting mesh variations just because it is a "mesh" in Blender, but a "Prefab" in Unity -- as long as it is in an Asset Library, it is an "instance" of a prefab, existing between both software applications)
• Greyboxing is kind of a "duh" operation in Blender, but dumb meshes can be swapped out for more fancy ones with materials / animations / etc., since Unity is aware of these, and the User can use an addon in Blender to send them over to Unity in a special way.
• Hardsurface modeling could be combined with sculpted modeling quickly and easily
  
• It would be possible to partner up with Blender Institute and bring more users to Unity as more "official" support of it as the replacement for Blender's game engine might come with an official partnership (or at least it might be possible to simply sit pretty for a while and even gain support from the official Blender development team to help with Unity's integration / mirroring of its tools/API if it ever desires to).
• Although Blender is non-native, it could FEEL like Blender is being used natively by making the UI / UX mostly transparent (in a similar way that Houdini Engine does it -- i.e. by providing a handle-based UI for certain UX -- such as for splines, curves, or other visual modifiers and UI / UX that is defined in a Blender addon to assist in value-tweaks to certain nodes and parameters as they appear in Unity (similar to an HDA in Houdini -- a digital asset), letting Blender do the hard work, and letting Unity appear to do this _natively_ -- which would fit into both applications in a way that slots naturally into Blender's procedural "everything nodes" pipeline
• Unity gets to decide how "intuitive" its art tools are by leveraging the Geometry Nodes (of the "Everything Nodes" project) and slapping an interface on them, probably by developing their own addon that helps signal to Unity the kind of UI or 3D widgets particular named nodes or custom nodes would require for their UX in Unity (such as pseudo-CSG operations, or even dungeon generation)
• Sculpting, Brush, and Chain/Placement tools are VR-ready
• Blender is aiming to integrate VR in its toolwork pipeline, meaning Unity may not have to be the pioneer in that pathway and integrate its editor
  
• Artists, Animators, and Game Designers are already using Blender for their development/design work

Cons:

• Unity has no official support for Python
• Unity wants barebones greyboxing tools and nothing more
• Unity doesn't want to use or play nice with third-party tools
• Unity has to put effort into a tool that is not its own, making that tool non-native
  
• Blender would be the boss over what features stay / go in the future
• Unity would (potentially) have to make an addon or two in Blender to control its output to Unity in order to maintain feature-parity with something like an HDA digital asset from Houdini (for custom procedural tools and pipelines)
• Keeps Unity out of the "business" of developing crappy art tools
  
• Procedural tools wouldn't be as good as Houdini -- but for free? -- It's definitely a start!
• Doesn't fit with Unity's (currently vague) greyboxing direction -- but provides all it will ever need (and more!) in a single tool solution (such as random greybox dungeon generation), so...
  
  
• It's me suggesting this so... it's probably "hard".
• Some designer @Unity might need me to guide them.

 

Here I have some more minor, cool features that could land in the backlog.

A nicer way to bevel corners: (skip to 1:22)

A cool feature in ue5, I've already had an occasion to use it, and It's almost perfect. I also love the interface that pops up from the left but only when needed (a bit like in Maya).

Some cool features from a video game (made in unity) that have house-building elements:
https://twitter.com/SoftwareIncGame/status/1165216090978316289
https://twitter.com/SoftwareIncGame/status/1468254803214147584
https://twitter.com/SoftwareIncGame/status/1468275145399750656
https://twitter.com/SoftwareIncGame/status/1021379550796820485


Also, would be nice to get an implementation of splines in probuilder.

 

Absolutely agree on the Cube Grid suggestion. Ever since I saw that I was drooling lol. The cube grid tool in UE5 is a game changer for workflow and is extremely simple to use for blockouts when you need a specific kind of prototyping. I tend to think more in that way, so I've been thinking of building my own solution in Unity for prototyping like that. Having support for it in ProBuilder would certainly be helpful though

 

Honestly, unity would have to first do something about their grid system and the fact that pro builder (and poly brush) meshes override in every scene.

Especially the grid system, UE5 now has two separate grid systems, one for placing the meshes and the second for creating them via cube grid. This becomes an annoying issue whenever you want to move the mesh you've just created, then go back to edit it a tiny bit.

There is also a problem with UV and mesh generation. You can't use this tool for anything than rapid prototyping, even If you intend to make a game with voxel graphics or a quake-like.

 

Well yeah, a blockout tool is a blockout tool. It doesn't need to be supported with all that extra stuff like UV mapping. Its just so you can block out a design for a level really really rapidly. Textures aren't usually part of a blockout. You'd export your blockout and build your nice fancy scene geometry in something like Blender, working around the blockout version. But I imagine simple UV mapping each block face as the full UVs would be sufficient for a blockout if you really needed to use some textures for something

I just think sometimes if you try to hard to make a tool into an "everything" tool, you will almost always fail to make it good at doing "specific" things. I'd rather have a really really simple blockout tool for more involved game development and art workflows than to have it be a dull swiss army knife tool that beginners can latch onto and not really learn any good workflows with other programs

 

Honestly, I like texturing pro builder meshes in prototypes, so having an option for that is always a big plus.

 

Stairs still broken! Cant make curve, steps have wrong angle.

 

I really hope that polybrush gets some love too! It hasn't been update for a long time

 

Honestly, I wish polybrush would be somehow merged with probuilder.

It's a separate package that attempts to do similar things but with worse execution in every possible way.
I mean, why do the polybrush and probuilder have separate "exporting" tools? There is fbx exporter package.
Or why do you need two separate components for the probuilder and polybrush? Both break prefabs in different ways.

 

For poop sake, PLEASE implement Blender-like shortcuts that are specific to editor context. Coming to Unity from Blender or other 3d editors is just terrible. Allow us all the basic mesh editing tools, especially dissolving and deleting verts/edges/faces. Nobody should have to import something as simple as a subdivided mesh from Blender because Unity isn't able to do it. Unity should have subdivided mesh primitives, or at least Probuilder should. Absolutely ridiculous. Also, vertex snapping!

 

Blender shortcuts for scaling, moving, and rotating along the different axis are a great timesaver for me.

 

"Enabled by Default" usually means "Adds a bunch of hotkeys that you don't want, and conflicts with things you already use daily." Please do not make it difficult to disable it. I have already played with the existing versions and am not interested in scratch modeling inside Unity.

 

Love to see the active responses to the feedback @gabrielw_unity

It's refreshing seeing lots of older systems come back to life recently, especially in these times divided over render pipeline differences and such Keep up the great work!

Also I'm curious... As focus was given to enable developers to extend and take advantage of the recently added Spline tools, has any similar thought been given to enabling certain outlets for developers to extend ProBuilder and give it custom functionality, or is that wayyyy out of scope for what it's intended for?

 

I know about contextual tools. Though the UE's solution is so good due to a greater execution. They've managed to redesign the entire editor, so all you see is a scene view, top bar, inspector, and little hierarchy window. Everything else shows up only when needed.

Also, a feature I think unity doesn't have right now, is the possibility to edit the pivot position of the mesh (instead of moving an entire mesh).

 

I wish we had something like BakeRS for baking rotation and scale.

 

Also, plz don't forget about geometry/prefab painting! Plz make it similar to prefab brush + / YAPP from assetstore! It's a very necessary tool for level designing! Also plz support terrain for prefab painting, don't want to use the default terrain painting because it really sucks and poorly developed! If it will support terrain it will be very easy to add scripts/ logic to the vegetation and would finally allow us to align trees/rocks with the slope and use LODS with grass and make it possible to use it with DOTS workflow!

 

I have a bit more specific feature coming out of a more complex issue. In Polybrush, you can use a tool for vertex painting, then use that feature in a shader. More specifically in the shader graph.

But by default, you can't make a shader graph that uses vertex painting and supports 2D lights in URP. At leastnot in 2021 LTS.

Either enable that feature or create some sort of solution for painting 2D sprites by editing a texture, for example:

I personally prefer the second option honestly.

 

Tried Probuilder for some simple box levels, quickly realized simple features are missing and moved to umodeler since I got it randomly from some bundle. https://forum.unity.com/threads/easy-way-to-remove-excess-geometry.536996/

 

I'm not sure if anyone has mentioned this, but a big reason we can't use ProBuilder / Polybrush for our production is that it stores *way* too much in the main scene file, and generally is not polite with source control dirtying.

Ideally making a small change to the greyboxing should store only a small change in source control. Currently the entire binary data for the meshes and anything else associated is dumped into the Scene file, meaning two people can't work on the same scenes together.

Ideally two people can move brushes / control points around independently, and it will merge, just like when moving separate Transforms around the scene. Binary meshes and other assets should be cached in the Library folder, not committed to source.

 

Commented before, I have to mention "remove edges" (and similar operations). If two faces share an edge, removing it should connect the faces. In some cases, all the vertex would be kept, but for some situations, these would be removed. This should work for edge loops and such.

 

Has any of this been implemented yet?
This thread has gotten pretty long and I don't want to post requests for things that maybe I can do now.

 

Also, in the worst case, the idea will end up in the backlog for a few years.

 

That's a good thing. Hopefully, new tools will have comparable features to the ones made for games like quake 3.

 

I took a look at workflow done in Source 2 (valve), and it looks so clean and nice to use. If we ever achieve this level of features, I would be a happy man. Here's a video demonstrating some of the things: