Jump to content
3DCoat Forums

debris

Member
  • Posts

    29
  • Joined

  • Last visited

Everything posted by debris

  1. Thanks Andrew, Hmm... it happens on 3 different systems, all x64, one Vista, two Win7, 2 QuadroFX 4600, one QuadroFX 4500. I'm using the x64 version of 3D-Coat 3.5.04A, bug is in both, CUDA and SIMPLE versions.
  2. In this build (3.5.04A) painting with the airbrush tool still is completely bugged. Looks like this:
  3. Hmm... airbrush in PTex mode seems to be completely broken... or is it just me?
  4. OK, crashes are gone now with the latest 3.3.14D re-re-re-re-upload! Thanks Andrew!
  5. Just in case someone didn't notice: 3.3.14 has been re-re-re-re-uploaded (now at 3.3.14D).
  6. Hmm... just uninstalled 3.3.14A, cleaned up everything (all folders containing "3D-Coat" in its name) and re-installed 3.3.14C (why isn't that mentioned in the updates-thread, or at least very well hidden that there are new versions?). Result: it still crashes reliably after the progress bar of the fill tool reaches its end. This is on Win Vista x64. On the very same hardware at home (Win7 x64) it works. Is there a list of directories that 3D-Coat writes to? Maybe I forgot to delete a settings / temp folder?!
  7. Thanks haikalle! I just noticed it only crashes at work... at home everything is fine. Gonna check my installation tomorrow! Cheers
  8. 3D-Coat 3.3.14A (don't know whether that's the first version where it started, but it's the first version I noticed it) crashes as soon as I try to fill a layer in PTex mode with e.g. the "Strips" pattern. The progress bar reaches the right side and then 3D-Coat crashes hard and even forgets all preferences after restarting it afterwards. Is it just me or can someone confirm this?
  9. Thanks Taros, thanks Andrew! The distance "should" be at least 4 pixels, according to the settings in Softimages "PolyPackUV" operator. I will re-check this. How many pixels does it need at least? I don't want to waste precious UV space with black holes Cheers Steffen P.S.: I would rather use a more contiguous UV layout but I'm still on the search for the correct UV smoothing setting in 3D-Coat. While "Smooth but keep edges" works supernice with mental ray's UV smoothing, it seems that none of the 4 settings is the right one for Arnold / Houdini / Renderman (they all share the same UV smoothing AFAIK).
  10. No, my problem is not solved... and I can't change the subject line as I'm not an admin / moderator... Sorry, if my description was unclear or the 2nd posting with the Ptex UVs made it unclear. In Ptex mode everything is fine, in other modes padding bleeds into neighbouring UV islands. EDIT: Hey Taros, could you please change the subject of this post back to "unsolved" or whatever? Or would you recommend me to open a new thread for it?
  11. OK, here a screenshot of the same object in Ptex mode. As you can see the distance between the UV islands is even smaller, BUT the padding is perfectly centered and no seams appear. This is the desired behaviour for the other modes, too.
  12. OK, quick update on this one. The padding NaN problem is fixed, thanks Andrew! Now I have another problem related to padding. I have to use a "1 poly = 1 UV island" UV layout to get undistorted results in Arnold and Houdini (and maybe in every other renderer that uses Renderman compatible UV smoothing... I'm still trying to find the correct UV smoothing option to use handmade UVs directly). So far so good. I just noticed that even in the 3D-Coat viewport I get visible seams after baking a Ptex object to microverts. I found out that the new padding seems to bleed into neighbouring UV islands (see screenshot) where it shouldn't. The UV island are close to each other (roughly 4 pixels of space for a 2048x2048 texture) but don't touch each others. Padding should ideally meet in the middle between two islands, but shouldn't ever bleed into "foreign territory". Cheers & thanks again
  13. Thanks for the info! After doing many tests, I found out that for mental ray subdivision surfaces (at least when rendered from Softimage) "Smooth UVs / Keep Edges" is the option that produces perfect results! I'm still searching for the right option to get perfect seams with Arnold / Mantra (which both use Renderman compatible UV smoothing). Maybe some Renderman user can help me out...
  14. I'd like to work with not-normalized floating point EXRs so I don't have to find out the normalization factor when rendering. No I didn't try that option. I exported the texture using the "Export Model" command.
  15. BTW this is the baked mesh BEFORE exporting and re-importing. Everything looks fine here.
  16. Heya! I spent the whole day fiddling around with Ptex-sculpting (which is NICE!) and then baking to a handmade UV set to finally render in Softimage / Arnold. I always got crashes and/or seams and started to wonder whether I'm just too stupid to find the right settings (e.g. for the UV smoothing etc.). Now after checking again and again in different apps (Mudbox, Softimage, Houdini, ...) I found out that it's not entirely my fault, and here are my findings: - 3D-Coat adds NaNs (not a number / illegal values) inside 32bit EXRs when using padding. At least when setting the mode to "Black is zero, not normalized". This crashes most renderers or at least causes spikes along seams... which leads to bug number 2 - I always get seams along UV borders, no matter what UV smoothing mode I use. I reconfirmed this in all the apps I mentioned above. In the end I tried loading the output OBJ into 3D-Coat itself and import the displacement map and even there are seams. Looks like 3D-Coat somehow messes up UVs while exporting. The strange thing is that UVs in 3D-Coats "Texture UV Editor" still look correct, while they produce results as if the UV island were overlapping the seams a tiny bit. This in combination with the NaNs makes it impossible to get clean displacement maps directly out of 3D-Coat. Thanks in advance, Andrew debris P.S.: This is all 3D-Coat 3.3.12 latest x64SIMP build on Win7 x64
  17. I also just noticed another (?) quirk with the latest wacom drivers, the very latest beta (3.1.17 x64) and Windows 7 x64: If I open a new scene, select the default sphere for per pixel painting and set the texture resolution to the default 1024x1024 everything is fine. But as soon as I up the texture resolution to 4096x4096 or 8192x8192, the pen acts weirdly. For example I can no longer adjust the ambient or primary light in fine steps. The pen then behaves like it was in some sort of "mouse mode" and the values just change in large steps at the slightes pen movement. Setting the texture resolution back to 1024 or 2048 doesn't help then any more. The same happens when you open a new scene for per pixel painting and directly set the texture to something above 2048. Can anyone confirm this behaviour? Should I open another thread for this? Thanks debris
  18. This is becoming more and more awesome every day! How about strengthening the procedural textures (like e.g. fill mode) even more? This is one of my favourite functions in texturing so far. Combining different fractals or building some sort of shader trees like in Darktree would be great and greatly reduce the need for photographic textures. Great stuff!
  19. I don't know since when this is happening, but it's definetely a bug in the current version (x64, DX, Vista64): In UV mode, when you navigate and release the mousebutton you accidentaly mark the edge or edgeloop you are hovering over as a seam, almost all of the time. This makes UV unwrapping a tedious task. EDIT: And another one in UV mode. If you use symmetry and SHIFT-select an edgeloop on the one side, only the single edge on the other side gets marked, while on the side you were working on a whole loop is selected.
×
×
  • Create New...