Jump to content
3DCoat Forums

3DCoat 4.8 BETA testing thread


Recommended Posts

  • Reputable Contributor
8 hours ago, Przemas said:

any chance for the Linux build to get an update?

Sergi mentioned about a page or two before this one, that they stopped regular Linux builds months ago because several users were telling them 3DCoat was performing much better on the Windows emulator than the standard Linux OS build. He mentioned they will look to resume them at some point under Ubuntu.

Link to comment
Share on other sites

  • Contributor

The end of native Linux builds is a concern here. We use 3DCoat because it was native, before other alternatives restricted to Win/Mac builds. Even if not as fast as in Windows, we would be using 3DCoat. Not so with WINE, for a variety of reasons.

Let's hope the vague "they will look to resume them [the native Linux builds] at some point" won't take long. I'm a bit baffled at the studio(s) that suggested using WINE, and quite surprised to see Pilgway accepting that as a real option for professionals.

We'll keep using the last builds available for Linux. Later, we might have to part ways. A pity, really, if that day comes, specially now that Allegorithmic is dead as a company and the future of their products is uncertain, as other forum members said in this very thread already.

Anyways, we'll see.

Edited by Allabulle
Link to comment
Share on other sites

  • Member
On 1/25/2019 at 10:42 PM, AbnRanger said:

Sergi mentioned about a page or two before this one, that they stopped regular Linux builds months ago because several users were telling them 3DCoat was performing much better on the Windows emulator than the standard Linux OS build. He mentioned they will look to resume them at some point under Ubuntu.

ouch... so if it is running better under Wine my suggestion is to package  3DCoat+preconfigured WINE as an Appimage. This way we'll get well performing application that will run easily on almost any modern distro (with Appimage / Flatpaks you can bundle all required libs along and those will get used instead of system ones).

https://appimage.org/

On top of that it will make it easy to handle desktop integration (shortcuts, icons and so on).

Link to comment
Share on other sites

  • Advanced Member
2 minutes ago, Przemas said:

ouch... so if it is running better under Wine my suggestion is to package  3DCoat+preconfigured WINE as an Appimage. This way we'll get well performing application that will run easily on almost any modern distro (with Appimage / Flatpaks you can bundle all required libs along and those will get used instead of system ones).

https://appimage.org/

On top of that it will make it easy to handle desktop integration (shortcuts, icons and so on).

Nope, that won't pass professional security requirements. OK for home use, but not at a studio.

Link to comment
Share on other sites

  • Member
1 hour ago, pbowmar said:

Nope, that won't pass professional security requirements. OK for home use, but not at a studio.

... yeah, because WINE will ;) , c'mon...

But apart from that (WINE not a solution if we take your strict standards), but what's the problem with Appimages? They can be sandboxed etc.

If you go Flatpak way you get even more security - and some extra benefits when it comes to "unbundling" your app from the libraries (but with a price - you need to get into its architecture and from what I hear harder to set up). Both solutions IMO way better that asking us to set up WINE.

Side note - I run a small workshop and wouldn't have any issues running Appimage / Flatpak. My guess is for huge chunk of users it wouldn't be a problem as well (don't know sales data so it is wild guess). If it is a problem for a given studio... simply don't use it... Go manual WINE etc route we're directed towards at this point of time.

Edited by Przemas
Link to comment
Share on other sites

  • Advanced Member

They're not my standards, they're AMPAS certification standards.

I agree, for many users it won't be a problem. So, if the number of large studios don't justify it then the 3DCoat team should not worry about it, and the big studios will need to look at other applications to use instead. Simple business :)

Any external software must be vetted, so Appimages or Flatpaks can have other scripts bundled that could compromise security. Again, I'm simply repeating the security standards so don't attack me for this :)

 

Cheers,


Peter B

Link to comment
Share on other sites

  • Contributor

@Przemas: I have to agree with @pbowmar and @Allabulle. Using 3D Coat through Wine is a potential source of problems.

For example, ask yourself a question: who will you send bug reports to? Pilgway or Wine development team? How will you know that a problem you're experiencing is caused by 3D Coat and not Wine (or vice-versa)? Sometimes you can probably tell, but not always.

Please remember that "Wine Is Not an Emulator". It is not meant to robustly run all Windows software. For that you have hardware virtualization and passthrough.

 

Link to comment
Share on other sites

  • Member

not my intention pbowmar - I'm just trying to point to a solution that at the very least will please SOME users, rather than relying on one that won't please the ones you're talking about (if WINE is ok - I still fail to see why appimages / flatpaks that would bundle wine and 3dc would be a bad choice, studios would still have an option to do WINE stuff manually) and would be a hassle for the rest :) .

As said I have no clue how much of a percentage of total 3DC sales studios that need to follow AMPAS make.

P.S. Got any link to AMPAS certification standards? Curious about those...

@ajz3d I'm not saying WINE is ok - check my post. I'd definitely prefer good native version. But as members of Pilgway team mentioned Linux builds have been dropped for the time being and direct us to use WINE I'm trying to make the best of the situation.

Edited by Przemas
Link to comment
Share on other sites

  • Contributor

I know. ;) I was trying to emphasize that running 3DC through Wine is not an acceptable solution for a production software (with all respect to Wine team of course).

I hope that the situation with GNU/Linux builds really is just a temporary one, and we will soon see updated releases on the download page.

Edited by ajz3d
Link to comment
Share on other sites

  • Reputable Contributor
20 minutes ago, ajz3d said:

I know. ;) I was trying to emphasize that running 3DC through Wine is not an acceptable solution for a production software (with all respect to Wine team of course).

I hope that the situation with GNU/Linux builds really is just a temporary one, and we will soon see updated releases on the download page.

 

35 minutes ago, ajz3d said:

@Przemas: I have to agree with @pbowmar and @Allabulle. Using 3D Coat through Wine is a potential source of problems.

For example, ask yourself a question: who will you send bug reports to? Pilgway or Wine development team? How will you know that a problem you're experiencing is caused by 3D Coat and not Wine (or vice-versa)? Sometimes you can probably tell, but not always.

Please remember that "Wine Is Not an Emulator". It is not meant to robustly run all Windows software. For that you have hardware virtualization and passthrough.

 

True, but I don't think Windows runs Windows apps robustly, to be honest. For a long time, I've heard 3DCoat runs faster on Linux than Windows, and recently there was some kind of scheduler issue with Windows cause noteworthy performance regression on certain AMD ThreadRipper CPU's. Hopefully, Sergi will get it sorted out soon.

Link to comment
Share on other sites

  • Contributor
58 minutes ago, AbnRanger said:

True, but I don't think Windows runs Windows apps robustly, to be honest.

Ah yes. that's a different story. One of many reasons which made me jump off the Windows train near the end of last year.

Then, when I was about to buy 3DC license for GNU/Linux, I stumbled upon Sergyi's post. Well, I guess I can only cross my fingers and wait.

Edited by ajz3d
Link to comment
Share on other sites

  • Member

Not sure if this is only for latest Beta. Just updated to RTX 2080  and noticing lots of stutter and lag when using any size brush in vox. I notice that FPS drop down to 60 the minute i rotate the view  and 50fps when i start to sculpt. ahain any size brush.  anyone seeing this 

Link to comment
Share on other sites

  • Reputable Contributor
10 minutes ago, calilifestyle said:

Not sure if this is only for latest Beta. Just updated to RTX 2080  and noticing lots of stutter and lag when using any size brush in vox. I notice that FPS drop down to 60 the minute i rotate the view  and 50fps when i start to sculpt. ahain any size brush.  anyone seeing this 

I'm on a 1080 and have no such problems. Could be completely different, though, with the 20xx series. Go to the EDIT menu > Preferences Panel > General Tab > toward the bottom of the panel, there is a option for V-Sync. Try switching it and see if that fixes the issue. It's supposed to limit the FPS to the max your monitor will run at.

Link to comment
Share on other sites

On ‎1‎/‎28‎/‎2019 at 4:45 PM, Allabulle said:

We use 3DCoat because it was native...

We stopped to build "3DCoat" only under old Linux CentOS 6 ("GCC" compiler from old CentOS 6 makes errors during optimizations). But soon we will try to make native "3DCoat" build under newest Ubuntu using its latest "GCC" with all possible optimizations. That should increase speed of "3DCoat" and will make "3DCoat" builds under Linux regular.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • Contributor
1 hour ago, SERGYI said:

We stopped to build "3DCoat" only under old Linux CentOS 6 ("GCC" compiler from old CentOS 6 makes errors during optimizations). But soon we will try to make native "3DCoat" build under newest Ubuntu using its latest "GCC" with all possible optimizations. That should increase speed of "3DCoat" and will make "3DCoat" builds under Linux regular.

That's reassuring. Thank you for the explanation, SERGYI.

Link to comment
Share on other sites

  • Advanced Member
1 hour ago, SERGYI said:

We stopped to build "3DCoat" only under old Linux CentOS 6 ("GCC" compiler from old CentOS 6 makes errors during optimizations). But soon we will try to make native "3DCoat" build under newest Ubuntu using its latest "GCC" with all possible optimizations. That should increase speed of "3DCoat" and will make "3DCoat" builds under Linux regular.

Thanks Sergyi, though if I can please implore you to make sure it works on Centos 7.5 and follows the VFX Platform specs, otherwise it can't be used at the studios... 

  • Like 1
Link to comment
Share on other sites

  • Member

Thx for the reply Sergyi . Thumbs up for keeping Linux builds going.

I second the sentiment of trying to build under Centos 7 (7.5) - in my workshop we use "enterprise" distro as well, and those tend to have glibc that is not as "fresh" as the one in recently released Ubuntu.

Edited by Przemas
  • Like 1
Link to comment
Share on other sites

  • Reputable Contributor
5 hours ago, SERGYI said:

We stopped to build "3DCoat" only under old Linux CentOS 6 ("GCC" compiler from old CentOS 6 makes errors during optimizations). But soon we will try to make native "3DCoat" build under newest Ubuntu using its latest "GCC" with all possible optimizations. That should increase speed of "3DCoat" and will make "3DCoat" builds under Linux regular.

That's good news. It would be helpful to post this statement on the download page, under the Linux logo, so all Linux users can see it without having to dig through the forum to find it, or ask again. 

  • Like 2
Link to comment
Share on other sites

  • Member
19 hours ago, AbnRanger said:

I'm on a 1080 and have no such problems. Could be completely different, though, with the 20xx series. Go to the EDIT menu > Preferences Panel > General Tab > toward the bottom of the panel, there is a option for V-Sync. Try switching it and see if that fixes the issue. It's supposed to limit the FPS to the max your monitor will run at.

thanks , but made it worst haha 

Link to comment
Share on other sites

4.8.33

- Edge width correction for Cube mapping, own settings panel for cube mapping

- EPS files import corrected.

- fixed problem of 16/32 bit tiff/exr alphas importing.

- fixed double undo problem in pose tool and lasso/rect selection

- Restored Rotate/scale controls in transform gizmo

- Correct undo after voxelization of the volume, attached to curve.

- Load/Save for noise

- fixed problem in curves tool - sometimes only one instance of the model was appearing.

- Importing multiple 3dcpack-s, enabled supports

- fixed negative alpha issue

  • Like 8
Link to comment
Share on other sites

  • Reputable Contributor

4.8.32-SL
When calculating occlusion and for light baking : "separate paint objects" does not work in vertex painting mode. (it does not separate sculpt objects, only paint objects)

(Yes, yes there is a workaround, bake a separate map for each object, but...)

 

Edited by lesaint
Link to comment
Share on other sites

  • Contributor

Hey everyone,

I quickly did the following tests:

1- I tried to import a file in EXR format (dragging from the windows explorer folder) and 3D-Coat closed (crash!) And asked to save the project.
- In the "Open texture" option of the Alphas palette there is no option of choosing the EXR extension to open. So, for me to try to open the EXR, I drag the file from the folder into 3D-Coat and for me the program closes (crash!) At the same time.

2- In the other test, I tried to use the Edit The 16-bit Tif option and the problem of opening the alpha continues. An error message and when the external editor opens, there is no alpha, but the document appears with black background.

image.thumb.png.d58361a1d24ce7195929b8ae79d57dd2.png

3- When you try to delete alphas from the Alphas palette, using the Delete Alpha option, 3D-Coat will momentarily delete, because when you exit the program and return, the alphas you deleted will return. For me to permanently delete an alpha that I do not want anymore, I go to the \ textures \ patterns \ directory and delete it directly, that way when I exit the program and the alpha is actually deleted.

4- When I use the Save to PSD / TIF option, saving the TIF option, the saved file can not be opened. When I went to check in Gimp happens the same error of test (2) IMAGE above. An error message appears and the document with black background appears.

What exactly were the fixes related to Alphas? I will still try to discover and test.

4 hours ago, Andrew Shpagin said:

- fixed problem of 16/32 bit tiff/exr alphas importing.

 

4 hours ago, Andrew Shpagin said:

- fixed negative alpha issue

 

Link to comment
Share on other sites

  • Member
2 hours ago, Rygaard said:



2- In the other test, I tried to use the Edit The 16-bit Tif option and the problem of opening the alpha continues. An error message and when the external editor opens, there is no alpha, but the document appears with black background.

 

I'm only guessing but the black phenomenon might have something to do with gimp not understanding adobe color schemes.

Link to comment
Share on other sites

  • Contributor
11 minutes ago, The_Mikeman said:

I'm only guessing but the black phenomenon might have something to do with gimp not understanding adobe color schemes. 

I do not understand much, but I forgot to mention that I also tested on Krita.
The difference is that in Krita the error message dialog box does not appear, but the document with black background appears and a completely different alpha than it really is.
My true Alpha is replaced by a square alpha.
I do not know why this happened and this square alpha came up.
(I captured the image for you to see what happens in Krita).
image.thumb.png.a12c6cdd2c736f3cbfd55939b0b3a6ae.png

If I'm not mistaken this also happens in Photoshop.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...