Heath_3d

Hi Andrew, I'd like to request to have a "color by depth contribution" option added to the "pressure dependant by" rollout or to the color options. This would be really useful when "additive painting" is turned off in the depth options. As an extension to this, a blend mode of "color by depth contribution" would be a useful addition as well. I feel this would really benefit a lot of people using 3d-coat for texture painting. Thanks, -Heath

Hi Andrew, I've just had a look at the colored spec blend mode and find it mostly great. One problem though is that when using cube mapping(the environment shade option in the view menu) the reflections get tinted a completely different color to what is expected. Metal effects such as gold,brass and copper are especially reliant on colored spec and cube mapping used in conjunction with each other. Otherwise, I actually really like the way the blend mode system works, as it makes it very easy to check subtleties by switching back and forth between colored spec and standard blend modes.

This would be fantastic, a major issue a lot of game artists have with 3d-coat is it's lack of colour spec maps support.

I suggested this a while ago but maybe it flew under the radar(or maybe there's a good reason why it hasn't been implemented ) But the voxel shader library is the only library that seems to not have the drop down "options menu" in the top right corner. Materials, masks, brushes, strips models and splines all have this handy feature but shaders don't. I'd really like to be able to organise my custom shaders into folders like Woods, Stones, Dirts etc. rather than have 150 shaders that i have to scroll all the way through to find the one I'm looking for. Thanks, -Heath

Hi Herve_bis, So the problem here is that you're wanting something not possible in your described workflow. With current VD tech, you simply can't take two arbitrary meshes and turn one into another. As mentioned by Ghib, VD does most definitely require a subdivision workflow(such as mudbox or Zbrush). This is because VDM do not bake from a delta like a normal displacement map, but use the displacement tesselation at render time to determine the final location of the subdivided polygon. It does it this way because when you subdivide a mesh for sculpting, the Uv's are subdivided as well. So the new position of the sculpted polygon can be represented as an RGB value showing it's offset to it's original position. To have a VDM work the way you'd like, would require a lot more calculation with a lot more room for various errors. The Bake would have to take into account edge connectivity, somehow determine what parts of the source and target mesh were "meant" to be representing the same part of the object(so you'd be talking about some sort of difference threshold just for an initial pass) and then you'd have to have something in place for when crazy artists want to put a hole in the sculpt when there are none on the low poly model(one of 3dcoats main benefits is the ability to put holes when and where you'd like). If it's the sculpting tools in 3ds you prefer and that's why you're not using Mudbox, a method that might work is to subdivide your low poly mesh in the topo room over your sculpt(with snapping)a bunch of times(until you get the detail you want), export the new hires retop as an obj. Import the original model as a base layer in Mudbox, subdivide up to the same level you were in in 3dcoat and import the highpoly retop obj as a new layer.... a hassle but it might work. Hope this clarifies a few things for you. Oh, I think the VDM in 3dc is just for when working on microvertex painting. Good luck!

Wow! Thanks for the reply! I just saw the new videos on Rauls blog(farsthary.wordpress.com/) The progress looks amazing and should really resolve some of 3dcoats current limitations as an end to end solution. Thanks again Raul and thanks Psmith for passing this on.

Hi Farsthary, It's really exciting to see you working on these features for 3dcoat. I have a few questions regarding your work. Are these features slated for 3d Coat V4 or are they intended as part of a point update to V3? What sort of mesh res will we be looking at with these features? Will this toolset allow for micro details and sharpness on par with Zbrush? Is the surface sculpting going to be a lot like sculptris, and would it be worth while familiarising ourselves with that tool in order to hit the ground running when these features are implemented in 3d Coat? To clarify the eventual goal: We'll have the ability to work with high frequency details on a voxel object by switching it to surface mode. We will then be able to return to voxel mode and these high frequency details will remain intact over our low frequency voxel model(similar in a way to a texture on a low poly object). Is this right? Thanks for taking the time to read this, I look forward to your reply. -Heath

Well, I'll be a monkeys uncle. I did a couple more tests and it appears that max/LW export works fine..... Sort of. On most of the work we've done there are many materials on individual objects. In this case I noticed all but one material use normal maps with the color orientations as I described above. The one that doesn't, uses the max standard by the looks of things. I'd say that at some point someones decided to bring blender normals into line with Max and Lightwave but there's some legacy issues/bugs. This would explain why some people have been having problems while others haven't. As a disclaimer, I only tested this on blender 2.49 and 2.54 so am not sure as to the consistency of the issue. Also, I tried splitting an object up so that it's individual faces were different UV shells, but didn't notice any problems occurring with more than 15 UV shells. BTW our workflow here has people working on different object parts and then joining them together in blender. Hope this helps in some way with dev. cheers

@michalis Sorry to open your mouth michalis. In regards to doing tests, it goes without saying. My point is purely based on using these two apps together in a production environment. In regards to this blender bug you mentioned, could you point me to a thread, bug report or any other URL regarding it? It would be genuinely appreciated. In regards to the inverted channel "myth", here's a quote right out of the blender manual. Warranted it's talking about the normal maps generated by blender, but it stands to reason that blender would generate normal maps it could then use. "Blender's normal map baking tool is different from other applications, such as xNormal and Maya. Both of these are widely used in the games industry and are already production proven (meaning the way they bake their normal maps is more commonly used and can be regarded as a standard). To convert a Blender normal map to an xNormal, you need to invert the Red and Green channels." I'm not wanting to start an argument or anything, it's just that my experiences with blender normal maps matches what the manual tells me to expect. That said, I opened your file in blender 2.49b and it seemed to work off the bat, so kudos for finding a method that works for you.

Hi guys, Just saw this thread and saw that people are having a few issues with blender normal maps(inverted relief or visible seams). I haven't tried the applink yet but have extensive experience with using 3dcoat and blender in conjunction with each other. The point I want to make is on the how blender treats normal maps compared to Maya and Max/LW(3dcoats natively supported export options). If you're exporting max/LW style normal maps from 3d coat(changable from the preferences) you will need to invert the red channel of those images in photoshop. If exporting maya normal maps you will need to invert both the green and red channels. I'm not sure if this applink already does this and peoples issues are unrelated. I've been doing this manually for a wide range of models for a while, and acheived perfect results every time. Hope this helps with development.

Thanks Artman, I'll check it out.

Hi, I think it would be great to have the ability to have retop groups be able to ignore/include the varios voxtree layers. At the moment one of the biggest issues I find with the voxel baking is that you get inadvertant baking of elements onto the wrong part of your retop mesh (eg. curtains being baked to the window as well as the curtain retop mesh). being able to exclude one voxel layer(eg the curtains) from a retop group(eg the window pane retop group) during the baking process would eliminate this problem.

Just to clarify, I am getting a normal map on my new low poly object after baking, But it's being driven by my higher poly objects geometry rather than it's normal maps.

Hi, I'm wanting to use the Retopology tools to make some lower LOD meshes from existing meshes I've created useing 3d Coat. I've textured the higher poly meshes and they have normal maps as well. I can load everything up in the paint room with no problems(including the normal maps) and make the new mesh and unwrap it in the retop room with no problems. When I "merge for per pixel painting with normal map" everything works well except the normals from my original objects normal maps get ignored! In short I can only get the color and specular information from my high poly object. Am I missing something? Any help appreciated, -Heath