Zeddicus

I finally managed to get ptex files to work and the solution was pretty simple. The trick was to export my mesh, which had no UV's, out of Max as an OBJ, delete the one in Max, import the one that had just been exported, then load that same OBJ file into 3D Coat. I chose the lowest resolution (the one equal to the total number of polygons my mesh actually has) with all the available options disabled, then painted away until I was content with my overall paint job. Using the Textures menu in the paint room, I exported using the Color to Ptex option (flip ptex quads was enabled), then loaded that ptex file into the material editor in Max (a VRayMtl with VRayPtex in the diffuse slot) which I assigned to my mesh and rendered successfully. I don't see why this wouldn't work with other apps and renderers if they support ptex properly. The key is to not use any meshes exported from 3D Coat, but instead replace the one in your 3D app with the one you exported for painting. What's great about this solution is that it allows me to keep all my smoothing groups, something 3D Coat still loves to destroy. If this doesn't work, then it's likely that your vertex order/numbering is being altered at some point during mesh export/import. If not that, then it's possible your doing something to your mesh that is messing up that order, which ptex relies on to work right. As I've said before, in Max this would be caused any number of mesh altering modifiers. Not sure what the equivalent would be in Maya though. You need to make sure you don't make any changes to your geometry after exporting it for painting. This means being absolutely sure you're done modeling and happy with it before doing any ptex painting.

It's been a while since I checked this thread and thought I'd share my thoughts. My understanding of ptex is pretty limited, so forgive me if I make mistakes. The regular bitmaps 3DC exports (TGA, BMP, PNG, etc) do work with the UV's that get set up when importing a mesh for ptex painting, but this isn't really the same as using a ptex file. Seams can be an issue with straight tiled UV mapping during render. Ptex stores not only the image data and mip maps, but information on the orientation and placement of each image tile. The Vray page calls this adjacency data and it's used for applying filtering so that seams are invisible. The adjacency data is mostly made up of vertex numbers I think, which are used to figure out which edges are shared between each polygon and also so each map can be oriented properly on the polygon it belongs to. Each polygon gets it's own texture map and each texture map can have it's own resolution (divisible by 2). You can change this resolution at any time while painting too. People often confuse ptex with the tiling Zbrush does, but as you can see it's really not the same. So why is ptex nice? You don't have do any UV mapping before painting it (or at least you shouldn't have to anyways). There are sacrifices which come with that of course, such as the ability to work on a texture flattened in 2D like you can with traditional UV mapping (i.e. Photoshop) but I have no doubt someone will come along with a way around that eventually. Mudbox already allows you to transfer your mesh to Photoshop in 3D form with the translation, rotation, and scaling locked, paint on it there, then transfer it back to Mudbox. This is similar to how projection master works in Zbrush (with actually transferring anything to another app of course). I've been playing around with 4.0 BETA 11, 3ds Max 2013, and Vray 2.30.1 lately and have been having problems too. The support for ptex within Vray has gotten quite good and it will properly render the examples on the Ptex website, as well as anything Mudbox exports. It doesn't want to work with the ones 3D Coat exports though, and I've tried everything. I'm beginning to think that the vertex reordering Max does when you apply modifiers like turbosmooth, meshsmooth, and symmetry also happen when you import a mesh. I've never worked with Maya, but seeing as it's also an Autodesk product there is a possibility that it suffers from the same problems as Max. Since ptex relies on an unchanging vertex order to work properly, the only way importing a mesh and smoothing it is ever going to work is if Autodesk fixes these problems. I have high hopes that since Mental Ray now supports ptex, Autodesk with finally do something about these problems when they go to add the interface elements required for importing ptex files into the material editor. I wouldn't hold my breath though seeing as they are notoriously slow to implement new features, even the ones artists want. For now the only thing that works remotely the way it's supposed to is by using the scene transfer option in Mudbox 2013, at least with 3ds Max since that's all I an test. You still can't use any of the commonly used modifiers though which is a downer. The only thing I haven't tried, which is basically an idea I got thanks to Vipera's post in this thread, is to create UV's for my mesh in Max, export it to 3D Coat for ptex painting, then apply the ptex file to the UV'd mesh that is still open in Max (not an exported mesh from 3D Coat after ptex painting). I already know this works with Mudbox so hopefully it will with 3D Coat as well. Edit: The idea I got from Vipera's post didn't work unfortunately. I really don't believe it's 3D Coats fault though, other than it shouldn't alter the UV's that are already on the mesh being imported if their already tiled. One thing I'm uncertain of is whether UV's are needed at all to use ptex. Both 3D Coat and Mudbox will create a set of tiled UV's on any mesh you import, but is this really necessary? I've been assuming it's just an extra step taken by the software so that it can export traditional bitmaps that will work too. Maybe it's a sort of guarantee that if ptex doesn't work, at least you'll still have your paint job. Of course so long as your saving *.mud and *.3b files, that shouldn't ever be a worry as you can always export a bitmap yourself if the ptex file doesn't work in your rendering app. This is especially puzzling if the ptex setup process when importing a mesh into either Mudbox or 3D Coat destroys any UV's it already had. I've never tested to see if that happens. Maybe someone who knows more about it will comment. For now it's all pretty much useless until the various devs of the different apps get it right (100% compatible with no vertex reordering ever).

Is anyone else seeing problems with ptex (missing quads) when using the DX CUDA version? It's most noticeable when importing an obj using a low carcass resolution. The OpenGL CUDA version, on the other hand, seems to work fine.

Good stuff there y carlosa. Different formats allow for higher bit depths too. For example choosing TIF will save a 16-bit greyscale displacement map and EXR will be 32-bit (unless you use the EDU version). One problem I've found with TIF maps is that the in/out you set when creating 8-bit displacement and normal maps doesn't work for 16-bit, which requires some experimenting to find. I'm not sure if it's supposed to do that or if it's a bug. Either way it can be a bit annoying. Another thing I found, insofar as 3ds Max and Vray are concerned, is that multiple UV tiles tend to create seams when rendered (normal & bump maps work fine though). Better to stick to a single UV tile if using displacement maps. I haven't figured out a way around this unfortunately. Just thought I'd toss this out there seeing as this is a pretty common combo (and maybe someone who knows how to avoid seams will comment).

Depends on which one you select as the space bar can open a popup allowing you to enter a numerical value too. In the Mantis entry, Andrew stated it was non-contradictory meaning these two functions still work with the new repositioning feature (which is going to be very useful IMHO). 3D Coat probably detects whether the space key is being tapped or held down and acts accordingly.

Wow that made me facepalm. Why is it always the obvious things we forget about the most often? Thank you for answering my question and going to all the trouble of creating the navigation file for me! I feel so dumb lol. Now I'll go play with your config while I hang my head in shame. Now that would be awesome, plus make a lot of users really happy I think.

Is there a way to change opacity in the paint room by holding down the RMB and dragging up/down? It's strange how doing this changes the depth value when both depth and specularity are disabled. If it's not possible to change opacity this way, perhaps the RMB+drag needs to be more context sensitive, affecting the opacity value when in opacity (aka diffuse) only mode, the specularity value when in specularity only mode, and depth only if depth mode is the only one active. The only problem I see is that two or all three can be enabled at the same time, meaning one would have to take precedence and I'm not at all sure how that should be handled. An option in the preferences maybe? Or perhaps 3DC could look to see what type of layer is active (I like to have separate ones each dedicated to map type). This might mean changing how layers work though and I'm not sure how much work that would be, if Andrew would want to do that, or even if it's a good idea. The reason I bring this up is because I change opacity every few seconds when painting my diffuse layer. I find it useful for slowly building up color while keeping it nice and blended with those nearby. Having to go up to the top of the interface is very annoying. The O and P keys aren't much better because it takes time for the values to change, and like I said I do this often. Basically both ways of changing opacity interrupt the fluidity of my workflow, making it difficult to work quickly and efficiently. I considered putting all this on Mantis, but decided perhaps I should ask here first just in case I'm overlooking something. Your input is most welcome!

Stay in select mode and after selecting the edges, hold down the RMB to drag them.

Assuming you're replying to me, I wasn't suggesting that voting is what we should do. Heavens no. Hiring someone whom specializes in interfacing is by far the better path indeed. What I suggested was just an alternative should hiring not be viable for whatever reason. It stems from earlier comments I remember reading about how difficult it is to reach a consensus regarding UI alterations (unfortunately for some reason I cannot find those specific comments to quote). I wouldn't call the UI in ZBrush terrible per se. It's not a layout artists are familiar with and this can be upsetting for some people, very much so for those among us unwilling to adapt. Despite that fact, it is still a very clean, streamlined UI and one that matches ZB's core purpose fairly well IMHO. The one thing it's definitely not is clunky. Coming from 3ds Max and Photoshop as I did gave me a little bit of grief when I first used it. Mostly it was the necessity of the edit button and lack of a traditional viewport that threw me off initially. Once I got past that, the rest was a breeze. I rarely needed to consult the manual, something which I feel is the mark of a well designed interface. Mudbox is even easier to pick up for obvious reasons. 3D Coat is on the right track so far as general layout goes, it's just the details that need some love for the most part. As others have discussed, naming conventions and descriptions need to be overhauled in order to be clearer (i.e. less confusing) and this begins with looking at commonly used terms people expect to see (AUTOPO being one example already discussed). There is a lot of redundancy as well. Exporting a mesh from the retopo room is one example, which leaves one wondering which they should be using and whether there is a difference between them. In some cases how a feature works in one room sometimes doesn't work/appear the same in another either. I think this more than anything is what leads to feelings of "clunkiness". Doing anything is 3D Coat shouldn't be a matter of repeated trial and error just to achieve whatever it is a user is after, especially when it's something most consider fairly basic such as exporting, generating maps, rendering, etc.

If hiring someone is out of the question, another option could be to set up a voting system for each suggested change to the UI. It would be important to send an e-mail to everyone who has purchased 3D Coat though, to make sure there are enough people voting so that a clear picture emerges of what the majority wants. As incentive to take some time out to vote, those who participate in all the necessary voting sessions could be offered a discount on the v4 upgrade and/or new licenses as well. It all depends on what Andrew wants to do since he naturally has the final say in everything. Democracy may not be the perfect solution, but it at least solves the problem of disagreements over how things should be changed. As to what should be changed... well I'm not really sure how this should be handled.

I understand what they're getting at. Basically the point is that in ones haste to make 3DC less confusing for "noobs", which has so far been the most common justification as to why sweeping changes to the UI should be made as soon as possible, you could end up causing the opposite effect if you're not careful. I'm betting the whole tutorial angle never even occurred to the majority of you. I'll be the first to humbly admit that it never occurred to me lol. The lesson we need to take from this is obvious; it's easy to overlook unintended consequences. We need to be more careful when pushing for changes some of us are absolutely positive they're right about. It's easy to brush off someone simply because they disagree with you and ignore what they have to say, or worse treat them with sarcasm and scorn. We're better than that on this forum, right?

I see what Andrew was thinking, which was obviously Au-topo. I think a lot of folks read it as Auto-po though. The last two letters of Auto and the first two letters of Topo are the same, so AUTOPO is actually a witty combination of the two that forms a new unique name, which is something you want for a proprietary feature meant to draw people to your application. I still like Auto-Topo which is a compromise between Auto-Retopo and Au-Topo... unless you pronounce it Awe-Toe-Toe-Poe instead of Awe-Toe-Taw-Poe. I do see where people from both sides are coming from. There are a lot of typos that need to be fixed as well. I just don't think these all that big of a deal at the moment. Focus on the new features and especially the bugs first, then focus on naming conventions later. Even if renaming is needed, and I'm not saying it isn't, it probably shouldn't be a distraction for Andrew right now. Just out of curiosity, are terms like QRemesher, ShadowBox, MicroMesh, LightBox, and DynaMesh confusing? Imagine you've never encountered them before. Is it at all clear from those names what it is they do or do you have to open the manual and read up on them first? Do you know what a Thigh Master is without ever having seen one before? Why not just call it a spring seeing as that is what it is essentially? Perhaps it's not the name that matters so much as the pop up description for it (which doesn't say automatic retopology anywhere). PS: I don't think viewport mesh is any better than carcass mesh either. Aren't all meshes a viewport mesh technically? There are probably still better terms that could be used. Frame, framework, skeleton, scaffolding (I like that one, it's straightforward), shell, support, cage, outline, reference (already used though), etc. Yes I abused the thesaurus a bit there lol.

It involves adding four letters actually, but I kind of like Autotopo now that you pointed it out.

Retauto? Thanks for all those bug fixes, Andrew. As a developer you are a joy to deal with. You listen to your customers with an open mind and are very quick to act on bug reports. Hopefully 3DC will some day get the recognition and crazy rabid fandom it deserves like ZBrush tends to attract.

Both are included (GL and DX both with and without CUDA). The choice of download has been reduced to whether you want the 32-bit or 64-bit version of 3DC.

http://3d-coat.com/buy-now/ It says upgrading from v3 EDU to v4 EDU costs $30 but there is no link. I've been waiting patiently for my chance to pay this and now that there is only 16 hours left I'm getting more than a bit worried.

Alright I now have v4 installed. Looking forward to playing with the new tools and what not once I get this retopo job done. Is there any way to make 3DC show how many vertices/edges are selected? Like I said before, it will ony tell me how many faces are selected. I want to know with 100% certainty that if I select four vertices and move them, they are absolutely the only ones that will be affected. I often run into trouble where vertices/edges are getting selected/tweaked which shouldn't be and I usually don't know about it until many saves later. They're either in the forground on some part of the mesh that is being clipped by the viewport camera because I'm working zoomed in, or in the background behind where I'm selecting, sometimes even on the far side of the mesh that is facing away from the camera. I try to create new layers whenever I can to get around this, but that isn't always possible. There is also the hide tool, but it was always sluggish in v3 and now in v4 it's fast but completely inaccurate, especially with symmetry on (like shooting a blunderbuss while blind folded lol). It also doesn't work on the retopo mesh. It would also be really nice if it didn't constantly switch to auto every time I press the escape key or CTRL+D or the clear selection button. As it is now, clicking on the canvas is the only way to deselect all without having this happen automatically. Unfortunately this is rarely possible, unless I want to zoom out repeatedly just to do so. If I choose vertex selection mode, that is my choice and I wish it to remain so while I work.

I only recently updated to 3.7.18H (though it actually says F I see) and am wondering if it's worth installing the v4 beta. I'm having a ton of continuously annoying problems in the retopo room and it's driving me nuts. I honestly don't remember having so much difficulty in the previous version (3.7.15 or .16, can't remember exactly). I've taken to incrementally saving after ever little thing I do because it's become so very easy to destroy some part of my mesh I can't see while zoomed in, which I am 90% of the time. So I guess my main question, besides the above, is whether it's ok to install v4 without it overwriting v3. Can the coexist side by side? And does anyone know how to get v3 to show how many edges are selected in edge selection mode, as well as show how many vertices are selected in vertex selection mode? That would go a long way to preventing damage instead of me having to load an older save and redo a bunch of work (again). Right now 3DC v3 will only show how many faces are selected when in face selection mode. PS: Sorry if this is the wrong place to post these questions, but the v3 thread says to come here because it's not supported anymore.

Too true that. The more memory you have, the longer it takes as well. It's still a good tool though so long as you've got the patience, especially if you're testing overclocking stability where you're not just tweaking frequencies but timings as well. Errors due to bad timing choices usually show up in the first pass. It's been my experience that what's written on the label isn't always 100% accurate and incorrect timings can certainly cause the symptoms described. Speaking of overclocking, that's another thing Monkeybrain may want to consider, especially when it comes to newer hardware like he has (e.g. speedstep). Pushing the CPU and motherboard too far is another thing that can cause the symptoms described, which if I've understood correctly involves his PC automatically turning off approximately 3 to 4 seconds after turning it on, as well as occasional freezing and checksum errors during post. My best guess is that it's either a BIOS related setting(s) or faulty hardware to blame. Hopefully it's the former. Seeing as there are only so many possibilities for this specific type of issue, I figured posting as many as I can think of might be helpful. What would be really great is photos of all his BIOS settings, which would go a long way towards narrowing things down for him. The only thing that can be ruled out for sure at this point is the operating system. I'm sure if we all put our heads together, we'll be able to get to the bottom of this problem in no time at all.

I read a comment recently stating that some power supplies have minimum requirements and will turn off within seconds of starting if the load being drawn isn't high enough (or too high for that matter). Since you're getting one beep, an indication of a successful POST, I'd wager the problem is indeed the power supply. You could try adding more components to see if that helps, or alternatively removing all the ones you don't actually need. I'd probably choose a better power supply though, especially if they'll let you swap the Cougar for something else at no cost (I'm quite happy with my Seisonic for what it's worth). Edit: If you think memory might be the problem, try running the program called MemTest86+ for a few cycles. It runs from a CD and some motherboards even have it built in. If you can't get your PC to start at all, you'll have to pull the memory and put it into another PC for testing. Overheating can be another possibility as carlosa points out, or the auto shutoff failsafe temperature setting is set too low in the BIOS. I once had a PC that would have trouble posting when the room temperature was too low which shows it can be something you'd never consider. I translated the Gigabyte forum and noticed you mentioned checksum errors. This means something has changed (settings most likely) or been corrupted since last boot. The checksum for the current boot is different than the checksum that was calculated during the previous boot. A common cause for this is a dying/dead battery on the motherboard, the one that provides power when the computer isn't on, allowing it to keep track of the time for example. Other things can cause checksum errors too, such as a physical problem with the motherboard itself. Heck it could even be a loose screw touching something it shouldn't be. If you're having problems with USB devices and you've already tried various drivers, try changing the configuration of the USB ports instead. For example if you have one port you know works 100% without fail, try connecting your buggy device to that port to see if that helps at all. That way you'll know whether it's the port or the device that's to blame. Another thing to consider about USB 2.0 devices is that they don't always get along with USB 3.0 ports. I only speak English which makes the grammar from the Google translation (and your own posts to an extent) hard to understand. Hopefully I've understood the exact problems you're having and what you've already tried. I apologize if I've misunderstood and hope I'm helping rather than making things worse.

I've just encountered something weird while in the voxel room (3.7.11B x64 DX CUDA). My pick point keeps changing on it's own, sometimes to another part of the mesh but more often than not it ends up out in empty space. It happens primarily when using my SpaceMouse Pro, usually after zooming in close on one section of my mesh, then out again so I can see my whole mesh. I spent quite a lot of time trying to figure out what's causing it, but alas it seems to be completely random. It does happen often though. I did manage to get it to affect ALT+RMB at one point too, again after zooming, and the pick point ended up really far away from my mesh. I can sort of get it to happen if I: 1) Zoom out until the whole mesh fits on the screen. 2) Pick point a corner of the mesh. 3) Zoom in close on that corner and sculpt a bit. 4) Pan/rotate around while zoomed in. 5) Pick point the zoomed part of the mesh. 6) Rotate and sculpt some more. 7) Zoom out until the mesh fits on screen again. Rotate again, and pick point isn't where it's supposed to be. It may take a couple of tries but that is the general idea of what I've been doing to cause it. Restarting 3D Coat didn't help fwiw. I sculpted all day yesterday on this same mesh and never encountered this weirdness at all. Any ideas as to the cause? Edit: I just figured it out. Pick point is selecting the exact point on the screen I click instead of a point on the mesh! Is this a bug?

I know 3ds Max 2012 support vertex colors. Setup is pretty simple too.

I have to say the changes to the brush system aren't very good at all, especially everything having to do with performance. No not good at all...rather they're totally awesome (ha ha, I got you)! I've been enjoying myself all afternoon. Everything is buttery smooth with 3.7.11B DX. Well done once again, Andrew! One quick question; is it possible to assign a hotkey to the "Invert tool action" toggle? If not, could we get a feature to do so? Or perhaps you could add an option we can enable in the preferences menu so that a fast double tap of the CTRL key toggles it on and off. It's really nice to have that toggle for many of the tools and a hotkey would make it even better. That way I won't need to constantly interrupt what I'm doing in order to move my cursor to the upper left repeatedly. I know I can already hold the CTRL key down, but that gets tiring after a while. Especially on my SpaceMouse Pro which is still new and thus has a fair bit of resistance. Thanks!

If you exported from 3D Coat a Ptex enabled mesh (.obj) and texture file (.ptx) they should work fine with 3ds Max 2012 SP1 and Vray 2.20.03 (the only versions I can speak for with 100% certainty). Unfortunately you cannot do any operations on the mesh once imported into Max because this will cause the vertex order to change, something Ptex relies heavily on (due to the fact each polygon gets it's own texture map, placement and orientation data is required). For example the turbosmooth and symmetry modifiers will both cause problems. Mental Ray for 3ds Max 2013 does now support Ptex, but Autodesk has not implemented a GUI for it, nor the code changes that will be required to prevent Max from constantly altering the vertex order. This means Ptex probably won't be useful until 3ds Max 2014 comes out next year... if we're lucky. Try out the test files from the official Ptex website if you want to check whether Vray is working properly or not. I know the bunny one does for sure.

I got into the habit of opening the task manager in Windows 7 prior to running 3D Coat because it's usually impossible to open after something has gone wrong, when 3DC is hogging 100% of my PC's resources. This way I have a slightly better chance of successfully forcing 3DC to close. You can also change it's priority by right clicking on the appropriate process in task manager. There is probably a way to set a program so it always starts up with below normal priority. This is something I used to do on Windows XP for another problematic app, but it was so long ago that I don't remember how. I have no clue about Linux and Apple machines either. I agree with digman, you need to head over to the Mantis page and put in an official request there if there isn't one already (do a search first). There are also a number of areas where 3DC could use warnings. You know, prior to beginning an operation that may bring ones PC to it's knees, begging for mercy lol. I've encountered such a warning on a few occasions, but more often than not there isn't one at all and interrupting was next to impossible just as you've stated. I've actually had to hard reset my PC more than once, causing me to lose work in other apps open at the time (hence why I now pre-open task manager... when I remember to heh). An animated icon might also be useful so we can tell whether 3DC is still working or has frozen (like when it seems stuck at X%).