I would like one addition to an existing tool:

• The scale tool - currently scales by a factor.

I wish:
- That it can be scaled by absolute distance. It would work thus:

You scale some objects, and to get it accurate, you type into the VCB how much you want to scale by:

• scale by number only (eg. [2.5]) - it scales by factor alone, as happens now.
• scale by number followed by a dimension unit (eg [300mm], [1'], [12"], [0.3m]), it "scales" by the absolute dimension.

That addition would feel quite sketchupy to me. It would save me time by not having to draw a construction line before a scale.

@tt_su said:

Have you tried to "touch" the old definition first by making a small change like entities.add_cpoint(ORIGIN) then trying to load the new?

Yes, I did! And it works. Happy camper.

It's great that you are thinking along the same line as me: Sketchup as a powerful production tool (as opposed to just concept design). However, I am not sure that getting output from Layout is the way forward. I would much rather get my information from the model directly as opposed to have Layout as the intermediary. I would much prefer the idea of a Layout tool (call it layout table) that generates a report dynamically from the model. The key, I think is in creating predefined filters that simplify the report into window schedules, door schedules and the like. You would filter by nested components/groups or by layer name, for example.

It is an important discussion to have. I want sketchup to be a highly productive tool in my architectural work. I am excited about the future, and discussions like these shape it.

@rich o brien said:

Love this. Best reaction I have seen to the atrocities yet.

@jim said:

Which is worse: CPU time or Disk I/O time?

You will need to do your own testing, but here's another possible work-around..

in Windows, save the definition as "nul" (or "\\Device\\Null"), and Mac as "/dev/null/"

These are special files that will not actually write to disk, but just throw away the data. But the definition path will be changed.

It's not exactly what you are asking for, but maybe better than creating double files on disk.

Thank you for your suggestion, Jim. I have made the test as you suggested:

definition = Sketchup.active_model.entities[0].definition

n = 50
Benchmark.bm do |x|
  x.report("save to nul ") { for i in 1..n; definition.save_as("/dev/null"); end }
  x.report("save to desk") { for i in 1..n; definition.save_as("/Volumes/.../Desktop/cubes.skp"); end }
end

                    user     system      total        real
save to /dev/null   7.770000   0.440000   8.210000 (  8.380249)
save to desktop     8.180000   0.630000   8.810000 ( 10.576788)

There is a marginal improvement. I imagine it would be a greater improvement if the save_as path was a network drive, so well worth noting.

Another lesson I learned in the process was understanding how fast the save_as method was. The component in the benchmark above was 3MB when saved. This works out at 0.055 seconds/MB on my Mac Pro (2008).

This contrasts markedly from the Definitions.load method, which guzzles a lot of CPU (it takes 6 times longer):

model = Sketchup.active_model

n = 50
Benchmark.bm do |x|
  x.report("load/save") {
    for i in 1..n
      definition = model.definitions.load("/Volumes/Storage/Users/Tommy/Desktop/Component.skp")
      definition.save_as("/dev/null")
    end
  }
  x.report("save to null ") { for i in 1..n; Sketchup.active_model.entities[0].definition.save_as("/dev/null"); end }
end
               user     system      total        real
load/save      59.010000   2.180000  61.190000 ( 61.211738)
save to null   8.720000   0.440000   9.160000 (  9.310672)

So the way ahead is clear. Save to change the path, then load only once.

@tt_su said:

@tommyk said:

I did NOT think of that! For my purposes, this may do the trick. Thanks!

Beware that users might not like that extensions arbitrary change the settings of the style they have set up.

I think the sensible way of getting around this is setting up a new style with the extension. You would then only implement the style changes if the selected style is the extensions style with Styles.active_style.

@tig said:

How about this alternative...
definition1.name >>> 'A' definition1.name = definitions.unique_name(definition1.name) ### e.g. A#1

Now RE-load the component SKP ['A.skp'] and there is nothing in its way.
Let's assume it's referenced as ' defintion2'.
It should arrive named 'A'.

Unfortunately, the component doesn't arrive named 'A'. definitions.load path returns the existing definition if the path is identical.

I have tried this:

` model = Sketchup.active_model

We have a single component in the model

old_definition = model.entities[0].definition
puts old_definition.path #=> '/HD/Users/User/cylinder.skp'

Rename the component

old_definition.name = model.definitions.unique_name(old_definition.name)

Attempt to reload the component

new_definition = model.definitions.load '/HD/Users/User/cylinder.skp'

if new_definition == old_definition
puts "The definitions are the same! This shouldn't happen, no?" #=> ...but it does
end`

It appears that the problem is not the clash of definition names when a definition is loaded, but the clash of paths between the new and old components. And you just can't change a definition path other than by loading it! Quite an omission in the API methinks.

In the meantime, my only other option is to temporarily rename the skp file from which the component is loaded using File.rename. It's messy, but it should work ok.

BTW - I am on Mac, Sketchup Pro 2015, and I experience this issue. I would be interested if this is the case on other platforms.

@tig said:

Do a save_as on the current-component into a random-number-named SKP file in the user's Temp folder.
It's stored path in the original model's definitions is then changed.
Reload the externally changed component from its 'usual' external fixed-path, now it should overwrite in the model...
Delete the randomly number-named SKP file in the user's Temp folder, using File.delete(full_path)...

I did think of this workaround as a worst case scenario. It troubles me because of the (wasted) CPU time required to write the new file. I have potentially tens of MB of Skp files I need to load at a time. If I have to save an equivalent size of file every time, then, it potentially doubles the amount of CPU time.

Another option is to rename the file to be loaded first, then change it back after the load, although in this case, the path the newly loaded component points to would then be wrong.

We could really do with a new API function I think: ComponentDefinition.path=

Any other suggestions would be welcome!

I have been having issues with DefinitionsList.load. I am trying to reload an external component that has been updated externally via Ruby.

I encounter the following behaviours:

[ruby]model = Sketchup.active_model
# We have a single component in the model
old_definition = model.entities[0].definition
puts old_definition.path #=> '/HD/Users/User/cylinder.skp'
puts model.definitions.count #=> 1

# Note that the definition was saved to '/HD/Users/User/cylinder.skp', and 
# the file was then edited independently

# Attempt to reload the component
new_definition = model.definitions.load '/HD/Users/User/cylinder.skp'

puts old_definition.guid #=> 1736b32a-8dd3-3040-bdfd-62a05e188985
puts new_definition.guid #=> 1736b32a-8dd3-3040-bdfd-62a05e188985
#  The same GUID! The file was NOT loaded, as it has been edited since.

# And a new (renamed) defninition was not added to the definitions list;
puts model.definitions.count #=> 1
if new_definition == old_definition
  puts "The definitions are the same!  This shouldn't happen, no?"
end

# However, loading a new component that does not share a path with another component works;
second_new_definition = model.definitions.load '/HD/Users/User/cube.skp'
puts model.definitions.count #=>2

# Other things I have tried;
# - Renaming the old definition before load - same result;
old_definition.name= "new name"
new_definition = model.definitions.load '/HD/Users/User/cylinder.skp'
puts new_definition.name #=> "new_name"[/ruby]

It seems that Sketchup refuses to reload a component from a path if there is a component with that path in the model already. This is driving me a bit mad.

...Or is it just me? Any suggestions for workarounds?

One wish:
Model.active_path= (Array of groups/instances like in existing method: active_path)

I haven't found a way to change the context (path) elsewhere, at least. I would like it in my case, as I use Ruby to reload a Component Definition. When the user is at the path within a Component that is deleted in the script, when the script executes, it just looks rubbish.

Second wish:
ComponentDefinition.path= (String representing path)
Currently, the only way to affect the definition.path of a ComponentDefinition is to use DefinitionsList.load (which loads a new component completely, and isn't completely reliable)

FYI, I am developing a plugin that does just this - not just xref, but editing one file between several users at the same time. I should have a vision to test in a mon or so. In the meantime, watch this space:
http://sketchucation.com/forums/viewtopic.php?f=323%26amp;t=59961

@tt_su said:

@tommyk said:

Perhaps the Sketchup team would find that the change to the API in this way would be too much of an intrusion to Sketchup's standard tools?

It would be a concern if there was multiple extensions that modified the selection colour of objects. Which extension would get the last say? And how easy would it be for the user to read the selection if the selection color changed?

I've been mulling this question over these last few days, and I think the solution might be to confine Ruby plugins that manipulate the presentation of a model to a specific style. I haven't formulated exactly how this would work yet, but it makes sense to separate the manipulation of geometry from the presentation of geometry in this way. Would involve extending the Style entity API I expect. What is exciting about this approach is that Ruby can get stuck in doing some special things with the presentation of the model. Eg:

• change line thicknesses for different components (useful for presenting depths of items maybe?)
• Color lines by layer (useful for people working with complex models, and want to retain materials on faces)

This approach makes sense for me, although I am well aware how much more I am asking for compared to my original request! Not to mention compatibility with LayOut.

@tt_su said:

Having said that, we've had a couple of requests like this. If you would be able to mock up a real use case, a mock screenshot I can add that to a feature request in our bugtracker.
I personally think it would be nice to have some generic way to draw additional graphic to the screen to display meta data etc. Not just changing selection colour.

I will mull over the question some more, and get back to you. And yes, additional graphic on the screen would be very handy, and would certainly improve my productivity in certain areas.

@eneroth3 said:

Isn't it already possible to just change the highlight color in the rendering options? It could be done from a selection observer and depend on what's currentply selected. Only supports one color at a time though.

I did NOT think of that! For my purposes, this may do the trick. Thanks!

@tt_su said:

@tommyk said:

@adamb said:

Pretty, but whats the use case?

If people wanted to distinguish some component types from others, for example. Or maybe a plugin could show a graphical overview of all the objects in a model to reflect some attribute, or something?

You could do this with a custom Ruby Tool with the current API though. That is unless you want to display the graphical overview all time time.

Yes, with a custom Ruby Tool. I would like to be able to change the highlight colour when the standard selection tool is used, and I believe there is no way to do this. Would you suggest that I script an alternative selection tool to mimic the native tool and add the additional functionality?

Perhaps the Sketchup team would find that the change to the API in this way would be too much of an intrusion to Sketchup's standard tools?

@otb designworks said:

1. I am experiencing lots of peculiarity with respect to consistent scene display. I have my scenes set with skalp sections and everything is perfect for a while, but then, with no warning, a particular scene won’t display a section correctly. Sometimes it won’t show the section, or it will only cut part of the geometry, or it will display nothing.

This sometimes happens to me too. Sometimes, there is a delay before the section appears, at other times, it is showing an older version of the section, and sometimes it doesn't update/show at all. In all cases, I do the following:

1. select the scene tab again
2. if that doesn't work, click on another scene, then click back into the original scene.

The above workarounds have worked for me quite consistently.

As for your other issues, I haven't had them. I might try the following:

for 3:

• are you sure that the scene saves all information about a scene (ie, camera position, shadow settings, fog settings, styles, etc). Check on the Scenes window, and expand it to show the deeper scene settings. Bit of a "duh" suggestion, but I've done it before.

@adamb said:

Pretty, but whats the use case?

If people wanted to distinguish some component types from others, for example. Or maybe a plugin could show a graphical overview of all the objects in a model to reflect some attribute, or something?

I have a plugin I want to create that uses 'external components'. To distinguish these from normal components for the user, having a different highlight colour would really help. More info on my thread: http://sketchucation.com/forums/viewtopic.php?f=323%26amp;t=59961

TeamEdit allows two or more users to edit a Sketchup file at the same time. Changes made to components in the model will be updated for all users when they next save their model. It makes the prospect of working on large models within a team simple and productive.

This is an alpha release, so should not be used in a production environment. And remember to backup your files!

Download here:
http://sketchucation.com/pluginstore?pln=TeamEdit

It is a bit like the XREF feature for AutoCAD, but much easier to use, and more dynamic. The intention for the final version is for it to become THE tool for managing complex models and projects that require the combined resources of a team.

HOW IT WORKS:
Team Edit saves all components in the model into a newly created folder. Team Edit saves and reloads amended components to/from this folder automatically, as they are edited by different users.

So you should use components to organise your model, making sure that each zone which team members work on is a component. Use components rather than groups.
J
The Sketchup file must be located on a network folder or sharing service such as Dropbox so that users can read and write to it.

REQUIREMENTS:

• Install Team Edit on all computers on which you want to edit synchronously
• All computers must have the same version of Sketchup installed
• tested on Mac, should work on PC (feedback appreciated!)
• A shared network folder, or a sharing service such as Dropbox running on all team computers. The Sketchup file to be edited should reside in this folder.

USAGE:

• make sure that the Sketchup file (the "master") is saved in a shared network folder, or a Dropbox folder.
• In the menu bar, Extensions > TeamEdit > Enable TeamEdit. This operation saves all components within the model as a new skp file in a folder with the name "[YourSKPFileName]_Components". This folder will be located in the same location as the master Sketchup file.
• save the model. The Sketchup file is ready for editing, and other users can open the model and start editing synchronously.
• every time you save the model, changes made by other users will be reloaded, and changes made by you will be queued up to be reloaded for other users.
• When opening a component, if the background turns orange, it means another user is currently editing that context. If the background turns red, it means there are changes made to the context that have not been loaded yet. By saving the model, these changes will be loaded automatically.

FEATURES:

• The individual components, which are saved as external skp files, can be opened and edited independently, and Team Edit would still work.
• You can use the native "Component (right click) > save as..." feature to save a component to wherever you want. Team Edit will continue to reload from / save to that new location (if you want it to). This feature may be buggy at the moment, and is a little experimental for this version.

KNOWN ISSUES:

• undo operations do not undo updating of components. This will be rectified in future versions.
• if Sketchup crashes for any reason, some components may falsely tell the user that another user is currently editing in this context.
• for services like Dropbox, it may take time for updated component files to be downloaded to the local Dropbox folder. In this case, TeamEdit will wait until the next save operation before attempting to reloading the component.
• for very large files with lots of nested components, saving the file can take considerably longer than normal. This includes auto save operations. This cannot be rectified as it is by design.
• when editing the master file in the default context (you have not opened any components). Any changes here will not be updated on other users who have the file open. This is because TeamEdit only updates components within a model. To get around this, you can wrap all contents of the master model in a new component, then save.

PLANNED FEATURES:

• Better structure, to allow nested components saved outside of the components folder to act as their own master model.
• Purge deleted and obsolete components from the components folder
• Better handling of situations where files and folders are moved or renamed.
• save component as static components (do not dynamically update).
• reload as TeamEdit component (allows the reloaded skp file to be dynamically updated from another Sketchup file)
• toggle on/off automatic reloading of new components on save.

REQUEST FOR FEEDBACK:
I wrote this plugin as I want to scale up the use of Sketchup in my architectural office. I do not intend to make money from it so long as the work required to maintain it doesn't get too onerous. With that in mind, I ask that if you use it, please give me feedback. I need this tool to be robust for my needs, and need to iron out any bugs. So, please:

• report bugs here
• does it work on PC? (only tested on Mac)
• does it work on Sketchup versions prior to 2014?
• let me know what future features are important to you
• let me know how you want to use Sketchup as part of a team generally

CHANGELOG
0.1.5

• Added sanitization of filenames. Previously, component names with invalid characters (such as backslash and slash) would fail to save.
  0.1.4
• It didn't work on Windows- silly me. Now fixed.
  0.1.3
• Edit style options changed - TeamEdit will now warn the user if edits are being made to a component in whatever style is active. Also added colour edges option.
  0.1.2 a
• Fixed issue with renaming components
  0.1.1 a
• fixed issue with making groups a component
• fixed issue with versioning of unsaved components
  0.1 alpha release
• first release for testing by community. Should not be used in a production environment.

I don't know if this thread is still checked by the Sketchup team, but I have one ruby request:

• be able to set selection colour per entity, including bounding box color.

It would allow different kinds of entities to be shown as such.

1. Animations for dynamic components to be saved per scene. For example, you could have a scene with doors all open, and a scene with all doors closed. Would make moving elements in Sketchup that much more presentable.

@artpen said:

GENERAL IMPROVEMENTS / FEATURES

1. TeamWork / Xref - is essential for any office based work
   I know there is an option to use components, but common it is not really useable for commercial projects with team of 10 people. Or it is not flexible.

+1
This would be a massive feature which would widen the scope for Sketchup. However, I think it could be delivered via a plugin, IF the Sketchup team were to implement a change to relative referencing of files and abandon the absolute reference approach:

• references to external components (via the "save [component] as..." and "reload..." commands) should be RELATIVE to the SKP file, as opposed to absolute references as is currently. If this change were made, a plugin could be made to do what you are thinking. In fact, I may start putting something together today...
• also, in Layout, use relative references. It just works better if you are using things like Dropbox, or indeed any shared folder. Absolute references and working across several workstations is a pain. It is not how most people's project folders are organised.

[EDIT] it turns out TIG has already made a plugin that is very similar to what we are talking about: http://sketchucation.com/forums/viewtopic.php?t=7329

• All of my keyboard shortcuts have been preserved from SU2014! It has been a particularly painless upgrade process this time round.

@bruce watt said:

TommyK; Sorry to hyjak the thread.

No problem! This sounds like a good place for your query.

@marcdurant said:

We still have a list of features that we'd like to add to the tool, so feel free to share any ideas you have after you've had some time to get familiar with LO 2015.
-m

Well, if you insist!

1. Not really a feature request, but cleaning up what is existing. I notice that fundamentally, you add <autotext> into the label string, and LO just replaces that autotext with the relevant information from the model. This is fundamentally sound. It provides you the flexibility to add custom suffixes and prefixes within the label text and string several pieces of information together. There seems to be a limitation on getting attributes from only one nesting level per label - i.e. when you select the <ComponentDefinition> of a toilet, you cannot add information from its parent (Bathroom, for example) within the same label - only other attributes of the toilet.

2. Make the asterisk * that allows you to add further <autotext> bigger or more prominent! I keep missing it! Or better still, replace it with a plus (+) sign. It was not immediately obvious that you could add further attributes by clicking on this tiny button.

3. You can get attributes of geometry, but what about the Scene? Again, it would add that flexibility without complicating things.

4. Model Info. Attributes at the model level are not included. If you are doing a schedule of products, you could have a table with a list of Sketchup components (as downloaded from 3D warehouse, for example). As much of the important information is stored at the model level, this information is not accessible via autolabel. I can imagine making a table with the label arrows being set to invisible (0% opacity). Adding this level of information would add further flexibility without adding complexity, I think.

5. Units - I use millimetres for lengths, square metres for area, cubic metres for volume. The ability to use autolabel to show volumes and areas is great, but I don't show floor areas in square millimetres! Choice of units will be great. Perhaps The Sketchup model info dialog should have options for "Area Units" and "Volume Units".

6. Moving the label pointer to a new object. Now I am getting picky, but I like those moments when I think - "I wonder if it could do that?" and the answer comes back "Yes!". I think when you move the pointer of the autolabel to a new object, it should update with information from the new object. If you are thinking "what nesting level?", then I would say the same level as the original pointed object (if that object has the attribute you originally pointed at). I hope that makes sense. What I can imagine doing is when labelling up a wall build up, I use autolabel to get info from the outer skin of brickwork, copy array down that autolabel, then simply amend the pointer of each copied label to each layer of the wall. It would save me from selecting the information type I want from an object. It would make annotations SO fast.

7. There needs to be a way of resizing the label text box without resizing the label pointer. Actually, this is a bit of a bug, I think, and should be fixed this version....

8. Open it up to developers! I use Skalp, for instance, which creates fantastic graphical sections in LO. When I use autolabel on the section cut faces, though, I can't get the information from the components from which they are cut - just face information. If their section cuts could simply reference the objects they cut through for autolabel to work its magic, Skalp and LO could work much better together. See http://sketchucation.com/forums/viewtopic.php?f=323%26amp;t=58685%26amp;start=60#p543147

All in all, the design of what you have done so far makes the implementation of the above seem quite simple and intuitive from where I am standing. I'm looking forward to using it for a real project.