Update to "scenes.rb" example (from the old API blog)

I just had to update this old example because it violated so many best practices.
(And I got tired of waiting for someone else to do it.) What does it do ?

In a Nutshell …

From the file header of the example script:

This code example allows you to have Dynamic Components
that modify themselves based on a Scene Change.

They need to have at the top level the following attributes
scene_change” a boolean value that if true force the DC to react
to scene changes and if false has the DC ignore the scene change
and “scene_trigger” which is the index that is incremented every
time there is a scene change and it is used to change attributes
for the DC.```

Author: Simone Nicolo - 2008 - v 1.0.0


:gift: What’s New in v 2.0.0

scenes_v2.rb (7.5 KB) :point_left: NEW

Scene Change Test Model (3DW) :point_left:

Updated: Dan Rathbun - 2015 - v 2.0.0

  • Module wrapped.
  • initialize attaches the observer & records the observer id number.
  • Constants are correctly defined in the class, not global!
  • grep(Sketchup::ComponentInstance) used instead of typename==‘string’.
  • return if’s used to short-circuit and reduce nesting levels.
  • next if’s used to increment loop and reduce nesting levels.
  • menu toggle added at bottom of View menu.
  • pause() & restart() methods added to support toggling.
  • MAX constant for changing scene trigger limit.
  • simplified scene trigger increment code to Range inclusion test.

:


The old example had been posted here since 2008: :flashlight:
Dynamic Components that react to scene (aka page) changes

:mag_right: For comparison, here is the old version (with only the copyright holder changed to Trimble.)

scenes_v1.rb (3.8 KB) :point_left: OLD

On the old blog webpage, the comments were not wrapped correctly, nor were the statements indented. So that was cleaned up as well:


2 Likes

I had a thought after I posted and shut down for the day…

Perhaps we should re-package as a Community extension, and generalize the limits features ?
@tt_su (ping)

When I changed the trigger limit test to use a Range object it “triggered” (pun intended) some ideas:

  • … that it would be more versatile to let the DC authors control the scene_trigger limits by other scene_trigger_min & scene_trigger_max DC attributes. (instead of hard coding them to constants. The constants become fallback values.) ?

  • insert the scene_page_index into a DC attribute [if it exists in the DC dictionary] ?

  • insert the scene_page_name into a DC attribute [if it exists in the DC dictionary] ?

  • LanguageHandler files

1 Like

Forgot to post the new link to the scene change test model on 3DW … (although the old link in the blog will be redirected.) [It has also been added to the first post.]

Scene Change Test Model (3DW) :point_left:

Yea, personally I want to get all these old examples cleaned up and put up on GitHub.
@ChrisFullmer - ping.

I’ve almost gotten v3.0.0 complete … all repackaged as a community extension.

When v3 is done, it’d probably be best if I set up the GitHub repo, and then do the “Transfer Repo ownership” over to the SketchUp community account.


NOTICE - I renamed the extension as “Scene Aware Components
(rather than “Scene Change Components”.)

Need to do the strings files in all the lang sub-directories.

Translation Questions (2):

(1) Is creator “SketchUp Community Developers” ever translated ?

(2) Is copyright “Trimble Navigation Limited” ever translated ?

The current strings file (for only the extension dialog, ie “sadc_dialog.strings”) looks like:

":title"="Scene Aware Components";
":creator"="SketchUp Community Developers";
":copyright"="Trimble Navigation Limited";
":description"= "Allows Dynamic Components to modify themselves when the active Scene Page changes. Dynamic Components need a SCENE_CHANGE Boolean (1 or 0) attribute at the top level, to become scene aware. Also, a SCENE_TRIGGER attribute that contains an index, which will increment through a range, whenever the user changes the active scene page. (Original idea by John Clemens.)";

If I do not need to translate creator or copyright holder then it’ll be simplier.


some ideas:

:arrow_right: All optional attributes, are written only if they exist in the DC dictionary. (The DC author must explicitly choose to use them.)

  • … that it would be more versatile to let the DC authors control the scene_trigger limits by other scene_trigger_min & scene_trigger_max DC attributes. (instead of hard coding them to constants. The constants become fallback values.) ?

:white_check_mark: Done. DC authors can choose to implement either override.

:white_check_mark: (the originals 1..4 fallback defaults are preserved so as to work with the original test model.)


  • insert the scene_page_index into a DC attribute [if it exists in the DC dictionary] ?

:white_check_mark: Done. As scene_index, which is 0 based, as it is in most all collections.

:white_check_mark: Also added scene_number which is 1 based.


  • insert the scene_page_name into a DC attribute [if it exists in the DC dictionary] ?

:white_check_mark: Done. As scene_name.

:black_square_button: Also added scene_label [if it exists in the DC dictionary].

Why? Because the “included in animation” flag is not yet exposed in the API.
The only way to know is to test the label to see if it equals the name surrounded by parenthesis.

:question: Hmmm. thinking,… Maybe I should write that test into the Ruby-side so the DC authors need not do it. And then just write a boolean attribute they can use, like: scene_animated ? Yes I think that is the better route. No sense in writing two near identical values into the DC dictionary. (Just wish there was a fast boolean query method already implemented in the Sketchup::Page class to ask if a page was “included in animation”.)

:white_check_mark: Done. Added scene_animated optional attribute.

:white_check_mark: Removed the writing of scene_label attribute (as unneeded.)

Dan, Thanks for this.
I just found this from a general google search, I was surprised to see wasn’t the only one who thought DC components should be able to do their thing for the show…

I downloaded the model, and version 2.0 and it works.

Sort of.

I quickly found some things that made me scratch my head a bit, Then index seems to get jumbled if you click through the scenes and skip over any - resulting in random results for each scene. Also, when I turned animation on and played the four scenes, I suddenly had a NEW color - White! Material was not getting painted as it played past each scene so the base was just default color. Then (of course) I exported to a mp4 file since that is one of my targets for the demo I’m working on, and I got a smooth transition but NO color changes at all. The scene changes are never detected during export.

Is that version 3.0 you mentioned posted somewhere? grin

Thanks again, Bob

Yes, I saw this before, (and forgot about it.)

I still see it in the latest version 3.0.0. (SU2015.)

Since it does not yet have a GitHub repo, there is no nice place to log and remember bugs, etc.
I started a issue textfile (in my local project folder) for now.

Logged as #1


Confirmed again in v 3.0.0 (SU2015.)

Logged as #2

I’m not sure yet if this is caused by my code, or by an internal bug in the SketchUp engine.


I’ll take your word for it, that it also is present in v 3.0.0 (SU2015.) (Since #2 does not seem to work, it would follow that this is a side-effect result of #2.)

Logged as #3

I’d think, fixing this depends on fixing #2.

I completed it, and posted it for peer and team review at a private place. But it was in the midst of SU2016 pre-release madness, and noone had time to even look at it. Also, I did not know it, but the team was doing an overhaul on the undo operation engine, and the code was written towards satisfying the old operations. I have been waiting for things to settle with regard to this overhaul (which I’d say is likely not entirely complete until next major release, 2017. At least I hope so.)

I cannot publicly release it, as it’s currently inside the CommunityExtensions namespace, and that it is an extension to Trimble’s Dynamic Components extension. (At least not without their OK.)


Thinking a bit more about it. If you (or anyone) were to make a model that leverages these features, and either publish it on 3D Warehouse or your own website, or via direct email,… you’d run into the strong possibility that users would not yet understand how to install SketchUp extensions.

Yes, even now with the ease of Extension Warehouse search, find it, click it, click the “Install” button (and similar with SketchUcation’s PluginStore,) there are still many people who are clueless.

This means likely wasting much of your time, explaining where and how to get the extension, just to have SceneAware DC component features.

Then, the fact that it is reliant upon the DC extension proper to be loaded, added a bunch of safety code and bloated the files.

If these features were to be actually added to the DC extension proper,… a lot of the bloat goes away, and since the DC extension is distributed with SketchUp, there is no need to explain much to newbie SketchUp users.


Another alternative is to repackage under my own toplevel namespace, but still add the functionality to the DC classes via the new Ruby 2.0 refinements feature.

Whoops. OK, looking at the code, I solved this a long time ago. This was the purpose in adding the scene_index (0 based,) and scene_number (1 based) attributes.

I didn’t see it working because I was loading an old version of the test model. I re-edited the DC so that it used “SCENE_NUMBER” instead of “SCENE_TRIGGER” in all the formulae.

SCENE_TRIGGER” just increments between scene_trigger_min and scene_trigger_max (resetting to min if it exceeds the max.)

SCENE_NUMBER” is always the 1 based scene number in the set of scene pages. So using a test model with this attribute (instead of “SCENE_TRIGGER”) in the formulae, always shows the correct sub-component and material color.

@RobertLuster: Update, re:

  • #2 (No “Material” DC Behavior changes for display animation)
    and
  • #3 (No DC Behavior changes at all during animation export.)

… The team got back to me, and stated that basically (as of v16) “by design intent” DC Behavior changes are not purposely meant to fire during either native display animation nor native animation export.

The fact that “Hidden” DC Behavior changes DO occur during native display animation, whilst “Material” changes do not, is a fluke. (I logged a bug for this difference, as they should both act the same, as the display serves as a “preview” for the Export.)

So… I’ll need to include some special display Animation loops (perhaps as a separate extension,) that will honor all DC Behavior changes. (This is not a problem with the current API.)

But export is an challenge. I can export a series of frame images to be stitched together with a external application. But SketchUp’s native export functionality does not yet seem to be exposed to the API.

Is this code still available? I get a 403 Forbidden for AWS download.

Thanks,

Dan

I don’t know why the code 403. @sam ?

I reuploaded the files in the initial post. (Seems the old files on the Amazon servers were purged.)

1 Like

Hey Dan! can you please explain, how do i can change this way, that scene_trigger changes, soit will not go from 1 to 4 and like that, but it will choose number of scene. is it possible in v2.0? or no

I don’t understand your question as it’s a run on sentence.

This thread is going on 6 years old now. I don’t remember all the nitty details as I have not looked at it in years.

v2 is just cleanup of the original (v1) as it was previously posted in the SketchUp API blog.

Version 3 had all the nifty improvements (discussed above.) I offered it to Trimble, but they are just not interested (both then in 2015 and now) in adding any new functionality to Dynamic Components, much less fixing ongoing bugs that have existed for years.

It would not be proper to publicly release v3 as it makes changes to proprietary Trimble extension. So this is basically a dead project! Sorry. (It was a good idea.)

They are now putting whatever time and money is budgeted for parametric components
into the Live Components project.