SketchUp 8 M2 is out!

[thomthom]

@khai said:

anyone know if the "flicks" bug has been fixed?
(where you zoom into a model, rotate round it, and suddenly the view is thrown several miles from the model and can be almost impossible to find the model again. resetting the views etc has little effect)

it was so bad in 8 I went back to 7... but from what I can tell, I maybe the only person it happens to

Do you mean where the camera zoom in big steps if you have the cursor over empty space? It's a big difference in the zoom steps depending on whether the cursor is over geometry when you zoom or not.

[Alan Fraser]

I can't say that I've ever come across the 'flicks' bug (as described) in all my years of using SU. I've occasionally imported 3rd part geometry which has come in very small and is difficult to navigate...especially if it's a long thin shape (easy to overshoot); but that's about the extent of it.

[TIG]

rv1974

You seen to misunderstand.
As more plugins were developed the gray-out issue was reported.
It was a mystery for some time until the cause was stumbled upon - it was noticed that several of Fredo's tools made 'commands' within context-handlers, so this rapidly increased the number of 'commands' used in Sketchup and could overwhelm it - so in effect it then started disabling some earlier 'commands' to make space for the new ones.
Thankfully once it was realized Fredo [and a few others] quickly fixed their code, and we now know of no plugins that have this 'fault'.
However, the gray-out reports continued to increase as new tools became available with additional 'commands' needed to use with their toolbars/context-menus etc.
This adds to the total number of commands Sketchup has to handle and so it can reach the fatal limit.
For some unexplained reason, this number-of-commands is relatively low - perhaps in the hundreds - so if you have lots of plugins auto-loading from the Plugins folder then you can get the gray-out menu items. A good solution would be for Sketchup to handle considerably more commands - x2 or x10 etc... BUT that needs Google to redo parts of their code...

Currently, there are several ways of reducing the number of commands loading and thereby avoid the gray-out issue.
If a tool is an Extension and you are unlikely to use it very often, then you can deactivate it in Preferences and restart, if you need the tool later you can always activate it again...
If the tool simply loads from a .rb/.rbs file in the Plugins folder you can find the file and rename it - so xxx.rb becomes xxx.rb! etc - only .rb and .rbs files will auto-load, so after a restart the "!" versions are ignored [note that any companion scripts in subfolders do not auto-load and so they need not be renamed at all]. Later, you decide you really do need to use a particular tool you can always open the Ruby Console and load it manually, thus load "xxx.rb!" - the code inside a .rb! file is still read OK and then the tool will load, it's active just for that session [unlike an Extension which would have to be disabled again to stop it loading every time].
As an alternative to renaming scripts you could simply move their files to a Disabled_Plugins folder but that is more drastic...
There are many scripts that you probably don't need to be loaded up every single day... do some spring-cleaning and stop getting gray-outs...

[thomthom]

@tig said:

For some unexplained reason, this number-of-commands is relatively low - perhaps in the hundreds

Google sources says it's 1000.

[TIG]

It's probably something like 1024 - following some 'binary logic'.
Which is better than 512... but not as good as 2048 or even 4096 !
Presumably someone somewhere in Google needs to 'allocate more memory' to this ?

[thomthom]

You'd think so, but he seemed quite specific to it being 1000...
http://forums.sketchucation.com/viewtopic.php?f=15&t=27941#p243583

@jhauswirth said:

The problem is Ruby scripts are calling-
UI::Command.new
and not attaching the new command to a menu item.

If you want to verify this run-

for i in 0..1000 do
cmd = UI::Command.new("Tester") { UI.messagebox("Hello World") }
end

I can see Ruby scripts creating new commands on each right mouse click.
Every new command creates a unique command ID in SU and there are only 1000
command IDs available. Normally a command is attached to a menu and when
the menu goes away the IDs are recycled, but since these commands are not
attached to a menu, they don't get recycled.
I'm going to try and figure out how to dump the list of commands (they have
menu item text) so that people can see who's causing the problem.

[TIG]

Well if it is exactly 1000, then they just need to change it to say 2000 or 10000 !!!
This is NOT rocket-science after all...

I am frankly amazed that Google have not fixed this seemingly straightforward issue... BUT instead they have chosen to expend effort on inventing RBZ/installers etc, which as you know, I feel fixes a problem that didn't exist [or if it did exist then it simply replaced it with an alternative problem]... all while the population explosion of installed plugins continues [which is at least theoretically made even easier by RBZ] - which is still wreaking havoc in the context-menus with gray-outs... which should have been fixed!

[halroach]

@jbacus said:

@unknownuser said:

...and I'll update you guys why it was so difficult to use. Has anyone else had any problems with that?

I'd be keen to hear why you prefer the old "Film & Stage" plugin to the new "Advanced Camera Tools" as well. We think the new version works better than the old one, of course

john
.

I just installed M2 and it jogged my memory why Advanced Camera Tools make things really confusing and even harmful in an un-sketchup like way of thinking:

1. creating a camera automatically creates a scene (sounds nice at first) but when you delete that scene the camera is still there. that can be fine, but when I click to look through that camera the scene is created again, why!?. Things have to be more straight forward and simple. If cameras are necessarily linked to creating scenes, deleting the scenes should logically delete the cameras. If they are unlinked, so creating a camera shouldn't automatically create a scene. It must be a straight-forward process! The reason this is annoying is because it is in combination with the next few points...

2. When you select to look through a camera - you enter the camera mode (with the dolly tilt roll etc. movements) - that's fine. When you select a camera scene, it does the same! That can be very problematic when going through different scenes when some aren't cameras... If I select a camera scene(A) and immediately select a regular scene(B) the minute I move my view a bit the camera is moved to the new scene(B) - I now have 2 scenes that are the same, when all I really wanted to do was move between scenes... That creates a LOT of confusion. And since scenes aren't undo-able you're totally screwed if you accidentally worked in a natural way and skimmed through your scenes with page up page down... without right-clicking on 'done' every time you happened to go through a camera scene...

3. When you copy a camera instance it doesn't automatically create a scene, does it!? not until you look through it and then it still refers to the old scene. So I now have two cameras in two different locations referring to the same scene... that's royally screwed!

4. I generally liked to use the cameras to copy scenes from model to model. I'm not sure what kind of scenes will be created now when I move to the new model. In any case with the old film and stage it was very straight forward. Maybe a bit tedious selecting each camera and then creating a scene for it, but at least it was straight forward and it worked every time...
   Try copying 5 different cameras between models and tell me it's not hell... You can always say this plugin wasn't intended for copying cameras... - for me, that's what makes sketchup what it is! Sketchup is all about copying and pasting - it's the only 3D program that does this well - and it's one of the things that make it SUPER!

5. Camera scenes are always created at the end of the list of scenes. When you have 200 and up scenes, and you want to create this camera scene right at the beginning of the list you have to click 200 clicks in the scene manager... On the other hand when you add a regular scene, you are able to add it anywhere by right clicking on the already created scenes. Why should camera scenes be any different!?!?

6. camera volumes adds a ridiculously large selection box around the camera. Once I used to be able to select the 'move tool' and I could easily rotate the camera from the outside... that's impossible now - at least with the move tool.

Fortunately "Advanced Camera Tools" can be disabled in the extensions list under preferences - so I can use the good old film and stage!

Ideas for further development:

1. It would make things simple and straight forward if entering a camera scene didn't automatically put you in "camera mode". then you could browse through different types of scenes without worrying scenes will get confused/erased. have a toggle in the preferences for automatic camera mode!? what ever it is, it has to be well thought out... KISS - keep it simple and stupid!

2. like you can copy and paste cameras between models, it would be nice to copy and paste scenes between models (without adding ruby plugins that still don't do it well or intuitively). click on a scene tab or on a bunch of scene tabs or on the border of a scene tab (something new maybe). press ctrl-C and you've got the scenes copied for pasting in the same model or in another model. Think about it like copying power point presentation pages from file to file. you can always insert a new page in between existing pages by having the mouse on the line in between...

3. camera volumes - It would be nice if you could scale the volume and that would adjust what the camera sees accordingly...

4. You guys need some serious beta testers for things like this... I'm up for hire!

[jbacus]

@tig said:

Well if it is exactly 1000, then they just need to change it to say 2000 or 10000 !!!

This number can't be infinitely large. How many commands are "enough" to meet your needs?

Just so that someone has said it... you guys could also leave fewer extensions activated. It was my hope that by making it easier to install and activate plugins you would find it easier to keep only those you really need for a particular model active in the application.

Hundreds of active plugins put strain on many parts of SketchUp. We can (and will) continue chasing bottlenecks in the code, but you guys can play a role here as well.

john
.

[TIG]

Clearly 1000 is not enough commands for a lot of users, so perhaps it could be nearer 2000 .

Many users are lazy and don't do house-keeping...
The gray-out issue appears on these forums at least once a week, often 'faulty' scripts are blamed, but it's actually been shown to be a limitation of Sketchup itself and therefore just 'too many scripts' !

I agree that if most tools were made as Extensions then switching them on/off via Preferences could help... BUT the Extensions list itself is not entirely helpful in that it does not order them alphanumerically, and you get an annoying warning after you un-tick each one.

I do have a longterm plan to Extension-ize my main tools, but as this is 'unpaid' tehn unless I need to reissue a specific toolset and I have the time then why should I be too bothered, especially if I am pressed for time doing some other 'real work'...

[thomthom]

@tig said:

Clearly 1000 is not enough commands for a lot of users, so perhaps it could be nearer 2000 .

Why not just set it to 10 000 or 100 000 ... if there needs to be a limit at all.

@tig said:

I agree that if most tools were made as Extensions then switching them on/off via Preferences could help... BUT the Extensions list itself is not entirely helpful in that it does not order them alphanumerically, and you get an annoying warning after you un-tick each one.

+1
The Extension list is not very user friendly. Especially them messageboxes.

@tig said:

I do have a longterm plan to Extension-ize my main tools,

Ditto. Will be updating as I go along.

[jpalm32]

dae inport: Unicorn.dae Size 14,000KB- Import 3.5 Minutes; get this explode -Gave up after 8 minutes.
Same file in VUE 9.5 Import 1 Second; Ungroup less (That's less 3 Seconds)
I don't understand!
Import was accurate, which it didn't do prior to update, but who cares.
How can one program be that much better??? VUE has it's problem also but man....

[jbacus]

@jpalm32 said:

dae inport: Unicorn.dae Size 14,000KB- Import 3.5 Minutes; get this explode -Gave up after 8 minutes.
Same file in VUE 9.5 Import 1 Second; Ungroup less (That's less 3 Seconds)
I don't understand!
Import was accurate, which it didn't do prior to update, but who cares.
How can one program be that much better??? VUE has it's problem also but man....

Ungroup in Vue is a different operation than Explode in SketchUp. Exploding this model in SketchUp merges all the geometry. Merging, while quite useful when modifying the model later, is pretty 'expensive' computationally. Vue doesn't merge geometry on explode.

john
.

[jbacus]

@thomthom said:

The Extension list is not very user friendly. Especially them messageboxes.

You'll be happy to find, then, that there is new support in the Ruby API for building your own Extension Manager which improves on all the faults of the default system. I think the updated docs are going up today...

john
.

[Rich O Brien]

@unknownuser said:

new support in the Ruby API for building your own Extension Manager

Can't wait to see what the gurus do with this

[thomthom]

@jbacus said:

@thomthom said:

The Extension list is not very user friendly. Especially them messageboxes.

You'll be happy to find, then, that there is new support in the Ruby API for building your own Extension Manager which improves on all the faults of the default system. I think the updated docs are going up today...

john
.

Ah, thanks. I was wondering when they where coming.

[jpalm32]

@jbacus said:

Ungroup in Vue is a different operation than Explode in SketchUp. Exploding this model in SketchUp merges all the geometry. Merging, while quite useful when modifying the model later, is pretty 'expensive' computationally. Vue doesn't merge geometry on explode.

At what cost? I can still manipulate all elements in VUE.
Don't get me wrong, I like SU, but come on... It also get's pretty expensive waiting!

[dmorong]

I wanted to chime in on the Film and Stage conversation above. I use the plugin all the time and teach it as part of Sketchup classes I teach to film and TV designers here in LA, so I have both perspectives to draw on.

I want to start out by saying I do think it is an improvement over the previous version. My favorite new feature is the ability to tweak the camera parameters with the arrow keys, which I find very useful, and the added new camera types make it more relevant to all the new cameras we run into nowadays. I also think the camera info you see in camera view is a nice addition.

My major point of agreement with Halroach is that it is bad that the act of looking through a camera or at an ACT scene puts you in an edit mode.
I can't begin to count the number of times perfectly good shots have been screwed up because you look at a scene and forget to RIGHT CLICK/ DONE and drag the camera to wherever you are going next. The act of editing a camera after it has been set should be a much more deliberate choice, and in both the camera and scene view (I feel like they are the same in this version) , I would prefer to have to right click in order to edit the camera position and settings.

Having the scene created with the camera does not bother me. I find there are almost always layer visibilities involved in every shot, so having a scene to support that is helpful. I agree you should be able to delete a scene and not have it come back every time you look through that camera.

My biggest issue with the ACT is the camera volumes. They are sometimes useful to check the extent of a wide shot, and the way they adjust to the fov is really impressive, but having them created for every camera just turns the model into a train wreck. We are almost always combining scenes created in the construction of the model with camera shots, and to have all those frustums to clean up in the earlier scenes is a drag. Also we often use parallel projection in our earlier scenes, and the introduction of all that huge visible geometry in those scenes causes foreground clipping that makes it look like the model is lost or ruined, and there are always some students who think they have done something that destroyed their model. I have never seen a project where having the pov volumes on all the cameras yielded useful information. Again I would much rather be able to right click, create pov volume for specific cameras rather than deal with them all.

The other thing about pov lines and volumes is how tenacious they are. I normally deal with them by deleting their layers and contents, but every time you create a new camera ALL the volumes for ALL the cameras come back. Sure you can delete them again, but on a large project it leads to a very whack-a-mole experience.

Cameras without the volumes also make it much easier to manipulate the camera object itself. (as mention by Halroach) It is very useful to be able to place a camera object outside a window or in the doorway to the hall and see what kind of shot you can get. Having the huge invisible volume as part of the camera makes moving and especially aiming the camera object much more difficult.

Image exports from the plugin are very satisfying, maintaining their camera parameters and aspect ratio, but oddly when you put the shots into Layout the aspect ratio is lost. The fov is right, but you need to re-mask them to get the proper aspect ratio. Layout is a great tool for presenting storyboards, so it would be nice if that were not necessary.

In the months before the release of the new Advanced Camera Tools I worked a bit on what I thought would be a desirable next version of the Camera Plugin. I think it would be great to have a camera shot window, like a camera preview, that is similar to the preview window in renderers like Shaderlight, but show you your choice of camera shot while you are working on the model in the sketchup window. This would allow you to finesse your design and placement of elements from any position and see what is happening in your shot. To be able to go outside an interior and adjust the backing placement and see how it looks from the camera shot would be very useful. I am attaching a preliminary interface idea I have from when I started working on this.

David

---

camera package.pdf

[voljanko]

I have noticed some differences with the in the

Sketchup.active_model.options[3]

that I use to extract the setted units information.Any plugins that are using this function can have problems with the SketchUp8 M2 version.
Is there a list of that kind of differences?

[Jim]

@voljanko,

You should use the named optioned "UnitsOptions" rather than a numeric index to access the Options. The order of the returned options appears to vary between computer systems.