Charlie_P
-
Posts
66 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by Charlie_P
-
-
Afternoon Peter, Yes a whole lot of nurbs/sweeps. The file as it stands now - after cutting and pasting in place from the old file - is all 3d and around 400 mb. Haven't tried WGR yet, that may well be next. Could it be the hardware? Always possible, certianly. I tried Rember overnight and nothing showed up (see earlier post) but I'll try a ram transplant from another identical but younger computer within the firm and see if that makes any difference (my ram came via Crucial, the transplantable stuff was Apple fitted). Another variable to close down.
I too hope we haven't offended Petri...
Incidentially I can't produce GL rendered viewports under any setting at the moment, same crash occurs. Hmm...
Thanks for all your help, I shall press on; progress is possible even in this reduced state. I've only got a few more views to go and then I'll resort to the more serious surgery (ram swap, clean install, visit the pub)
Cheers
Charlie
-
Hello again Peter. Yes I am aware of the religious nature of None and Dimension, that's partly why I stuck everything in None - it was as near as I could get to a "clean" class, i.e. least chance of corruption and lowest possible number of classes in a file.
The plot thickens somewhat. I'm getting some partial success in that openGL will render under some settings but not others; low & medium OK, textures OK, anti-aliasing - nurbs - high - very high are all no go in any combination. Renderworks is bits of both. Sometimes FQR works, sometimes it's just a complete stall (activity monitor shows no cpu use, VW unresponsive, leave it for an hour - no change); other RW modes have been similar but I haven't comprehensively tried this problem on them (I tend to use GL for a quick look and FQR for output; reasonably swift on a quad core)
My feeling is that there is a glitch in the way VW interacts with GL. Just a feeling as I haven't tied it down fully yet, but it's a memory addressing problem and it may be a 64 bit related; it's probably something to do with my installation, my next step is a clean install of VW. We shall see...
Thanks again
Charlie
-
Short update... It may have been a corrupted class. As I was rebuilding the file I flattened the class structure by putting everything into "None" and it rendered; so far so good but I'm not saying that I'm cured just yet...
Charlie
-
Thanks for the response Peter, the files were all VW drawn - no import; the corrupt object possibility - I tried, for a start, dividing the drawing into a number of chunks, the idea being that if one misfired I could tunnel down through in ever smaller lumps to the roque object. On first division all parts rendered OK. When I put them back together they didn't.
Charles - tried Rember, first time I've met it, looks like a useful tool. Left it running for 6 hours, all OK.
Katie - full shutdown and restart is a daily occurence, I also do logouts a couple of times a day, it really keeps VW up to speed. The disk permissions I hadn't done in a while so when I ran disk utility it found & fixed a load of stuff. Also ran Cocktail to manually clear all caches and run all the cron scripts. And for a start things rendered. Unfortunately five minutes later, they didn't, same error file as before.
Incidentally VW created about a dozen .txt files on the root directory (i.e. filepath is /) with filenames that read like a filepath - /users/username/application support/vectorworks/12/plug-ins/VW_mech/data/... the final part being a selection of VW Mech plugin names. All of these were zero K files. I deleted them during the cleanup exercise and they haven't reappeared.
Peter, I'll try your rebuilding exercise in full as a next step.
Thank you all for your help so far, any further suggestions welcome.
Charlie
-
Sorry to alarm you Petri - my celebrations are strictly alcohol based
-
Afternoon all, hope you are all having a lovely Easter.
I seem to be making a habit of creating unrenderable drawings at the moment; everything looks reacts fine in wireframe but as when I try to render using openGL the program goes through the usual symbols...geometry.. at the top right of the screen but then crashes before render occurs. Looking at the crash logs (I now have a fair selection) they are always EXC_BAD_ACCESS ... KERN_PROTECTION_FAILURE , always thread 0 crashing, always gleAddCommand +53 with a similiar addresses (0x1834b868, 0x18347868, a number of times), the same address occurring under the eip listing for the processor report.
Looking at Apple's website there is a technote ref the crashreporter Technical note TN2123 which seems to point to a memory handling error.
The error output in the application support file (/users/username/library/application support/vectorworks/12/) shows "warning : _74_122 - Handle variable is NIL."
Looking about a bit it looks as though this may be linked to a 64 bit problem, but that's no more than a quess. There is also a suggestion that repairing permissions may help so I'll try that.
Anyone got any other good ideas?
Thanks in advance,
Charlie
-
Afternoon Christiaan.
Yep, it crashes. I can get one circle movement occaisonally, but any more causes VW to abandon ship. I've had constaints crashes in other situations as well, notably angle/distance realted. Bug?
-
<<Were you using the backup folder feature of autosave>> No
<<Did you ever try autosaving with the backup feature set the opposite way?>> Unfortunately not
<<When you were seeing the corruptions was it notifying you at file save time with the "This file is corrupted on disk..." message? Or were these corruptions things you didn't see until file open time?>> Yes, at file save time - although I didn't always get to the dialog "this file hasn't been saved for 15 minutes..." before the standard dialog of doom.
Incidentally no further file loss at all since I've been manually saving instead of autosaving. Certainly hope you've found the problem though (as it sounds like you have).
-
In answer to Christiaan's original question - sometimes, and haven't really noticed any link. (firewire & usb drives)
My file corruption problems have stopped now I have turned autosave off - same as go2greece
I'm also using 12.5.1 65397 like Donald, and yes the problem is definately there
Charlie
-
Good evening Katie,
I'll send it all off of course, although it'll be tomorrow now (22.40 currently in the UK).
As to the path name it'll be -
/users/charles/desktop/slew ring.mcd
for the recently deceased drawing. Other different file names with a similar path have also expired as well as some saved direct to drive, i.e. /filename
I've always used local disk for saving until this problem arose since which I've been using a networked mini as a backup (as outlined above). I've only had problems with the local hard drive but then I've only saved across the network as an escape route after I've been bitten. Donald sounds as though he has more experience of this problem than I have so it may be worth a cross check.
Regards,
Charlie
-
Concur with Larry. FQ RW fairly zips along, a lot of the time faster than open GL...
Just open activity monitor and watch those four bars go all the way up...
Regards
Charlie
-
Today's experiences...
ok - after losing a couple of files yesterday (see above), duplicated all my files on the active project first thing and moved them across the network to the mini (all done from finder, not VW and save as). Had a prospective client later on so the thing had to run. Opened a main file (500 mb) and set up an animation, left it to run. Back later, everything ok but within 5 minutes of sitting down the familiar messages returned. But this time I had the backups so the head was a little clearer; tried to save to local disk, no go (no surprise). Tried to save across the network under a different filename - success! I was then able to save to local disk under the original filename no problem.
But why?
No autocaddery (at all; in fact to "foriegn" program input at all), a few classes - 20 odd, not vast. Saving was to desktop of logged in admin user. I had activity monitor running at the time showing cpu in the floating window and had one core run full bore for a couple of seconds before curtains; sorry can't remember wiich one - rather backs up Donald's rogue process idea though.
I don't think it's file size. I've had a file expire containing a couple of circles only as well as big buggers. I'm experimenting with autosave off, doing it manually instead. I'll let you know. Personally I think it's something to do with the file naming or path hierarchy; a misplacing between VW and OSX as to what should be where. When the autosave timer comes around there must be a checking process as to the state of the field and I think this is what is misfiring. When my kit implodes I don't always get a save dialgog come up, Mostly it justs "file is corrupted" at me and swearing ensues.
The fact that a filename is showing zero K when seconds before it was showing several meg indicates that it's the data that's lost it's connection to it's name rather than the data evaporating.
I seem to have become overly verbose for which I apologise profusely.
Regards
Charlie
-
Yep, me too. 20 mb file reduced to 0, unable to save, same as above. Unfortunately didn't have the safety mirror running. Lost the lot.
For your infomation Katie...
VW 12.5.1(65397)
Mac Pro Quad 3 ghz, 3gb
VW, Safari, Mail, Preview running
Wasn't autosaving to a backup file, wasn't autosaving without OK,no workgroup references, no server, small network (Main Mac and mini)
VW itself didn't crash, just refused to save and ate the source file.
Funny thing is that before 12.5.1 VW was being unusually crashless; now crashes seem to be really quite frequent - had one today whilst using the create polygon from inner boundary tool, something I hadn't had since VW 10. Certainly haven't lost ENTIRE FILES before, ever. Like Donald and Don (see above) I've been knocking around on macs since the Plus. Don't know what you've changed with 12.5.1, but it's a disaster; at least give us a link to set us back to 12.5.0 so we can at least get on.
Regards,
Charlie
-
Good evening everyone.
This may be a Mac related issue (it'd be interesting to hear from multicore PC users) but VW dosen't seem to make full use of the processing power available. Under osx if you run Activity Monitor with a pretty high refresh rate showing processor usage and knock about a suitably large VW file over a number of operations what one sees is one particular core taking the load with the others doing very little; the loading switching between cores every five seconds or so. Quite often one can sit there waiting for an operation to complete with only 25-30% processing power being used - one core flat out, the other three virtually idle. This dosen't seem to happen with other apps - iLife stuff spreads itself out ok for instance.
It is, of course, entirely possible that this is peculiar to my installation. I shall watch for howls of derision.
Cheers
Charlie
-
Yes. not many about in the galleries are there? I have a suspicious feeling that there is but a few of us. Agree with the TC tools comments; how precise are you working and with what sort of elements?
Cheers
Charlie
Unrenderable?
in General Discussion
Posted
Good afternoon islandmon,
only non-standard plugins are Animationworks related (10 of them). I'll try removing them and see how I get on
Thanks for the suggestion Michael, I've been hunting for rogue objects but as the problem is affecting a number of files it wold have to be particularly bad luck. As to the number of objects I'm afraid they're all needed (yes I am using symbols), it's a complex drawing.
Thanks for all suggestions thus far,
Charlie