SketchUp 8 M2 is out!

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 · Macbook Pro 16" (M1) Mac 12.1 Sketchup 22.0.353

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.

thomthom

@voljanko said:

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?

See my notes at the bottom of the OptionsProvider page, a snippet to list out the different options:
Sketchup.active_model.options.keys.each {|key| p key; Sketchup.active_model.options[key].each {|k,v| puts "> #{k} - #{v}"} }

McGyver

It is great that now when you export a model from SU in COLLADA format it retains the texture name... unfortunately that does not apply to colors or renamed colors,apparently.
Why would that not be included? Is it some freaky mojo of the COLLADA format that makes that impossible?
Kinda sucks to still have to rename all the materials that are not jpegs... I know it sounds like a whiney complaint, but if you have like 10 or more different materials that you intend to render as metallics... somehow ID3,ID55,ID278 etc, does not exactly make it easy to figure out which is which.
Well, I still appreciate that I don't have to rename the image based texture anymore.

voljanko

@unknownuser said:

See my notes at the bottom of the OptionsProvider page, a snippet to list out the different options:
Sketchup.active_model.options.keys.each {|key| p key; Sketchup.active_model.options[key].each {|k,v| puts "> #{k} - #{v}"} }

Thanks for this.I still cannot see any notes at the bottom of the RUBY API pages.It is some old language problem.

@unknownuser said:

You should use the named optioned "UnitsOptions" rather than a numeric index to access the Options.

Yes,but it was easy to check the units with numeric index because under 2 in was the american style and over 1 it was the metric style.Now I have to switch-case all the units

thomthom

@voljanko said:

Yes,but it was easy to check the units with numeric index because under 2 in was the american style and over 1 it was the metric style.Now I have to switch-case all the units

You mean the result of Sketchup.active_model.options["UnitsOptions"]["LengthUnit"] ?

That you can still do.
http://forums.sketchucation.com/viewtopic.php?f=180&t=35923&p=316407#p316407

The various data types for model.options["UnitsOptions"]

LengthFormat: 0 = Decimal, 1 = Arcitectural, 2 = Engineering
LengthUnit: 0 = Inches, 1 = Feet, 2 = Millimeters 3 = centimeters, 4 = Meters

Aerilius

@voljanko said:

I still cannot see any notes at the bottom of the RUBY API pages.It is some old language problem.

There are no comments on the international pages (code.google.com/intl/...). The standard page used to redirect non-english users to the international page so nobody could see the comments, but I asked them to turn the redirect off and it seems to work now on this link:
http://code.google.com/apis/sketchup/docs/index.html

thomthom

Yea, the Google pages are really annoying me with the redirects. I had to change my language preferences in my browser to be able to access the comments.

grim

ok this is going to be viewed as a dumb question

how do you know if you have downloaded and installed SU8-M2

there is nothing on the website saying this is M2 and there is nothing in the version record to say M2

Is version 8.0.11752 what you are all raving on about, so far i cannot see anything new or different

have i got the right one?

Gaieus

If you have this, you have the latest M2.

Bob James

I started to have trouble with M2 not working: SU started crashing every time I tried to open it. Before that I was getting instant grey right-click menu items.

So I uninstalled SU completely and reinstalled M2. I also limited the number of active plugins (they are still in the Plugins folder, but not checked as active).

So far, so good

Update:
I spoke too soon: even with a minimum of toolbars active the dreaded "grey-out" has returned. I assume from this that just deactivating plugins does not help. The only thing left is to remove them from the plugins folder. What a mess

TIG

Bob

It's not the number of 'active' extensions or tools, but it's the number of 'loaded plugins' that have made 'commands' - which are then used in menus, context-menus and toolbars - even if these toolbars are not visible ['active'] they still have a command made for them.
There were some 'rogue' scripts that did add multiple commands - which brought the whole issue to light - but these have long been updated [ensure you have all of the latest versions of any of Fredo's tools, which were the main culprits].
Note that many scripts are NOT packaged as 'extensions' - so they will always auto-load from their .rb/.rbs file in the Plugins folder. Extensions work slightly differently from a 'plain' script, as their .rb/.rbs 'loader' file in the Plugins folder auto-runs, but then if that extension is set to be inactive then it does not load the tool's main code [from files inside the tool's subfolder] - so having an extension deactivated means that its 'commands' do not auto-load, until it's activated - when they do.
To have this 'gray-out' you need to have over 1000 commands loading, which is a lot [but it would be good if it could be more!]. I have many scripts loading, but I do 'manage them' to avoid the dreaded gray-out.
The way I do it is you rename the scripts that you don't want to auto-load from the Plugins folder as .rb! or .rbs!. Then only the .rb/.rbs ones auto-load. If you find you've disabled something that another tool needs then simply rename it back! [an example might be that 'progressbar.rb' is needed by several other scripts so it should always be left as its .rb format]. Now... if later on you discover that you do want a tool that is not being auto-loaded then you can type a simple command at the Ruby Console to load it temporarily for that session
load "the_desired_script.rb!"
[or whatever its real name is!]
Changing a file's suffix from .rb to .rb! doesn't affect that file's contents, so its code loads OK [making menus/toolbars etc as normal], irrespective of the file's suffix - it's just that .rb/.rbs files in the Plugins folder 'auto-load'. If you find yourself manually loading a script often then you can rename it back to .rb so that it then auto-loads thereafter...
You'll be surprised how a spring-clean helps, you probably have dozens of scripts loading that are not used one month to the next - this way you can always manually load one for just that session as you need it...

Also please ensure that you don't have rogue copies of files that should be in the Tools folder in your Plugins folder - the SUp install puts the right ones into Tools but older versions and some ill-advised script 'collections' put old files into Plugins and break things subtly - typical files that should NOT be in Plugins are 'extensions.rb' and 'sketchup.rb' - so open both folders and check the relatively few Tools scripts against the Plugins scripts - remove any Plugins 'duplicates'...