Jump to content
3DCoat Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About pior

  • Rank

Profile Information

  • Gender
  1. Hello - I am interested in the plugin but the installation process is not clear. Why are two .py files required ? Installing simple_coat.py gets me the following addon descriptor, which lacks the input field for the exchange folder There needs to be a readme file clearly stating the minimum, necessary steps for installation. What does __init__.py does ? Will it change my user preferences ? Also the name of the addon should be related to the name of the py. It is not logical to have to filter for "3d..." after installing an addon with a name starting with "simple". Either call them both with a name starting in "3DCoat", or both with a name starting with "simple" (with "3DCoat" being the obvious, logical choice). Lastly, what is the difference between "MifthTools" and the 3DCoat/Blender bridge ? Thanks ! [Edit] Installing through the ini py gives the same result - still no input field.
  2. On a semi-related note, something I noticed while painting which I believe did not happen with the earlier 3.x releases : The brush tool seems to miss strokes at a rate of more or less one out of ten. Is anyone else getting that ?
  3. @Findus : Thank your for taking the time to try it out, that's appreciated. I wasn't aware of the functionality of the V key. I assumed that it was the default shortcut for the eyedropper/sampler, but it actually isn't. It looks like this is more of an overall, hard-coded picker that operates independently of the actual Sampler tool that I was attempting to use. Overall I find V-picking it to be a pretty good behavior, even if a bit unusual with the way it relies on mouse hover rather mouse click. The way I see it is that it is definitely not a bug, but rather a UX oversight. What I mean by that is that while it does behave "as designed", the way sticky keys are designed breaks down when used with the Sampler tool on a fast workflow. BUT this remarks only applies to the scenario of a key being assigned to the Sampler tool itself, and not the special "V picking mode", so maybe this is irrelevant after all. I personally don't use sticky keys in any program because I find them to slow me down, but I understand that some users may enjoy them so of course the behaviour should stay (although I would personally appreciate to have the option to disable this behavior globally as I find it to be quite error-prone). So, that brings me to the following questions and requests for @Carlosan : 1 - What is the recommended way for the user to remap "V picking" to another key ? 2 - Is it currently possible to assign it to alt (both left and right) ? 3 - Is it possible to set it to operate on click rather than hover ? (In short : please give us a way to make picking work just like alt-picking in Photoshop) Of course all this should be optional, so that users relying on the current system do not get the carpet swept under their feet Thanks.
  4. Are there any specific conditions required for the crash to happen, that one could reproduce ? I just tried performing a few dozens polygonal freeze selections here (adding and removing) and got no crash, but of course the fact that it is working fine on my machine doesn't mean that it is bug free. I am under win7, i7 2668, with a 750ti running driver 361.91.
  5. Hi Findus, thank you for chiming in. I certainly wish there was a way to use alt indeed. I will try to dig into the config files and/or some autohotkey solution and I will report back with what I find. As far as brush size control is concerned I am personally not bothered by the 3DC implementation as I am relying on [ ] myself but I can see how not having access to alt+rightclick drag could be annoying for those used to that method. As for the other point, I will try to come up with a way to consistently reproduce the issue. For now broadly speaking it can be summed up as "if you color pick very fast in 3DCoat using the "sticky key" method, at one point or another you end up switching tool instead of colorpicking, thus making you color pick again when you actually want to lay down a stroke" - something that can never happen when alt-picking in PS. I'd be curious to hear if it happens for you, and on my end I will try to see if the default V shortcut causes it to happen too. Thanks !
  6. Hello all, I have been using 3DCoat for a few years now and my main use for it is diffuse texture painting. The program is great at it but I do have a long standing issue with the way the eyedropper/Sampling tool works. Like many artists involved in texture painting I come from a Photoshop background therefore this will be my main point of reference. - My first question is related to the mapping of the tool. I can of course map it to any usual keyboard letter key (I personally set it to "i") but it would be great to also be able to access it by holding down Alt while painting - if only because of muscle memory coming from PS. Now of course I am aware that the Alt key is already used by the navigation system when working with Maya-style navigation but surely enough these two things are not mutually exclusive. Maybe there is a way to assign it to the Alt key by manually editing a setting file ? If so please let me know. - Second question : The clever behavior of "hold down a key to temporarily activate tool, or tap the key to switch to it fully" can get quite irritating when dealing with the Sampler tool at high speeds while painting. If I hold down my assigned key, tap down with my stylus to sample, then release both in a very slow and deliberate manner, I do get the color that I want. But if I attempt to colorpick at my usual speedy rate I then always end up with the wrong color samples because it is quite easy to accidentally fully switch to the tool as opposed to temporarily activating it ... meaning that when this happens my next intended paint brushstroke ends up being yet another Sampling pick, forcing me to color pick *again* to go back to my previous selection. Very frustrating. This is getting to a point where it is seriously slowing me down and negatively affects my workflow, definitely kicking me out of the zone ... every 10 seconds or so. How do you guys deal with that ? In general, are there any known workarounds to make hotkey-driven color Sampling more reliable ? Thank you for your help !
  7. pior

    UI responsiveness

    Yeah man, we're definitely on the same page All I am trying to do is bring a little bit of focus on some specific points that might go unnoticed by a significant portion of the user base - which means that some of these issues are probably not often discussed or reported. I assume that ultimately the goal for the devs is to make the program as good as possible for everyone, so I hope these reports will prove themselves helpful. So, may I count you as a user experiencing the issue of the main dropdown menus not keeping up with the mouse mouvements ? That would total to 3 confirmations of the problem out of 3 users so far. But of course I would still love to get more data points. On the topic of a timed and/or space tolerance on mouseover above UI elements, here is a diagram showing 2 important popup menus that would benefit from some improvements (but of course this is true for all other popup menus as well) : I personally tend to lose the E menu pretty often, especially near its top edge. The spacebar menu can be problematic too, but that's less of an issue because it is quite large to begin with. Giving these popups a thicker margin would be a very straightforward fix, but a timed tolerance could be good too. As for anything UI/UX related it is always to predict which fix will end up feeling the most natural/unobtrusive. And again I'd love to hear of any reports on these UI/UX issues, confirming or invalidating them. The list so far is as follows : 1 - Main dropdown menus (File / Edit / View / ...) are not keeping up with fast mouse movements - Yes, I am experiencing this / No, I am not experiencing this. 2 - Dropdown and popup menus are closing themselves when the mouse cursor is out of their surface area (as discussed above this not necessarily a bad thing per say, but I am still interested to know if this happens to everyone as this is not standard Windows behavior) - Yes/No 3 - UI elements are not interactive on the first mouse click when clicking within an unfocused 3DCoat window - Yes/No 4 - When clicking the header of a dropdown menu multiple times fast, the frequency at which said dropdown menu opens and closes is about two times slower than with native Window apps - Yes/No 5 - Sub menus (for instance File > Browse > Installation Folder), the Voxtree right-click menu, and the E and spacebar popup menus have no timed tolerance allowing for the mouse to go out of them then back in without them closing, whereas the main dropdown menus (File / Edit / View / ...) do have a built-in timed tolerance - Yes/No Thanks in advance everyone !
  8. pior

    UI responsiveness

    Hi there Digman, thanks for chiming in. Nice to see some other early adopters out there I totally agree that personal preferences strongly come into play, and of course no two users are alike. You are obviously making a very valid point about the "auto-focused" nature of the UI - that is to say the way menus disappear when the mouse is not hovering over them. This is a great example of a design choice taking its roots in established norms but expanding on them. However, my main concern is error prevention - that is to say, in this specific case, making sure that the user does not have to perform an action multiple times because the environment is not reacting to inputs in a predictable manner. And while the auto-hiding of top menus behaves fine in that regard, there seems to be a definite issue with sub menus and Vox tree menus. Below is another video illustrating this point. It shows that the main rollouts do have a little bit of timed tolerance built into them - what I mean by that is that these menus only disappear once the mouse cursor has been out of their active area for some time. But ! For some reason, this behavior is not respected with sub-menus and the Voxtree menu. Both disappear instantly, without tolerance, which is definitely is a cause for errors. As shown here : Expanding on that, I would argue that the E popup menu (stroke picker) and the spacebar popup menu (color picker and sculpting brush picker) would also benefit for a little bit of tolerance. Another solution would be to give them a invisible margin - in other words, giving them a spacial tolerance rather than/on top of a timed tolerance. I hope this makes sense. - - - - - Regarding possible fixes for increased performance : I believe we are not talking about the same thing here. 3DC runs very well on my machine, with no performance drops or anything of the sort. What I am referring to in regards to menu delay is the way menus seem to not catch up with the mouse pointer by design, as shown in my earlier video report : www.youtube.com/watch?v=K9g5npuduGs May I ask you to give this specific test a try ? I'd be really curious to see if this happens to other users. So far I have gotten one report confirming that it happens on somebody else's machine, but I'd like to gather more data points in order to submit a solid bug report on the topic. And I would have the same request regarding the way the first mouse click is being ignored when clicking within an unfocused 3D-Coat window, as originally shown here : www.youtube.com/watch?v=G13k6xd90Zc - - - - - Also, another issue I recently noticed : When running 3D-Coat in windowed mode, resizing the window makes the splash screen re-appear. Anyone else getting that one ? Thanks !
  9. pior

    UI responsiveness

    And lastly, a note on sub-menus : these seem to disappear as soon as the mouse cursor moves away from them, whereas the expected behavior is for such menus to remain displayed until the user clicks away or performs an action. This is tied to the first remark made at the beginning of this thread about dropdown menus , but I thought I'd try to be as precise as possible by mentioning the specific case of sub-menus. As a matter of fact this particular problem is probably what causes the most missed inputs for me when navigating the UI. Shown here : (Note that there is a little ghosting issue going on in the video when sub menus are rolled out from the vox tree, but this is due to the recording software and is not relevant to what is being pointed out here) Thank you for your time, and by all means please give these little tests a try !
  10. pior

    UI responsiveness

    Also : if the header of a dropdown menu is clicked more than once, with the time interval between two clicks being shorter than a certain threshold, the menu doesn't drop down and/or doesn't roll up in due time. As a matter of fact there is such a time threshold in native Windows app too, but it is much shorter. Is anyone else experiencing this as well ?
  11. pior

    UI responsiveness

    Another UI issue I am noticing : there seems to be about 4 pixels of deadzone between each dropdown menu header (File / Edit / View / Textures, and so on), whereas the default Windows UI norm is to have no deadzone at all, which allows for drowdown menus to instantly switch from on to the other. Again, a seemingly minor issue when described like this but definitely something that can get irritating in the long run
  12. pior

    UI responsiveness

    Hi Abn - I too was wondering if the selection tool was the cause of the issue here but unfortunately this behavior occurs in other scenarios as well, as seen here : (And just to be clear, I am not just hovering over the panels here but actually clicking them. Going forward I need to find out if OBS can display some kind of highlight to make this more obvious). That said, this is a much more minor problem than the one about the dropdown menus not catching up with the cursor. As far as drivers are concerned, yup I am all up to date These tests were performed with a mouse btw. Now since you are under win10, may I ask you to quickly run these tests as well ? I'd be interested to see if other users are experiencing these issues. I doubt that the OS and/or my hardware and software combination is at play here since I remember running into similar problems a while back on a different machine, but that is worth investigating still ... Overall I'd say that this kind of stuff is obviously not really affecting the actually features of the program but it *does* affect the perceived performance of the 3DCoat environment, making it feel less responsive than it could be, and also more error-prone.
  13. pior

    UI responsiveness

    Also, another detail I noticed : when the program is out of focus (that is to say, when the top bar is grayed out because another program is being used) there seems to be an issue with popop windows not being selectable. In other words, the cursor somehow goes "through" them until a first click is detected. Again, a seemingly minor detail but still something that can cause problems. Here is a video showing this behavior compared to the way Photoshop and Mudbox react in a similar scenario : This is of course will be mostly noticeable with multi monitor setups, although I believe that this can probably happen in other cases too. I hope this makes sense !
  14. pior

    UI responsiveness

    Hello all - I have been using 3DCoat for a few years now (as a matter of fact, checking my purchase history tells me that I started using it in ... 2009 !). Until now my main use for it has been projection painting between 3DC and Photoshop, and it has been working great for that purpose all these years. However I am now finding myself using voxel modeling more, and while I am delighted by all the fantastic tools that have been progressively added to the sculpt room I cannot help but notice some issues with the UI responsiveness. As a matter of fact I think I remember running into these problems all the way back to older versions of the program. It's a little hard to explain. Basically these issues mostly occur when "power using" the program, that is to say, interacting with the UI very fast. I keep experiencing missed clicks and overall odd menu behavior. This is especially obvious when compared to native Windows programs. Here is a video to illustrate the issue, comparing the behaviour of the 3D-Coat UI to Notepad : The two main things I notice are : - Dropdown menus disappear when the mouse cursor is not over them, whereas the default Windows behaviour is for them to stay open until the user actively closes them by clickout out of them.- After opening a dropdown menu and pointing to other ones, these do not open until the users slows down the the cursor speed under a certain limit, whereas the default Windows behavior is to open other dropdowns instantly, regardless of cursor speed. I understand that these might seem like minor issues, but they quickly become quite irritating when using the program for long periods of time. Note that I have nothing against original/innovative UIs like those of Zbrush or XNormal in principle - but here it seems more like a bug or issue that went under the radar than a conscious design decision. And of course I rely on keyboard shortcuts for my most used operations, but that is besides the point My system specs are win7 pro x64 sp1 7601, GTX 750Ti, 24Gigs of ram - therefore this is not the system lagging behind. Are other users experiencing the issue ? And what are your thoughts on this ? It personally bothers me quite a bit, making me feel like the program is often about to "break". And of course don't hesitate to let me know if that problem has been brought up in other threads already. Thanks !
  15. A few more notes on 4.5beta8 : - On overall interface responsiveness This is something that I brought up way back in the day (version 2 maybe ?) and I feel like it would be worth mentioning again. Basically, despite its very impressive set of features 3DCoat seems to still have some problems when it comes to UI behavior. This is without a doubt a minor point, but it does affect the "feel" of the program for lack of a better word. Here is a video attempting to show the issue, comparing the menu behavior of 3DCoat with the menu behavior of the most basic Windows program I could think of, Notepad. The video was recorded at 60fps for clarity. Pay attention to the way the 3DCoat dropdown menus do not follow the mouse, and the way they close if the mouse is away from them when for a certain amount of time when they actually shouldn't. There is probably more to it than that, but I feel like these two seemingly small details illustrate the issue well. This behavior is probably the price to pay for using a unified UI API for cross-platform release, and to be fair other software packages suffer from similar symptoms (Zbrush being the obvious). But it might be worth looking into this just for the sake of making the program feel less "glitchy". The help area flashing very fast at the bottom of the interface is another example of that. - On brush preview There needs to be an option to disable the white ghosted brush preview. I know that it disappears while painting, but it is still a hindrance when one is just about to lay a brush stroke as it tends to hide parts of the area being worked on. I hope this helps ! Despite these issues, 4.5 is shaping up to be a truly fantastic release