Remesh Node #89052

New Issue

Fabian Schempp · 2021-06-11T10:35:40+02:00

Fabian Schempp commented

2021-06-11 10:35:40 +02:00

Remesh Modifier Modes will be split into two separate nodes.

Voxel Remesh (Voxel Remesh algorithm)
Block Remesh (original Remesh algorithm mainly useful for block effect)

Properties can be used as they are in the modifier.

Algorithms are already external from Modifier code so it should be easy to reuse it for the node.

Remesh Modifier Modes will be split into two separate nodes. 1. Voxel Remesh (Voxel Remesh algorithm) 2. Block Remesh (original Remesh algorithm mainly useful for block effect) Properties can be used as they are in the modifier. Algorithms are already external from Modifier code so it should be easy to reuse it for the node. ![voxel_remesh.png](https://archive.blender.org/developer/F10166701/voxel_remesh.png) ![block_remesh.png](https://archive.blender.org/developer/F10166700/block_remesh.png)

Fabian Schempp self-assigned this 2021-06-11 10:35:40 +02:00

Fabian Schempp commented

2021-06-11 10:35:40 +02:00

Added subscriber: @FabianSchempp

Roger B commented

2021-06-11 11:26:42 +02:00

Added subscriber: @rboxman

Roger B commented

2021-06-11 11:26:42 +02:00

Will there be any provisions for guarding against very low voxel sizes or high octree depths? Since these are node inputs that may flow in from other parts of the graph, I can imagine it being very easy for "bad" values to end up as input either accidentally or otherwise. Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first.

Mindinsomnia commented

2021-06-11 16:24:50 +02:00

Added subscriber: @Grady

Mindinsomnia commented

2021-06-11 16:24:50 +02:00

In #89052#1175075, @rboxman wrote:
Will there be any provisions for guarding against very low voxel sizes or high octree depths? Since these are node inputs that may flow in from other parts of the graph, I can imagine it being very easy for "bad" values to end up as input either accidentally or otherwise. Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first.

That's a good point.
Technically there's nothing stopping the user from implementing their own 'limits' mechanism by passing any inputs through some kind of node logic that clips the values to a limited range.
But it could be worth considering adding that to some nodes as a built in feature.
Some kind of 'min' and 'max' setting to prevent insane values, like a voxel size of 0.00001 which would almost certainly result in a crash and be hard for users to 'debug'.. or possibly even fix after it's set..
Perhaps similar to how the RGB Curves node clipping UI works.
Example below.

> In #89052#1175075, @rboxman wrote: > Will there be any provisions for guarding against very low voxel sizes or high octree depths? Since these are node inputs that may flow in from other parts of the graph, I can imagine it being very easy for "bad" values to end up as input either accidentally or otherwise. Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first. That's a good point. Technically there's nothing stopping the user from implementing their own 'limits' mechanism by passing any inputs through some kind of node logic that clips the values to a limited range. But it could be worth considering adding that to some nodes as a built in feature. Some kind of 'min' and 'max' setting to prevent insane values, like a voxel size of 0.00001 which would almost certainly result in a crash and be hard for users to 'debug'.. or possibly even fix after it's set.. Perhaps similar to how the RGB Curves node clipping UI works. Example below. ![example.png](https://archive.blender.org/developer/F10167012/example.png)

Paul Larson commented

2021-06-11 19:31:57 +02:00

Added subscriber: @GeorgiaPacific

Fabian Schempp commented

2021-06-11 19:56:40 +02:00

In #89052#1175075, @rboxman wrote:
Will there be any provisions for guarding against very low voxel sizes or high octree depths? Since these are node inputs that may flow in from other parts of the graph, I can imagine it being very easy for "bad" values to end up as input either accidentally or otherwise. Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first.

Interesting Point. I will consider this!

> In #89052#1175075, @rboxman wrote: > Will there be any provisions for guarding against very low voxel sizes or high octree depths? Since these are node inputs that may flow in from other parts of the graph, I can imagine it being very easy for "bad" values to end up as input either accidentally or otherwise. Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first. Interesting Point. I will consider this!

Hans Goudey commented

2021-06-12 06:09:34 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Ludvik Koutny commented

2021-06-12 10:06:41 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2021-06-12 10:06:41 +02:00

In #89052#1175075, @rboxman wrote:
Will there be any provisions for guarding against very low voxel sizes or high octree depths? Since these are node inputs that may flow in from other parts of the graph, I can imagine it being very easy for "bad" values to end up as input either accidentally or otherwise. Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first.

Regular modifiers suffer from this as well. It's super easy to freeze/crash Blender by mistyping voxel size value in the remesh modifier or accidentally dragging on the spinner. So rather than having some solution hardcoded in the new geometry nodes, I think this problem should be tacked more globally. Ideally by Blender having some sort of system to allow users to escape running operations.

And once that's in place, GN nodes, non GN modifiers, and pretty much any operators in the entire Blender (Smart UV project for example) with risk of excessive processing times could implement this global safeguard.

It'd be really sad if only a few specific nodes in only one specific editor would have this sort of functionality. But then again, that's a very Blender way of doing it, so that's probably how it will end up :)

> In #89052#1175075, @rboxman wrote: > Will there be any provisions for guarding against very low voxel sizes or high octree depths? Since these are node inputs that may flow in from other parts of the graph, I can imagine it being very easy for "bad" values to end up as input either accidentally or otherwise. Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first. Regular modifiers suffer from this as well. It's super easy to freeze/crash Blender by mistyping voxel size value in the remesh modifier or accidentally dragging on the spinner. So rather than having some solution hardcoded in the new geometry nodes, I think this problem should be tacked more globally. Ideally by Blender having some sort of system to allow users to escape running operations. And once that's in place, GN nodes, non GN modifiers, and pretty much any operators in the entire Blender (Smart UV project for example) with risk of excessive processing times could implement this global safeguard. It'd be really sad if only a few specific nodes in only one specific editor would have this sort of functionality. But then again, that's a very Blender way of doing it, so that's probably how it will end up :)

Pratik Borhade commented

2021-06-12 18:07:33 +02:00

Added subscriber: @PratikPB2123

Paul Kotelevets commented

2021-06-15 15:03:15 +02:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2021-06-15 15:03:15 +02:00

In #89052#1175075, @rboxman wrote:
Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first.

How about proper default values? Something like 0.5
Five times safer.

> In #89052#1175075, @rboxman wrote: > Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first. How about proper default values? Something like 0.5 Five times safer.

Roger B commented

2021-06-15 20:01:52 +02:00

In #89052#1177169, @1D_Inc wrote:
How about proper default values? Something like 0.5

Defaults won't help. This is about connecting the output of some existing node network to the input socket on the node here. That existing network already has values flowing through it and, unless you are absolutely sure of those values, plugging it into the node here is a recipe for disaster. Even allowing the user to "break" out of the operation is not good or desirable; often times it's still too late no matter how quickly you press ESC. It's also dangerous after you connect it. Tweaking the network will feed new values into the node and those can be problematic as well.

If there's no good solution to this, the design might have to remove the ability to connect sockets for that input at least.

> In #89052#1177169, @1D_Inc wrote: > How about proper default values? Something like 0.5 Defaults won't help. This is about connecting the output of some existing node network to the input socket on the node here. That existing network already has values flowing through it and, unless you are absolutely sure of those values, plugging it into the node here is a recipe for disaster. Even allowing the user to "break" out of the operation is not good or desirable; often times it's still too late no matter how quickly you press ESC. It's also dangerous after you connect it. Tweaking the network will feed new values into the node and those can be problematic as well. If there's no good solution to this, the design might have to remove the ability to connect sockets for that input at least.

Paul Kotelevets commented

2021-06-15 21:30:56 +02:00

In #89052#1177301, @rboxman wrote:

If there's no good solution to this, the design might have to remove the ability to connect sockets for that input at least.

Something like a "preventer", a safety node, or node part that breaks the chain in case of possible overload?

> In #89052#1177301, @rboxman wrote: > If there's no good solution to this, the design might have to remove the ability to connect sockets for that input at least. Something like a "preventer", a safety node, or node part that breaks the chain in case of possible overload?

Ludvik Koutny commented

2021-06-16 10:39:38 +02:00

In #89052#1177345, @1D_Inc wrote:

In #89052#1177301, @rboxman wrote:

If there's no good solution to this, the design might have to remove the ability to connect sockets for that input at least.

Something like a "preventer", a safety node, or node part that breaks the chain in case of possible overload?

I find it impressive how you consistently manage to find a worst solution to most problems in Blender. The whole point of overload errors is that they are hard to predict, and happen by accident, not on purpose. The whole point of accidents is that you don't anticipate them, so you don't put the "preventer" node in there. You only realize that you need that node there when it's already too late and Blender is frozen.

There's industry standard for handling these situations - ability to escape running processes, usually based on either user pressing a key (usually Escape key), or occasionally combined with another safeguard in form of memory limit, which automatically escapes the running operator if the memory consumption exceeds threshold (let's say 80% of available RAM).

> In #89052#1177345, @1D_Inc wrote: >> In #89052#1177301, @rboxman wrote: > >> If there's no good solution to this, the design might have to remove the ability to connect sockets for that input at least. > > Something like a "preventer", a safety node, or node part that breaks the chain in case of possible overload? I find it impressive how you consistently manage to find a worst solution to most problems in Blender. The whole point of overload errors is that they are hard to predict, and happen by accident, not on purpose. The whole point of accidents is that you don't anticipate them, so you don't put the "preventer" node in there. You only realize that you need that node there when it's already too late and Blender is frozen. There's industry standard for handling these situations - ability to escape running processes, usually based on either user pressing a key (usually Escape key), or occasionally combined with another safeguard in form of memory limit, which automatically escapes the running operator if the memory consumption exceeds threshold (let's say 80% of available RAM).

Mindinsomnia commented

2021-06-16 11:16:07 +02:00

I just did a quick mockup in Photoshop so excuse the quality. What about something like this? It's a design pattern that could be used for other nodes and modifiers as well that have 'dangerous' inputs.

In this case, the limit percentage "0.1%" is referring to 0.1% of object's longest dimension, that way it works no matter how big or small the object is.

But a simple 'limit' setting on nodes could allow for them to have safe guards against dangerous inputs and by having those limits there by default, new users won't accidentally feed a 0.0000001 value into a remesh node and wonder why Blender is crashing.

![mockup.jpg](https://archive.blender.org/developer/F10174683/mockup.jpg) I just did a quick mockup in Photoshop so excuse the quality. What about something like this? It's a design pattern that could be used for other nodes and modifiers as well that have 'dangerous' inputs. In this case, the limit percentage "0.1%" is referring to 0.1% of object's longest dimension, that way it works no matter how big or small the object is. But a simple 'limit' setting on nodes could allow for them to have safe guards against dangerous inputs and by having those limits there by default, new users won't accidentally feed a 0.0000001 value into a remesh node and wonder why Blender is crashing.

Paul Kotelevets commented

2021-06-16 11:27:22 +02:00

In #89052#1177532, @Rawalanche wrote:

I find it impressive how you consistently manage to find a worst solution to most problems in Blender.

Generally unprovable.

The whole point of accidents is that you don't anticipate them

For sure. So this is not about remesh node development anyway.

There's industry standard for handling these situations - ability to escape

3dsmax still can save files larger than it can open later on the same computer. There is nothing about "industry standards", it is about individual software solutions to handle harware limitations and sometimes about probable solutions to halting problem as well. I tried to deal with this problem when I was making scripts for Autocad that process large amounts of data, and I can imagine how difficult it is to solve this problem for cross-platform.
Safety magic is always hard to achieve.

In #89052#1177550, @Grady wrote:
In this case, the limit percentage "0.1%" is referring to 0.1% of object's longest dimension, that way it works no matter how big or small the object is.

This already can be solved with math node. Hard to say if it is a solution, if to take into account that value that you can process depends on your hardware)

> In #89052#1177532, @Rawalanche wrote: > I find it impressive how you consistently manage to find a worst solution to most problems in Blender. Generally unprovable. >The whole point of accidents is that you don't anticipate them For sure. So this is not about remesh node development anyway. > There's industry standard for handling these situations - ability to escape 3dsmax still can save files larger than it can open later on the same computer. There is nothing about "industry standards", it is about individual software solutions to handle harware limitations and sometimes about probable solutions to [halting problem ](https://youtu.be/t37GQgUPa6k) as well. I tried to deal with this problem when I was making scripts for Autocad that process large amounts of data, and I can imagine how difficult it is to solve this problem for cross-platform. Safety magic is always hard to achieve. > In #89052#1177550, @Grady wrote: > In this case, the limit percentage "0.1%" is referring to 0.1% of object's longest dimension, that way it works no matter how big or small the object is. This already can be solved with math node. Hard to say if it is a solution, if to take into account that value that you can process depends on your hardware)

Erindale commented

2021-06-16 14:10:13 +02:00

Added subscriber: @Erindale

Erindale commented

2021-06-16 14:10:13 +02:00

Constraints to protect unaware users can often become obstacles to users needing specific outcomes.
Perhaps soft limits would suffice like on the Subdivide modifier where you can manually type in larger numbers if needed.

I would be wary of setting a precedent for mollycoddling functionality out of Blender.

Constraints to protect unaware users can often become obstacles to users needing specific outcomes. Perhaps soft limits would suffice like on the Subdivide modifier where you can manually type in larger numbers if needed. I would be wary of setting a precedent for mollycoddling functionality out of Blender.

Paul Kotelevets commented

2021-06-16 17:08:04 +02:00

Soft limits are a UI usability solution and are not related to hardware capacity and its ability to run nodes layout.

Ludvik Koutny commented

2021-06-17 22:34:21 +02:00

In #89052#1177649, @Erindale wrote:
Constraints to protect unaware users can often become obstacles to users needing specific outcomes.
Perhaps soft limits would suffice like on the Subdivide modifier where you can manually type in larger numbers if needed.

I would be wary of setting a precedent for mollycoddling functionality out of Blender.

A simple example. You create a cliff generator GN node network which turns any primitive shape into a cliff mesh, and it utilizes a remesh modifier. You test in on roughly 10M^3 mesh and it works well. Another user you supply the GN network will import a mesh from other DCC and doesn't check the scale of the object, so he ends up with 500M^3 mesh. As soon as he puts on a GN modifier an selects your network, he freezes his Blender and loses any unsaved work. How do you prevent that?

Is your solution really to rely on users to carefully explore every GN node network that's not their, to scour it for any scale dependent modifier and fix them themselves?

> In #89052#1177649, @Erindale wrote: > Constraints to protect unaware users can often become obstacles to users needing specific outcomes. > Perhaps soft limits would suffice like on the Subdivide modifier where you can manually type in larger numbers if needed. > > I would be wary of setting a precedent for mollycoddling functionality out of Blender. A simple example. You create a cliff generator GN node network which turns any primitive shape into a cliff mesh, and it utilizes a remesh modifier. You test in on roughly 10M^3 mesh and it works well. Another user you supply the GN network will import a mesh from other DCC and doesn't check the scale of the object, so he ends up with 500M^3 mesh. As soon as he puts on a GN modifier an selects your network, he freezes his Blender and loses any unsaved work. How do you prevent that? Is your solution really to rely on users to carefully explore every GN node network that's not their, to scour it for any scale dependent modifier and fix them themselves?

Piotr Adamowicz commented

2021-07-05 13:30:21 +02:00

Added subscriber: @MadMinstrel

Piotr Adamowicz commented

2021-07-05 13:30:21 +02:00

I would suggest that a limit is indeed present, but there must be a way to disable it.

Just because an object is large doesn't automatically mean it's going to take a lot of memory. For example, a procedurally generated, sparse asteroid field is not going to have much of an impact on account of mostly being empty space. While previously you could argue that this is an implausible scenario, and each asteroid ought to be an individual object, now with geometry nodes, it's quite feasible, and a limit of 0.1% will prove nothing but a headache. Just taking the typical case into account is never a good idea.

I would suggest that a limit is indeed present, but there *must* be a way to disable it. Just because an object is large doesn't automatically mean it's going to take a lot of memory. For example, a procedurally generated, sparse asteroid field is not going to have much of an impact on account of mostly being empty space. While previously you could argue that this is an implausible scenario, and each asteroid ought to be an individual object, now with geometry nodes, it's quite feasible, and a limit of 0.1% will prove nothing but a headache. Just taking the typical case into account is never a good idea.

Jarrett Johnson commented

2021-10-12 06:29:57 +02:00

Added subscriber: @Jarrett-Johnson

kavu commented

2021-11-09 05:59:13 +01:00

Added subscriber: @Kavukamari

kavu commented

2021-11-09 05:59:13 +01:00

I think Erindale's solution where the slider has a soft cap at something like 0.01 but the user can type in any value they want is a good one. but it doesn't solve the problem of users plugging random nodes in and accidentally crashing the program. maybe a checkbox for "bypass voxel size limit" that defaults to off? something feels off about it, but I think it might work

Mindinsomnia commented

2021-11-09 07:48:35 +01:00

In #89052#1250735, @Kavukamari wrote:
I think Erindale's solution where the slider has a soft cap at something like 0.01 but the user can type in any value they want is a good one. but it doesn't solve the problem of users plugging random nodes in and accidentally crashing the program. maybe a checkbox for "bypass voxel size limit" that defaults to off? something feels off about it, but I think it might work

Perhaps just a simple warning dialog.

"Warning, the voxel size of XX.X could take a while to compute, continue?"
[ Yes ] [ No ]

Or simply, show a progress bar while geometry nodes are processing (if they take longer than say, 1 second to finish) with an option to cancel to abort.

Either way, I think the issue as it stands, is a broader issue that affects many inputs across Blender, including many geometry node inputs, and probably should have a broader solution.

Just my 2 cents.

> In #89052#1250735, @Kavukamari wrote: > I think Erindale's solution where the slider has a soft cap at something like 0.01 but the user can type in any value they want is a good one. but it doesn't solve the problem of users plugging random nodes in and accidentally crashing the program. maybe a checkbox for "bypass voxel size limit" that defaults to off? something feels off about it, but I think it might work Perhaps just a simple warning dialog. > "Warning, the voxel size of XX.X could take a while to compute, continue?" > [ Yes ] [ No ] Or simply, show a progress bar while geometry nodes are processing (if they take longer than say, 1 second to finish) with an option to cancel to abort. Either way, I think the issue as it stands, is a broader issue that affects many inputs across Blender, including many geometry node inputs, and probably should have a broader solution. Just my 2 cents.

Joel Philips commented

2021-12-12 21:57:35 +01:00

Added subscriber: @VoxelRemeshNodePliz