AbnRanger

This video might offer some good practices to use in such situations.

I did a quick test and can confirm that there is a bug. I will report this immediately and hopefully we will see a fix in the next build

Yeah, as Carlos said, it appears that a stencil is active, and is the reason this pattern is appearing.

I don't think so. Another option is to go to the GEOMETRY menu and choose SEPARATE DISCONNECTED PARTS (the layer needs to be in Surface mode). Assign a hotkey to that menu option and the next time you want separate a part quickly, you can just hit that hotkey and 3DCoat will do it for you.

Sabastian, it's understandable to have some frustrations, but what Carlos suggested is actually not a work-around. If a user has multiple objects on the same Sculpt Tree layer, they are indicating that they want them all to be treated as a single unit/object. The Pose Tool is actually a more advanced TRANSFORM tool, and thus it can do things the TRANSFORM tool cannot do. I have asked Andrew to change the name so new users understand this without the need of a tutorial. You can also have 3DCoat separate individual objects on the same layer, so that they are completely independent. With your layer in Surface mode, go to the GEOMETRY menu and choose SEPARATE DISCONNECTED PARTS.

Thanks, but for some reason the recording lasts about 32 seconds, so I didn't get to see the part where the brush performance stuttered or anything. I am very curious about this because AMD is coming out with a new series of CPU's that can get up to 5.7Ghz with it's own default OC/boost

Yeah, but the more the number of people ask for the same thing, the more priority it gets.

Okay. I was wondering if maybe the Voxel Paint Depth (in the Tool Options panel) was a bit too thin, but knowing this happens just when you save, seems like a bug for sure. Can you go to the HELP Menu and send that workfile to Support and then email (support@pilgway.com) to explain what steps you were taking to produce this? Andrew will probably have it fixed by the next build.

+1. I have asked Andrew about this before, as well. Would be a very welcome addition.

Sabastion, does it do this when you hit the CTRL + S hotkey combination, to save? Is this a Sculpt Object (object either imported into or created from scratch in the Sculpt Workspace) or Paint Object (Object...usually a low polygon UV mapped model...imported directly into the Paint Workspace, or a copy of a Retopo mesh after baking sculpt details from a Sculpt object)?

Could you screen record this happening, using a default object like the Splash Screen > Voxel Sculpting > Bust? Maybe increase the resolution to where it is about 1-2 million triangles (count is visible at the bottom of the UI, in the status bar) and try to test it? If it is still a problem, letting Andrew see that it indeed is, can be a huge assist. He used OpenGL acceleration to a few other Voxel Brushes (Fill, Grow and Smooth) and perhaps this will compel him to apply it to Airbrush also.

There could be a bug, but I think I would try a few "house cleaning" tips before proceeding. 1) Delete the empty Piston head Retopo group layer...Autopo always creates it's own new layer using the name of the voxel object 2) RMB click the Voxel layer (Piston Head) and choose FILL VOIDS and then RMB click the layer and choose TO GLOBAL SPACE 3) Switch the layer to Surface mode and then in the GEOMETRY menu (Sculpt Workspace) choose SEPARATE DISCONNECTED PARTS. This should separate those rings on the side, which I think could be messing with the Algorithm since it is so close to the actual piston head. It seems to me that making that its own separate object would give you MUCH, MUCH cleaner results. 4) Choose a lower estimated polycount at the top of the Autopo wizard. 50k seems a bit high. Maybe 20-30k? 5) During the calculation I could see a mess of green strokes. I would recommend clearing those. At the bottom of the Autopo wizard, there is an option to bypass strokes and details painting. Uncheck that and see if those strokes appear when you get to the STROKES creation stage. If you see any, go to the section of the tool panel, called SPECIAL and hit the CLEAR button. That should clear that mess of strokes, which I think is the biggest culprit, here.

Please send support@pilgway.com this feature request. I have made the same request multiple times over the past 5 years or so. The more users who request a given feature, the higher the priority it gets. There are different tools that make use of procedural NOISE, and all of them could use a nice large library to choose from. Even the FILL tool has more procedural noise types than what is available in the Smart Materials panel. I wish Andrew would make those and other noise types available. There is a large opensource noise library called Bercon Maps, which is used in 3dsMax. I wish Andrew would try to add these procedural maps to all the Noise-based tools in 3DCoat, including the NOISE tool in the Sculpt Workspace. https://github.com/Bercon/BerconMaps

RMB clicking on a Voxel layer > FILL VOIDS is always a good idea, in case there are any voids inside the volume which can mess with the Auto-Retopo algorithm.

Can you screen record what is occurring in your Viewport/UI when you try to do this? A lot depends on the shape/complexity of the object, and the estimated polycount.

Have you raised this issue with Andrew (support@pilgway.com)? It seems using an Intel Thread Building Block Library could still be an issue. https://medium.com/codex/fixing-intel-compilers-unfair-cpu-dispatcher-part-1-2-4a4a367c8919 This problem was mentioned almost a decade ago and it may still be a problem. Can you screen record a test on the default head bust (from the Splash Screen > Surface Sculpting > pick the Head Bust starter object > click the INCREASE RESOLUTION icon at the bottom of the Sculpt Tree panel, to bring it to about 1 million polys (you can see the polycount at the bottom of the UI, in the status bar). I am really curious to see where this issue is happening. I will try to do a similar test on an AMD laptop (4800H CPU) and see if I can replicate the issue. I did a similar comparison between it and the ThreadRipper (1650X) I had and the AMD Laptop was much better than the ThreadRipper, for some strange reason (probably because it was a much newer CPU than the ThreadRipper).

I think the common denominator is that some applications use Intel's compilers or libraries...which are optimized for Intel CPU's only. Therefore, it can make AMD CPU's seem slow when these Intel tools are used. If anyone is having similar issues, please let Andrew (support@pilgway.com) know about it. I reported this issue to him a few years ago, and he said he might look at using another compiler, but switching could be a massive undertaking. Nevertheless, AMD CPU's are fantastic at most everything else and it seems unfair to be penalized because the Multi-threading in 3DCoat and other apps use an Intel compiler.

I believe that is because the EDIT FALLOFF is just for those modes and not for Paint. I am not 100% certain and it's been a long time since I used that feature, but the falloff for the PAINT mode would be dictated by the FALLOFF parameter in the Toolbar...which is for Brush Alpha falloff values. Maybe Andrew can speak to this, but that would be my guess.

I feel the same way. I had and still am, to a large extent, a big fan of AMD CPU's, but I knew that 3DCoat's multi-threading is based on the Intel Thread Building Blocks (TBB) library. I noticed a big difference in years past, because Intel pulled a dirty trick and hamstinged AMD CPU's (when Intel TBB was used). That was litigated in court, and AMD won a large chunk of change...but I don't know if there is any residual problems from this. Please contact support (support@pilgway.com) and see what Andrew has to say about this. I told him about the issue I had with ThreadRipper and he said he might look at an alternative to Intel TBB, but that would be a huge task. What is strange is my son-in-law's AMD laptop is buttery smooth when sculpting in 3DCoat...it was outperforming my ThreadRipper even!

Can you contact support at support@pilgway.com and explain the nature of this problem? If you could demonstrate it in a screen recording, that would really help them to troubleshoot the issue. Before you do that, try a few things...check the Tool Options panel and make sure JITTER is not enabled (MISC SETTINGS). Also, it would be a good idea to uncheck AUTO-SUBDIVIDE in the Subdivision section of the Tool Panel. At least temporarily, while trying to get to the bottom of this issue. If those don't help, try one last thing...I used to have an AMD ThreadRipper CPU, and at times I had a similar issue. I switched to an Intel CPU (10900) and had no more issues. So, it is possible there is some sort of CPU thread scheduler issue still, with some AMD CPU's and Windows. I think he went into Windows Task Manager > Details > RMB click 3DCoat.exe > Set Affinity > Uncheck CPU 0

Did this help with your specific (brush performance) issue? The guy (Rygaard) who did the Rhino sculpting has an AMD CPU, 5900X (12 cores) and there appears to be no stuttering effect in his sculpts.

You can bring this to the attention of the developers (support@pilgway.com), but I don't think there is anything wrong with the first core being maxed out. It could be handling the most critical operations and the rest are given secondary tasks. An example might be that the first core has to store Sculpt Layer information on the fly, while the other cores deal with the actual deformation of the vertices + dynamic subdivision, etc.

I think it is quite possible that the jerkiness is from REMOVE STRETCHING...when that is enabled in the Toolbar. The reason is, 3DCoat has to perform another calculation once your stroke is finished. It is remeshing locally, on the fly...hence the little pause you might feel. CONFORM RETOPO also does this at the end of a stroke, if it is enabled. Try to leave those unchecked and see if that is indeed the reason. My son in law has a laptop with an AMD (4800H) 8-core CPU (16GB and an NVidia 1660 and it sculpts like a boss, so I don't think it is an issue with AMD CPU's.

That sounds like a good feature request. Also, for auto-snapping, the Surface Snapping mode should strictly disable vertices from penetrating into or through a Voxel/Sculpt object. Period. You would think it would behave this way, already.

Sorry about that. Google was trying to $cam me for more drive space, so I had to spend hours cleaning it up. I may have inadvertently deleted it. I will try to upload it, shortly and replace the link. EDIT: The link was replaced with an updated one. It's a large file, though (2GB). To use, unzip the file and in the FILE menu of 3DCoat, choose INSTALL > EXTENSION (choose the 3DCpack file and it should install the shaders) > Restart the app after the install