Gian-Reto

Thanks for the quick response. Preset is the right one, Unreal Engine. I never changed that anyway. Before and after images (first image is the mesh as edited in Blender imported as obj, second image is after selecting "Shuffle/Pack" in UV Tool room, and applying. Both are shown with height information only) I exported the mesh and imported it into Blender and Unreal Engine. 3D Coat is accurate in its display of the height information, the normals seem to be garbled in all other tools I imported the mesh to.

I have a rather simple lamp mesh that I exported to obj from 3D Coat, and then modified in Blender to create a thin lampshade (Duplicated the lampshade tris, flipped the normals). Then I painted everything, looks good in the game engine. Now, I found later that the overlapping UVs for the lampshade generate a rather big issue, as I can no longer paint the self illumation by the lamp on the inner part of the shade as illum mask, but have to use a static helper light to bake it to the shadowmap. Apart from the inefficiency of the process (the shader is using a self-illum mask anyway), this kind of defeats the point of using a Stationary main light in UE4, as I can scale the brightness of the main light, but not the helper "self illum" light as this is static. Using another stationary helper light is a nonstarter as there is a max of 4 overlapping stationary lights in UE4, and this helper light would eat into that budget for the small effect it has... Long story short: I am looking for a way to re-shuffle my UV map so the overlapping parts are no longer overlapping, and I can start using a self illum mask to illuminate the inner part of the lamp shade without affecting the outer shell, yet keep the potential to scale the brightness through the shader. The 3D Coat UV Tool function "Shuffle/Pack" seems to be able to do the job. One click, and the overlapping UVs get separated, the UV Map gets neatly re-arranged. After that I hit "apply UV Set" (strangly enough I have to hit apply in the Paint room again). All the color layers I imported get their islands moved to the correct location, looks good. The Gloss map has some black pixels around the seams, but nothing that couldn't be fixed later. But the normal map is completly broken. Hard to describe.... looks like the islands have moved correctly (I see the edges and groves map to the correct location on the mesh), but it looks like the normaldirection of the pixels is messed up. This of course is quite annoying as there is no way to fix that. Is this a known issue? Anyone else had this before? Is there a setting I missed somewhere? I have my global setting set to the Unreal Engine preset, is there a separate setting just for the UV Tools room? Is there another way to separate the overlapping UVs and have 3D Coat rearrange the Islands in the Textures that is less destructive on the normalmap? Thanks in advance for any help.

This is actually something I have noticed before... 3D Coat, at least up to Version 4.7.32, does fill voxel sculpts with colors if you floodfill a per pixel paint layer... Actually, sometimes even the airbrushed on paint ends up there. I never really paid that much attention to it, I didn't think about it as blowing up the filesize this much... probably didn't use floodfilling all that much before. The sculpt room objects where not filled with any vertex color information before baking and starting painting... Also, it usually transforms my voxel objects to surface mode, probably linked to transferring the colors to vertex colors. I guess this is just the normal behaviour when you do not switch off voxel objects in the paint room, like @Carlosan suggested. And while I am not sure why I cannot prevent the tool from transferring the color data or switching my voxel objects to surface mode without hiding them, its not the end of the world.

Got a reply from Andrew. He was able to recover parts of the file. More importantly he was able to pinpoint what was the issue: 1) Part of the file was corrupted... probably due to not having enough disk space at the time. 2) The large size (which in turn caused number 1 to be a problem) was caused by me flood filling paint layers, not knowing that the voxel sculpt in the background would be also filled via vertex colors. And as I had quite a large Voxel sculpt in the Voxel Room, with many vertices to fill, that caused a lot of additional data to be written. So take away for 3D Coat users is: 1) never flood fill the whole layers or 2) keep your baked meshes you paint in a separate file to your voxel sculpt to avoid filling the sculpts vertices with vertex colors.

So I am back with results: Installed 3D Coat Version 4.8.10, ran the DX Build, tried to open the same file. Same Result. Installed the GTX 1070 of the gaming rig in my work rig, tried opening the file again in V4.8.10 - same Result, still an "out of memory" exception even though only around 1.8 GB of VRAM used is reported by GPU-Z at the time of failure. Given we are talking about 8 GB of VRAM now, I guess we can rule out VRAM being to low. I will send Andrew an E-Mail with a link to this thread, the Dump and a download link to the file just noticed the filesize: almost 5 GB Filesize. I am guessing something is not right here, given the Voxelsculpt was just around the 1 GB marker last time I checked. Something must have gone wrong here. What I did afterwards was just creating a retopo mesh, baking, deleting the baked mesh and layers, tweaking the retopo mesh, rinse and repeat for maybe 10 or 15 times, until I was satisfied. Then I started painting. Around that time the "out of disk space" errors started hitting, and Undo history was going wonky. Is baking and then deleting the objects and layers leaving something back in the file? Could that have caused the filesize to grow to 5x the size of the voxelsculpt alone? I guess just the retopo mesh, UV Sets, and paintin layers cannot be 4 GB in size, right?

I have trouble opening a file. Since some days I am getting "out of memory" exceptions during the load of the file. Memory used at the time of the crash with the DX version: 13.5 GB of 24 GB total available to the system VRAM used at the time of crash: 1.7 GB of 3.5 GB effective on the Video card Virtual Memory has been increased increased to 300 GB total (100 GB on D: / 200 GB on H:) Disk space free is: 32 GB on C: 49 GB on D: 1.7 TB on H: Trying to open the file in the GL version resulted in a similar crash. Only difference is that VRAM usage is at 2.4 GB at the time of crash. Hardware used: CPU: i7 970 (6C/12T) GPU: GTX 970 (3.5GB VRAM) Memory: 24 GB DDR3 Disk: 250 GB C: / 500 GB D: / 3 TB H: Measurements taken with GPU-Z on the VRAM side Doesn't sound like 3D Coat really is out of memory at the time of the crash. I had trouble with frequent "out of memory" exceptions while having the file open prior to the file becoming nonworking. At that time the Disk space was low, until I cleaned out some old junk to make room. At the time I thought the problem was that the 3D Coat Undo file was failing to write the history steps, given I was limited then to a single Undo step. What I haven't tried yet is to download and open the file in 4.8 .... because the page was down in the morning. Besides that, I have a GTX 1070 in my gaming rig that I can swap in to see if its a VRAM issue (given that card has more than double the effective VRAM)... but as that is quite some work, I'd like to verify first that a VRAM size issue is plausible. Given the readings of the VRAM used at the time of the crash, is it possible that either GPU-Z was not reaporting the VRAM usage correctly, or that the reading was before 3D coat was trying to get a huge chunk of VRAM? Also, given that there is still unused Memory at the time of the crash, and I should have plenty of virtual memory, can I be completly sure its not a limitation with the amount of RAM in the system? If needed, I can provide a crash report. Didn't wanted to attach it to the Thread for privacy reasons, given it shows quite a bit about the files on my local drives. Should I send an official crash report once I have exhausted all my options (newest 3D Coat version tried, bigger VRAM size tried), or reach out to Andrew directly?

I second that. Fingerwheel support would be very welcome here. And a generalized system which could read all the different additional channels, and maybe generic analog axes that could be mapped to other devices like foot pedals would be great. You can never have too many analog axes to work with (unless you run out of fingers and feet to control them of course ;))

Okay, gave the "retopo via decimate" a testrun today and have to say, I am officially impressed. For a moderatly complex model with many sharp angles (a crystal), the algorithm did a fabolous job once I got the amount of decimation right. Cleanup was needed, but once the Voxel object was smoothed, there were no weird artefacts, just some unneded bevels. I think this is pretty close to what I originally envisioned. Thanks for all the hints and tricks mentioned. I am grateful for all the help you have given me!

Couldn't get that test done this weekend. Will try to look into it this week. I am pretty curious how well this method works, but I will maybe have no time to try until friday. I'll update the topic as soon as I have tried @digman: Is there a difference between how Blender and how Maya does the decimation? From my tests with 3D Coat voxel objects exported as meshes it looks like the problem with messy parts of the decimated mesh comes from the exported ZBrush mesh, which most probably has some weird artefacts somewhere in the mesh. So Blender seems to work just fine together with an exported 3D Coat voxel object, without any cleanup needed really. As I do no longer have access to Maya, could try you the same thing with Blender to see if there is a difference in the output? Again, only if you have Blender installed and the time to run the decimate modifier. Would be cool to see how the two tools stack up in this particular use case.

Gave exporting the voxel mesh a try... wow! Works like a charm. Why the hell did I never see this option before? Is it new? Not 100% how well the resulting decimated mesh would be of use for baking, but seems to work rather well all things considered with the Blender decimate option. Certainly quicker to work from such a mesh than first creating a retopo mesh from scratch in some cases at least. Of course, this is only really usefull for static assets that are kinda damaged, or of natural origin, where exactness of the mesh is of no real importance. An improved autopo algorithm for game asset creation would probably still have some value, as Blender decimate, while doing a fine job, sometimes makes some questionable geometry and is not as configurable as I would wish. And of course, export > import of such a large mesh always takes quite a bit of time. BTW, thanks for the DarkBlender hint. I really have to chech this theme out. Maybe Blender starts looking like the professional tool it is with this? Still have to look into some of the other options... but thanks a lot for all the useful information guys!

Which is a shame really. Given that I had quite good results with the decimate modifier in Blender, is there any way to directly create a mesh from a Voxel object and export that? I mean, 3D Coat has to create a mesh anyway to send to the GPU, sooooo... is there a way to export the mesh of millions of polygons that is used to display the voxel sculpt? That would allow to export the sculpt, and let other 3D tools with different decimate capabilities run over it. Like Blenders decimate, which ain't perfect, but does the job.

In fact I did not. Seems I missed some options on the Autopo window the last time I tried. I will try it out and report back how it works for me now. Thanks for the hint.

But can you tell the algorithm to favor tris? I found that I often had to go in and add edges because the algorithm ignored part of my guides and placed a quad on an edge of my voxel model. Also, I still think the algorithm shouldn't wholly rely on density paint to choose the density of the mesh at certain points... thats just wasteful for game assets. But thanks for the hint about running autopo only on parts of the model. Have to try it one of these days when working with a simpler voxel object.

Long time 3D Coat user here, been mainly using 3D Coat to create game assets for my own hobby projects for some years now. Impressed what the tool can do, having to use blender less and less with some of the features I have found in 3D coat over the years. One thing never really worked for me however, and that is the autopo feature. Now correct me if I am wrong, but I see the current implementation of autopo as being more optimized for people wanting to create 3D models for animation, rather than games. The heavy emphasis on quads and even distribution of the polygons seem to suggest this. For game assets, at least the static ones, that is the wrong approach in my expierience however. Getting the best shilouette match with the least amount of tris used, and more often than not, using tris instead of quads to make sure every single tris counts towards the shilouette seem to be the right way to go forward. Having purchased ZBrush lately because some of the brushes are just better for general sculpting of rocky objects, I found out that I could directly export the high poly sculpt from ZBrush as a mesh, which besides being easy to import as a high poly voxel object for retopo in 3D Coat, also allowed me to import it into blender to run the decimate modifier over it. And to my amazement, that modifier actually did work, and gave me an 90-95% usable low poly mesh I could then load into 3D Coat for retopo. Now, Blender decimate is not perfect. There are the misplaced edges sometimes, which result in ultrathin tris giving 3D Coat headaches during the bake, which need to be cleaned up after. Sometimes the algorithm just seems to stumble and fall on its face, resulting in areas with tons of tiny tris for no apparent reason (that could be a problem with the ZBrush mesh though). So I did have to clean up the meshes. But even with that, I got a mesh that very closely followed the shilouette of the highpoly mesh, and was able to quickly bake the low poly mesh after about an hour or so of clean up. Contrast that to the amount of time I would spend on putting guides on the high poly mesh for Autopo, and then STILL get a mesh with just evenly spaced quads placed without taking the shillouette of the voxel sculpt into consideration apart from my guides, and I bet I would spend way longer going down that route. So what I would like to discuss here if there would be a need for an improved Autopo function, which lets you select different algorithm to generate the Autopo mesh. So the idea clearly is not to replace the current algorithm, which I guess is fine for many users, and what I am suggesting here is very much tailored to the needs of game assets... but giving the user the option to select what kind of meshing algorithm should be used. The algorithm I envision would basically try to to create a mesh, matching the high poly mesh / voxel objects shilouette as best as possible while using the least amount of tris within a given tris budget. So if there is a flat surface... ideally use only 2 tris, or however many are needed to get a good shape in case the flat surface resembles an octagon more than a quad, for example. If there is an edge in the high poly mesh or voxel object, place the edge of an Autopo mesh tris on it. Favour the more acute edges, and steeper angles first, only placing edges on smaller detail edges when the bigger details have been accounted for. Keep the tris budget input, keep the guidelines (as you might want to help guid the topology for something like a face), keep the density modulator (in some use cases that might be helpful)... but the main work should be done automatically by the algorithm, so when you have run it on your voxel object, you get a pretty usable mesh for a game asset right out of the box, without fiddling around with guidelines or density. As long as you don't care about the topology, you should get a mesh which best captures the details it can from the high poly object within the tris budget you set, without anything other than setting that budget and hitting the autopo button. Maybe a selector switch for tris or quad preferrence would be a good idea.... after all, some people prefer quads, seems to be still preferred for skinned meshes. Maybe a way to paint areas where one or the other should be preferred the way it is currently done with density? What do you guys think? Am I just not getting the way the current Autopo tool works, or is there a real need for an Autopo revamp?

Still cannot post in the subforum... do I have to wait a day or something?

Title says it all really... I'd like to post a feature request, I know about Mantis and Trello, yet my feature request is nowhere near as thought out yet that I would feel mantis or trello would be the right place for it. I would rather like to disuss it and see what other people think. If somebody can suggest another forum to do that besides the Feature Request forum were the idea still gets seen by the developers should it be any good and feasible, I am open for any suggestion.

Had another test run, and it seems auto smoothing groups also do the trick. The nice part is that from my testing, visual seams on the edges are now pretty hard to see from a certain distance in Unity... you have to zoom in quite close even in the non-AA-ed editor view to see them. Given that I couldn't see a difference between the bevelled and smooth grouped model ingame from the intended viewing distance, I guess I will start working with smoothing groups for now. Saving another 10% tris gives me more headroom for particle effects or stuff like that, so I'll gladly take that @digman: yeah, I guess these additional loops are what is necessary to make such sharp angles work for baking. Must ask some more up to date guys in the Unity forums what the newest wisdom on subpixel tris in a running game is... I know some of the latest AMD cards have a stage in the pipeline that filters them out before they cost much, and frankly I am not sure anymore if the reason why people were not happy about those was because of the cost vs. benefit relationship (geometry that is not visible but has to be calculated is was pretty bad when the geometry budget was still quite limited). Probably "hacks" like hat in game assets don't matter nearly as much anymore.

Hi Carlosan When I look at the 3b file you uploaded, I see no Voxel Object and no mesh object, just a surface object in the voxtree. When I hide the voxtree, the paint room is empty. What should this test? When I try to bake it, I run into the same errors I get with my voxel model. Bake settings: distance 3 both (setting them to 1 gives me black areas at some places), other scan settings doesn't matter (tested them all), and setting the triangulate option (not setting the triangulate option leads to the same artefacts though). On the other topic of the stretched normals if cubical projection is used, seems 3D Coat cannot handle non bevelled cubes when doing these kind of projections. Which is understandable given how a not that sharp voxel edge is mapped to a supersharp mesh edge, which leads to a distorted normal map... no visible normally, but seems to screw with the cubical projection. I'll try to add bevels in these places and see if it helps. Not ideal for ingame models, but given the total polygon budget of the asset, hardly going to make much of a difference (besides more subpixel polygons). I'll see if it helps with the projection. EDIT: Bevels worked... no more normal stretching in paint room when using cubical projection. Was able to save some polygons elsewhere, so only adding bevels to clean 90° angles cost me about 10% more tris overall. Hardly ideal for an ingame model, especially because they are small tris, but meh, good enough for a max LOD asset. The lower LODS will most probably not need the normal map details so I can drop the bevels there. Maybe I'll give smoothing groups a try to later to see if it still leads to visible seams along the edges like it did with earlier versions of Unity.

Probably the best idea... I will do that, but will take me until tomorrow to do it. Thanks for all the help guys!

Model AFAIK is not very small. Seems to be about 1:1 size when imported into game engine (Unity)... but I will check the settings you mentioned. I am not sure about the scene scale as I usually do not touch this. I can screengrab the bake settings. Inner Outer currently set to 3, AO baking to 5, traingulate selected, other than that everything is left on default. How could the bake influence problems like the one described in my last post? Or are you still talking about the baking errors I originally described? Kinda lost what problems we are talking about here (which totally is my fault for not opening a new thread for different problems showing up ).

Thanks Carlosan, will give it a go tomorrow. I have now a mesh that works, separated the boxes into their own mesh, worked fine, just had to add some fake geometry to the hidden parts of box and column so I still get some AO there. But while testing the mesh I had big problems with cubical projection when flood filling the mesh... I tried to get some small normal details on the mesh. Thing is, the boxes currently have no bevels around the edges. And at some edges the cubical projection gets stretched increasingly as we go toward the edges. Is this a known problem? Anything I can do against it? The UV Projection seem to work only with very specific models, and actually also seem to have a problem along those edges in my case... here the projection does not get stretched, but the normals get more intense. Image of the problem area with UV Projection (sadly have non of the even screwier cubical projection)... you see the normals getting more intense towards the lower edge, yet they should be uniform. That part of the mesh should be flat in the UV. Seams placed along the vertical edges. Any Idea?

Screengrabbed some picture of the problem... This is the Problem as visible in the Paint Room Here is the retopo mesh of the problematic area. And this is how it looks in the game engine once imported, and only showing the scene normals. Next I'll give the newer 3D Coat version a test run. EDIT: new bake tools didn't work for me. Checking the inner cage I think I know now what is the culprit, the inner cage slightly clips through the voxel model to the outside at the problematic edges, and I cannot get it to stay inside by increasing the inside distance. But the new tools also did nothing when I tried. I can make it move outside more, but not inside. After that I tried setting the preset to Maya instead of Unity. Immidiatly the errors are gone after the bake. But I now get a ton of weird errors when painting normals on the model in the paint room. I think I'll just separate into two meshes and call it a day. As this is a static level prop, most probably not worth further tries when it all gets put into a single batch inside the engine anyway.

Added an edge loop above the problematic area, it made the problematic area "smaller" as the problem stayed in the lower half of the now split polygon, but the problem did not go away. I THOUGHT I had the latest version, but looking at the image you attached, probably not. This looks different than the dialog I see. Have there been new scan depth altering tools added? I only see the sphere of influence tools and these did not help. Guess I should download the latest version and give it a spin. Outer cage looked okay from a quick glance. Should probably check the inner cage too. Wasn't sure if the polygons/voxel surfaces set at an outer angle smaller than 90° might confuse the raytracer though....

Well, its not the normal waviness problem. Its an actual baking error. Looks like a "rip" in the model in the 3D Coat Painting room, and if you look at the normal map in another app the normal is messed up from this rip down to the next edge. But true enough I COULD separate the voxel object and create different meshes... I originally dismissed that because I thought that the AO wouldn't be baked correctly for the overlapping meshes, but now that I think about it, I did this some years ago and it worked fine with AO being baked as expected. Guess that would be the easiest way to fix this problem. Going to give it a try tomorrow. Nevertheless, are there other options? I can upload images of the problem in the evenening if its not clear what problems I am talking about.

Hi guys... 3D Coat has become pretty great at baking my retopoed models without baking errors lately... but one thing I still struggle with on a regular basis: edges placed in crevices. Sometimes you have that big fat crevice that runs around a model where you just have to place an edge in because the crevice is pretty important for the overall mesh silhouette. Yet the resulting mesh bend in on itself in an outside angle smaller than 90 degrees. Now you almost HAVE to place the seam inside the crevice as else you might get massive squash and stretch on the UV map somewhere else... But if you place the seam in the crevice, you get massive normal map errors along the seam in the baked model. Now, I have seen these problems before, currently I am stuck with the retopo of a greek pillar. The pillar has bulges at the end which rest upon square stone boxes. where the bulge meets the box is where the trouble is seated. I tried both placing a seam in that crevice which results in the said normal map errors, and removing the seam which results in massive squash and stretch in the upper side of the box, which results in normal map errors there. What I didn't try yet was to activate auto smooting groups, an option I last tried 3 years ago, when it would result in massive problems with visible seams in Unity, so I never touched it again. Maybe I should give it another try now that both Unity and 3D Coat had new versions come out. And I understand if you say pictures would help. Couldn't take pictures yet as I was in kind of a hurry, but figured maybe somebody had the problem before and knew what I was talking about without pictures. I can add pictures when I get home in the evening. Apart from the auto smooting groups, anything else I could/should try? Anyone had the problem before too and found a solution to it? Currently when something like this crops up I easely waste more time on resolving the issue with additional tris, different seam setup and shifting vertices around than time needed for sculpt, retopo AND subsequent texture paint. As always, any help is appreciated a lot. Thanks in advance for that. Gian-Reto