3D-Coat 3.3 updates thread

[AbnRanger]

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

I haven't tried that tool lately, but hiding parts doesn't reduce it's memory footprint. The best thing to do is to use the "Split" tool to divide up your parts. That way you can both cache and hide the parts you aren't currently working on. Not that the hiding tools shouldn't be fixed, but that it's not the most efficient method of doing what you want...now that caching has been added.

[renderdemon]

Thanks AbnRanger,I'll try.

Keep in mind that my first goal is to separate the parts,for this reason I wanted to use "separate Hidden",I'm doing a sculpted group,every character touches the others so for me is easier to try to separate with hiding the parts(as if I do a mistake I can always remove something from the hiding or add something inverting the selection).

Btw,doing hiding and after using the split tool seems to do the work.

Thank you very much.

[ifxs]

thanks Andrew for all the new fixes & the OSX build of 3.3.05! :-)

looking forward to 3.3.06 to test out the pose-tool smoothing fix, and of couse the array of retopo room fixes. You're cranking out tons of great updates as of late. Thank you for your hard work!

[haikalle]

I agree. Andrew has been on fire lately. There has been very important updates coming out every week. If this speed

continues we can see 3d-coat 3.5 out pretty soon.... Can I pre-order already

[Andrew Shpagin]

Updated to 3.3.06 [beta] (Win+OSX, Linux - soon)

Changes:

- Caching of volumes with non-unique names is supported.

- The problem with camera shortcuts solved - http://bit.ly/acl0gB

- Retopo strokes tool improved to work better on very small sized objects

- Fixed the issue in retopo strokes tool: http://bit.ly/dy8tRj

- Several longstanding issues with retopo strokes (slices) solved - green circles (unclosed) instead of orange (closed), missed quads

- Fixed pose tool smoothing issue: http://bit.ly/boiqd5

[3DArtist]

I still get the flicker from the camera shortcuts. (seems worse)

Also, In the Retopo room, the up and down arrows cycle through the tools. Is that supposed to happen? It only works in the Retopo room.

[splodge]

I still get the flicker from the camera shortcuts. (seems worse)

Yeah, still broke..

I'm beginning to wonder if this problem is specific to mine and 3DArtist's machines. I remember having a camere issue in 3D Coat where the camera would be locked at the default position. Whenever I tried to move the camera it would move, but the moment I released my mouse button then the camera would flick back to default position. It was really odd because the way I fixed it was to disable my screen saver in Vista. I know, sounds crazy!

Perhaps other people can confirm the camera shortcuts bug? This way Andrew knows it's a problem for everybody and not just me and 3DArtist.

Bug description:

At the moment the camera shortcut is managing to recall the recorded camera angle, but it's not recalling the recorded camera position. Or rather, it recalls both the angle and position but then quickly replaces the recorded position with some other position.

[artman]

Yeah, still broke..

I'm beginning to wonder if this problem is specific to mine and 3DArtist's machines. I remember having a camere issue in 3D Coat where the camera would be locked at the default position. Whenever I tried to move the camera it would move, but the moment I released my mouse button then the camera would flick back to default position. It was really odd because the way I fixed it was to disable my screen saver in Vista. I know, sounds crazy!

Perhaps other people can confirm the camera shortcuts bug? This way Andrew knows it's a problem for everybody and not just me and 3DArtist.

Bug description:

At the moment the camera shortcut is managing to recall the recorded camera angle, but it's not recalling the recorded camera position. Or rather, it recalls both the angle and position but then quickly replaces the recorded position with some other position.

Its superlongstanding.

Camera shorcut remembers orientation...but not scroll and zoom position.

Its always been like that on my side.

I wrote about this a long time ago.

Anyway,orientation is the most important parameter...lets say you are using "Edit projection in external editors".

Zoom and scroll are easy to reposition(if you were in ortho..).

[splodge]

Thanks for confirming, Artman. No need for other replies on this issue if it's a well known problem. I just hadn't seen many people mention it. Maybe just not a much used feature...

[3DArtist]

Maybe just not a much used feature...

I would actually use it if it worked.

[artman]

Thanks for confirming, Artman. No need for other replies on this issue if it's a well known problem. I just hadn't seen many people mention it. Maybe just not a much used feature...

Well,by longstanding I meant "not fixed" not "well known".

But its true,even in ZB remembering camera position is not a feature that is used that much(except when using Zapplink).

Altough I agree Having 3DC remember scroll and zoom properly would be cool.

But if you are in orthographic mode...try matching a view render loaded as a "material" to a camera shortcut for example

:its pretty easy. Zoom and scroll are easy to match,only orientation is nearly impossible.

[splodge]

Well,by longstanding I meant "not fixed" not "well known".

But its true,even in ZB remembering camera position is not a featured that is used that much(except when using Zapplink).

Altough I agree Having 3DC remember scroll and zoom properly would be cool.

But if your are in orthographic mode...try matching a view render loaded as a "material" to a camera shortcut for example

:its pretty easy. Zoom and scroll are easy to match,only orientation is nearly impossible.

Thanks for the tip, but I never use orthographic.

Orthographic is okay when using diagrams for reference, but it's not great when using photos for reference. The content of photos tend to have perspective, and so it's essential to try to match the perspective.

This leads to a bigger problem I'm having in that the focal point of the camera can't be set. For example - if you zoom into a face of a character that's been superimposed over a reference image then the perspective on the model will change. We need the ability to have the focal point remain at a constant position.

ZBrush gets around the above problem by having default focal point set to the center of the document/background. This means you can pan and zoom into the face of a figure and have the perspective remain constant.

[AbnRanger]

The only thing I've noticed is that sometimes, when Autosave does its thing, it jumps to an arbitrary camera position instead of where I was.

[Tinker]

Спасибо

Thank you

[Andrew Shpagin]

Win version re-uploaded in order to solve cam shortcuts problem.

In addition you can switch between ortho/persp mode using shortcuts.

[3DArtist]

Looks like it works nicely now, Thanks!

oops:

Save and reload a scene with camera shortcuts (mix of perspective and ortho).

When I Cycle to an ortho cam shortcut, the object disappears. But if I switch back to perspective (via perspective icon or '5') the object reappears after a refresh. And it seems after I switch to an ortho cam shortcut, it breaks the ortho view for everything else.

[AbnRanger]

Win version re-uploaded in order to solve cam shortcuts problem.

In addition you can switch between ortho/persp mode using shortcuts.

Thanks Andrew...I had one item disappear when I uncached it. Turns out, it had been re-named while cached, and that seemed to be the root of it. So, the naming convention fix in 3.3.06 still isn't 100%, I don't think.

[splodge]

Looks like it works nicely now, Thanks!

oops:

Save and reload a scene with camera shortcuts (mix of perspective and ortho).

When I Cycle to an ortho cam shortcut, the object disappears. But if I switch back to perspective (via perspective icon or '5') the object reappears after a refresh. And it seems after I switch to an ortho cam shortcut, it breaks the ortho view for everything else.

I can confirm this. Although you only need a single shortcut to expose the bug.

I just saved a scene with a single perspective camera shortcut and then loaded the scene back in and switched to the shortcut, I then clicked on the Orthographic button and the display froze.

[Andrew Shpagin]

Save/load with shortcuts fixed. reuplosaded.

[splodge]

Save/load with shortcuts fixed. reuplosaded.

That seems to be working! Thanks!

[Ghostdog]

This whole business with re-uploading a new version with the same build number is highly confusing. If you keep doing so, would please be so kind to mention the re-upload on the first page of this thread also, so people don't have to dig through this whole thread just to find out if they have already (some days ago) downloaded the actual latest build or if the actual latest build is a later re-upload.

Hopes this makes sense...

+1

Also, please date the build version information.

[Andrew Shpagin]

Linux build uploaded too.

Ok, I will try to avoid multi-re-upload.

[AbnRanger]

This whole business with re-uploading a new version with the same build number is highly confusing. If you keep doing so, would please be so kind to mention the re-upload on the first page of this thread also, so people don't have to dig through this whole thread just to find out if they have already (some days ago) downloaded the actual latest build or if the actual latest build is a later re-upload.

Hopes this makes sense...

Personally, I'd prefer Andrew keep it the way it is. He's re-uploading only when a critical bug or issue has been fixed, and it's much less time consuming for him to just mention here that he's added the fix and you can just re-download. If you think that is too confusing, then just wait til the next point release...they're frequent as they are.

He doesn't usually re-upload. When he does, it is usually done to help get a fix in the hands of those who reported the bugs and may depend on the severity of the issue.

[Javis]

Personally, I'd prefer Andrew keep it the way it is. He's re-uploading only when a critical bug or issue has been fixed, and it's much less time consuming for him to just mention here that he's added the fix and you can just re-download. If you think that is too confusing, then just wait til the next point release...they're frequent as they are.

He doesn't usually re-upload. When he does, it is usually done to help get a fix in the hands of those who reported the bugs and may depend on the severity of the issue.

Quoted for agreement. I don't see it as a problem. I actually find it useful to have these quick fix builds posted, and to be frank, I don't see why it wouldn't be useful to anyone else.

As others have asked, I think maybe adding a date to the build would help those whom are confused, and allow the rest of us that are used to how the builds are currently published still enjoy the quick fix updates.

[philnolan3d]

Yeah I agree, or even something quicker like a + to indicate that it's been reuploaded. Actually most of the time these quick fixes are just one small bug and it often doesn't even affect me that much so if I do miss one it's not the end of the world.

[digman]

I agree, sometimes a quick fix is needed in a new beta release. All that would be required as mentioned is the date of the new upload. No confusion that way...

[Taros]

Hirazi is completely right.

[michalis]

as every build deserves it's own number

Exactly!

[AbnRanger]

Sorry, but it seems as if most of you haven't even read my original post. I'm not claiming the quick fix should go, the re-uploading with only a mention in some post in this thread is what I'm having problems with, making it necessary to follow the whole thread to keep informed on the latest build, making the first post somewhat redundant...

My suggestion was to name a quick fix as such and/or at least mention the re-upload in the first post of this thread.

I resent the earlier remark, that I should just wait for the full release, as this would imply beta's are only for those people "living" on this forum 24/7...

I was just pointing out some IMHO better (and as I can tell from other beta's quite "normal") practice, as every build deserves it's own number and if not at least an extra mention on the "download" page... (the first post in this thread)

But you're probably right: I shouldn't have bothered...

The point is...it's rare for Andrew to re-upload, and if he thought it was critical enough to warrant another release #, he would do so. The releases/builds are fast and frequent as they are, so if you don't check the update threads often, chances are that you haven't missed anything. If that offends you...I'm sorry, but that's the reality of it. What I'm concerned about is Andrew deciding NOT to re-upload at all now, and making everyone wait til the next build.

Again, in the rare case that Andrew does re-upload...it's only because of a relatively small bugfix that came at the last moment (and Andrew is being gracious enough to add it in under the current build)...and it's generally for those that reported the bug. Maybe you don't realize that it takes time away from working on the application, to have to go in and not only re-upload a last minute bugfix, but to have to go and change what is listed on the mainpage. In such a case, Andrew could easily decide it can just wait til the next build. Do you follow me? Andrew is being kind enough to add something small at the last minute, and if we start making further demands...you can see where that is headed.

[AbnRanger]

You still don't get it, but hey, that's your problem, not mine!!!

Oh, I get it...alright. I get that Andrew is a busy man...and it's far easier for us to check the updates thread for...well...updates.

Also, if there is an issue you are having...you can report it in the bugs threads or contact Andrew (with a video example of the problem and a copy of the file that is having the issue). In such a case, Andrew will let you know if he's fixed it and most of the time we simply wait for any subsequent fixes to come in the next build. That's been the standard protocol, and to quote a famous philosopher (Tony Stark, in Iron Man), "It's worked pretty well so far."