• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About MaDDoX

  • Rank

Contact Methods

  • ICQ
  1. You know what would be great for instancing? If we had an "additive" instance mode, where the source object editings would propagate to the instanced ones, but they had their own "internal layer" of sculpting to change their shapes in unique ways. This way, for instance (pun intended), you would be able to have a base face sculpt, and several clones with facial expressions, ideal for morphing and such. Then If you added a wrinkle to the base face or changed its proportions, the "smile" and "frown" clones would take the same change. Of course that would only make sense in a real world production pipeline if one could also propagate the base voxel retopology to all the instances and then export them separately - which does sound like quite a complex system for what originally seemed like a small suggestion Anyways, the suggestion stands, hope it's helpful in some form or fashion. Great work with this as usual Andrew, I wish you and the whole 3DCoat community/family a nice, prosperous and productive new year!
  2. Andrew, no matter how hard this community push and pull you towards our 'impossible' to reach desires, you continue to deliver. The comparison to other "major" players seems like a joke, like the Mudbox guys which publicly admitted how much they avoid adding 3D-space editing operations due to its "complexity" - for instance, a simple "smear" brush, which 3DCoat has had for ages. Way to go man, awesome rithm between adding new features and substantially improving previous ones.
  3. +1 BTW, I rarely if ever sign for betas, but this just rocks. Gameplay seems right on mark, and the scope and quality of the scenario is mind-blogging to say the least. Congratz to the team!
  4. I do think mouse over feedback is a great feature to have, especially for newcomers, but I have to agree with AbnRanger when we don't even have real time progress bars! Seriously, what the hell is with 3DCoat's progress bars?? Every artist I show 3DCoat to and that tries to use it always complain about the fact that it might take 5-10 seconds just to show the progress bars after clicking on some commands, even auto-retopo. Believe it or not, I've actually seen a bit more anxious artist hitting ctrl+alt+del to finish the application once in such a situation.. Not to mention that when the operation completes before the progress bar box shows up, you get zero feedback about what happened - especially if it was an operation that led to no result, like for instance performing relax on an already relaxed island. It's just as if the program went to zombieland for a moment and then back, with no warning.. You know what I've got used to do to know when the program had completed some operations? To put the mouse pointer over a different menu option than the one selected. As soon as it highlights I know the program is back to his externally-conscious state. Ouch.. That all might sound funny and minimal, but it's a serious issue that makes the program seem quite unprofessional. If the progress bar box showed up instantly for such operations, even if stuck at zero% for some time, this kind of frustration would be completely removed.
  5. Well Phil, last time I've tried it (it's been a couple months and considering 3DC's dev speed this is a long time ) there was a sensible delay between the UV-viewport stroke (which's 100% realtime) and the stroke actually showing up in the 3D view. With well laid out UVs it's quite handy (for instance, to get perfectly aligned color stripes) to brush on the UV view while you keep looking at the 3D-view result, that's why I keep both views tiled side-by-side all the time in the paint room. Anyways, maybe my experience it's just another side effect of the sluggishness of the paint tools in general. All this "brush radius controlling pinpoint operations" concept is kinda disorienting tbh. I found it by mere accident and it has led to needless additional frustration - having to increase and decrease brush size just to carry out this or that operation. I've also read a couple comments from users that think the software is bugged because of it. It makes little-to-no sense when you're using a single-item-picking operation and have to watch your brush size. Worst case currently is when you try to split an edge and have to lower the brush size until it fits the middle of the edge to pull it off. Now, I thought points-and-faces wasn't even working, since I couldn't for the life of me use it to create quads while working yesterday, then I read here that it's just a case of reducing the brush size again? Oh my.. It's not as if we can keep the brush size to one, since we generally need to smooth and brush-nudge poly areas. I know the previous behavior was very inaccurate and shaky, but there must be a better option. Maybe a toggle between both?
  6. Hey, that sounds great, I hadn't heard of that before Will sure try it, thanks for the hint. Sure, if a visual seam is to be expected or won't matter, it's actually smarter to add the UV seam, to make the UV islands more relaxed. I should have said "try to keep to one island per continuous material type". That's really weird, I've always got that option pinned on my layout. Maybe you're not finding it 'coz you're looking at the windows-popups menu item, un-obviously enough this specific window is found on textures->texture uv editor. It's one of the most amazing things in 3DCoat actually, allows you to check normal, diffuse and specular maps, and even paint straight on the flattened UV while you see it updating in (semi) real-time in the 3D view. BTW Andrew, as we're talking about not-real-time painting performance, would you mind checking this thread (if you didn't yet):
  7. I suspect adding multi-threading to the paint tools will improve situation but not totally fix it. That's why, I believe, Andrew wants to go through some deeper optimization procedures - which, as a rule of thumb, are always the hardest to pull off. I second the plight for speed improvements, right now for me it's Mudbox all the way for texture painting. Which's kinda weird considering that texture creation was the whole reason why the app was created to start with - hence the "coat" name and the fresh paint logo, aye?
  8. Even if just for "coating" (texturing) 3DCoat has features that easily rival that of its most expensive counterparts. Mudbox 2011 for instance still got no proper "color smudge" brush, while 3DCoat even has nifty inflate/deflate brushes. Bear in mind that texturing speed used to be very bad with big brushes but this is being improved over time. A few hints: - Always paint on a subdivided model, don't do it in the low res (cage) model or else the brush accuracy will suffer. Just don't subdivide the model too much, for obvious performance reasons, generally the third or fourth subdivision rez option works fine. - Don't trust too much the 'soft stroke' option, even with large settings it doesn't smooth lines half as good as the zbrush 'lazy mouse' equivalent option. - Play with the airbrush, try tiling some textures with it and "feel" how it works. It's great
  9. True, it's many times handy to have edges "locked", that's exactly why UVLayout (probably the most professionally used UV creation application) has a 'smooth edges' toggle. UVLayout also has the ability to create 'pins' (using the A key shortcut) that hold specific vertices in place as the smoothing is carried out, very handy for the smoothing of tight corners in which you never want some vertexes to move and create overlaps. Edge padding work things out nicely for diffuse (color) textures, but it's really insufficient for normal maps. That's more related to the normal map technology itself than to some 3DCoat limitation, there's a recent Pixar workflow presentation that explains that in detail - you can search for Pixar + ptex in youtube. Talking of which, normal map creation also has been an area in which 3DCoat has fallen short in my opinion, although Andrew has made great improvements in that aspect recently. Anyways, my point stands that your best option for real-time/game engines is have the least seams possible, preferrably just one island, and keep those seams as well hidden as possible. To achieve that goal I'm finding the UVMaster (zbrush auto-UV creation plugin) + 3DCoat combo to be almost unbeatable. I create the base UV cuts in ZB/UVMaster, those cuts work as a great starting point while the auto-UV option in 3DCoat just creates garbage which's unfortunately as useless as hard to clean up. I then edit and smooth them in 3DCoat using its excellent UV toolset. A little known fact is that 3DCoat's smoothing brush algorithm is sensibly superior to the brush smoothing algorithm in UVLayout (not talking about the island-wide option, that one is pretty kickass). 3DCoat's UV brush reaches higher levels of smoothing and distributes smoothing better across larger area, leading to superior results. Actually the texture maps show up in the UV preview window normally in the Texture Editor (Paint Room) just not in the retopo's UV preview. To be honest I don't understand why that would make any sense, since while you're retopo'ing you - as far as I know - shouldn't think about the final texture, just about seams and distortion. Care to explain why you'd need that?
  10. When you're smoothing out your UV, you're basically diminishing the compression (blue in 3DCoat) and stretching (red in 3DCoat) of the polygons in the UV space. In the other hand, it's generally advisable to have the least possible amount of islands in your UV to minimize seam problems related to edge padding (black edges show up when enabling LoD in real-time and game engines) and normal maps, since in render time - real-time or not - it's almost impossible for the renderer to keep the simulated normal continuity across discontinuous islands. I'm putting that on light terms since these problems would require a much more thorough explanation, but for the point in discussion suffices to say that it's wise to have the least possible amount of seams and "hide" them (ie. keep them out of the intended or most common viewing ranges) as well as you can. It's also worth mentioning that PTex is supposed to correct all these problems, the problem being that almost no current real-time engine supports it, but if you're working for TV/movie production it's definitely a superior and no-frills option. Back to UV-land. The problem with reducing the amount of islands is that you induce sensibly more stretching and compression issues. To fix them gets exponentially harder since you employ less "decompression cuts" when defining the islands. All that's to say that you have to manually move the UV island edges away from its current contour to open room for the inner polygons to expand (ie. de-compress). Not having the ability to do that algorithmically (yet localized by the brush radius) forces you to do lots of tedious vertex pulling. Hope the explanation didn't get too confusing. I wish I had the time to grab a couple screenshots to better illustrate it - which, curiously, would probably be faster than typing all this lol
  11. Glad that you got my point, Geo. Anyone that has ever used UVlayout knows exactly what I was talking about, and considering how 3DCoat exceeds UVLayout in most aspects (usability, stress feedback, relaxing, etc) it's AWESOME that Andrew has just - as in 5-minutes ago, according to his twitter - added this feature to its suite Go Andrew go!!
  12. Hey guys, is it just me or do you still feel the need to use UVLayout just because it can smooth out the edges of the UV islands? In 3DCoat's UV room you can use the brush tool + SHIFT key to smooth out the tension of the UVs, but only inside the island or selection itself. You can never smooth out the island edges algorithmically, only manually, which is tedious and a serious bummer. Or am I missing something?
  13. +1! Only reason why I still use Topogun for the retopo of thin areas.
  14. Where to put lines in such non-organic models? Probably nowhere. Those are static models, you'll hardly have the need to deform them, so "1-click" auto-retopo should work just fine. A bit hit-and-miss in a couple corners (specially when smooth and rigid corners are mixed in the same model) as some screenshots have show, but in practice they'll be a) very easy to manually clean-up afterwards or can be simply ignored anyways since you'll probably use a normal map in your end application to reproduce the hard and soft angles anyways, as long as the major silhouette features are preserved. Guides are only all-mighty important when we're talking about models for organic/character animation. Then things get tricky because you'll generally need the best possible edge-bracketing by the placement of poles. Poles are vertexes connected to three edges (also called Y- or N-poles), five edges (aka star-poles or E-poles) or more-than-five edges, also called extraordinary poles, although it's worth mentioning that this last type is generally to be avoided 'coz it tends to ruin the UV smoothing process. Proper Placement and connection of poles, or "bracketing", is absolutely critical for good deformations in low poly models. In the modern auto-remeshing algorithms proposed (most noticeably Bommes and Huang), the Y-poles are shown as blue dots and the star-poles as red dots. In my opinion the more control we have on the placement of those poles, the best. From the screenshots - I haven't still tested it first-hand - the crossing of guidelines are prime candidates for the generation of poles, but the lack of snapping and any visual feedback on if the generated poles will be the Y or star types hampers the user ability to fine-tune the edge flow. One possible way to improve the situation is, after a first "preview retopo", shown in the retopo room, to highlight those poles in blue and red and enable the user to re-snap them to other edge loop crossings as needed, before generating the final mesh output. This could be hard to implement but would enable outstanding control of edge flow where there's no drastic change in mesh topology and the automatic routine falls back to guesswork to define the placement of poles. For better/more visual reference of what I'm talking about - which might be alien matters for whoever just make "casual" topology work - please check the following links and it should all be clear: To sum things up, re-topology is only really needed for low-poly related work, which include base models that will be animated (to make the process speedy and practical, since high-poly animation is still a technical nightmare) or models targeted for real-time applications like games and simulations. For static models, normal maps will make up for 99% of any weird edge flow in the recreated topology. For animated organic models, edge flow is much more important but the density is not all that important - it can be added/removed in record times with very basic modeling operations - as long as the Y and star poles are placed appropriately.
  15. LOL nice one, best joke of the day BTW, the guidelines idea is *genious*, I still remember suggesting to Andrew almost a year ago that we should have some "magnets" to define Y-topology (3-edges) and star-topology (5 edges) vertices, since these are the ones most important to define edge flow. That'd already be great, but he made it even easier! Instead of setting 4 y-edged magnets to define a bracket loop for an appendage, all you need now is one traversal line circling the shape. ONE LINE! OMG, I'm flabbergasted The only bad part of all this godliness is that I can't hold myself in anxiety to put my hands on it..