The README says in step 3:

Add this repo as a remote so you can pull in updates to your clone.

Is that something you need to do if you use the GitHub Windows client? I'm not quite sure I've grasped what a "remote" is...

Unable to install this Extension.
SketchUp was unable to install the Extension you have chosen for some unknown reason.
Consult your Extension's documentation for additional help.

Mac OSX 10.8.2
SketchUp 8.0.16845
sketchup-stl-1.0.0.rbz

Any pointers for troubleshooting appreciated!

I've written a small utility to keep track of the performance of given methods without having to modify the source code or suffer from big performance penalties.

It's part of my next version of TT_Lib² (2.7) https://bitbucket.org/thomthom/tt-library-2

Note: This does not replace utilities such as Profiler__, which is used to find out where the bottlenecks are. This is when you know exactly what methods you are interested in and want to try out different solutions and keep an eye on the performance.

As an example of usage, I wanted to monitor the performance of some select methods used when Vertex Tools activates as I knew there was some bottlenecks there. I created a Profiler config file like this (which I can then load whenever I want)

require 'TT_Lib2/core.rb'
require 'TT_Lib2/profiler.rb'


profiler = TT::Profiler.new( 'Editor Activation' ) {

  self.report_each_event = true
  self.report_event_start = false

  track( TT_Vertex, :edit_vertex )
  track( TT_Vertex, :array_to_lookup_hash )

  track( TT_Vertex::Editor, :activate )
  track( TT_Vertex::Editor, :build_ui )
  track( TT_Vertex::Editor, :rebuild_cache )
  track( TT_Vertex::Editor, :update_scope )

  #track( TT_Vertex::Selection )
  track( TT_Vertex::Selection, :initialize )
  track( TT_Vertex::Selection, :activate )
  track( TT_Vertex::Selection, :refresh )
  track( TT_Vertex::Selection, :get_model_selection )
  track( TT_Vertex::Selection, :update_soft )

  # This trigger will print a report each time Vertex Tools' Editor activates
  # and ensures that the data is reset.
  attach_trigger( TT_Vertex, :edit_vertex ) { |prof|
    prof.print_report
    prof.reset
  }

  start()
}

This config will output live the time to took for each method as well as outputting an report in the end. (Strictly speaking, since I set up a trigger to output a report and reset data for each run I don't need the live method output.)

The results I get is something like this:

> #904840351 TT_Vertex::Selection.get_model_selection : 0.000000s
> #1206940865 TT_Vertex::Selection.refresh : 0.000000s
> #1764322652 TT_Vertex::Editor.update_scope : 0.000000s
> #839121163 TT_Vertex::Editor.rebuild_cache : 0.010000s
> #1793773315 TT_Vertex::Editor.activate : 0.030000s
> #970921526 TT_Vertex.edit_vertex : 0.110000s


==============================================================
 Profile: Editor Activation (22 November 2012 - 13:28)
--------+----------+------------+----------+------------------
   %%   |          | cumulative | average  | Method
  time  |  calls   |  seconds   | seconds  | Name
--------+----------+------------+----------+------------------
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex::Selection.update_soft
   0.00 |        1 |      0.00  |     0.00 | TT_Vertex::Selection.get_model_selection
   0.00 |        1 |      0.00  |     0.00 | TT_Vertex::Selection.refresh
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex::Selection.initialize
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex::Selection.activate
   0.00 |        1 |      0.00  |     0.00 | TT_Vertex::Editor.update_scope
   6.67 |        1 |      0.01  |     0.01 | TT_Vertex::Editor.rebuild_cache
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex::Editor.build_ui
  20.00 |        1 |      0.03  |     0.03 | TT_Vertex::Editor.activate
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex.array_to_lookup_hash
  73.33 |        1 |      0.11  |     0.11 | TT_Vertex.edit_vertex
--------+----------+------------+----------+------------------
 100.00 |        6 |      0.15  |     0.02 | Total
========+==========+============+==========+==================


> #1188782231 TT_Vertex::Selection.get_model_selection : 0.000000s
> #971581720 TT_Vertex::Selection.refresh : 0.000000s
> #932029851 TT_Vertex::Editor.update_scope : 0.000000s
> #1498329497 TT_Vertex::Editor.rebuild_cache : 0.020000s
> #1313627741 TT_Vertex::Editor.activate : 0.040000s
> #894215532 TT_Vertex.edit_vertex : 0.060000s


==============================================================
 Profile: Editor Activation (22 November 2012 - 13:28)
--------+----------+------------+----------+------------------
   %%   |          | cumulative | average  | Method
  time  |  calls   |  seconds   | seconds  | Name
--------+----------+------------+----------+------------------
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex::Selection.update_soft
   0.00 |        1 |      0.00  |     0.00 | TT_Vertex::Selection.get_model_selection
   0.00 |        1 |      0.00  |     0.00 | TT_Vertex::Selection.refresh
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex::Selection.initialize
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex::Selection.activate
   0.00 |        1 |      0.00  |     0.00 | TT_Vertex::Editor.update_scope
  16.67 |        1 |      0.02  |     0.02 | TT_Vertex::Editor.rebuild_cache
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex::Editor.build_ui
  33.33 |        1 |      0.04  |     0.04 | TT_Vertex::Editor.activate
   0.00 |        0 |      0.00  |     0.00 | TT_Vertex.array_to_lookup_hash
  50.00 |        1 |      0.06  |     0.06 | TT_Vertex.edit_vertex
--------+----------+------------+----------+------------------
 100.00 |        6 |      0.12  |     0.02 | Total
========+==========+============+==========+==================

I'll be setting up some profiler configs that can be used to test the Importer and Exporter. I'm thinking of making an issue for each profile where reports are posted as code is modified so we can track the performance of the plugin.

Discussions around other issues show that we need an API to the importer and exporter. An API will have multiple purposes:

• Import/Export can be unit tested.
• Import/Export can be profiled - checked for performance.
• Can be called externally without the UI

Any thoughts on the design?

Its premature to ask until STL is awesome, but it would be a great addition to be able to choose to output to STL, GCode or S3G directly from SketchUp. This is what would let you print directly to a device from SketchUp without having to jump over to Makerware or Replicatorg.

Here is a starting GCode bit, just for visualization: http://builders.reprap.org/search/label/gcode%20visualization%20tool

Exporter should remember last export settings.

I've begun to work on a WebDialog option window for the Importer.

It tries to mimic the UI of the native OS and suppresses the HTML context menu and selection feature.

I'm trying to make it so it'll be easy to create the same for the Exporter. (Or any other plugin.)

Didn't get around to finish it today. Just an FYI in case someone else where thinking in the same lines.

Feature is build in "feature-options-window" branch of my fork if you want to inspect.
https://github.com/thomthom/sketchup-stl/tree/feature-options-window

This method should return more detailed info in regard to the import process. Right now it's just Success or Failure.

https://www.dropbox.com/sh/gm8sv1vzcrrp0yb/lzLsnLV-82

http://people.sc.fsu.edu/~jburkardt/data/stla/stla.html

I sort of wish there was a per-repo discussion forum. I can't find old comments I wanted to follow-up on. Am I missing something?

We should set up performance profiles so we can monitor performance as we make changes. See #48 for info on setting up profiles.

I didn't know if we (or anyone else) were planning on using the GitHub downloads tab, but effective immediately it is no longer available.

https://github.com/blog/1302-goodbye-uploads

The importer uses the initials of the original author as a module name wrapper to guard against conflicts with other extensions. Wrapping code in namespaces is good practice.

Now that the code has been adopted by SketchUp and open-sourced, the module name should be changed to reflect this. I suggest using Trimble as a top-level module name for this and all SketchUp extensions created during this era. This particular extension should also be wrapped in its own module also. The name STL seems appropiate.

The exporter does not use any top-level module namespace, but should also be wrapped in the same module hierarchy as the importer, i.e.

module Trimble
    module STL
        # extension code here.
    end
end

The exporter is modifying the group and component names as it iterates them. This is a big no-no!

I would suggest an agreement on a Ruby style guide to follow. It doesn't really matter which one, just an agreed upon once to make style decisions clear and easy. Because we are developing on github and it looks reasonable may I suggest https://github.com/styleguide/ruby

Currently, stl import is selected from a menu item that is labeled "STL Importer (*.stl) by Jim Foltz"

While Jim is awesome (and we all know it!), this doesn't match the pattern set by other importers. Probably we should change this to read "STereo Lithography Files (*.stl)"

Need to make sure Jim gets proper credit elsewhere. Maybe in the Options dialog?

Looks like constants and method Importer.get_unit_ratio can be reused in Exporter.self.units_dialog.

Will be be doing this?

http://en.wikipedia.org/wiki/STL_%28file_format%29

There are at least two variations on the binary STL format for adding color information:

Exporter should be moved to: File>Export>3D Model>"Stereolithography Files (*.stl)"

Since it can't go there due to API limitations, we should first move it to: File>Export STL...

Importer should be moved to: file>import>"Stereolithography Files (*.stl)"

Fresh install of Trimble SketchUp 8.0.15157 on OS X 10.8.2.
Preferences -> Extensions -> Install Extension... -> (chose sketchup-stl-1.0.0.rbz)

Result: "Sketchup was unable to install the extension you have chosen for some unknown reason."

The default unit for export is mm (currently hard coded) and the default unit for import is inches. These should match and should probably be mm. The units of the current model is really irrelevant on import because you need to pick the units the STL file was created with.

First of all - I had no idea this was possible. Seem to be an undocumented feature. @scottlininger ?

I noticed this in the exporter:

  IS_MAC = ( Object::RUBY_PLATFORM =~ /darwin/i ? true : false )
  if IS_MAC
    insert_index = 19
  else
    insert_index = 17
  end
  UI.menu("File").add_item("Export STL...", insert_index) {
    dxf_export_mesh_file
  }

Menu.add_item accepts a menu order index! o_O

Works with any menu item:

UI.menu('Plugins').add_item('First Post!', 0) { puts 'w00t!' }

So that is neat. But I do wonder how reliable the hard coded indexes used in this project is. Does it work correctly on all current versions? Is there any constants that might help?

Installing on brand new Windows 8 machine with latest version of Sketchup. Other RBZ's have worked fine, but this one says:
"Unable to install this Extension.

SketchUp was unable to install the Extension you have chosen for some unknown reason.
Consult your Extension's documentation for additional help."

Looking thru the documentation shows answers for Mac users, but I didn't see anything for Windows users?

Thanks,

Marcus

You guys are making code changes & commits without changing the version attribute in the sketchup-stl.rb file.

And BTW, the RBZ archive is still at v1.0.0

Add Issue Labels for:

1. Optimization ( Green )
2. Bad Coding Style ( Yellow )

Below is an example label list from my VisTools repo

Importing some sample STL files and was very confused as I often didn't see where the model ended up. I suggest we do what the DWG importer does and place the imported instance at ORIGIN and zoom the camera to it.

I added a tip on a wiki page for viewing GitHub diffs without the white-space.

https://github.com/SketchUp/sketchup-stl/wiki/Git-And-GitHub-Tips

Just noticed this. When I started SketchUp and imported an STL model without modifying any import options it would not use the options from last session - instead id's use the defaults.

importer.rb:line 11

CommunityExtensions::STL::Importer should be subclass of Sketchup::Importer

Allows inheritance of common functionality, etc.

For instance, the Sketchup::Importer superclass has ALREADY defined status constants, that can be inherited, viz (at the console):
Sketchup::Importer.constants.sort returns:

["ImportCanceled", "ImportFail", "ImportFileNotFound",
 "ImportSuccess", "ImporterNotFound"]

It is generally best practice to use these API defined constants for future API compatibility, rather than defining custom constants that reference discrete integers.

IF you MUST (because you do not like the the fact that the superclass' constants are in module/class identifier style, instead of ALL_CAPS constant style,) then you can do:

      IMPORT_SUCCESS                        = ImportSuccess
      IMPORT_FAILED                         = ImportFail
      IMPORT_CANCELLED                      = ImportCanceled
      IMPORT_FILE_NOT_FOUND                 = ImportFileNotFound
      IMPORT_SKETCHUP_VERSION_NOT_SUPPORTED = 5

... **provided that you sublcass Sketchup::Importer

There is a API question.
What is Sketchup::Importer::ImporterNotFound which equals 3 ??

:)

It's just not good coding practice to use globals. The variables should instead be class variables of the module wrapper for this project. (Or class level instance variable - there's different opinions on what should be used when.)

I haven't been able to figure this one out.

I had a branch I used before named "small-fixes". That branch was committed into upstream and my master branch was then synced with the upstream master.

That left "small-fixes" as a dead-end.

How can I recycle it?

Delete it? (I'm afraid this affects history in some way... ?)

Merge master into it before reusing it?

Thoughts?

When I export using the ASCII option, then import the file back into SketchUp the geometry is flat and skewed. I thought this was working in an earlier version.

Once we've implemented an API for automating import and export, refactored the blocking messageboxes out of the code, #47, we should add some unit tests to this project.

In Sketchup I created a 1 inch cube and exported it to STL format. Then I imported it back in and selected the units to inch in the STL import options. The cube was now 304.8 inches on each side. I know I can scale this down, but I'd rather have it be the right scale.

We should maybe think about compiling a new .rbz installer (and also where to host it in case the repo would increase too much in size).
The one we currently have (1.0.0) still spreads the bug that thomthom fixed in 2889768 and fails for all users who have no up-to-date SketchUp. (Of course letting them update SketchUp is a nice option as well 😀 , but it's not obvious and the error is an unpleasant experience, and we target wider compatibility than just SU8M4+)
(Or is there any major release date in sight?)

Do we really need the Yes / No messagebox?

My pet peev with SketchUp plugins is the use of #typename. Should never be used.

If we want to emulate the other importers, then a new Group is used only if the model is not empty on import. Currently, the is_solid? method needs a Group (or Instance.)

is_solid? needs to also work when the Model is the parent of the imported entities.

The files jf_stl_importer.rb and skp_to_dxf.rb should be renamed to better describe their roles as part of the STL extension.

For example, they could named stl_importer.rb and stl_exporter.rb; although the stl_ prefix may even be unnecessary in the context of the extension.

The importer and exporter should probably use LanguageHandler to load a strings file and all string references should go through the LanguageHandler to facilitate translation.

$stl_strings = LanguageHandler.new('sketchup-stl.strings')

The stl importer uses the registry (Sketchup#write_default) to save program options.

What should the key name be? It seems logical that it mirror the modules used i.e

Sketchup.write_default("CommunityExtensions::STL", "Keys" "Value")

Any thoughts?

Its a great feature that seems essential in cleaning up a newly imported and messy STL file.

There are several scripts out there that already do it so it should be somewhat simple to recreate.
DWG/DXF Import also has a Merge Co-planar option which gives precedent.

The only question is, should it be a checkbox like it is for DWG or is it safe to assume everyone would want to do it?

The exporter does a lot of string handling - in loops that processes each entity. These should be converted to symbols or integer constants so there's not the overhead of string processing for each iteration.

This also needs to be made so that it can load from anywhere.

At the moment I'm copying files around to test my changes and it's just messy.

I personally don't like that the options for selecting units for the export was removed. I think the user should have the option. It should probably default to mm because it is the most common (so I hear) unit used in STL.

Reference file:

https://www.dropbox.com/s/62mizso4bm4pd3g/carcassone_tile_holderV5.stl

When imported it's not a solid. There are a few places where I need to draw new edges on top of a few existing ones to make them merge properly.

There's also a couple of zero length edges.

Is this due to the data in the STL, or is it the importer?

If it's the STL data - is there something we can do to correct it? (Erase zero length edges, force vertex healing?)

So we can be sure we're all looking at the same specification document.