3D-Coat 3.3 updates thread

[AbnRanger]

I'm not quite sure but I think that splodge is talking about this issue. http://www.vimeo.com/12543932

LJB, very good find. Hope it will be taken care soon.

I see...maybe greying out the voxel/surface icon temporarily, so you can't switch modes until you un-cache the layer, would be the quickest fix, I suppose. It's playing with fire to do that anyway, when you KNOW the Multi-Res feature is operating through the Surface mode. It's best, unless Andrew wants to change things, to just inform users (in the Manual and Video tutorials) how Multi-Res works, and what it's current limitations are. As I see it, right now...it's looking pretty good. I'm always happy when I get some extra horsepower under the hood...even if that means I have to hit a switch to get it.

[haikalle]

AbnRanger, That is a good option to make it more clear. For me this workflow works just fine. I don't mind to click couple times to get the

speed I want. I agree also that Andrew should focus multires into surface mode. You are very hard to make very detail work in voxel mode because

voxel mesh density is wavy. But in surface mode you can move mesh as you wish. That's why you can also add details with much better accuracy.

I'm quite happy already because 3d-coat makes my old computer look new. It means that I don't have to spend money to get a new one.

[polyxo]

I agree also that Andrew should focus multires into surface mode.

I disagree!

I'd personally gladly live entirely without Surface-Mode if one only could fluidly change

Voxel-Resolution without Model-Size - Change. The resolution limits of Voxels don't cause problems in every Industry!

For users who wants to use 3DC in anything else but Character-modeling the inhibited freedom to create Voxels allow

for are far more interesting than the option to paint single Skin-Pores.

[AbnRanger]

I disagree!

I'd personally gladly live entirely without Surface-Mode if one only could fluidly change

Voxel-Resolution without Model-Size - Change. The resolution limits of Voxels don't cause problems in every Industry!

For users who wants to use 3DC in anything else but Character-modeling the inhibited freedom to create Voxels allow

for are far more interesting than the option to paint single Skin-Pores.

I really don't care....if we could ever get the merge times reduced down to manageable levels. I thought something might be happening on that front when I saw the merge progress bar appearing when using a large brush radius (I thought it was automatically Merging after each brushstroke, so that the final merge isn't such a colossal wait)

[LJB]

Ok So please watch my video again to those of you that think this is working right. See the crash at the end and brush hitching. This never used to happen. As to the process and extra clicks, sure I understand that its only a few extra clicks. What I'm trying and failing to get across here is that All of these controls are active and available whatever you do, whether your in voxel mode or in surface mode. There needs to be more consideration in making these options safe for use, cos clearly they dont function well in Voxel mode. So Yes Either grey them out or remove them from modes that they dont work from.

What you have currently is like putting ejector seat button right next to the Ignition button. One accidental press in the wrong area makes the sculpt unworkable, which could have potentially disastorous consequences. But if we think that this is acceptable then fine leave it like it. I kinda think half the battle with UI Developement is tracking down these incompatibillties and fixing them before the user has to find and make those time costly mistakes. To that end the 3dc UI could do with a complete overhaul of Redundant/Semi reduntdant tools that coul be removed and tidied in this way.

Im not trying to be Nasty Im just trying to help Andrew and Team make this application Rock Solid. Why is there always this Battle with everyone here when making this type of suggestion. Please think about the application and how everyone should use it before jumping in and making commnets like 'It works fine here', and 'I dont mind a few little extra clicks' That doesnt help everyone. If there is something present in a software that has the potential to break someones work in an unrecoverable way, then IMHO it should be limited to where it cant do the harm.

[haikalle]

I agree with you LJB. Everything that will remove your mesh should be iron out. What I ment to say that as a

alpha version it really looks promising.

[AbnRanger]

Ok So please watch my video again to those of you that think this is working right. See the crash at the end and brush hitching. This never used to happen. As to the process and extra clicks, sure I understand that its only a few extra clicks. What I'm trying and failing to get across here is that All of these controls are active and available whatever you do, whether your in voxel mode or in surface mode. There needs to be more consideration in making these options safe for use, cos clearly they dont function well in Voxel mode. So Yes Either grey them out or remove them from modes that they dont work from.

What you have currently is like putting ejector seat button right next to the Ignition button. One accidental press in the wrong area makes the sculpt unworkable, which could have potentially disastorous consequences. But if we think that this is acceptable then fine leave it like it. I kinda think half the battle with UI Developement is tracking down these incompatibillties and fixing them before the user has to find and make those time costly mistakes. To that end the 3dc UI could do with a complete overhaul of Redundant/Semi reduntdant tools that coul be removed and tidied in this way.

Im not trying to be Nasty Im just trying to help Andrew and Team make this application Rock Solid. Why is there always this Battle with everyone here when making this type of suggestion. Please think about the application and how everyone should use it before jumping in and making commnets like 'It works fine here', and 'I dont mind a few little extra clicks' That doesnt help everyone. If there is something present in a software that has the potential to break someones work in an unrecoverable way, then IMHO it should be limited to where it cant do the harm.

That's fine, but I think we were right to point out that it (Multi-Res working in Surface mode) is simply how Andrew chose to implement it....instead of laboring for several more weeks or months to try and force a square peg through a round hole (going Multi-Res through Voxel Volume mode), we get it in our hands much more quickly. Andrew said a week or two ago, here, just how he was going to try to approach it.

As far as losing work, I agree, and that's why I mentioned that temporarily disabling the ability to switch would be one way to solve that.

[Andrew Shpagin]

OSX build of 3.3.04 uploaded too. Linux build will be uploaded soon too.

Now I will try to solve other issues mentioned above.

[lino]

Im not trying to be Nasty Im just trying to help Andrew and Team make this application Rock Solid. Why is there always this Battle with everyone here when making this type of suggestion. Please think about the application and how everyone should use it before jumping in and making commnets like 'It works fine here', and 'I dont mind a few little extra clicks' That doesnt help everyone. If there is something present in a software that has the potential to break someones work in an unrecoverable way, then IMHO it should be limited to where it cant do the harm.

Couldn't agree more.

Thanks Leigh.

[digman]

These discussions bring me back to my conclusion that the new builds need to be clearly denoted as "beta builds" Sometimes they are ,sometimes not and heck sometimes I don't even know. I would like to see a new section in the forum that is just for the new builds. At the present the bug reports for the betas get thrown into the versions jungle or sent directly to Andrew. It is confusing to new users when we have several versions floating around that are not clearly defined...

Also what happens is that the version downloaded from the main website is lagging behind the beta builds. That is to be expected.

The problem is now that any bug in the "version" from the main website is fixed in a new beta build. That leads to the problems I discuss. You are in the middle of production. You report a bug, It is fixed but in a "new build" and not the official downloaded version. You download the new build, great the bug is fixed but now something say in the retopo room is broken in the new build. That would lead a company or person to becoming very frustrated. I have suggested to Andrew, fix any problems in the official version and run a separate program for the new builds. Yes it is more work but at least there is no confusion and lost of your customer base.

Again what happens now is that a stable version(one that can be used for production) is used by a user/company, then a new beta build comes out. It is downloaded and sometimes what was working is not anymore. That causes a misconception of Andrew's program and might even cause a company to abandon his software. This would not be a problem if the new builds would be presented in a fashion that clearly states that when downloading this "build" somethings could be broken. Beta's have bugs, Since Andrew does not have an official beta team (I think that is true), then it defaults to us, which I rather like cause he sure gets the feedback. . Though I think it could be more constructive for Andrew if things were more clearly setup for testing the new builds

I think a clearly defined beta,next a release candidate and then an official build is not a completely bad idea for all concerned...

My two cents worth...

[Andrew Shpagin]

Linux build is there too.

[AbnRanger]

These discussions bring me back to my conclusion that the new builds need to be clearly denoted as "beta builds" Sometimes they are ,sometimes not and heck sometimes I don't even know. I would like to see a new section in the forum that is just for the new builds. At the present the bug reports for the betas get thrown into the versions jungle or sent directly to Andrew. It is confusing to new users when we have several versions floating around that are not clearly defined...

Also what happens is that the version downloaded from the main website is lagging behind the beta builds. That is to be expected.

The problem is now that any bug in the "version" from the main website is fixed in a new beta build. That leads to the problems I discuss. You are in the middle of production. You report a bug, It is fixed but in a "new build" and not the official downloaded version. You download the new build, great the bug is fixed but now something say in the retopo room is broken in the new build. That would lead a company or person to becoming very frustrated. I have suggested to Andrew, fix any problems in the official version and run a separate program for the new builds. Yes it is more work but at least there is no confusion and lost of your customer base.

Again what happens now is that a stable version(one that can be used for production) is used by a user/company, then a new beta build comes out. It is downloaded and sometimes what was working is not anymore. That causes a misconception of Andrew's program and might even cause a company to abandon his software. This would not be a problem if the new builds would be presented in a fashion that clearly states that when downloading this "build" somethings could be broken. Beta's have bugs, Since Andrew does not have an official beta team (I think that is true), then it defaults to us, which I rather like cause he sure gets the feedback. . Though I think it could be more constructive for Andrew if things were more clearly setup for testing the new builds

I think a clearly defined beta,next a release candidate and then an official build is not a completely bad idea for all concerned...

My two cents worth...

It's my understanding that initial point releases (3.x) are supposed to be deemed "official"...and everything in between (3.x.0x) is considered Beta builds.

[ifxs]

Thanks for the OSX multires build Andrew!

I see it as very clear which builds are and aren't beta builds.

cant wait for 64bit OSX builds!!!! and a "shift key view lock/constrain" for 3D coat, thus allowing for locked rotation of the viewport in 45 degree increments(or 15degree, or whatever, (like Zbrush & blender & other sculpting apps.)).

EDIT: I just did my first multi-res tests, and WOW, very impressive thus far. Thank you again Andrew for all your hard work!

[Andrew Shpagin]

These discussions bring me back to my conclusion that the new builds need to be clearly denoted as "beta builds" Sometimes they are ,sometimes not and heck sometimes I don't even know. I would like to see a new section in the forum that is just for the new builds. At the present the bug reports for the betas get thrown into the versions jungle or sent directly to Andrew. It is confusing to new users when we have several versions floating around that are not clearly defined...

Also what happens is that the version downloaded from the main website is lagging behind the beta builds. That is to be expected.

The problem is now that any bug in the "version" from the main website is fixed in a new beta build. That leads to the problems I discuss. You are in the middle of production. You report a bug, It is fixed but in a "new build" and not the official downloaded version. You download the new build, great the bug is fixed but now something say in the retopo room is broken in the new build. That would lead a company or person to becoming very frustrated. I have suggested to Andrew, fix any problems in the official version and run a separate program for the new builds. Yes it is more work but at least there is no confusion and lost of your customer base.

Again what happens now is that a stable version(one that can be used for production) is used by a user/company, then a new beta build comes out. It is downloaded and sometimes what was working is not anymore. That causes a misconception of Andrew's program and might even cause a company to abandon his software. This would not be a problem if the new builds would be presented in a fashion that clearly states that when downloading this "build" somethings could be broken. Beta's have bugs, Since Andrew does not have an official beta team (I think that is true), then it defaults to us, which I rather like cause he sure gets the feedback. . Though I think it could be more constructive for Andrew if things were more clearly setup for testing the new builds

I think a clearly defined beta,next a release candidate and then an official build is not a completely bad idea for all concerned...

My two cents worth...

I will follow this policy:

- every new build will be marked as "beta"

- if it reported as clean I will mark it as "stable" in 2-3 days

[michalis]

Thank you for this nice mac build Andrew. I own you a full 3dcoat sculpt now. We'll see. Excellent work so far.

[Andrew Shpagin]

Updated to 3.3.05 [beta] (Win only, Mac+Win - probably tomorrow)

Changes:

- Well known "faceting" problem while baking to MV/Ptex of higher resolutions solved in both - voxel and surface modes. All looks very smooth after baking. Also baking and snapping quality to voxels in surface mode improved essentially.

- Obsolete links to images in image picker will be removed because it can cause crash at startup.

- Edges highlighted in viewport will be highlighted in UV preview window too - http://bit.ly/9bNZze

- Several small improvements: SL import corrected, new buttons in UV tool - Restore UV and Auto Scale (read hints)

- I made SHIFT constraint to work well in retopo strokes mode

- I made support of picking color from clipboard. In so way you may pick color from Photoshop and Leigh's reference image app. If clipboard has 6 hexadecmail digits 3D-Coat treats it as color.

There are mostly small changes to improve stability and general usability.

[haikalle]

Thanks Andrew for fixing "faceting" problem. This fix alone is a huge step foward.

[PalSan]

- Edges highlighted in viewport will be highlighted in UV preview window too - http://bit.ly/9bNZze

Perfectly!

[Giuseppe]

Andrew, Thank you, works fine really fine

[geo_n]

Downloading the new builds. Is it slow for everyone? 90mb takes half an hour to get.

[philnolan3d]

Not here, takes maybe 1 minute. Of course I have a 15Mbit connection so that probably helps.

[geo_n]

Hmm. I have fiber ops 1GPS service :P

http://www.auone-net.jp/service/connect/ftth/net/index.html

2gigs is a few minutes for me.

Dont know why its super slow to download builds.

[Andrew Shpagin]

OSX build uploaded.

[AbnRanger]

Hmm. I have fiber ops 1GPS service :P

http://www.auone-net.jp/service/connect/ftth/net/index.html

2gigs is a few minutes for me.

Dont know why its super slow to download builds.

It was super slow last week for me too, but that's been about the only time I've noticed it abnormally slow. Download today was fairly normal.

[Tinker]

3d-Coat-V33-05-CUDA32 windows

Баг с использованием proxy: если на сцене имеются объекты с неуникальными именами, и один из них сохранить в прокси, сохранить сцену, выйти из программы, загрузить сцену - потом при возврате вокселей из режима прокси, происходит глюк - объект или исчезает, или происходит объединение с объектом имеющим такоеже имя.

Хотелось бы избежать необходимости использовать уникальные имена.

[Tony Nemo]

Downloading the new builds. Is it slow for everyone? 90mb takes half an hour to get.

Sounds like everybody trying at once. My download was around 425 kbs.

[Andrew Shpagin]

3d-Coat-V33-05-CUDA32 windows

Баг с использованием proxy: если на сцене имеются объекты с неуникальными именами, и один из них сохранить в прокси, сохранить сцену, выйти из программы, загрузить сцену - потом при возврате вокселей из режима прокси, происходит глюк - объект или исчезает, или происходит объединение с объектом имеющим такоеже имя.

Хотелось бы избежать необходимости использовать уникальные имена.

Да, такое есть. Могу или -

- автоматически делать имена уникальными (это проще)

- что нибудь пртдумать

For all:

Please use UNIQUE names of layers otherwise you will get problem if

- move object with some Name to proxy

- move other object with same name to proxy

- save scene

- open scene

- get back from proxy

I will fix it in future

[Andrew Shpagin]

Linux build uploaded too.

[Tinker]

Автопереименование конечно очевидное решение, но тогда будут проблемы с мержем. Если не сохранить оригинальные имена объектов, не будет работать объединение при мерже. Фича с объединением объектов с одинаковым именем с включенной опцией "merge to separate volumes" очень удобная, было бы здорово продолжить ей пользоваться.

Autorename of course the obvious solution, but there would be problems with merge. If do not keep the original names of the objects some merge feature will not work. Feature with the union of objects of the same name with "merge to separate volumes" are very comfortable, it would be great to continue to use it.

[renderdemon]

Andrew, does "delete Hidden " and "Separate Hidden part " work in 3.3.05 ?

I have a 25 million sculpt( a sculpture made of several characters) and I would like to split every part(every character)in a different layer,so I can work faster and easier.

But not matter what I do,I can't isolate a part and put the others(hidden)in another layer.

There is another way to do that?

Thank you