Jump to content
3DCoat Forums


3DCoat Developer
  • Posts

  • Joined

  • Last visited

Posts posted by SERGYI

  1. On 11/6/2022 at 4:43 PM, Cuissedemouche said:

    So, I didn't expect it to work since I also have a crash when there is a scene file, obj or whatever other file (so couldn't open a saved scene), but both the executable you shared to me are working.

    I can open a save without problem, for the picture, when I'm opening it the file dialog is closing, but nothing is loading, but I suppose it's normal since there is not the library for it.

    Please contact me by email: sergkryzh AT gmail DOT com.

  2. On 10/25/2022 at 2:28 AM, Allabulle said:

    The last Linux build (2022.48) doesn't work in Manjaro due probably to more up to date python version installed than Ubuntu's. I'll figure out how to work around it.

    Thanks for the build, though! :good:

    Edit: Build 2022.47 still works, though. Now I'm confused. @SERGYI Could you  please take a look if it works fine? Have python requirements changed in 2022.48? Thanks!

    Edit: My system has Python 3.10.7. 3Dcoat's build 2022.47 works fine with it, as stated. But build 2022.48 complains that it misses Python 3.8

    The "Python" dependency was added since "48". I will try to statically link with "Python" to get rid of the dependency.

    • Thanks 2
  3. On 11/4/2022 at 1:54 PM, Cuissedemouche said:

    So I installed a fresh instance of Arch, went for gnome to be sure to not have a WM related bug, and I have the same bug.

    3DCoat is crashing when it's showing a file in the file manager. I attached a small video to show the behavior.

    I suppose there is a dependency that needs to be filled, but I still can't find any error for the crash.

    To stop blaming "PNG" I have built 2 special executables for you without the library "PNG" inside:
    Download the archive into existing "~/3DCoat-2022.49" which contains "3dcoat". Then unzip it:
    $ unzip 3dcoat-no-png-simple-dialog.zip
    Make the 2 new files executable:
    $ chmod u+x 3dcoat-no-png
    $ chmod u+x 3dcoat-no-png-simple-dialog
    Run "./3dcoat-no-png". It will not be able to load a bunch of icons because they are in "PNG" files. But all the icons are in their places, and they are clickable regardless of whether they are invisible. Therefore, you will be able to click the invisible icon "Camera" in the top-right corner of the viewport. Then select "Background". Then "Ref image for X-axis". I suspect that the behavior will be the same as it was in the normal executable which includes the library "PNG". To furthermore isolate the problem, I have built another special executable for you "./3dcoat-no-png-simple-dialog". The file dialog inside "3DCoat" has been replaced with the simplest code taken from the GTK official site. The code doesn't modify the file dialog class in any way. It simply calls a couple of lines.

    • Like 2
    • Thanks 1
  4. On 9/5/2022 at 7:58 PM, Allabulle said:

    Hopefully with the WSL implemented and working you'll be able to increase the cadence of the Linux builds.

    Sometimes source code of "3DCoat" is not possible to build outside Windows because of substantial changes that our programmers make only under Windows. That requires some work from me to make "3DCoat" cross-compatible again. But when "3DCoat" will be possible to build under Mac, I will build it under WSL in sync. Thanks for your offer, Allabulle.

    • Thanks 2
  5. On 9/2/2022 at 9:09 PM, Allabulle said:

    Thanks for the explanation (and the build!!).

    Thanks, Allabulle, for your feedback and your understanding. Actually, I was planning to buy an additional dedicated machine for Linux builds/development. But the war has changed that plan. I don't want to purchase any things now. So in the nearest future WSL on my existing machines will be the tool for Linux builds.

    • Thanks 1
  6. On 8/30/2022 at 6:49 PM, Allabulle said:

    could we Linux users have a little love from the developers?

    Hi, Allabulle! Everyone in Pilgway is using only Windows. I have 2 Macs, and since some point, the native installation of Ubuntu is not working properly on either of them. So to give love to Linux users requires a lot of effort from me. Under Windows 11 on one of my Macs, I have installed and configured WSL with Ubuntu. Then I built the latest "3DCoat 2022.43" under it:


    • Thanks 1
  7. У меня как раз Wacom Intuos 3. На чистой Windows 11 установил старый драйвер Wacom 6.3.15-3 за 2015 год - это последний, который поддерживает Wacom 3. После перегрузки и подключения, зашёл в Wacom Tablet Properties. На вкладке Grip Pen > Pen убедился, что Right Click назначен на боковую клавишу пера. Зашёл в последнюю 3DCoat 2022.39 для Windows. Парение пера Wacom с зажатой боковой клавишей над поверхностью планшета - масштабирование. Движение пера по поверхности Wacom с зажатой клавишей на пере - панорамирование. Если в 3DCoat > Edit > Preferences > Brushing > Tablet Interface поменять значение с WinTab (Wacom) на WindowsInk, то панорамирование не работает. Режим WindowsInk предназначен для перьев Microsoft Surface - они не поддерживают интерфейс WinTab (Wacom).

  8. After 3 weeks of work and several unsuccessful tries to notarize 3DCoat for macOS (there were problems with code signing and notarization because of USD file format support integration), the build for macOS has been uploaded to FTP. USD import in 3DCoat for macOS works as well as under Windows: 3DCoat imports geometry from USD, USDA, USDC, and USDZ. Export under macOS works for binary USD and USDC. Export under macOS distorts geometry in textual USDA and USDZ. This problem will be investigated this week as well as I will try to build 3DCoat under Linux with USD support.

    • Thanks 3
  9. 15 hours ago, ebitz said:

    Can I ask what the issue was in simple terms?

    When I installed the new Ubuntu 21.10 to debug "Bake w/ Normal Map", it turned out that the crash was occurring when calling "pthread_mutex_lock" inside the system library "libc.so.6". I double-checked that the std::mutex is correct (its 40 bytes are not overwritten by some code in "3DCoat"). Thousands of times "pthread_mutex_lock" was successful. But at some point, it wasn't (as I said the std::mutex is valid). This mutex was used in the memory pool class. To workaround this crash for Linux I changed memory allocation from the pool to standard "new" operator (which doesn't require mutex).

    • Thanks 3
  • Create New...