Page MenuHome

Blueprint tool
Needs RevisionPublic

Authored by Pablo Dobarro (pablodp606) on Thu, Jul 25, 5:44 PM.
Tags
None
Tokens
"Love" token, awarded by brilliant_ape."Love" token, awarded by Okavango."Love" token, awarded by Kramon."Love" token, awarded by amonpaike."Love" token, awarded by ace_dragon."Like" token, awarded by erickblender."Love" token, awarded by xrg."Like" token, awarded by billreynish.

Details

Summary

This is the implementation of the blueprint tool that is currently on the sculpt branch. It is just a prototype implementation to start polishing its behavior.
Right now it works as a modal operator with multiple states. It would be ideal to integrate it with the tool system and gizmos.
We should also decide what is going to be the scope of this tool:

  • Simple tool only for scene layout
  • Main tool for geometry creation, compatible with the current add mesh operators
  • Full features tool for providing a CAD workflow for hard surface modeling. It should include booleans, modifiers, and compatibility with the future node system

Diff Detail

Repository
rB Blender
Branch
blueprint-tool (branched from master)
Build Status
Buildable 4156
Build 4156: arc lint + arc unit

Event Timeline

What we really need in Blender, are basic tools to let you drag out primitives in the scene. When you add a cube, plane or the other primitives, it's often a lot more useful and intuitive to just 'draw' out the object in 3D space, with auto-snapping to surfaces, and a grid. This is more or less exactly what you've done, which is superb.

The related 'Create Object' tool todo item is here: T57210

The main thing that is missing, is support for the full set of primitives.

I think we should split the tool into separate entries for

  • Plane
  • Cube
  • Cylinder
  • Cone
  • Sphere
  • Torus
  • Polygon <- this is more or less your tool currently

Technically, the main challenge is to keep the redo panel working for the primitives so you can set the U and V segments. Perhaps @Campbell Barton (campbellbarton) has an idea here.

As for your question, ie should this tool do all sorts of other tasks, I think no. We should start by getting the basics to work well, so it's easy to add primitives interactively into the scene. More advanced tools and options can be added later, probably as separate tools.

We should also decide what is going to be the scope of this tool:
Simple tool only for scene layout
Main tool for geometry creation, compatible with the current add mesh operators
Full features tool for providing a CAD workflow for hard surface modeling. It should include booleans, modifiers, and compatibility with the future node system

I think this tool is very useful by itself already without generating modifiers or nodes. For a more procedural modeling type system we should wait until there is a bigger design and plan to go in that direction, it's not something we can do half-way without creating a mess.

To me it seems this should be separate from the planned add primitive tools, even if possibly some code or UX could be shared. I would treat this blueprint tool more as a modeling tool that can quickly create extruded shapes, and automatically perform boolean ops when extruding from or into existing meshes. Assuming we can get booleans working reliably, since dealing with overlapping faces is not working so well right now. If it's a modeling tool that would mean it needs to work in edit mode too, and be implemented using BMesh. It can still work in both object and edit mode using the same BMesh code.

@William Reynish (billreynish), I'm not sure we should wait for add primitive tools before adding this one. I guess @Campbell Barton (campbellbarton) already planned to work on those at some point, and if @Pablo Dobarro (pablodp606) can help all the better.

@Brecht Van Lommel (brecht) Sure, I also think @Pablo Dobarro (pablodp606) can help. This tool is a great basis for many things we should add.

My main point is:

  1. This tool should work in a consistent way with the add primitive tools, using the same grid and snapping system. This already seems to work very well here, and we could base the primitive tools on this tool.
  2. Overall we should aim to make simple things simple. I think this tool, while great and super useful, is more of a speciality tool compared to the basic ability to add the main primitives. So it's just a little odd to have a super nice visual interactive tool for adding arbitrary polygons, but not having it for the basic primitives. The toolbar makes things more prominent, so it makes things a little asymmetric in that way.
  3. In terms of priority, I think we should try and get the basic primitives working before adding more advanced features such as auto-booleans, and other more advanced use-cases.

That's all - in terms of how to proceed, I think for sure we could just merge this after release, and then work to get the primitives working before the 2.81 release.

@Campbell Barton (campbellbarton) What are your thoughts, technically, on how this works with the grid and snapping system?

Not actually reviewing the code yet since the design is not decided on, but left a few comments.

I guess the main tricky thing here is making this work as a tool. It's a bit unclear to me how to best implement such multi-step tools and how the UI should work for them. One way would be:

  • When the tool becomes active, show the blue grid as you move the mouse, similar to a gizmo
  • As soon as you click, enter the modal operator and go through all the steps
  • After completion, show the blue grid again

That probably works ok, and you could tweak for example the extrusion depth afterwards in the adjust last operator panel. Though of course it's not fully taking advantage of the tool system. You could have a gizmo to adjust the extrusion depth (or other parameters), but then how do you transition to showing the blue grid again? Making the drawing on the plane non-modal could be useful too, but how would the user transition to the next step?

source/blender/editors/object/object_blueprint.c
654

ot->prop should only be assigned for one property. It's mainly used for when an operator has multiple modes as an enum, that needs to be exposed as a submenu in menus.

1151

The code here should be implemented using BMesh, which can be converted to Mesh at the end when needed. I'll probably simplify the code some.

mface and tessfaces is something we are trying to deprecate.

1422

A fixed distance of 100 does not work at all scene scales.

Not actually reviewing the code yet since the design is not decided on, but left a few comments.
I guess the main tricky thing here is making this work as a tool. It's a bit unclear to me how to best implement such multi-step tools and how the UI should work for them. One way would be:

  • When the tool becomes active, show the blue grid as you move the mouse, similar to a gizmo
  • As soon as you click, enter the modal operator and go through all the steps
  • After completion, show the blue grid again

Yes that's pretty much exactly how I think it should work. This would work for polygons as well as the primitives.

Brecht Van Lommel (brecht) requested changes to this revision.Fri, Jul 26, 3:01 PM

Marking as request changes since this code is not finished. You can also set it to Planned Changes for this when submitting the patch.

This revision now requires changes to proceed.Fri, Jul 26, 3:01 PM

@Brecht Van Lommel (brecht) The gizmo for this tool should be everything that is under the BLUEPRINT_STATE_PLANE state. (white transparent grid with fixed size). When you start the tool, the modal operator should start directly from BLUEPRINT_STATE_DRAW (blue background, dynamic size and a drawing mode active).
I'm not sure if this is possible, but can we add two gizmos at the same time when the tool is active, the default grid gizmo and another one for adjusting the extrusion of the last operation. The ones that adjust the extrusion should grab the input first, but the user should be able to lock the plane and start a new drawing operation by clicking on any other area.

@William Reynish (billreynish) The main problem for supporting adding any primitive using this tool is the rendering code. It is designed to render only polygons and extruded shapes, so I would need to add a different rendering code for the specific case of a sphere and a torus. I think that for that kind of tools, it would be better to have a specific gizmo designed for each primitive.
On the other hand, we can add anything under the BLUEPRINT_STATE_EXTRUDE state and it already has flags to disable the custom rendering, so it should be not hard to share some code when designing the gizmos for primitive creation.

Some other considerations:

  • We should probably support undo certain drawing modes, like polyline. You should be able to undo the last added point. I'm not sure how to integrate this with the undo system, or if I should handle that input from the modal operator. Maybe we can leave this for a future version.
  • As it is now, this tool won't work from an orthographic view. I'm not sure how we can adjust the extrusion if you are looking directly to the drawing plane.
  • I would like to left booleans for a future version. I have a working version with boolean support, but if you enable snapping it generates coplanar faces and the boolean operation fails. It is also going to make the UI much more complicated

@Brecht Van Lommel (brecht) The gizmo for this tool should be everything that is under the BLUEPRINT_STATE_PLANE state. (white transparent grid with fixed size). When you start the tool, the modal operator should start directly from BLUEPRINT_STATE_DRAW (blue background, dynamic size and a drawing mode active).
I'm not sure if this is possible, but can we add two gizmos at the same time when the tool is active, the default grid gizmo and another one for adjusting the extrusion of the last operation. The ones that adjust the extrusion should grab the input first, but the user should be able to lock the plane and start a new drawing operation by clicking on any other area.

Yes, I got the colors of the grids mixed up. In the current tool system, I don't think you can have gizmos in a modal operator, unless you manually implement them somehow. They usually invoke an operator, not handle input for a running one.

We should probably support undo certain drawing modes, like polyline. You should be able to undo the last added point. I'm not sure how to integrate this with the undo system, or if I should handle that input from the modal operator. Maybe we can leave this for a future version.

This is rather tricky for a modal operator, would leave it for a future version.

As it is now, this tool won't work from an orthographic view. I'm not sure how we can adjust the extrusion if you are looking directly to the drawing plane.

The transform system has to deal with a similar issue. I think it has some threshold where if the translation axis is (near) orthogonal, it switches to interpreting the mouse movement differently. You still can't really see what you're doing (unless you have some secondary 3D viewport), but I'm not sure there is much we can or should do about this.

It would be good if view navigation worked in this modal tool, we have the same issue for other modal tools. Some general solution should be possible (like putting navigation operators in a separate keymap).

I would like to left booleans for a future version. I have a working version with boolean support, but if you enable snapping it generates coplanar faces and the boolean operation fails. It is also going to make the UI much more complicated

That seems reasonable. To make this work I guess we'd either need to wait for booleans to support coplanar faces, automatically tweak the coordinates a bit so that they are not exactly coplanar, or using something other mesh modeling code (knife?) to achieve a similar result.