Remesh Voxel Size can be much to small by default (leading to crashes). 'Edit Voxel Size' operator can have wrong range #77868

New Issue

RedAssassin · 2020-06-14T23:04:19+02:00

RedAssassin commented

2020-06-14 23:04:19 +02:00

System Information
Operating system: Windows-10-10.0.17763-SP0 64 Bits
Graphics card: GeForce GTX 1660/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 432.00
Processor: AMD Ryzen 7 3800x 8-Core Processor 3.90 GHz

Blender Version
Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-06-12 17:01, hash: fd8d245e6a
(Also with Blender 2.83 BETA)

Short description of error
Selecting the "Remesh" modifier, selected "Voxel", Voxel size below "0.01m" = PC Crash. Needed to restart the PC.

Exact steps for others to reproduce the error

Start Blender.
Let the default Cube alive and add the "Remesh" modifier.
Make the "Voxel Size" below "0.01m".
Did it crashed?
(Found out in my Blender Project, but I tested it then in a default Scene. Same thing happened.)

(Why I set the Voxel Size below "0.01m"?
It happens accidentally, when I have it like "0.42m", but I hold my left click and slide it to the left, so I accidentally go below "0.01m".)

{F8619727, size = full}

Good Luck!

**System Information** Operating system: Windows-10-10.0.17763-SP0 64 Bits Graphics card: GeForce GTX 1660/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 432.00 Processor: AMD Ryzen 7 3800x 8-Core Processor 3.90 GHz **Blender Version** Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-06-12 17:01, hash: `fd8d245e6a` (Also with Blender 2.83 BETA) **Short description of error** Selecting the "Remesh" modifier, selected "Voxel", Voxel size below "0.01m" = PC Crash. Needed to restart the PC. **Exact steps for others to reproduce the error** 1. Start Blender. 2. Let the default Cube alive and add the "Remesh" modifier. 3. Make the "Voxel Size" below "0.01m". 4. Did it crashed? (Found out in my Blender Project, but I tested it then in a default Scene. Same thing happened.) (Why I set the Voxel Size below "0.01m"? It happens accidentally, when I have it like "0.42m", but I hold my left click and slide it to the left, so I accidentally go below "0.01m".) {[F8619727](https://archive.blender.org/developer/F8619727/image.png), size = full} Good Luck!

RedAssassin commented

2020-06-14 23:04:19 +02:00

Added subscriber: @RedAssassin44

blender-admin commented

2020-06-14 23:04:19 +02:00

#100877 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#99466 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#98347 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#93318 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#90272 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#88634 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#87946 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#82239 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#82072 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#78825 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#78808 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

blender/blender-addons#77664 was marked as duplicate of this issue

blender-admin commented

2020-06-14 23:04:19 +02:00

#77556 was marked as duplicate of this issue

Robert Guetzkow commented

2020-06-14 23:33:37 +02:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-06-14 23:33:37 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Robert Guetzkow commented

2020-06-14 23:33:37 +02:00

If your operating system crashes there seems to be an issue outside of Blender. Please update the graphics driver and check if the crash still occurs. Be aware the remeshing is very memory intensive, you may be running out of memory (see similar reports blender/blender-addons#77664 and #77556).

If your operating system crashes there seems to be an issue outside of Blender. Please update the [graphics driver ](https://www.nvidia.com/Download/driverResults.aspx/159887/en-us) and check if the crash still occurs. Be aware the remeshing is very memory intensive, you may be running out of memory (see similar reports blender/blender-addons#77664 and #77556).

Ankit Meel changed title from ~~--{ Blender crashes PC. Modifier Remesh Voxel Size issue. }--~~ to Blender crashes PC. Modifier Remesh Voxel Size issue.

2020-06-15 08:20:30 +02:00

Ankit Meel commented

2020-06-15 08:32:36 +02:00

Added subscribers: @car313, @Alaska

Ankit Meel commented

2020-06-15 08:33:02 +02:00

Added subscribers: @visionarymind, @HDMaster84, @MeshVoid

Ankit Meel commented

2020-06-15 08:38:10 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2020-06-15 08:38:10 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Ankit Meel commented

2020-06-15 08:38:10 +02:00

{F8620460, layout=inline}{F8620461, layout=inline}{F8620462, layout=inline}{F8620463, layout=inline}{F8620464, layout=inline}
The memory usage goes wild when reducing the voxel size just under .01 (use the "reduce" button beside the slider)

{[F8620460](https://archive.blender.org/developer/F8620460/Screenshot_2020-06-15_at_11.59.39.jpeg), layout=inline}{[F8620461](https://archive.blender.org/developer/F8620461/Screenshot_2020-06-15_at_11.59.50.jpeg), layout=inline}{[F8620462](https://archive.blender.org/developer/F8620462/Screenshot_2020-06-15_at_12.00.09.jpeg), layout=inline}{[F8620463](https://archive.blender.org/developer/F8620463/Screenshot_2020-06-15_at_12.01.44.jpeg), layout=inline}{[F8620464](https://archive.blender.org/developer/F8620464/Screenshot_2020-06-15_at_12.01.17.jpeg), layout=inline} The memory usage goes wild when reducing the voxel size just under .01 (use the "reduce" button beside the slider)

Ankit Meel commented

2020-06-15 08:39:38 +02:00

An easy fix would be to put a soft limit of 0.01 in the slider UI itself. and manually let people type into it what they want.

Henrik D. commented

2020-06-15 11:33:33 +02:00

Currently there is only a soft limit for the voxel size at 0.0001, but you can also type in something as low as 0.00002. A value of 0.001 on the default cube does still work on my computer, but takes very long to compute, but if I scale the cube down in editmode by 0.01, then even the voxelsize of 0.0001 works. I think that the solution should not be a hard limit of 0.01 in the UI.

If there shoud be a limit, then that should be calculated at runtime of the modifier. The modifier would check the bounding box size and make sure that memory usage stays under some reasonable amount. If the modifier did clamp the voxel size it would give an error message to the user as well indicating that. Keep in mind this is about the modifier version of voxel remesh, and it makes no sense to have an extraordinarily slow modifier in the stack. So for very high resolution the normal remesh feature in the mesh data properties would be always preferred.

IMO the optimal soution would be to have logarithmic/nonlinear sliders which would work similar to the brush radius slider in Krita. This way you would not go into the dangerous region by one click, but rather smoothly descent.

Currently there is only a soft limit for the voxel size at 0.0001, but you can also type in something as low as 0.00002. A value of 0.001 on the default cube does still work on my computer, but takes very long to compute, but if I scale the cube down in editmode by 0.01, then even the voxelsize of 0.0001 works. I think that the solution should not be a hard limit of 0.01 in the UI. If there shoud be a limit, then that should be calculated at runtime of the modifier. The modifier would check the bounding box size and make sure that memory usage stays under some reasonable amount. If the modifier did clamp the voxel size it would give an error message to the user as well indicating that. Keep in mind this is about the modifier version of voxel remesh, and it makes no sense to have an extraordinarily slow modifier in the stack. So for very high resolution the normal remesh feature in the mesh data properties would be always preferred. IMO the optimal soution would be to have logarithmic/nonlinear sliders which would work similar to the brush radius slider in Krita. This way you would not go into the dangerous region by one click, but rather smoothly descent.

Robert Guetzkow commented

2020-06-15 11:45:11 +02:00

@ankitm I can't reproduce a crash on my system with 0.001 on a subdivided Suzanne, it only consumes a large amount of memory. That in itself is not surprising, since the smaller the voxel the more memory it needs and the memory consumption grows cubically. The issue is that the soft_min is 0.0001 (or 9.999999747378752e-05 to be precise), which means that sliding over the value can easily result in OOM. ~~I wouldn't change the hard_limit, since someone with more memory or a use case like @HDMaster84 described, may want to use really small values and should be able to type them in manually.~~ Edit: I would change the hard_limit too, in order to avoid the arithmetic error reported in #77878.

@ankitm I can't reproduce a crash on my system with 0.001 on a subdivided Suzanne, it only consumes a large amount of memory. That in itself is not surprising, since the smaller the voxel the more memory it needs and the memory consumption grows cubically. The issue is that the `soft_min` is `0.0001` (or `9.999999747378752e-05` to be precise), which means that sliding over the value can easily result in OOM. ~~I wouldn't change the `hard_limit`, since someone with more memory or a use case like @HDMaster84 described, may want to use really small values and should be able to type them in manually.~~ Edit: I would change the `hard_limit` too, in order to avoid the arithmetic error reported in #77878.

Robert Guetzkow commented

2020-06-15 11:52:04 +02:00

This comment was removed by @rjg

*This comment was removed by @rjg*

Chingiz Jumagulov commented

2020-06-15 11:52:54 +02:00

In #77868#953889, @HDMaster84 wrote:
Currently there is only a soft limit for the voxel size at 0.0001, but you can also type in something as low as 0.00002. A value of 0.001 on the default cube does still work on my computer, but takes very long to compute, but if I scale the cube down in editmode by 0.01, then even the voxelsize of 0.0001 works. I think that the solution should not be a hard limit of 0.01 in the UI.

If there shoud be a limit, then that should be calculated at runtime of the modifier. The modifier would check the bounding box size and make sure that memory usage stays under some reasonable amount. If the modifier did clamp the voxel size it would give an error message to the user as well indicating that. Keep in mind this is about the modifier version of voxel remesh, and it makes no sense to have an extraordinarily slow modifier in the stack. So for very high resolution the normal remesh feature in the mesh data properties would be always preferred.

IMO the optimal soution would be to have logarithmic/nonlinear sliders which would work similar to the brush radius slider in Krita. This way you would not go into the dangerous region by one click, but rather smoothly descent.

I agree with Henrick. I'm just finishing sculpting quite a hefty model in Blender. I think the solution of having a hard limit of 0.01 is not a solution as you definitely use these small numbers when you scale the model down, when you have little details, but you still need that geometrical density to sculpt, it all depends on the type of the model and its scale and putting a hard-limit is a hacky solution. To be honest, I would argue that your computer running out of memory because you created a geo that is too dense is a bug, that is your fault.

Having no notification that geo might get too dense and you'll most likely get a crash (as it is done in Zbrush once you subdivide model too much) should be considered more of a UI paper-cut I guess. You can crash any sculpting software like that if you don't know what you're doing and which numbers are viable. You can easily crush Zbrush the same way if you over-do Dynamesh values or overly subdivide your model.

> In #77868#953889, @HDMaster84 wrote: > Currently there is only a soft limit for the voxel size at 0.0001, but you can also type in something as low as 0.00002. A value of 0.001 on the default cube does still work on my computer, but takes very long to compute, but if I scale the cube down in editmode by 0.01, then even the voxelsize of 0.0001 works. I think that the solution should not be a hard limit of 0.01 in the UI. > > If there shoud be a limit, then that should be calculated at runtime of the modifier. The modifier would check the bounding box size and make sure that memory usage stays under some reasonable amount. If the modifier did clamp the voxel size it would give an error message to the user as well indicating that. Keep in mind this is about the modifier version of voxel remesh, and it makes no sense to have an extraordinarily slow modifier in the stack. So for very high resolution the normal remesh feature in the mesh data properties would be always preferred. > > IMO the optimal soution would be to have logarithmic/nonlinear sliders which would work similar to the brush radius slider in Krita. This way you would not go into the dangerous region by one click, but rather smoothly descent. I agree with Henrick. I'm just finishing sculpting quite a hefty model in Blender. I think the solution of having a hard limit of 0.01 is not a solution as you definitely use these small numbers when you scale the model down, when you have little details, but you still need that geometrical density to sculpt, it all depends on the type of the model and its scale and putting a hard-limit is a hacky solution. To be honest, I would argue that your computer running out of memory because you created a geo that is too dense is a bug, that is your fault. Having no notification that geo might get too dense and you'll most likely get a crash (as it is done in Zbrush once you subdivide model too much) should be considered more of a UI paper-cut I guess. You can crash any sculpting software like that if you don't know what you're doing and which numbers are viable. You can easily crush Zbrush the same way if you over-do Dynamesh values or overly subdivide your model.

Henrik D. commented

2020-06-15 11:59:47 +02:00

@rjg for me bpy.context.object.modifiers["Remesh"].bl_rna.properties["voxel_size"].soft_min - 0.0001 is basically giving zero, so the soft_min matches. The little error is due to float not beeing able to store that number exactly (see https://www.h-schmidt.net/FloatConverter/IEEE754.html)

@rjg for me `bpy.context.object.modifiers["Remesh"].bl_rna.properties["voxel_size"].soft_min - 0.0001` is basically giving zero, so the `soft_min` matches. The little error is due to float not beeing able to store that number exactly (see https://www.h-schmidt.net/FloatConverter/IEEE754.html)

Robert Guetzkow commented

2020-06-15 12:03:09 +02:00

@HDMaster84 You're right I misread it and thought there was one erroneous extra zero digit. The actual deviation is obviously coming from floating point precision.

Ankit Meel commented

2020-06-15 12:07:39 +02:00

Edited the comment up there. #77868#953819 It felt surprising to me that going from 0.03 > 0.02 > 0.01 > (the number here) created such a huge increase. What I had was the default cube with nothing else.

I can't reproduce a crash on my system with 0.001 on a subdivided Suzanne, it only consumes a large amount of memory.

Just to clarify: is anyone opposing the confirmation of the report ?

Edited the comment up there. #77868#953819 It felt surprising to me that going from 0.03 > 0.02 > 0.01 > (the number here) created such a huge increase. What I had was the default cube with nothing else. >I can't reproduce a crash on my system with 0.001 on a subdivided Suzanne, it only consumes a large amount of memory. Just to clarify: is anyone opposing the confirmation of the report ?

Henrik D. commented

2020-06-15 12:12:49 +02:00

@ankitm No it definitly crashes when decreasing from 0.01 with the left arrow going to the softmin at 0.0001. But only on the default cube and objects of similar size or bigger.

Henrik D. commented

2020-06-15 12:28:06 +02:00

#77878 is related to the decision what the hard limit should be.

Robert Guetzkow commented

2020-06-15 12:33:27 +02:00

@HDMaster84 What is a suitable soft_min, when the required memory is relative to the size of the object? Remeshing a 50 m cube and a voxel size of 0.01 will have the same effect, allocating about 27 GB. In a perfect world the modifier would base the limits on the available resources. The next best would be dynamic limits based on the object's bounding box. I'm not sure if there's a good solution that fits well with Blender's current concept of limits on properties.

~~If I'm not mistaken #77878 that is a duplicate of #72747 fixed in 6a54969cf1~~ Nevermind that is for the voxel remesher, but generally related. Making too many mistakes this morning.

@HDMaster84 What is a suitable `soft_min`, when the required memory is relative to the size of the object? Remeshing a 50 m cube and a voxel size of 0.01 will have the same effect, allocating about 27 GB. In a perfect world the modifier would base the limits on the available resources. The next best would be dynamic limits based on the object's bounding box. I'm not sure if there's a good solution that fits well with Blender's current concept of limits on properties. ~~If I'm not mistaken #77878 that is a duplicate of #72747 fixed in 6a54969cf1~~ Nevermind that is for the voxel remesher, but generally related. Making too many mistakes this morning.

Henrik D. commented

2020-06-15 12:42:32 +02:00

@rjg

In #77868#953889, @HDMaster84 wrote:
Currently there is only a soft limit for the voxel size at 0.0001, but you can also type in something as low as 0.00002. A value of 0.001 on the default cube does still work on my computer, but takes very long to compute, but if I scale the cube down in editmode by 0.01, then even the voxelsize of 0.0001 works. I think that the solution should not be a hard limit of 0.01 in the UI.

If there shoud be a limit, then that should be calculated at runtime of the modifier. The modifier would check the bounding box size and make sure that memory usage stays under some reasonable amount. If the modifier did clamp the voxel size it would give an error message to the user as well, indicating that. Keep in mind this is about the modifier version of voxel remesh, and it makes no sense to have an extraordinarily slow modifier in the stack. So for very high resolution the normal remesh feature in the mesh data properties would be always preferred.

IMO the optimal soution would be to have logarithmic/nonlinear sliders which would work similar to the brush radius slider in Krita. This way you would not go into the dangerous region by one click, but rather smoothly descent.

@rjg > In #77868#953889, @HDMaster84 wrote: > Currently there is only a soft limit for the voxel size at 0.0001, but you can also type in something as low as 0.00002. A value of 0.001 on the default cube does still work on my computer, but takes very long to compute, but if I scale the cube down in editmode by 0.01, then even the voxelsize of 0.0001 works. I think that the solution should not be a hard limit of 0.01 in the UI. > > **If there shoud be a limit, then that should be calculated at runtime of the modifier. The modifier would check the bounding box size and make sure that memory usage stays under some reasonable amount. If the modifier did clamp the voxel size it would give an error message to the user as well, indicating that. Keep in mind this is about the modifier version of voxel remesh, and it makes no sense to have an extraordinarily slow modifier in the stack. So for very high resolution the normal remesh feature in the mesh data properties would be always preferred.** > > IMO the optimal soution would be to have logarithmic/nonlinear sliders which would work similar to the brush radius slider in Krita. This way you would not go into the dangerous region by one click, but rather smoothly descent.

Robert Guetzkow commented

2020-06-15 12:49:34 +02:00

@HDMaster84 I definitely shouldn't be allowed on the internet without caffeine. Sorry for missing so many obvious things today. Do you know of any modifier that currently implement dynamic limits? I don't think that's currently the case, but given how many things I was already wrong about today ...

Henrik D. commented

2020-06-15 13:01:51 +02:00

@rjg I don't think there is a modifier with dynamic limits yet. The general assumtion is that you know what values you are allowed to enter without crashing blender. There are lots of modifiers that can crash blender in a similar way (array, screw, bevel, subsurface). All of those other modifiers including the other modes of remesh are designed in a way, that you slowly descent in performance when clicking or dragging the slider, so you can intuitivly see where the limits for your computer are. The voxel size is the only field which will jump in a very rapid way to a crash (one click literally). Thats exactly what I was on in the last paragraph of my comment #77868#953889, when I was talking about nonlinear sliders.

What also should be considered is that, if your object is very big in size, adding the modifier will already crash blender. In that case an error message raised by a dynamic limit would be a life saver.

@rjg I don't think there is a modifier with dynamic limits yet. The general assumtion is that you know what values you are allowed to enter without crashing blender. There are lots of modifiers that can crash blender in a similar way (array, screw, bevel, subsurface). All of those other modifiers including the other modes of remesh are designed in a way, that you slowly descent in performance when clicking or dragging the slider, so you can intuitivly see where the limits for your computer are. The voxel size is the only field which will jump in a very rapid way to a crash (one click literally). Thats exactly what I was on in the last paragraph of my comment #77868#953889, when I was talking about nonlinear sliders. What also should be considered is that, if your object is very big in size, adding the modifier will already crash blender. In that case an error message raised by a dynamic limit would be a life saver.

Robert Guetzkow commented

2020-06-15 13:26:20 +02:00

@HDMaster84 The issue with dynamic limits based on available memory is that it is not quite easy to know how much is actually available, due to virtual memory, swap and other programs (de)allocating alongside of Blender. I don't think this is the right approach. As you've said, there are already plenty of ways to run out of memory, it just shouldn't be that easy to do that unintentionally.

The different scaling of the increments is a nice idea. What I meant in my comment was that instead of an absolute voxel size, one could rather use a factor that is used to determine that voxel size based on the object's bounding box. This should solve the problem, including the case when the modifier is added to a large object.

@HDMaster84 The issue with dynamic limits based on available memory is that it is not quite easy to know how much is actually available, due to virtual memory, swap and other programs (de)allocating alongside of Blender. I don't think this is the right approach. As you've said, there are already plenty of ways to run out of memory, it just shouldn't be that easy to do that unintentionally. The different scaling of the increments is a nice idea. What I meant in my comment was that instead of an absolute voxel size, one could rather use a factor that is used to determine that voxel size based on the object's bounding box. This should solve the problem, including the case when the modifier is added to a large object.

Henrik D. commented

2020-06-15 14:16:24 +02:00

@rjg no please not, please! The bounding box size changes all the time when using different modifier combinations or shapekeys and I don't like the effect that the other remesh modes are giving me. The other remesh modes do exactly that. They have an octree depth and a scale to scale and subdivide the bounding box. The issue is that it would render this new voxel remesh as useless as the others for metaball-like animations. I want the grid to stay where I specified it with a certain size that I can easily control. I don't think there is a reasonable way around nonlinear sliders.

Also nonlinear slider when implemented would be used everywhere is blender (e.g. all Merge Thresholds, Voxel size also for the remesh in the properties ans sculpt, most scale sliders, radius in painting and sculpt mode, ...) so it would be a very very useful addition for blender in general.

@rjg no please not, please! The bounding box size changes all the time when using different modifier combinations or shapekeys and I don't like the effect that the other remesh modes are giving me. The other remesh modes do exactly that. They have an octree depth and a scale to scale and subdivide the bounding box. The issue is that it would render this new voxel remesh as useless as the others for metaball-like animations. I want the grid to stay where I specified it with a certain size that I can easily control. I don't think there is a reasonable way around nonlinear sliders. Also nonlinear slider when implemented would be used everywhere is blender (e.g. all Merge Thresholds, Voxel size also for the remesh in the properties ans sculpt, most scale sliders, radius in painting and sculpt mode, ...) so it would be a very very useful addition for blender in general.

Robert Guetzkow commented

2020-06-15 14:31:04 +02:00

Added subscriber: @PabloDobarro

Robert Guetzkow commented

2020-06-15 14:31:04 +02:00

@HDMaster84 I see, that's a valid point. I like the non-linear slider idea. Perhaps there is an even better solution for this particular modifier, but I'm not familiar with the implementation of the remesher and openvdb.

@PabloDobarro since you've added the voxel mode to the modifier, perhaps you could take a look at this?

@HDMaster84 I see, that's a valid point. I like the non-linear slider idea. Perhaps there is an even better solution for this particular modifier, but I'm not familiar with the implementation of the remesher and openvdb. @PabloDobarro since you've added the voxel mode to the modifier, perhaps you could take a look at this?

RedAssassin commented

2020-06-15 15:45:45 +02:00

Robert Guetzkow (rjg) (Can't tag you, why ever I tag then someone else) To the first comment you've sent: I updated my Graphics Driver and tried it again. It's crashed, I needed to restart my PC. My Memory is 16GB RAM, so I don't think, that this is a problem, because, when I try to get high, I can get higher than like 20000000000m. Also, when I go below 0.1 to 0.01, it is smooth, it works ok. But then suddenly, when I go below 0.01 it just freezes and I need to crash my PC to be able to restart it. So, with an updated Graphics Driver and recommended Hardware/Memory specs, it just goes down.

**Robert Guetzkow (rjg)** (Can't tag you, why ever I tag then someone else) To the first comment you've sent: I updated my Graphics Driver and tried it again. It's crashed, I needed to restart my PC. My Memory is 16GB RAM, so I don't think, that this is a problem, because, when I try to get high, I can get higher than like 20000000000m. Also, when I go below 0.1 to 0.01, it is smooth, it works ok. But then suddenly, when I go below 0.01 it just freezes and I need to crash my PC to be able to restart it. So, with an updated Graphics Driver and recommended Hardware/Memory specs, it just goes down.

Robert Guetzkow commented

2020-06-15 16:05:13 +02:00

@RedAssassin44 As we've discussed in the comments above. Going below 0.01 can very easily exceed the available memory. At 0.0001, which is one step after 0.01, it takes approx. 27 GB with the default Cube. Depending on the available swap space this may either result in Blender crashing or being frozen for a long time. Your OS may react very slowly too, until either Blender finishes processing or it terminates Blender for running out of memory. Note that the OS freezing/reacting slowly is not the same as a crash. A crash means that it terminates unexpectedly, it could be displaying a blue screen or the computer simply turns off/restarts on it's own.

Ankit Meel commented

2020-07-10 23:01:45 +02:00

Added subscriber: @daendew

Robert Guetzkow commented

2020-07-11 13:30:57 +02:00

Added subscriber: @arsdever

Andrii Mykhailov commented

2020-07-13 12:17:23 +02:00

Added subscriber: @zelfit

Andrii Mykhailov commented

2020-07-13 12:17:23 +02:00

Happened couple of times for me too. Crashed on 64gb ram.
Maybe it will be better to show some kind of warning before proceeding after certain threshold. Similar example from Maya: if you try to subdivide dense mesh you'll receive warning message, from there you can confirm or cancel.

Happened couple of times for me too. Crashed on 64gb ram. Maybe it will be better to show some kind of warning before proceeding after certain threshold. Similar example from Maya: if you try to subdivide dense mesh you'll receive warning message, from there you can confirm or cancel.

Arsen Gharagyozyan commented

2020-07-13 12:24:05 +02:00

For 3ds max there is a good opportunity to cancel the currently executing task via pressing ESC

For 3ds max there is a good opportunity to cancel the currently executing task via pressing `ESC`

Henrik D. commented

2020-07-21 11:43:24 +02:00

@rjg I just found out that the Array Modifier has a limit at which it sends an error without crashing blender. It limits the vertex count to 67 million. We could do the same for the voxel remesher, so it would abort if it would generate more than say 2^32 voxels (computed from bounding box volume), which would be for a simple cube 24 million vertices with 2000 voxels per dimension (2000^26=2410^6). That example still works on my 8 GiB computer. For more complex objects it would be more vertices and can go up to almost the voxel count (or a fraction of it? I am not entirely sure on the upper limit for vertices here). Then it will crash on my computer due to lack of memory, but may still work for others.

@rjg I just found out that the Array Modifier has a limit at which it sends an error without crashing blender. It limits the vertex count to 67 million. We could do the same for the voxel remesher, so it would abort if it would generate more than say 2^32 voxels (computed from bounding box volume), which would be for a simple cube 24 million vertices with 2000 voxels per dimension (2000^2*6=24*10^6). That example still works on my 8 GiB computer. For more complex objects it would be more vertices and can go up to almost the voxel count (or a fraction of it? I am not entirely sure on the upper limit for vertices here). Then it will crash on my computer due to lack of memory, but may still work for others.

Robert Guetzkow commented

2020-07-21 12:20:52 +02:00

@HDMaster84 Sounds like a good idea for a heuristic. Since I'm not familiar with the algorithm used for the voxel remesher and currently busy with my thesis, this should be looked at by @PabloDobarro or other developers familiar with the memory requirements and runtime complexity.

Germano Cavalcante commented

2020-08-05 20:23:16 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-08-05 20:23:16 +02:00

It doesn't crash here, but the time it takes to compute is also not convenient.
Perhaps the modifier could raise warning messages, but it also seems like a good idea to lower the sliding limit when pressing and dragging with the mouse.

diff --git a/source/blender/makesrna/intern/rna_modifier.c b/source/blender/makesrna/intern/rna_modifier.c
index a891194550f..4c715bbb747 100644
--- a/source/blender/makesrna/intern/rna_modifier.c
+++ b/source/blender/makesrna/intern/rna_modifier.c
@@ -5557,7 +5557,7 @@ static void rna_def_modifier_remesh(BlenderRNA *brna)
   prop = RNA_def_property(srna, "voxel_size", PROP_FLOAT, PROP_DISTANCE);
   RNA_def_property_float_sdna(prop, NULL, "voxel_size");
   RNA_def_property_range(prop, 0.0001f, FLT_MAX);
-  RNA_def_property_ui_range(prop, 0.0001, 2, 0.1, 3);
+  RNA_def_property_ui_range(prop, 0.01, 2, 0.1, 3);
   RNA_def_property_ui_text(prop,
                            "Voxel Size",
                            "Size of the voxel in object space used for volume evaluation. Lower "

It doesn't crash here, but the time it takes to compute is also not convenient. Perhaps the modifier could raise warning messages, but it also seems like a good idea to lower the sliding limit when pressing and dragging with the mouse. ``` diff --git a/source/blender/makesrna/intern/rna_modifier.c b/source/blender/makesrna/intern/rna_modifier.c index a891194550f..4c715bbb747 100644 --- a/source/blender/makesrna/intern/rna_modifier.c +++ b/source/blender/makesrna/intern/rna_modifier.c @@ -5557,7 +5557,7 @@ static void rna_def_modifier_remesh(BlenderRNA *brna) prop = RNA_def_property(srna, "voxel_size", PROP_FLOAT, PROP_DISTANCE); RNA_def_property_float_sdna(prop, NULL, "voxel_size"); RNA_def_property_range(prop, 0.0001f, FLT_MAX); - RNA_def_property_ui_range(prop, 0.0001, 2, 0.1, 3); + RNA_def_property_ui_range(prop, 0.01, 2, 0.1, 3); RNA_def_property_ui_text(prop, "Voxel Size", "Size of the voxel in object space used for volume evaluation. Lower " ```

Henrik D. commented

2020-08-06 15:26:32 +02:00

@mano-wii The problem why we kind of agreed, that that was not the solution is that 0.0001 is kind of reasonable when your bounding box is 0.02 instead of 2. There are lots of people (that I know) who dont comply with the rule to use a unitsystem where your objects are "close" to a size of 1. They would want to use 0.0001 then.

If you want to implement a quick solution, doing it this way would be nice:

In #77868#982749, @HDMaster84 wrote:
@rjg I just found out that the Array Modifier has a limit at which it sends an error without crashing blender. It limits the vertex count to 67 million. We could do the same for the voxel remesher, so it would abort if it would generate more than say 2^32 voxels (computed from bounding box volume), which would be for a simple cube 24 million vertices with 2000 voxels per dimension (2000^26=2410^6). That example still works on my 8 GiB computer. For more complex objects it would be more vertices and can go up to almost the voxel count (or a fraction of it? I am not entirely sure on the upper limit for vertices here). Then it will crash on my computer due to lack of memory, but may still work for others.

@mano-wii The problem why we kind of agreed, that that was not the solution is that 0.0001 is kind of reasonable when your bounding box is 0.02 instead of 2. There are lots of people (that I know) who dont comply with the rule to use a unitsystem where your objects are "close" to a size of 1. They would want to use 0.0001 then. If you want to implement a quick solution, doing it this way would be nice: > In #77868#982749, @HDMaster84 wrote: > @rjg I just found out that the Array Modifier has a limit at which it sends an error without crashing blender. It limits the vertex count to 67 million. We could do the same for the voxel remesher, so it would abort if it would generate more than say 2^32 voxels (computed from bounding box volume), which would be for a simple cube 24 million vertices with 2000 voxels per dimension (2000^2*6=24*10^6). That example still works on my 8 GiB computer. For more complex objects it would be more vertices and can go up to almost the voxel count (or a fraction of it? I am not entirely sure on the upper limit for vertices here). Then it will crash on my computer due to lack of memory, but may still work for others.

Marinus de Beer commented

2020-09-29 17:40:28 +02:00

Added subscriber: @Marinus

Marinus de Beer commented

2020-09-29 17:40:28 +02:00

I am having the same issue on Mac os Mojave and Blender 2.90
It is not exactly the same, but out of nowhere Blender and eventually the entire computer hangs on simply adding the remesh modifier. Even with the object being hidden. Standard voxel size of 0.1m wasn't an issue yesterday but now even after a reboot it doesn't want to work. It even crashes other programs when adding the remesh modifier.

I am having the same issue on Mac os Mojave and Blender 2.90 It is not exactly the same, but out of nowhere Blender and eventually the entire computer hangs on simply adding the remesh modifier. Even with the object being hidden. Standard voxel size of 0.1m wasn't an issue yesterday but now even after a reboot it doesn't want to work. It even crashes other programs when adding the remesh modifier.

Jonas Sandstedt commented

2020-10-23 18:44:48 +02:00

Added subscriber: @Sandstedt

Jonas Sandstedt commented

2020-10-23 18:44:48 +02:00

I have the same problem that Unity crashes while trying to apply a Remesh modifier to a fairly complex mesh. But the problem occured first after trying to crank up the regular Octree Depth to around 9 and then changed to Voxel to see what it was. And now the default value is set to voxels with 0.1m voxel size that craches the program very time.

Tried to uninstall blender and install the latest 2.90.1. But seems there where some save files left. Couse had still stuck on the voxel preset for every time I applied the modifier to a new mesh.

I have the same problem that Unity crashes while trying to apply a Remesh modifier to a fairly complex mesh. But the problem occured first after trying to crank up the regular Octree Depth to around 9 and then changed to Voxel to see what it was. And now the default value is set to voxels with 0.1m voxel size that craches the program very time. Tried to uninstall blender and install the latest 2.90.1. But seems there where some save files left. Couse had still stuck on the voxel preset for every time I applied the modifier to a new mesh.

Jonas Sandstedt commented

2020-10-23 18:49:31 +02:00

Manage to get around it by applying the modifier in edit mode, and then switch back to sharp instead.

Alaska commented

2020-10-26 10:17:27 +01:00

Added subscribers: @Mashimaro7, @manzanilla

Robert Guetzkow commented

2020-10-29 22:58:58 +01:00

Added subscriber: @rocketman

Draško commented

2021-02-03 13:01:15 +01:00

Added subscriber: @Dragosh

Draško commented

2021-02-03 13:01:15 +01:00

Remeshing a cube of 20,000 m x 20,000 m x 2000 m with a voxel remesh of 0.1 crashes blender after it devours all of my 32 gb of ram, running latest blender release

Robert Guetzkow commented

2021-05-01 00:13:43 +02:00

Added subscriber: @gert7

Robert Guetzkow commented

2021-05-27 21:15:07 +02:00

Added subscribers: @Wiczus, @Calra

Sam Brubaker commented

2021-05-31 23:51:17 +02:00

It may not be my place to suggest, but I feel that this would be quickly solved by replacing "Voxel Size" with its reciprocal, "Voxels Per Unit".

For instance: voxels per unit = 100 would be the same as voxel size = 0.01.

When larger numbers correspond with greater complexity, there's little chance of accidentally crashing Blender with a single value. You don't even have to bother with non-linear sliders

It may not be my place to suggest, but I feel that this would be quickly solved by replacing "Voxel Size" with its reciprocal, "Voxels Per Unit". For instance: **voxels per unit = 100** would be the same as **voxel size = 0.01.** When larger numbers correspond with greater complexity, there's little chance of accidentally crashing Blender with a single value. You don't even have to bother with non-linear sliders

Henrik D. commented

2021-06-01 12:26:13 +02:00

@rocketman One problem I can see with that is versioning. The way to do it with correct versioning would be to add a combobox with multiple choice for [voxel size, voxel per unit, voxelcount, etc]. That is how "Points to Volume" in Geometry Nodes solved it. That also solved the problem of bad defaults by using voxel amount as default option. Just making it reciprocal would not change the fact that adding the modifier on a mesh can already crash (out of memory) blender, because the default can not be good for all situations.

dendy commented

2021-06-07 06:52:15 +02:00

Removed subscriber: @daendew

Andrew Stevens commented

2021-07-24 02:39:19 +02:00

Added subscriber: @SquidlyPerson77

Andrew Stevens commented

2021-07-24 02:39:19 +02:00

I ran into this problem today by accident. I have:
Ryzen 3400g
16 (2x8Gb) RAM

I slid the slider to 0 by accident and it stopped responding. My video stopped (In browser) and my system started to have bad lag. (My mouse would stop responding some times). However, I was able to slowly make my way to the task manager to find that Blender was making my system usage of RAM to ~90-~95%. I killed the program and my RAM usage went down. I can confirm that there might be some error or something of the sort that allows for unlimited RAM usage and crashes most pcs with low amount of RAM. (My theory)

I ran into this problem today by accident. I have: Ryzen 3400g 16 (2x8Gb) RAM I slid the slider to 0 by accident and it stopped responding. My video stopped (In browser) and my system started to have bad lag. (My mouse would stop responding some times). However, I was able to slowly make my way to the task manager to find that Blender was making my system usage of RAM to ~90-~95%. I killed the program and my RAM usage went down. I can confirm that there might be some error or something of the sort that allows for unlimited RAM usage and crashes most pcs with low amount of RAM. (My theory)

Robert Guetzkow commented

2021-07-28 19:57:00 +02:00

Added subscribers: @Microweb4, @DarkKnight

Robert Guetzkow commented

2021-07-28 20:02:53 +02:00

Added subscriber: @ideasman42

Robert Guetzkow commented

2021-07-28 20:02:53 +02:00

@HDMaster84 @ideasman42 Can this issue be closed as 3.0.0 will have the logarithmic slider?

Henrik D. commented

2021-07-28 23:02:56 +02:00

The problem described by the user is fixed.

The open problem mentioned by multiple users in the comments here is that you could apply the modifier on an object which is out of scale (like 1000bu in size). This would be solved by

adding the options like in the equivalent node to scale with size (as an additional new default option)
changing the default to smooth or blocks etc, because they only use relative sizes
adding a constraint on how any voxels the modifier is allowed to create (similar to how it is done in the Array Modifier)

The problem described by the user is fixed. The open problem mentioned by multiple users in the comments here is that you could apply the modifier on an object which is out of scale (like 1000bu in size). This would be solved by 1. adding the options like in the equivalent node to scale with size (as an additional new default option) 2. changing the default to smooth or blocks etc, because they only use relative sizes 3. adding a constraint on how any voxels the modifier is allowed to create (similar to how it is done in the Array Modifier)

Brandon Lockaby commented

2021-09-25 14:41:21 +02:00

Added subscriber: @brandonglockaby

Brandon Lockaby commented

2021-09-25 14:41:21 +02:00

Accidentally dragging the slider to the left crashes hard on the default cube, and I have 32GB of memory. Maybe the lower limit is too low...

Philipp Oeser commented

2021-11-23 13:37:34 +01:00

Added subscribers: @samrrr, @lichtwerk

Philipp Oeser commented

2021-11-23 13:38:44 +01:00

Should this also take into account scene's unit scale?

Ignacio Borderes commented

2021-11-23 17:29:53 +01:00

Added subscriber: @ignacio.borderes

Ignacio Borderes commented

2021-11-23 17:29:53 +01:00

I accidentally wrote a negative value on that modifier and it crashed, I reproduced the steps with the modifier disabled on viewport and I realized that any value below 0.0001 mm, including negatives, go to the minimum of 0.0001 mm voxel size. This could still happen with a logaritmic slider (I never use the slider), there might be a better "fool proof" way of implementing this. Ideally I would love an advanced configuration option, where I could set default, minimum or maximum values for modifiers, that would be very useful.

Andrew Palmer commented

2021-11-29 06:56:43 +01:00

Added subscriber: @AndrewPalmer

Andrew Palmer commented

2021-11-29 06:56:43 +01:00

I've also noticed that simply having an object that is very large will cause blender to crash or hang for a long time when using remesh. I work with Unreal a lot, and sometimes export meshes from Unreal to tweak in Blender. Since the default units in Unreal is centimetres, objects come into Blender looking the correct size, but the scale is set to 0.01, so an object that may look like it's about 4 meters wide is actually 400 meters wide when the scale is set to 1.0, and putting a remesh modifier on it will hang/crash Blender. I think part of the reason it's so frustrating is that there doesn't appear to be any way to change the settings of a modifier without adding it first.

I think Henrik's suggestion of adding an option to take into account scene and object scale and enabling it by default would go a long way to avoid frustrating users who did not notice that their object was actually enormous because it was scaled.

However, to solve this issue for a wider variety of cases, how about checking how many voxels will be needed to remesh the object and use this number to determine whether or not to intervene in some way? This could be in the form of adding a prompt that allows the user to cancel and set a larger voxel size, or setting the voxel size based on some predefined maximum voxel count and the dimensions of the object in order to make sure it doesn't crash the user's machine. Another option would be to add the modifier in disabled state if it looks like it was going to be heavy and showing a note on the modifier itself until the user takes some action. I know these ideas may sound a bit heavy handed, but if it prevents Blender from crashing and the user losing time and possibly work, I think it's worth doing.

I've also noticed that simply having an object that is very large will cause blender to crash or hang for a long time when using remesh. I work with Unreal a lot, and sometimes export meshes from Unreal to tweak in Blender. Since the default units in Unreal is centimetres, objects come into Blender looking the correct size, but the scale is set to 0.01, so an object that may look like it's about 4 meters wide is actually 400 meters wide when the scale is set to 1.0, and putting a remesh modifier on it will hang/crash Blender. I think part of the reason it's so frustrating is that there doesn't appear to be any way to change the settings of a modifier without adding it first. I think Henrik's suggestion of adding an option to take into account scene and object scale and enabling it by default would go a long way to avoid frustrating users who did not notice that their object was actually enormous because it was scaled. However, to solve this issue for a wider variety of cases, how about checking how many voxels will be needed to remesh the object and use this number to determine whether or not to intervene in some way? This could be in the form of adding a prompt that allows the user to cancel and set a larger voxel size, or setting the voxel size based on some predefined maximum voxel count and the dimensions of the object in order to make sure it doesn't crash the user's machine. Another option would be to add the modifier in disabled state if it looks like it was going to be heavy and showing a note on the modifier itself until the user takes some action. I know these ideas may sound a bit heavy handed, but if it prevents Blender from crashing and the user losing time and possibly work, I think it's worth doing.

Philipp Oeser commented

2022-05-24 09:04:09 +02:00

Added subscriber: @Kendall-3

Philipp Oeser changed title from ~~Blender crashes PC. Modifier Remesh Voxel Size issue.~~ to Remesh Voxel Size can be much to small by default (leading to crashes). 'Edit Voxel Size' operator can have wrong range

2022-05-24 09:06:51 +02:00

Germano Cavalcante commented

2022-08-17 20:10:48 +02:00

Added subscriber: @SRZ