Jump to content
3DCoat Forums

Vexod14

Advanced Member
  • Posts

    243
  • Joined

  • Last visited

Posts posted by Vexod14

  1. Simply go into the folder where you've installed smarmaterials (by default : C:\Users\YOURUSERNAME\Documents\3D-CoatV49\patterns), and look for png images. To find corresponding material, simply look for the Hexa code after the "auto_mtl_preview_" string, it has a corresponding ".pbrm" file with the material name you can read when in 3DCoat. This is just to double-check you're about to edit the good PNG file ;)

    Then, go on you drawing app of choice, bring on any other render that suits up best your material, and replace the existing PNG file with yours.

    Little tips Corresponding ".pbrm" files are simply text files, so if you need to replace/edit a texture path for example, you can go with a text editor outside of 3DCoat, modify the files in some text editor (I highly recommend using Notepad++), and save it. It's especially usefull if you need to point a lot of textures of a lot of files to a specific path ;)

    /!\ 3DCoat will generate (and override) your PNG each time you'll modify your smartmaterial inside 3DCoat /!\

  2. 13 hours ago, Andrew Shpagin said:

    3.12.20 4.9.68 (stable)

    - Dbl click in UV texture editor in the Hide tool hides the whole island.

    - Fixed transform tool problem when transform was applied twice if both - parent and child were selected.

    What I love with 3DCoat is the huge number of unexpected yet purely awesome features coming out of nowhere. Every update feels like christmas, with its pack of excellent surprises

    • Like 2
  3. 22 hours ago, Carlosan said:

    24.11.20 4.9.67 (stable)

    - fixed particular seams problem - painting over geosphere produces seams in the middle of the big UV-island.

    - Just checked it on the default robot, issue is still here


    I think it would be better to test if this bug is gone based on this default robot file and not the geodesic sphere or any "big & clean mesh" since the bug seems to occur easily on smallest UV islands and since we have to paint more often heavy UVSets/characters than geometry primitives.

    To reproduce and ensure painting/fill works well, please use this default robot file instead of a sphere or any mesh which has perfect/big UVs. If painting on this default robot file works, I think this will be a good sign that bug is gone for good.

    Look close to UVs, try painting and filling islands and see how pixels are painted (test on tiny islands). Idealy when you paint/fill an island it would be nice to get back a strong/plain/solid paint under your brush to match what you've painted/filled and no longer leave grey (unpainted) pixels. If UVs overlaps, I personnaly expect to have pixels replicated as many times as I have stacked my coordinates

    I feel like this is a hard one to fix, take your time (texturing can still be done in older builds, so it's fine ;))

    for those who wants to texture without this issue, use the 4.8.44 here : 

     

    • Like 2
    • Thanks 1
  4. Merging all under the same island (or something with minimal number of seams) is not accurate when you deal with normalmaps/baking, seams allows to reduce polycount and avoid too-thin triangles which are a pain to render for your graphic card and also may cause extra-checkup work when fine-tuning skin weights  (even with a strong tool like Akeytsu)
    To me actually the solution is simply to downgrade at a lower version, as said above (4.8.44, I wish the server could display the full history but I could only retrieve this build thanks to the link posted in 4.8 Beta testing thread), I hope the bug will be solved one day but this old version still does the job so it's fine to me actually (I don't want you to stop your plans with the next huge 3DCoat-2021 which I can't wait to play with )

    Cheers Pilgway team, you're the best !

  5. Just to be sure we're talking about the same unpaintable pixels : You see that little grey-dude on your screenshot ?
    image.thumb.png.d608cb289aca362f40db5f2b3c566b6c.png
    That's exactly this kind of issue I'm having on each models around seams, I use to split vtx normals over seams all the time that said (but I'm doing so since 2015 and I've only seen that unpaintable pixel bug quite recently).

    By the way, on the 4.8.44 I don't have the 2nd bug (which is the most problematic), but first one was already there

  6. It's made using the default robot provided with 3DCoat (shoulder part) + it's already in flat shading view. What you see is only curvature(overlay)+AO(Multiply) over "Layer 11"

    So, to reproduce :
    - simply launch 3DCoat
    - chose paint mode
    - pick this little robot
    - activate flat mode
    - toggle seams display on
    - create a new layer
    - pick a colorful tone (red, blue...flashy helps better spot the bug)
    - paint over seams (on my side it fails over the right shoulder)
    - you might see a lot of fails
    - hide layer
    - show back layer > most "unpainted pixels are painted now (1st bug)
    - some pixels may remain unpainted and these will stay unpaintable (2nd bug)

    Appart from this, past versions of 3DCoat used to create proper pixels on seams correctly when painting, even with an automatic unwrap (which made it useful on rush parts of production when you can't spend time on UVs, quite rare, but happens).

    I've got the bug on all my models since several versions, and I often do and control my UVs precisely to get the cleanest bakes possible (I don't like automatic stuff...). I've tested with 4.9.05, quite same issue but closer to what you've called "triangle not painted" in this one. (I'm downgrading to 4.8.44 to see if I got better results)

  7. Hi everyone !

    It's been a while since I didn't report anything here, I'm having an issue in painting room around seams, as depicted in this video :




    Here are two big problems :

    1 - painting over seams is no longer reactive, since you often have to hide then show back again your active layer to diplay what has really been just painted
    2 - some pixels remains definitely "unpaintable", which causes serious problems when you need to texture something...


    I'm usually running the GL version, but DX fails the exact same way.
    I'm also encountering this bug since several builds (at least since 4.9.55)
    Here are my preferences : 


    image.png.accffbc7d8ab5b9700eeced206fa062a.png
    image.png.79be5a9c16d732030119d111788283ec.png
    image.png.fd9423365b1b443111c60ac70c9cde4a.png
    • Like 2
  8. Textures exported out of 3DCoat are perfectly fine, you need to understand how your shader pipeline works on each engine you want to use these textures.
    Using Substance Painter or Mari won't change this rule.

    A little clue : Gamma setup (on 3dsmax) & sRGB stuff has to be setup with logic on each maps.
    Also, on 3dsMax, there's some parameters you need to take in account to make it work, like for example you can't throw a normalmap directly in the bump input (it sucks, we all know that, and in recent versions of 3dsmax you have "PBR Metal/Rough" materials which handles PBR almost like regular realtime engine does...they just lacks of parameters but anyway)

    Keep also in mind that nowadays rendering a nice shot can be done using realtime game engines such as Unreal, you can litterally crank up the details and achieve gorgeous results in no time, post-process is also done in realtime, so compositing is no longer a real need.

    Since 3DCoat fully did its job (doing PBR maps, that's it), I guess there is no need to ask for help here but on autodesk forums

  9. Sorry for late reply, but yeah I get your point. Partnership could be really interesting. At the moment I'm using both tools to make my assets and that's good enough to achieve what I need (btw I still didn't get the time to dig into 3DCoat -awesome- sculpting tools, I remain a super big fan of the texture paint room )

×
×
  • Create New...