Dave - It may be a mac version issue as I have noticed the same bug. It's (apparently) intermittent, and it resolves on 'reset workspace'.

However when it appears, none of the normal window behaviour applies: you can't lengthen it with the corner handle, and though you can hide and show details, in either state it still doesn't show the cut-off part of the main entity info window.

Seems related to the overall wonky palette/toolbar behaviour in SU, for which the 'reset' function is a bandage and not a fix.

Thanks for the replies.

Brodie - I did check the Activity Monitor (Mac equivalent of Task Manager) and on opening the file CPU usage hovers between 99.6 and 100.2% (not sure what that means!). The dynamic memory allocation seems to increment real and virtual memory blocks 1 for 1, with the total depending on file size. In the original case it was about 700 MB of each, real and virtual.

When I opened the 4 mb file on it's own after a system restart (to reset memory), it opened in about 20 seconds. When I opened it after the 40 mb file, it took about 3 minutes this time. I hadn't rebooted the system for a while (2-3 days) when the same file took 5 minutes to load, and if there is a memory leak, over time it could end up swapping more with virtual memory, no? (And/or create other problems with memory allocation.)

In both cases however (and apparently when any SU file loads), it brings the system to it's knees with 100% cpu and an 'application not responding' status. This doesn't seem normal to me, regardless of load times. However, it also suggests that more RAM could improve load times, if on load it's swapping back and forth between real and virtual memory. Correct me if I'm mistaken.

ThomThom - no, not a network file location: it's on my boot drive.
There is nothing special about the file - other than it contained a couple of dynamic components. It was two slightly modified SketchData DC cabinets (no applied textures), and as I said it loads in about 20-30 seconds when it's the only file.

Jean - in this case I hadn't created any scenes, as the file was a working sketchpad to modify cabinet components before importing into the larger file.
Though I will try your trick for the larger file: create a bare bones 'opening scene' that I save and close on.

Will experiment some more and see if I can isolate the issue.
Thanks again for the suggestions.

While waiting over 5 minutes for SU to open a 4 MB file (beside an open 40 MB file), I decided to post a question or two:

Is this normal?

Am I alone, or do other people suffer these same delays for loads and saves? This includes component loads from the browser, which can be unusable at times. (I'm aware of the reported memory leak in the mac version)

Is there something I can do to reduce these waits? (I have already changed the default Autosave period)

Will adding more RAM make any difference? (currently 2 GB Mac Mini 2.4 GHz / GeForce 320M)

Would also be curious to know if anyone is working with an SSD on a relatively equivalent machine (e.g. 2.4 GHz MacBook Air), and if so if they find a big difference in load/save times?

I should note that once the files are loaded, SU performs quite well on the Mini.

If anyone has any suggestions, I'm all ears.
Thanks,

Doug

Just wondering if SU viewer is 'lighter' on the processor due to reduced functionality?
Or is SU performance determined solely by model/size complexity - whether in Viewer or full version?

Context is this:
I create my models on a Mac Mini:
| 2.4 GHz Core 2 Duo | Geforce 320M | OSX 10.6.5 | SU8)|
I would like to show them from my old 12" PowerBook:
| 1.33 GHz G4 | GeForce FX Go5200 | 1.25 GB | OSX 10.5.8 | SU 7.1|

Will this work/perform acceptably for navigating large models? (It doesn't using full version of SU 7.1)

Other usage is for clients to download that have varying HW / OS

Thanks,

Doug

Chris, thanks for the explanation.

It is baffling in Round Corner how certain, seemingly complex, edge combinations process in seconds, (or at worst a minute or two), while other - apparently simpler - combinations don't resolve after 30 minutes or more. (it also crashes the program on occasion)

Obviously there is something going on I don't understand, so I don't yet get what the specific differences are in what I'm asking the plug-in to do. Maybe with more experience, it will become clear to me what it can and can't handle, and what can be done in a reasonable processing period (5 minutes or less - timed with a coffee break!), and what might take half the night.

What would be useful is a thermometer style progress indicator (with a remaining processing time countdown), so you can decide whether the time required is worth it for the desired effect. Plus it would negate the confusion of whether an apparently non-responsive program will every return control from the script.

Is there anything like that in the API toolkit, or would it have to be written by the plug-in author?

@wo3dan said:

I don't think this is possible, to have it turned off by default.
SU checks if there is one single face/with clean loop in the selection (to create the component) that is sharing the same 3D space/plane with a larger face. If that is the case, then 'gluing to' is turned on as option at the time of creating the component. You can still turn it off.

I guess I misunderstood the behaviour - what I should have said is that every time I make a component - and I pay attention to the 'glue to' attribute, I turn it off.... i.e. it's my default, not SU's!

@wo3dan said:

No, editing a component in editing context does not give you this "opportunity", not by choice, nor by mistake.
You can change the components property to 'Glue to: .....' by selecting the component in the component browser and by editing its properties right there. Already placed components however will still be unglued.
(This is about native SU tools / Ruby plugins can act different.)

Thanks for the clarification. While SU is simple in metaphor - a 3d sketching tool - there are many aspects to its behaviour that are not simple at all, because of the multiple interaction of states and conditions of tools, entities, structures and their modifying processes.

Unfortunately the existing official documentation is extremely 'thin' is describing the more subtle aspects of SU.
As a new forum member, I really appreciate the assistance of people who have that knowledge and are generous in sharing it.

So thanks to all that replied to my post. Very helpful, and a good antidote to the occasionally unavoidable frustration of working with such a powerful - and not always intuitive - tool.

@chris fullmer said:

Also, most scripts that appear to be "hung" are probably just working. On detailed processes, they can take hours to complete. So don't think that it is not working just because SU is frozen. Chances are it is just processing.

Chris

Is there a way to know if it's hung or just processing?
My assumption has been if there are no 'working' bars showing or progressing in the status bar area, the script is probably hung.

With RC, certain combinations seem to give it trouble: but as Gaieus says, not necessarily the obviously complex ones.
In any attempt that eventually resolves in RC, there is visual progress indication that the script is still 'working'.

The hangs seem pretty obvious, though I suppose I could be misinterpreting a very long process for a hang, on occasion.

OK - I'm feeling a bit foolish!

Just returned to my hung script, and right-clicked... et voila: an 'exit tool' command that kills the script.
It's part of RoundCorners command set apparently.

So to rephrase the question, do all plug-ins have/require an 'exit tool' command?
Is it part of the Ruby API, or something plug-in writers have to add themselves?

I've been using Fredo6 's RoundCorner plug-in.
It's an awesome tool - most of the time.

Every once in a while it hangs SketchUp and the only way out seems to be to force quit SU.
Is there a way just to cancel/kill the script when it hangs?
(hitting esc has no effect)

If not, are there particular known selected edge combinations that can cause RoundCorner to hang?

It's not just RC that I've had problems with... other plug-ins as well.
It's just that I use RC all the time, so I run into much more often.

A way to kill the script process and returning control to SU proper would be seriously useful given the plug-in free-for-all.

Doug

Marcus -

That was the problem - it was glued to the plane, so inference locking (arrow or shift) didn't work on the axis I was trying to move on.
I made the bolt head in this model (I think!), then saved it as a component in the browser.
I don't remember setting the 'glue to' attribute when I made it - by default I always have it unchecked.

In any case, you've solved my problem. I was just adding some more bolt heads and having the same issue,
(which is why I checked back in on this thread). I unglued it and it's all good.

Follow up question: is it possible that a component becomes glued to a plane after it is made (when the 'glue to' was set to 'none' on creation)
through some specific operation - for example I believe that I was editing the component it became glued to when I added that bolt head.
Could that glue it to the plane because entities are 'sticky' when components are in edit mode?

Thanks also to Jeff for the suggestions.
My frustration with the apparent inconsistency of the locking was probably a symptom of the same cause.

Didn't see the upload attachment button right in front of my face.
Here is the file.

Hettich_BlueMax_v3.skp

Jeff -

Thanks for the prompt reply. The help is appreciated.
I'm aware of the shift lock, but find it's behaviour erratic as well.
Again, sometimes it works as advertised and demoed in tutorials...
other times it either refuses to lock -
or locks on the axis, but throws the object in the opposite direction (on the same axis) of where I'm trying to move it to.
In any case, this time I couldn't start the motion on the desired (red) axis, no matter what I did.

My understanding was that the arrow keys allow you to lock direction before you move?
Whereas the shift inference lock requires you to start in the intended direction first, before locking.

I was trying to move the allen bolt head in the attached file. It was buried in the part it now sits on.
I had shifted the face it was located on by 3/16 on the red axis.
I was trying to pull the bolt the same 3/16 on the same axis.
It moved only on the green (primarily) and blue and stayed stuck on the red.
I got so frustrated I deleted it, copied the bolt head from the other side and placed it without incident.

Can't replicate the behaviour now as I saved the new version, but if you have any ideas why it refused to move at all on the red, I'm all ears

It's the variation in behaviour that frustrates me.
Sort of like golf...
when you think you've got everything sussed, then it all falls to hell the next swing!

Also, (probably unrelated) I have an astounding number of freezes and crashes (v8.0 Mac OSX 10.6.5).
Is the windows version more stable?
More predictable in inference? (not that it should be)

I do use xray mode for moves that require it - and in fact tried it on one of the attempts in order to find the handle on the back of the bolt.

Thanks again for the advice,

Doug

P.S. just realized I don't know how to attach a file!

Unbelievable frustration with the move tool.
Arrow key direction locking doesn't seem to work on the Mac.

No matter what scale or perspective I can't move along the axis I need.

I am not a beginner. ( I have been using SU since AtLast still owned it)
I have built some fairly complex models.
I make guidelines and pay attention to the move handles I choose.
I understand 3d space.
And still SketchUp refuses to let me move objects from one point to another.

When I've chosen a specific point on the object I'm moving and I move the cursor exactly to the point I want,
why in hell does SketchUp insist on flinging the object miles away to some random point in space.

The total apparent randomness of this infuriating behaviour just adds to the overall frustration.
Some sessions movement seems predictable, precise, simple and intuitive.
Select, drag click and the object is in perfect position

Other sessions I can't place objects after multiple attempts, varying every known variable in the abortive process.
If someone can suggest what I am missing I would appreciate it.

OK, I think I've figured out what was happening:

I reset the workspace, and it returned to normal - briefly!
It seems there must have been a space in the search box (which I didn't see, of course)
which selected only the objects that had a space in the name.

Still, what is the logic behind white on white text (if that's what it is) or disappearing the text of objects that are within the search criteria?
This is extremely bizarre and unhelpful behaviour. If anyone understands the rationale behind this, I'd love to hear it.

and is there anything that can be done about it?

Think I remember reading elsewhere that the problem is white on white text, but even when an item is highlighted it still doesn't show. This is happening to several objects that aren't locked (red icon, not visible text) at any level.

I can see what is selected through the entity info box, but if I can't read it directly in the inspector it makes it almost useless for quickly identifying and organizing the model.

Other objects that I can select in the model don't show up at all in the inspector.

Is this the deliberate behaviour, (and if so what genius thought it was a good idea!) - or a bug that will be fixed?
... or am I missing something that will resolve the issue?

Doug