Jump to content
3D Coat Forums

Emi

Member
  • Content count

    9
  • Joined

  • Last visited

  • Days Won

    2

Emi last won the day on February 10

Emi had the most liked content!

Community Reputation

8 Neutral

About Emi

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Enable
  1. Emi

    [Solved] how to install multiple brushes

    3dcpack is only a zip file renamed, to be unpacked by 3DCoat. you could just change the 3dcpack file to .zip and then you will be able to extract them and move the content to Documents\3D-CoatV48\ even if you had a folder full of TIFF files for example (which is the only format that doesn't get replaced by a mclp file) you could drop all the TIFF files in a folder at 3D-CoatV48\textures\patterns and the folder with all those alphas would be read by 3DCoat and you don't need to manually do anything, you can even do a change on a Tiff file, delete the xml and mclp file that would be generated and then a new one will be generated again (reason why Tiff is the best format in my opinion).
  2. Emi

    [Solved] The Normal Map Preset issue

    Yes, what I mean is that a model with 90° edges should be set automatically to hard edge, there is no other way around and that's it. it doesn't matter if the Cube has 6 sides like in this case or 1000 subdivisions Width, height and Depth. If you don't set the 90° angle of a box as hard edge, it will always have the weird shading on those edges that are 90° but are set to soft or whatever. You are applying a single smoothing group (like you said it) to the whole entire set of objects and that's wrong, that's the issue, because you can't make soft edges or whatever Blender is doing to Boxes (which in my test looks more like the average ones), especially if they objects are only cubes with 6 faces (the lowest possible cube you can have) So the whole box will look wrong. I don't know why you are doing it, or why you think it is a good idea, you even showed me the screenshot and the issue is there, but then you say i is okay and blame 3DCoat, when you are setting things incorrectly before you export it. You can't "smooth" something like, especially if you have a simple 6 polygons box, if you want to use a box like in your models, set all the sides to Hard Edges. Or the other only way around is to add a bevel around the edges to break the 90° angle harsh and then set it to soft. Baking the normal map to hide the issue is not the solution, it might look a little better but the shading error still exists on the model. Even the cylinders in your scene should have soft edges on the sides and on the top and bottom faces they should be set to hard edges unless you add a bevel. So the question is why do you still want to keep everything as a single smoothing group? unless you work on it properly and set things that should be hard edges hard and soft edges soft or add bevels on every 90° angel then nothing will fix your issue, and you have to just hide the issue with the normal map and pretend no problem exists.
  3. Emi

    [Solved] The Normal Map Preset issue

    Leaving aside the UVs rules, the issues it cause are minimal, if you are aware of that, then it's your choice saving some UV space and ignoring the edges and the issue that might happen vs doing them correctly since you would have to get too close to notice the issues. sometimes there is a big gap between the edges, has happened to me but in this case they are not that noticeable. But looking at your screenshot, it was exactly my point. you can't have those boxes as average vertex normals or soft, they have to look like hard edged boxes because they are 90° angle edges. if you want to use soft edges you have to create a bevel. Shading error exists on your screenshot and until you don't fix it the problem it will only be covered by your normal map, but the error is still there. Boxers should be 100% hard edges, Cylinders should be Top and bottom Hard and the sides Soft. When I opened the model in Maya, it seems even worse what what I thought because all sides were average and others hard. so it is a mess for any engine to deal with it. The lowest poly are usually the models with more issues because you are dealing with few polygons that can't deal with the high res topology that well, especially if you go the lowest possible poly count and you do a 6 faces 90° angle edges boxes like in this case, that's why I suggest making bevels, just tiny bevel will make a big difference on many cases, especially in 2019 where there is no excuse to have a box with no bevel at all for something like this. And no, 3Dcoat presets like I said, are just small variations that you can even manually select by using unknown, you dont need the presets, they are just to help 3DCoat interpret the normal map and the model, but I never trust the presets, because like you say Unity preset should be set to MikkTSpace. But my point is that it's not just about OpenGL vs DirectX normal map. so that's not the issue here. So, when I use 3DCoat which is usually to paint, everything works fine, but that's because I make sure everything on my low poly is good as well, I mean, to make good normal maps and make them work everywhere you need a good low poly that can catch the whatever high poly details you made. There is no magic, it just works because I make sure of everything, like the smoothing groups and UVs and all that.
  4. Emi

    [Solved] The Normal Map Preset issue

    I am sorry to tell you, but the problem is your model, not 3DCoat. But Maya and Marmoset Toolbag present the same issue. I will explain why the best I can, but it starts for the way you are exporting your model from Blender, but it will happen the same on any other software if you do the same. Yes, normal map might fix a little the shading issues, for how the normal maps are read by software, and that might make the issue a little less too noticeable, but the issue it is still there, you are just ignoring the real issue and then it seems you aren't applying some of the rules that would help you to make easier the job and life easier by baking better normal maps. By opening the model on maya, right away the model looks terrible, I noticed that most normals were average and few ones were hard, which was weird to see. But that's clearly the the main reason of your problems here, how you are exporting the smoothing groups for your model and how they are being read in other software. First, the boxes can't be soft edges or average, they are 90° angles, and no matter what you do, they will always have this lighting issue if they are not set to hard edges. In the past, before more advanced baking programs like Marmoset appeared to make it easier, you had to always make a cage, and the cage would be the one that had the average vertex normals, so the cage would be used to do the average 'searching' of the high poly, without causing errors on the baking since the box would remind hard edges. Of course now Marmoset has the checkbox "smooth cage" doing the same and now you don't need a cage unless you really need a cage. So there are two 'rules' here and they are linked as well. 1. when you are doing models with 90° angles, they should be always hard. Of course you can also do a little beveling and avoid the 90° angle edges. this will not only follow the shape closely of the high res model, but also, you can use the soft edges on the box and make it look nicer and with less issues, and rounded and prettier and all that. 2. Hard edges (which pretty much should be 90° angles) should always be split on the UV to avoid issues as well, you might not really notice it on your model, but it is there, and it has to do with how the pixels meet at the 90° angle and how pixels might get blended and they are just different so there is not enough space like a padding would do to fix the small issues that might happen. Yes, it depends on the resolution and UVs and all that and that might make it more noticeable than others, but yes, in a case like this where you are doing boxes, you would have to split all those 90° edges, and yes, that means 6 box sides = 6 islands to avoid issues. Talking about 3DCoat and how it works with presets and all that. What I understand about it is that by using the presets like Blender or Unity, you are actually using a predefined file with not only how it will treat the Normal map, which you are right, it will be Green flipped or not. But also Tangent Space, the triangulation, and how it exports the normals and some other options. If you use the Unknown option, you will be able to use the ones on preferences, the ones you set. If you go to C:\Program Files\3D-Coat-V4.8XXX\ToolsPresets\ExtTools you will see the XML files and how Unity differs from Blender, because Blender preset uses MikkTSpace while unity is set to LengyelAreaAngleWeightedSpace. That is the only difference. but apparently enough for you to see it because they are being interpreted differently. Technically they shouldn't affect much anything and only the way it reads the normal map if it is 'DirectX' or' OpenGL', but the root of the shading problem is not about the normal map, it is about the model and it will always be the model. I hope I explained decently what the issues are here so it might help you on your future normal map bakings. Good luck and have a good day!
  5. Emi

    16-bit alpha inside 3D-Coat? How?!

    Yes, pretty much the conclusion of my post was to say that Photoshop is the only way to do 16bit 3DCoat alpha system. Gimp is able to do it, it can read and add multichannel and manipulate it like Photoshop but the problem about Gimp is about how it exports the Tiff files, since it will not be multichannel, and if you have extra channels it will import the first from top to bottom as RGB. So in the end doing it the color, specular brushes on 8bit files and use the layered PSD to further edit the brush is the best option today if you don't have photoshop and even if you do, because dealing with the alphas and extra channels is weird. @tokikake You got a good question there "but when I install it to 3d coat, I do not know, if it keep height-alpha as 16bit" I made some tests, created a PSD with an angle gradient. I used photoshop for the sake of "compatibility" because I wasn't using it anymore, but should work on GIMP and any program. So with the gradient I saved the file to Tiff and PSD, 8 and 16 bit, and also RGB and Greyscale files. With the Stamp Grab mode, and 2D grid mode and snapping enabled 100% depth and layers Opacity to 0% since I don't care about anything but the depth to easily see the result for now but I placed each version on different layers. 8 vs 16 bit, is a huge difference and that's because the 8 bit file will create noise around the whole alpha. and the 16 bit version would not. I just made also a test with PNG and it happened the same, while the PNG with the angular gradient looks terrible on 3DCoat it behaves the same, noise on 8bit, no noise on 16 bit. There is also a difference between how Photoshop exports the PSD vs TIFF or how 3DCoat imports PSD and Tiff or both. Because for example if you chose "Subtract depth" from the layers option, which is the way I tested about the noise and compared the layers. You will see that PSD and Tiff don't subtract each other 1:1, I mean. 8bit TIFF vs 16Bit TIFF would only display the noise but they would cancel each other. but PSD 8 vs 16 would still leave some elements behind besides the noise. and 16 tiff vs 16 PSD has a slight difference, a tiny difference but still visible, 16 tiff vs 8 PSD would display some of the difference between layers, not as many besides the noise but still the expected difference, PNGs would also look different when subtracting each other, but PNG looked bad in general. Grayscale tests, they PSD 16 RGB vs PSD 16 Grey look the same, Tiff 16 RGB vs Tiff 16 Greyscale look the same, 8 bit tiff RGB vs Grey look slightly different. it left noise behind don't know why. The big difference is PSD 8 bit didn't import, it was a flat square brush, nothing about the gradient happened. I don't know why, but it just didn't work. SO the question is What does 3DCoat import? 16 bit files were double size than the 8 bit version but still the mclp file would be the same size on PSDs and even PNG and Tiff had the same mclp size. So 16 bit images make a better alpha but I guess I won't know the exact reason why. So making these tests and now talking about the PSD brushes from Zbrush forum and GIMP, I think in my opinion that the best way to deal with is to conver them as TIFF files. Since they are grayscale images, then Gray = 1 channel and that means that it will take the pixels and convert it to the Heightmap and Alpha. Like the 16 bit manual says. If you want to add color, then convert it to RGB, but then you are limited with just that and you have to add the Alpha channel in GIMP, because if not, you will only use RGB that means that Green channel (3 CH: 1, 2, 3 = RGB, 2= A, H) would be the one in charge with the Alpha and the Height. which makes it awkward because in the end, only colors that are on the Green would be displayed on 3DCoat and depending on how much green it has or not, it will vary on heightmap and the alpha on it, so other colors might look faded and weird. So using the Alpha channel would make it easier (4 CH: 1, 2, 3 = RGB, 4 = A, H), It seems that GIMP exports TIFF as RGBA, and while Photoshop didn't read it, 3DCoat did and that's all that matters, but of course if you want the Alpha+ Height on the Alpha channel, from a grayscale image you would have to send the RGB to the alpha and that might make the alpha look slighly different from the original 1 channel grayscale. But you can add color, why would you add color? I don't know, and I would not complicate myself and just go 8 bit as usual, because you still won't be able to add the Specular, since Gimp wont export Tiff multichannel. Of course if you only want to import the grayscale brushes like the ones from your link, then you can either, import them directly as PSD into 3DCoat or convert them to Tif. I made a test with an alpha from the link you gave, and testing PSD vs Tiff you will have a tiny difference between how they are imported. I used Affinity and Photoline to compare the images and apparently they should be the same but still 3DCoat when doing the depth add vs depth substract it would still be different. I don't know which format is the one that you are suppose to use, I would trust more Tif since in my test it gave a 1:1 extraction from 8 vs 16 for example minus the noise, and Tif format has the advantage of not getting deleted if you decide to directly place the files in any folder on Documents\3D-CoatV48\textures\patterns and that way you would only need to delete the mclp file (and probably the xml as well), and if you make some change, the mclp file would be created again when you refresh the folder (switching folder tabs on 3DCoat), something PSD wouldn't allow and you would have to import it manually by drag and drop or whatever. But yeah, if your alphas are only grayscale, and you won't add color, then using the 1 channel since the channel will be converted to Alpha and Height and you dont need to worry about it and then you shouldn't have any trouble with them and you you can edit them on any software if necessary, which is the easiest way since it is only 1 channel, and if you need color for whatever reason for 16 bits, you can use the RGBA I explained. About the change of size, I guess that happens because 3DCoat brush engine is a circle, which was a weird decision so the only way to support the squared alphas few updates ago, was to scale them down to fit the brush inside the circle, so maybe it detects some alphas like the Cross_xxxx and then mess with the thumbnail vs the real size of the brush, of course most brushes seem to behave nice though so I never worried about it. I hope that will be changed in the future.
  6. Emi

    16-bit alpha inside 3D-Coat? How?!

    From what I have learned and gather in all the tests I have done with different software is you can't compare edit with PSD vs Tiff, PSD will be 8Bit, Edit in ext. editor will do PSD so it is 8bit, if you want to edit the 16bit, you must use the Tiff implementation, nothing else. and that's where the trouble happens, because it uses Channels rather than layers. so you can't think about Color, HeightMap, Specular and EraseMask like on the PSD version, you can't just grab the PSD go 16bit and save it and import it either, you have to think about the channels and the order that they are done in Photoshop, which is what matters there. Carlosan's suggestion's link show how the information is read from the Tiff file in 3DCoat. 1 CH: A&H 2 CH: 1 – A 2 –H 3 CH: 1, 2, 3 – RGB, 2 – A, H 4 CH: 1, 2, 3 – RGB, 4 – A, H 5 CH: 1, 2, 3 – RGB, 4 – A, 5 – H 6 CH: 1, 2, 3 – RGB, 4 – A, 5 – H, 6 – Spec 7 CH: 1, 2, 3 – RGB, 4 – A, 5 – H, 6 – Spec, 7 – Erase mask So using the alpha created by zbrush.tif in 3DCoat does exactly what the list says, since it only has a single gray channel, it will be converted to Alpha and Height by 3DCoat. after that if you if you right click edit 16bit tiff and use photoshop, then the edit version will be the 7 channels version. so the first 3 will be white since there is no color information, Channel 4 will display the Alpha, 5 the Height, and 6 would be white and 7 black. But yes, you need to work on the extra Alpha channels. and the order of those channels will matter. So you can duplicate and manipulate and paint on the alpha channel, it works okay I guess, but it's a weird system to have, especially when it is mostly compatible with Photoshop. I could also make Gimp do the same as Photoshop, but the problem with Gimp is how it exports the Tiff, it just won't work, Exports 16bit but only the RGBA which would explain why the alpha would look different if you use to Edit 16bit Tif on 3DCoat and send it to Gimp since it is not using the channels correctly, and only the RGBA which is darker. But I manually achieved the same channels you get in Photoshop when you edit on 16bit Tiff. First had to hide all the extra channels on the bottom, then I right clicked on the alpha and duplicated it, it will appear at top of the list of extra channels but it has to be on the bottom bottom, which would be the Channel 4 in Photoshop because it goes from bottom to top. Now the problem is the Height is darker than what you would get in Photoshop, so to fix it all I did was to paint in white color the RGB to remove the alpha and make it a solid color, then having RGBA visible and TIFF Channel (which now is 2nd from bottom to top) I duplicate the channel and it creates a lighter version of it, put it on second place (from bottom to top) and delete the old Tiff channel. Now it will look exactly the same in Photoshop but guess what? You can't use Tiff with Gimp and Gimp exports PSD as 8bit not 16bit for whatever reason so it won't work like I thought it would. So in my tests sadly there is no way to do it without Photoshop and I hope Andrew can come up with a better system for the future, like I don't even understand why he made the the way he made it, since the PSD implementation with layers is better and easier and compatible with any program, while the 16bits one is just not good at all. I even tried Affinity software and Photoline and they can't even read the 16bit tiff from 3DCoat. Affinity just throws everything away and keeps the RGB and Photoline doesn't seem to have any channel editing feature. so no way to do the same you can in Photoshop. I saved the Tiff as PSD in Photoshop and could work a little on it with Affinity, reads the extra channels and all but you can't really do anything with them, just put them on the RGB so unless I go to Photoshop and I delete one of those channels it will be imported as RGB and not separated channels. But that was just a test so I didn't worry about it since I knew the Tiff wasnt work anyway.
  7. Emi

    Export for Lightwave ?

    You can open 2018 LWO on previous lightwave versions, you would just need this plugin https://www.lightwave3d.com/assets/plugins/entry/lwo3-loader/ but I have never used it and who knows it is good enough or not. The problem is with LWS, there is no plugin for that. About the surfacing on 2018, you can load it from previous versions but it will not take any advantage of the new PBR features, LW will try to plug everything where it's suppose to be in this backwards compatible material that looks like previous versions. But it's just an approximation trying to give people something if they decide not to re-learn the new PBR workflow render features, but going the new features it's the recommended thing, even if some people say it's slower because rendering a cube will take longer, PBR is the future and it's a good future. I still would use FBX and do all the manual work myself like I have always done it, at least this way I have more control and I don't have to deal with LW trying to convert from one version to another and while LWO might be okay, it will not take advantage of any new feature so it's kind of useless to use it.
  8. Yeah it was more general recommendation to improve theUVs, hide more seams and stuff like that, but I know sometimes it might be hard to do. But the problem is not the padding itself but more the interpolated mode of the padding, you have to understand "interpolated" means it will blend 50% one color and 50% the other color, so it will blend in this case jagged edges. so the only way to avoid the issue in 3DCoat is by changing Realtime Padding mode from Take interpolated color to Naïve padding. did you try that for the jagged edges fills? because to me that worked and I avoided the jagged edges.
  9. @GimbalLock The problem is your UVs, one thing you should always considere is making your UVs straight, not only a straight edges, but also place them horizontal/vertical, something other than 90° degrees may cause these issues, since you are placing your UV seams in these way, then more seams = more possibility of problems like this. You might think the software can figure out how to put color and stuff and fill the edges, but from the start 3DCoat's default action on the padding is to interpolate between the two materials, so it doesn't look sharp and unnatural. For example, you can test this type of behavior on Photoshop or any other image editor, make a horizontal or vertical straight line then make a 45 degrees or whatever other degree line. then obviously the one that is not straight, will show more pixels, and that's exactly what is going on here, especially since you are using 1024px maps. UVs done right, shouldn't show this type of issues or not as much. so that's where you have to start doing things right. But you either use 3DCoat Naïve Padding to reduce a little these issues but it looks weird, since it is just a sharp and unnatural look (if you dont mind) or make your UVs with more straight edges as possible so the interpolation and the fill and pixels will do a good job.
×