Old greenhorn's questions (nodes/functionality) - "answer walk with me"


please help

see this simple graph:

there should be 3 openings, but moving them up/down/left/right, they sometimes disappear, sometimes you can see only 2 openings…

what is wrong with it?

thank you

There seems to be a bug with the box !
I replace with an extrude rectangle

hello simjoubert,

thank you, nice, so actually not my fault :wink:

your solution works well - I’ve already tried it.
but in case that you don’t create a “closed box” from a rectangle but a “pool like box” (so: rectangle/offset/extrude) I came into same problems…openings did not show properly.

It does not change anything !
The same graph with a swimming pool variation

nice graph, works mostly fine, only sometimes…

there are of course many ways how to create a pool, you made it “box in box” and boolean…
I made it for example this way
PLUS the bottom (an extra rectangle) but that is not important now.
i don’t know if the way you make the walls has impact on the holes…probably it has…

To force the refresh, I added a test if the state is ephemeral.
Thus, it refreshes Boolean subtractions only when the values are established. This reduces latency when changing values and eliminates unnecessary calculations that clutter the server’s CPU. The result is a bug-free refresh!


My method for creating the envelopes makes it possible to manage a difference in depth of the basin and to easily have a homothety of the hull.



super, always new things to find in your graphs :wink:

it would be really great (at least for non-professionals) to prepare some basic explanations to every node, lets say compared to the similar functionality in SU… now I go to study your expression to the “mask” node in connection with “set points” to be able to adjust diferent hight for each side - that’s nice.

unfortunately, even in this case there is still the same problem

I think, your first answer to this topic is the right way:

and the “pool” just simply consists of 5 separate walls which “cooperate” together as for the length/width/height…

I reported the bug to the Trimble Creator team
wait and see

I will :+1:

Hi guys! Great to see some experimentation with 3D Booleans!

This isn’t actually a bug, but rather what I would consider a limitation of the 3D Boolean node. The node itself is specifically a Mesh 3D Boolean, which, by nature of the operation can be rather finicky, you’ll find this is often the case in many modelling software’s (compared to it’s NURBS 3D Boolean brother which currently isn’t implemented in Creator at this time).

That being said, here are a couple things to bear in mind when using the node:

  1. Try to avoid “coplanar” faces. Specifically this means two faces which share the same plane. In the example above with the cylinders and the box, the cylinder “caps” share the same plane with the sides of the box that is being cut. Often stretching the size of these cutting objects can allow for more consistent behaviour (either via scale on the transform node, or via the smart size node).
  2. The operation will often also have some trouble calculating a 3D Boolean when the specified place that is being cut is smack bang in the middle of a triangle of a mesh. The operation of mesh 3d boolean’s utilize vertices and edges of a mesh to calculate where primitives/meshes should be cut/operated on. Thus if there is no intersection with a vertex or edge, then the node will have a little trouble calculating this. You’ll notice on THIS version of the graph, that where a cylinder intersects the box on the white line (the mesh edges), the boolean operation is consistent compared to when they do not. One solution to this is to up the complexity of the input primitives (though this isn’t always a great idea as it will also decrease performance of the graph).

Otherwise, a more consistent solution for now would look like Simon’s example via the use of 2D Boolean, then extruding the result.

In the meantime, I’ll bump your feedback for better 3D Boolean tools!

1 Like