Real-Time Parametric Geometry Editing in Babylon.js

Tutorials and tips
,
22

That’s not trivial thing to do, though.

Especially if to do that on the level of Blender. But maybe the Blender’s deps graph could give some inspiration.

Personally, I’ll try with something simple like @property / _isDirty / update()

23

Blender is different. It model the system as a mesh not as a parametric geometry.

→ Blender = mesh modeling system (approximate geometry)

→ CAD = kernel-based system (exact geometry)

But yeah it’s not something easy but still worth it for Babylonjs to have at least the basic functionality of this for some use cases.

24

I’ve used dependency graph, then depth- or breadth-first search depending on links-to-parent or links-to-children (one search per node set) gives you processing order. Anything changes and start search/processing at the changed nodes. Prevents looping through multiple times looking for “dirty.” Is that what we’re already talking about?

25

Yes, Blender is totally different in this matter, but the dependency handling is basically the same: it only updates those meshes affected by changes, just like we need to only update affected VertexData. The changes in Blender come from UI, animation, modifiers, constraints, drivers, scripts, probably something more. And all that stuff is interconnnected and handled by depgraph.

In Babylon the dependencies are implemented in a very hardcore way, with _isDirty and if (this._isDirty) this.recalculate() hardcoded all around the codebase. And it doesn’t work well somethimes (i.e. getAbsolutePosition() for animated meshes implies kinda another layer of _isVeryDirty)

If you’ll manage to solve that in a generic way, you’ll be a hero! :smiley:

26

Well… I will only copy other hero work to Babylonjs :sweat_smile:(a lot of other open source engines handle this issue in better ways)

27

Honestly I’m open to improve the node geometry to support live update!! If someone wants to help I’ll be more than happy to review the PR.

This could be a fantastic update

4 Likes
29

I love to

1 Like
30

Ok.

In very general, i see at least two reasonable levels of difficulty (following Cynefin scheme):

  1. Simple: just a combination of parametric primitives. Like a CSG union-only. Apparently, this could already solve many market-demanded cases, such as modeling custom furniture or something.
  2. Complex: CSG-like modeling, with quite deterministic dynamic of geometry. This is CAD-like use case.
  3. Complicated: requires search for optimal/valid solution satifsying constraints and rules. This is also actually demanded on the market by manufacturers and construction buisnesses.
  4. Chaotic: (successfully covered by AI)

The simplest case can be relatively easy solved by implementing classes for parametric primitives, transformation rules, and a master function to compute parameters. And then just putting them all into main parent node.
We still have to deal with case of overlapping surfaces, but that could be solved manually according to a specific construction scheme.
And this is actually what nodes intended to solve, except they are not real-time and also self-destructive.

The complex case requires modifying geometry drastically, such as adding new faces or splitting manifolds. And that cannot be done in-place reusing the same VertexData.

The somplicated case requires running simulation or optimization algorithms, which are all either NP-hard or non-deterministic, and totally not real-time. Some real-time-ization is acheved via using pre-calculated templates that themselves fit into simpler categories.
Although it’s simplest to implement, because whole geometry just regenerates.

Do I miss something?

Personally, i’m interested mainly in the 1st category.
And the idea of re-inventing geometry nodes still bothers me.

31

Is there a chance the nodes could be refactored to solve the evaluateContext issue automatically?
Maybe, via some recursive dirtyness or something?

That alone would bring the nodes to quite another level.

32

Careful reuse of VertexData can result in dramatic increase in speed. So too, can reducing the generation of large temporary arrays. In my applications, I usually design for repeated generation of vertex data, into the same buffer if possible.

Most Babylon mesh generation functions take Array() as input, but some also take Float32Array. It’s unclear to me whether those that take Float32Array also copy that array before using it as a vertex buffer (in some cases, the arrangement is different, so it must copy).

Usually, the pattern I adopt is

  1. use (nested) float array() (when needed for clarity) and call MeshhBuilder.X class.
  2. call mesh.getVertexData.
  3. update Float32Array (looking at the data to make sure I understamd the pattern)
  4. call mesh.updateVertexData, vertexbuffer.update, or geometery.updateDirectly
  5. repeat 3 & 4 per frame or as needed.

Or

  1. create Float32Array bigger than will be needed,
  2. use the TypedArray overlay mechanism to adapt to smaller size (WebGL doesn’t like resizable TypedArray),
  3. then create new overlay when needed, and
  4. use setBuffer when changing size (or use update when using different data in the same array)

Or, with thinInstanceMatrix that might grow in number,

  1. use a Float32Array (bigger than initially needed)
  2. change thinInstanceCount (thinInstances use Count to determine size of GPU transfer
  3. to delete a thinInstance, copy the last thinInstance data into your deleted one, reduce count by one (be sure to update any other references to specific thinInstance indexes similarly)

My biggest issue with CSG2 is that there is no “update in place” or “use this array if big enough”. If reusing a mesh with CSG2, then it may be worth managing CSG2/mesh references for repeated use. It’s kind of a chore, though.