Model#export weirdness

Developers Ruby API
, , , ,
1

I’m seeing strange behavior in my PrettyPrint plugin when I call model#export to produce a 2D PDF file.

If the amount of data being exported is large (say, 500K edges), this method with either crash SketchUp outright or at least destroy SketchUp’s ability to render the view, resulting in a garbage display or simply a blank window. This happens on Windows only - on Mac everything works fine.

I had no such problem in PrettyPrint 1.0, so I figured some of my new code was at fault. But when I applied Occam’s Razor, I could not find anything in my own code that was causing the trouble - I carved the code down to just the API method itself and still got the crash. It seems that some of my code preceding the method call is somehow causing the crash, even though it’s unrelated to the method itself. Or else something in v1.0 was preventing the crash?

I’ve tried many varieties of the options hash parameters (including empty hash and no hash), but that does not solve the problem. Exporting manually (with the SketchUp UI and using default settings) works just fine.

This behavior happens in both SKP 2017 and 2023 on Windows, and does NOT happen in either version on Mac, So for now PrettyPrint 2.0 is Mac-only. :frowning:

Any thoughts?

2

How about a minimum code snippet and a sample model file to reproduce the issue ?

3

Here you go, Dan:

def test1
  model = Sketchup.active_model
  modeldir = File.dirname(model.path)
  temppath = File.join(modeldir, 'temp.pdf')
  options_hash =  {:line_width => 0.05,
                  :line_width_section => 0.05,
                  :line_weight => 0.5,
                  :show_summary => false}
  status = model.export(temppath, options_hash)
  puts "temppath is #{temppath}, status is #{status}."
end # def
4

Message me where to send the sample file, if you need one, Dan.

5

Using a couple of simple models with SketchUp 2023.1.340 (Windows,) the files are properly written out to the model file’s disk location.

I get no crash.

It perhaps could be that your test model file is corrupted.
What version was it created on?
Is it the newer versionless format or the old SKP format?
Have you run check for errors on it?

You never mentioned whether BugSplat! was trapping the errors.
If so, did you send in the report(s). You should keep track of report numbers so they can be looked up.
Was there a helpful response to any of the reports.

Have you checked the API Issue tracker at GitHub ?

6

It perhaps could be that your test model file is corrupted.
This happens on several different files I’ve tested with. All of these files are very complex, and all say “No problems found” in a Validity Check.

What version was it created on?
I created it in 2017. this error happens in both SKP 2017 and 2023 (and likely in all versions in between).

Is it the newer versionless format or the old SKP format?
The test files are 2017 format, but it also happens with 2023 files.

Have you run check for errors on it?
Yes, no problems found.

Sometimes I get a BugSplat, sometimes I get a Windows “not responding” message, and sometimes SketchUp does not crash, but the display window goes haywire.

Similar to Eneroth3’s experience, the camera is in parallel projection, but it also happens when I use perspective.

The weird thing is, this call works just fine in my v1.0 code, but does NOT work as a standalone code snippet.