Helmut S.

This looks exactly like the problem I posted here a while ago: http://www.3d-coat.com/forum/index.php?showtopic=4637 Good for me: you don't use Kubuntu, so the number of affected platforms seems to have increased by one for now ... maybe this makes it easier to nail that bug down, finally. I would still be very glad for a fix as well - in fact I had no further use for 3DC since I reported the problem, because I can't import anything, and just switching the OS is no option at this point ... a very unsatisfying situation.

Don't know if this is useful information, but anyway: before experimenting with alternative OS installs, I tried 3DC on my current installation, using plain X11, no KDE, no window manager. It shows the very same symptoms. My wild guess would be that this, as we seem to use the same driver version, is no driver-related issue, but somehow is related to shared library versions (are kubuntu DSOs exactly the same as the libs bundled with plain ubuntu?). @Sergyi: did you ever consider to build and distribute statically linked binaries for Linux? I know, it's horrible and the opposite of elegance to consider from a SW development point of view, but it may help to workaround all these obscure differences between Linux distro flavours ...

Okay, so I seem to have an almost optimal 3DC SW configuration - it's just the 'k', which does the harm.

Hi Sergyi, thanks a lot for this helpful info & advice. To be honest, I'm a bit afraid of diving into OS install orgies on that machine - I need it up and running, and you know ... "never change a running system". However I might be able to try out ubuntu on my spare/backup system. Is there any (k)ubuntu version you would recommend for running 3DC? Any restriction/minimum requirement concerning the NVidia drivers? @goethefaust: I'm using the one which gets installed by default on Jaunty, if you select to use the "non free drivers". It's version is 180.44. As I read of bad performance issues with NVidia under Karmic, I did not feel like trying the upgrade, and due to bad experiences with overriding the bundled driver in prior ubuntu releases, I did not replace 180.44 with NVidia's more recent one until now. Should I?

Sorry for bringing this up once again, but I'm not quite sure how to proceed now. @Andrew: are you sure this can be a driver problem? As described above, there are several cases where 3DC crashes - not only display problems. Is there some kind of 3DC "compatibility" list on Linux (aka: minimal NVidia driver version ...)?

I already did that a few weeks ago, as I noted that 3DC and the Linux KDE4 GL desktop stuff interfere.

I wish I had this option. I'm using Linux ... no DirectX available here. Just checked the NVidia driver version: it's 180.44 - the one which, by default, installs with Jaunty Jackalope, if you select "non free drivers". Too old, that one?

Hello Andrew, thanks a lot for your offer! If you would like to test using my model, I'll happily send it to you (just drop me a note). However, the issue is not restricted to this special OBJ - it's the other way round for me: I've never been able to import a single one of them properly so far. I just played around and tried a few of the included sample OBJs - if the problem is reproducible for you at all, you should be able to observe it, using any of these. Interestingly, the symptoms vary a bit, depending on the chosen object file. I did the following: 1) launch "3d-coat-64" 2) in the startup wizard/dialog, I select for per-pixel-painting, what I want (either by shortcut icon, or by file dialog) 3) I accept all standard settings offered by the import dialog (good idea of mine?) Then I observe - crash on "Samples/creature.obj" and "Samples/cube.obj" - "Samples/dino4.obj" is loaded, but displayed completely garbled (see image 1 below) - "Samples/sample.obj" gets loaded, but is displayed as a "ghost". The mesh import itself seems to be okay, as the mesh gets displayed in the UV room (see screenshot 2 and 3 below). - "Samples/bracelet.obj" leads to an "out of virtual memory" exception message (which can't really be true, as the model isn't too large, and I've been able to voxel-sculpt in 4x resolution without problems so far) Ah, yes: all of the above models import well into Blender. Here are the screenshots: I hope I was able to be precise enough for you to spot the problem (as I'm a 3DC (and 3D in general) beginner, I'm of course not sure whether there's something I'm doing wrong). Best Regards, Helmut

Up to version 3.1.19, I can't use 3DC's OBJ/LWO import facilities (haven't checked 3.1.20 yet, but as this problem exists at least since 3.1.14 - the first version I tried - and is not mentioned in any release note since then, I assume the recent build still has it). On import, "something" actually gets loaded, but either nothing at all gets displayed (in any room), or a few single planes appear (which have no obvious correlation to the actual model). I run 3DC on (K)Ubuntu Jaunty Jackalope 64bit, Intel C2D 8400, GeForce 9800 green edition. Unfortunately, I currently have no option to compare the Linux build's behaviour to that one on Windows or OSX ... but I assume it's working properly on the latter two, as no one else complains about it. A solution for this would be *much* appreciated - can't use 3DC as I'd like to, if I can't import things. Thanks in advance, Helmut

In 3.1.19, the OBJ/LWO import facilities still do not work (and in the release notes up to 3.1.20 it is mentioned nowhere). This really is a major issue - on Linux, 3DC seems to be unusable for all but Voxel sculpting, as you can't import existing stuff for retopo, per-pixel painting etc. (which I would love to do ...). Is there a chance this will be fixed soon? PS.: a bit late ... but: merry X-mas all!

Thanks a lot for the very quick, helpful replies! While waiting for my posting to appear here, I managed to reset the symmetry planes myself, by moving the model to a newly created layer (which recenters the center of gravity), and resetting the symmetry planes. Rather weird - and I can't exactly recall the order in which I performed these steps - but worked in the end. Fortunately, re-snapping the retopo-mesh worked like a charm after that. Sculpted myself, right away from the sphere. As I stated in the Linux RC thread, I can't import stuff ... was a bit annoying to run into this major bug immediately after I had bought the license, but on the other hand, my plan was to use it as an "authoring" tool, for original sculpting anyway. Worse it would have been, if my retopo plans had failed. Voxel sculpting is really great, but I'd really love it to be able to use the results somewhere outside 3DC.

I can confirm the display bug related to OBJ import. I'm currently using the 3.1.14 64bit binary on (k)ubuntu Jaunty Jackalope, and have tried 3.1.17. Both are not able to display the imported meshes. Hardware is Core2 Duo E8400 / GeForce 9800GT green edition. I've noted another strange behaviour, which I assume is not intended to work that way: transform tool's numeric input fields don't let you input non-integer coordinate values (i.e. any value is truncated). However, non-integer values are displayed, if you move/scale things interactively.

Hello all, new to this community, I have to state at first, that 3DC is a really inspiring piece of software for me (having some software developing background myself, I'm even more impressed, Andrew's coding talent is truly stunning ...)! Nevertheless, I dare burst in with a bunch of (probably stupid) questions ... so here they are: to get used to 3DC, I started voxel sculpting right away. My intention was to use 3DCs unique modelling features together with the retopo tool, export the meshes to blender, and do rigging, clothing, animation experiments there. Now, having finished my first sculpt and started working on retopo, I run into a problem: the sculpt's object coordinate system is slightly off the world coordinate system, which seems to be used by the retopo tools to implement symmetry (in contrast to voxel painting, where symmetry obviously is based on local coordinate space). Now, I just can't figure out how either make retopo work with local coordinates, or switch everything to global coordinates properly (i.e. actually centering the object around global coordinate origin). Whily trying so, I noted that the sculpt's center of gravity lies outside the sculp itself, asymmetrically positioned to it's right ...?!? I just don't get it. Probably it's my fault as a newbie, but I'm not completely sure about it, 'cause I'm using the Linux Release Candidate 3.1.14, which definitely has several flaws (can't open/display sample meshes, numerical input is truncated to integer bounds ...). Here are screenshots I made to illustrate the issue: This one shows the slightly off-sync local Z plane (upper red circle: it's displaced by a minimal amount to the right), and the center of gravity far to the right of sculpt. IMO it should lie, where the physical center of gravity would be located (slightly below the navel). Here I activated symmetry in retopo, resulting in a slightly-to-the-left displaced mirrored mesh. Any hint/help is appreciated. IMO the ideal solution would be to be able to retopo in local object coordinate space. However, for the moment I got stuck. Best Regards, Helmut