Posts made by miggy

@kaas said:

@miggy said:

...
I have a script that manipulates very many (20-30+) Google Earth terrain groups written back in SUv8...

My script copies and explodes lots of groups & components. I do see a positive difference in V16 and opening / closing the outliner doesn't make any real difference.

Maybe your v8 code hasn't been optimized? You do make use of
model.start_operation("name of operation",true)?
the true flag here disables the UI which could make you code run faster. Just a thought.

Thanks so much kaas for getting me to re-examine my scripts.
I have always used start_operation with disable_ui, but I have always believed that disable_ui didn't do anything useful - this because I have view.refresh in most of my loops!
Because the scripts are long-running, they would seem to be dead without view.refresh, especially because, most often, I also get the Windows 'not responding' in the title bar.
So, all said, a basic misunderstanding of view.refresh overriding disable_ui...

To clarify this for myself, I've written a test script and a mini model to test against.
It has really cleared out any doubts or misunderstandings I have had.
If anybody is interested I have attached both script and test model.
Any further clarifications on my comments below are truly welcomed - sorry if any of them seem obvious to others, but these were grey areas for me...

Also, if anybody has found a way to get Ruby/Sketchup to 'talk' to Windows and tell it that "I am busy so please don't lock out my status bar and console", I am very interested.
I have tried using threads as well as Win32 calls to various PeekMessage, GetMessage, etc., but to no avail, so far, ... the only thing that works is UI.messagebox, but that is a useless solution for long running (20-40 minutes) analysis scripts...

The net clarifications, for me, that came out of this script revisit and testing are:

1. The Layers window is never updated whilst a script is running - regardless of start_operation or value of disable_ui.
2. view.refresh overrides disable_ui.
3. view.refresh is required if the model view-port needs to 'move' during processing.
4. disable_ui doesdisable Outliner updates as well - good-bye attempts to automatically close it via script
5. status bar and console are notaffected by disable_ui
6. window 'not responding' doeslock status bar & console, but does not affect view.refresh

---

test_disable_ui.rb

---

test_disable_ui.skp

@juju said:

Sorry to hear about your script and the extra work to get it compliant again.

The change was mentioned in the release notes, for those who care to read it.

If I recall correctly there was an announcement from Google somewhere in the recent past that Google Earth will reach end-of-life soon, they're moving all to Google Maps.

Thus the change actually makes perfect sense in my mind.

I understand the change when a new terrain is loaded - SU wants/needs to distance itself from the Google Earth / Google Maps world.

All of this is fine... and understandable and documented
I read the documentation, but never did I understand that a previously saved file would be changed "under the covers".

I open a skp file in SU2016, created in SU2015, and lo & behold the layer that I had in the SU2015 version no longer exists in the SU2016 version!
Which means SU can blithely change saved object names without warning!

OK, so I fixed my script, but if anybody thinks that an object name change, without warning, when opening an older skp file is acceptable, then I'm worried.
If SU had raised an error saying that my layer name no longer was acceptable or had been changed, then this issue would have been easier to handle...

Not a Google Earth issue, really, just the fundamental concept of a software upgrade changing a user's saved data... that's all folks

Just installed SU2016 after SU2015.
I manipulate terrains from GE.
After quite a while of debugging, I eventually found that SU2016 had quite blithely, with neither a "if you please" nor a "may I?", changed the actual names of my two layers which were named "Google Earth Terrain" and "Google Earth Snapshot" (replacing the text "Google Earth" by "Location").

My script simply fell over.
It did not know anything about this surreptitious, may I say "ILLEGAL", change of attributes of the entities that were previously created in SU2015, contained in a file that I had saved and considered "safe" and complete.

So, rather than complain to the "authorities", I would just like give a "heads-up" to others on this forum who might be interested... (does anybody from Sketchup actually read this forum...?)

I have now added a chunk of code to detect whether I have layers named "Location Terrain" or not and therefore act accordingly... not really a nice wake-up call

As I said - "heads-up" for "Google Earth", sorry, "Location" users...

@topofsteel said:

I have read through several old threads concerning this, but the links to outside sites/scripts were broken. I am going through the process of moving the selection box and grabbing terrain over and over again to get an acceptable resolution. I am looking for a way to automate that process. Possibly with a nested for loop moving the selection box incrementally. I have programming experience but i'm new to Ruby. Are there any similar scripts, starting points or other solutions? Thanks.

to topofsteel:
I have been manipulating GE terrains via Sketchup for many years.
My purpose is to create contour slices, color them and end up with a color-graded contour map.
It works very well - 99% automated, but only once the original terrains are manually imported - and even then, problems can arise if the imported terrains don't overlap correctly.

I have tried to intercept the Sketchup "Add more imagery" menu option.
I have a partial result, which means I can begin to "talk" to the GE map server, but then that communication link fails... obviously, I don't have the correct classes/methods available in my context...

Any thoughts or experiences you (or anybody else) might have on this subject area are more than welcome.

@jql said:

@kaas said:

• you can leave the Outliner open when running ruby scripts. Up to v2015 that could make your ruby go very slow.

It still runs much slower... Where did you find differences? If it's in autohide the problem disappears as outliner... autohides

I agree JQL:
I can confirm that the Outliner (new tab in SU2016) being open is just as horrendously slow as before.
However, this slow-down is (I believe) only really perceived when the script creates and destroys (erases) groups.

I have a script that manipulates very many (20-30+) Google Earth terrain groups written back in SUv8.
Just ran it in SU2016: my major script phase runs in 2 minutes with Outliner closed and I had to abort it (via Windows10) after 20 minutes.
Re-ran it immediately with Outliner closed and it ran in 2 minutes.... as before

Intel i7 @2.2GHz, 6GB RAM, GeForce 550M w/ 1GB onboard + 2GB shared
I really can't understand why I get this fantastic fps when others out-spec my Dell XPS laptop quite considerably.
No shadows: 63.1 fps !!!
w/ shadows: 62.9 fps...?

I didn't have any other applications open (other than FF), just an empty, standard environment.
I noticed a massive slow-down when I then opened up some other apps - Word + Excel + Photoshop - down to 25 fps...
looks like maybe SU couldn't re-allocate some shared memory that was taken away?

I then made a component of the existing cube & then made a 4x4x4 version, so 64 times the existing. (btw, disk space only doubled)
There I got about 9fps.
I then moved the whole 64x block up the blue axis so as to hide the top half of the model out of the FOV.
I then got 18fps...
Looks like SU only calculates the rendering of the visible FOV, which is great...
But, every manipulation in the sketchup window was molasses-slow - menu display, pasting into the ruby console, etc.

Then I rebooted, and try as I might, after some 50 times, I consistently only got around 31 fps on the standard cube...???
I have no complaints about my speed, but I can't understand where that turbo effect came from when I first tried it...

food for thought...?