@jeff hammond said:

@slbaumgartner said:

Another reason you didn't mention is that an update of SketchUp might legitimately overwrite any part of the /Applications/SketchUp XXXX/SketchUp.app folder.

not might-- it does overwrite it...

Hey guys,

Not to contradict, but to reinforce, here's a little more info. Once upon a time, we had a true "installer" program for Mac. We distributed our software as a file with the "mpkg" extension. Upon double-clicking, such a file is opened by the Mac's built-in "Installer.app" program and then instructions and program files are pulled from the mpkg file and installed. This was really useful when we installed files to other folder locations outside of the app bundles during installation. During an upgrade of an existing installation, that installer followed a certain set of rules for file and folder overwrites according to how Installer.app operated.

Starting with 2013, we abandoned the traditional installer in favor of a "drag and drop DMG". The idea now is that when you download SketchUp from us, we give you a compressed DMG, or disk image, that contains not an installer, but a folder housing the three applications' bundles. Rather than turn the installation work over to "Installer.app", in the new system, we just let the user manually drag the SketchUp 2014 folder from its location on the disk image, to a shortcut representing the "Applications" folder, which Finder simply interprets as a command to copy the folder from one place to the other. This is possible because all of the SketchUp Pro apps are fully self-contained within their bundles now, obviating the need for a more complex installer program.

Whereas the old system relied on Installer.app to do its magic to install the program (according to its idiosyncrasies) , the new system relies only on Finder to copy the data. Therefore, ultimately the specific method by which the files are copied is a function of Finder's implementation and would possibly be implementation-dependent. Meaning, Apple might change the way the copy routine from Finder works in 10.10 and then the way an existing copy of SketchUp gets "updated" might change.

As a result of this somewhat problematic update scheme, and also due to my fear that Finder might interpret your desire to copy a new SketchUp installer "2014 B" to the /Applications folder where SketchUp "2014 A" already exists as an invitation to overwrite old with new and keep anything from the old folder that isn't in the new one, any time anyone asks me how to install a maintenance release of SketchUp on the Mac, my advice is automatically and unequivocally, "drag the old /Applications/SketchUp 2104/" folder to the trash, empty the trash, and then open the new DMG and copy the SketchUp 2014 folder from that location to /Applications.

My instructions may only be followed confidently if you've never messed with the app bundles yourself and aren't at risk of losing anything by performing the delete. So yes, avoiding loss of any custom changes due to reinstall is a great reason to leave the app bundles alone.

Andrew

@john sayers said:

I was looking at a building I'll be working on in Denver in Google Earth and I realised the whole city was in 3D and it wasn't the normal inserts by individuals - looks like someone has written a program that turns the 2D images into 3D. The building facades seem accurate so it must be accessing Street View.

John,

Denver was one of the very first cities we modeled in 3D back in the early days of the Google Earth geo model pipeline (by hand). This also meant that it didn't get to benefit from all of the little things we learned in the first few years after that as the initial all-manual process was soon supplemented by all kinds of other data.

In consideration of Google's desire to map the entire world, reliance on more automatic, algorithmic modeling techniques is the only way to go long-term. That was a definite factor in Google selling SketchUp, and more obviously, in Google retiring the 3D model pipeline last year.

Combinations of satellite, lidar, street view, etc., all contribute to Google's ability to perform algorithmic modeling of large geographic areas in high detail with little to no user intervention.

As a result of Denver being an early "guinea pig" in the geo modeling process, it looked dated much sooner than it otherwise might have, which is I suppose, a great reason for it to have been recently refreshed by Google's new geo modeling robots.

Cool stuff, indeed, but still a ways to go before the quality of individual models will be able to match what was produced by the most passionate and active members of the geo modeling community.

Andrew

@slbaumgartner said:

Another reason you didn't mention is that an update of SketchUp might legitimately overwrite any part of the /Applications/SketchUp XXXX/SketchUp.app folder. Anything a user puts there is at risk of being lost!

That's probably the most obvious reason and I totally omitted it. Good catch!

Andrew

@mwm5053 said:

any particular reason you say not to?

The reason not do do it that way is simply, "that's not the way it was designed to work." Any time you fight against the intent of a program's designers, there's a good chance it'll come back to bite you later, so I think you'd do well to try to fit what you want to do into the provided paradigm, even if it's not what you're used to.

In current versions of Windows and Mac OS, there is a strict partition separating program data from user-modifiable data, and partitioning users from one another. The idea of treating every computer like a multi-user system is nothing new in UNIX, where it's been the case forever, and it's also nothing new on Mac OSX, which is itself based on a variant of UNIX called BSD. It is a much newer topic on Windows, where it's taken a long time to move the OS and user community toward that understanding, but we're there now.

That distinction of user vs. system data is seen clearly in this case.

The .app bundles live inside the /Applications folder, which requires root privileges to modify. This makes perfect sense because when messing around in that folder, you're either installing or upgrading a program that affects all users. Any changes you make there affect every user account on the system, and your permissions must be elevated accordingly.

The user's home directory is the appropriate place to make changes that should not affect any other users. To me, personal customization via changes to plugins, materials, templates, etc., are all examples of items that should go inside a given user's folder and should not pollute the system for other users. On a Mac, the tilde (~) character refers to a given user's home directory. The correct location for custom materials is ~/Library/Application Support/SketchUp 2014/SketchUp/Materials/. If that folder does not already exist, it's because you haven't created any custom materials yet. You may create the folder yourself and put your custom materials in there, or you can try creating a custom material from SketchUp and it will appear there.

I fully recognize that you may be the only user of your computer and you may find it an inconvenience to treat it as if there are other users. Nevertheless, that's the way the operating system was designed to work, so this is really the best practice, even if you are the only user.

One final note about why you shouldn't modify anything inside the .app bundles is that someday, manually modifying the contents of the bundles we provide may actually break SketchUp. When we distribute SketchUp, we digitally sign the bundle to prove that it came from us. The bundle's signature is only valid if its contents remain exactly the same on your machine as they were when we signed them. Although it doesn't cause any security problems right now, the day is probably coming when seemingly benign modifications, such as to skm, skp, jpg, or png files within the bundle will cause the OS to prevent launching the program, marking it as a security risk due to the presence of unauthorized changes occurring since signing. You will avoid ever having that problem if you make a point of staying out of the app bundles altogether.

Andrew

@gohch said:

ok, this is really odd, i ran SU2014 in Win7 and the crash occurred,
and then i ran SU2014 on Win7 again with compatibility mode set to XP(service pack 3) and no more crashes.
Ran SU2014 on Win7 with compatibility set to Vista SP2 no crashes.
So, in Win8 i have to run as compatibility for Win7
and in Win7 i have to run as compatibility for XP or Vista

I don't know anything at all about the specific plugin you're running, but I can at least tell you this: When running on any operating system newer than Vista (7, 8, 8.1), using any version of SketchUp (8, 2013, 2014), SketchUp automatically executes in Windows Vista compatibility mode. You can force it down to an older XP compatibility mode, but even if you choose something newer, the highest it will actually go is Vista.

The reason is that we have not formally taken measures to embed any OS compatibility flags within the SketchUp Windows executable. As a result, the OS assumes an incompatibility on Win 7, 8 or 8.1, and therefore automatically runs it in Windows Vista compatibility mode. In theory, it should not make any difference that you are running a newer OS, or attempt to force it into a newer compatibility mode elsewhere.

Again, I know nothing about the use or design of your specific plugin, but I would suggest that compatibility modes are likely not the source of your problems. Any perceived connection may be largely circumstantial.

Good luck,

Andrew

Hey everyone!

Until now, I knew the basic nature of how this problem occurs. We noticed and investigated it during SketchUp 2013 development, even going so far as to implement a fix we thought would prevent it from ever happening again. Imagine my surprise at seeing it once or twice during the beta period and now continuing to get support inquiries about it. With no apparent pattern to who sees it or why, I just couldn't figure out its random persistence...until now.

After thinking about it some more this afternoon, I just had an epiphany about exactly what's causing this behavior. Although the only method for preventing this is not something I can readily implement, I'm thrilled to have figured out the root cause of this problem's continued appearance, despite our previous countermeasures.

A (typically) lengthy explanation follows.

Background

When Windows Vista was released, Microsoft changed enough of the Windows internals to break backward compatibility with many legacy programs. This compelled them to create a "compatibility mode" to help users install and run programs made for older versions of Windows under Vista. When in compatibility mode, Windows changes its behavior to mimic an older operating system in an effort to play nicely with software that would not work otherwise. This feature continues in Windows 7 and 8 today and can be very helpful when dealing with software that wasn't explicitly written for newer OSes. An important component of compatibility mode is the "Program Compatibility Assistant" (PCA), a system process which operates in the background to discover and correct incidents of program incompatibility. Think of it as a troubleshooter that keeps an eye on things and gets involved to automatically fix perceived compatibility issues in legacy programs when they arise.

However, if a program was actually written for compatibility with the OS you're running, it's important that the PCA never get involved because enabling legacy compatibility mode for a program that doesn't need it might cause more problems than it solves. An example of such a problem is that which started this thread, where our perfectly Windows-7-compatible installer is being mistakenly launched in compatibility mode and behaves incorrectly as a result. In order to prevent the PCA from interfering unnecessarily, a newly created EXE must include a "manifest" file that explicitly declares which operating systems it was targeted to support.

How the PCA works

The PCA works by monitoring certain attributes of a program's execution. If you launch a program that does not include a manifest stating compatibility with the OS you're running, then the PCA will monitor that program and try to determine if it ever misbehaves. If it detects misbehavior at any time while monitored, then when the application terminates, it will pop up a dialog to ask if you might like to try re-running it in compatibility mode instead. If you ever happen to choose "yes", then the file and path name of the application in question is added to the registry in a section marking those files which should always be run in compatibility mode and then it sets the flag on the file with a default value. After that, unless the "compatibility mode" option is manually disabled, the program will forevermore be launched in a context where Windows masquerades as an older operating system than it actually is. In the cases that concern us, the PCA chooses a compatibility mode for Windows XP SP2, which is older than the SketchUp 2013 installer allows, thereby causing it to abort installation.

Here's the curious part

The SketchUp 2013 installer was explicitly written to include "Windows Vista" and "Windows 7" compatibility statements in the application manifest. Therefore, the PCA service ignores it and will never get involved with our installer on those OSes. That means the Windows 7 PCA isn't responsible for having enabled compatibility mode on that file. Given also that we have yet to find a case of a user going out of their way to invoke compatibility mode and also cannot find any group policies that could be responsible for blindly enabling compatibility mode for the entire system, why then do we see that the tell-tale compatibility setting is enabled and causing installation problems for some of our users?

And now the twist

This is the part I just realized this afternoon that solves the mystery.

None of this is actually a problem with SketchUp 2013. It's actually SketchUp 8's fault.

SketchUp 8 vs. PCA

The SketchUp 8 installer does not contain the application manifest to declare its compatibility with Windows Vista or Windows 7. It isn't that the SketchUp 8 installer is incompatible, but just that the need for a manifest was not known to us back in the time of SketchUp 8, so we never took the proper steps to include it. As a result, when running the SketchUp 8 installer, it's monitored by the PCA and as explained above, if any "misbehavior" is detected, the PCA will pop up a dialog to tell you that it thinks the installer may have failed prematurely due to a compatibility problem and ask if you wish to possibly try it in compatibility mode instead.

Why does the PCA think the SketchUp 8 installer misbehaved? Well, the PCA detects that the program is an installer and therefore assumes if it completes correctly, the "Add/Remove Programs" (aka "Programs and Features") menu will necessarily be changed if the installer runs correctly to completion. Therefore if for any reason the "Add/Remove Programs" menu remains unchanged when an installer exits, the PCA thinks it misbehaved. Upgrade scenarios and even launching the installer and clicking "cancel" are both circumstances in which the installer will exit without changing the "Add/Remove Programs" list, so those are cases where the PCA will probably show up, even though nothing actually went wrong. Then if you happen to dismiss the dialog without reading it (such as by clicking too fast or hitting "Enter" for some reason), the default choice is to affirm that the installation was a failure. Then the file gets marked as needing to run in compatibility mode in the future.

I've saved the best part for last

Here's where it all comes together. You may have noticed that whenever we launch new versions of SketchUp, they're always available at the same web address and are always named something generic like "SketchUpProWEN.exe" or "SketchUpMFR.dmg". There are numerous reasons why we do this which I won't get into, but this is a critical factor in explaining how the SketchUp 2013 installer is being sabotaged by SketchUp 8.

If at any time you downloaded and ran a SketchUp 8 installer by a name like the one above (aka SketchUp 8 M4 or M5, before we launched 2013) and for any reason had the PCA dialog pop up and then ever clicked "yes" when asked if Windows should use compatibility mode for that program, the PCA recorded that file's name in the Windows registry with a note to say that it should always be opened in a default compatibility mode for (Windows XP SP2).

Some time later, you realized your download folder was getting full and confusing, so you either deleted the old SketchUp 8 installer, or renamed it so you could better tell what it was.

Fast forward to today.

If you download SketchUp 2013, you're going to get a file named exactly like the one you got for SketchUp 8, saved to the exact same place as the old one--your downloads folder. Now, when you double-click to launch it, the PCA rears its ugly head and BOOM, you're stuck in Windows XP SP2 compatibility mode for the SketchUp 2013 installer, even though none of us intended it to be so.

• It doesn't matter that this is a brand new file that you've never had on your computer before.
• It doesn't matter that the contents of this file are nothing like the old SU 8 installer that caused compatibility problems in the past.
• It doesn't matter that we've included the correct application manifest inside of this installer, declaring that it's perfectly Windows 7 compatible.
• It doesn't matter that you either deleted or renamed the old SketchUp 8 installer and it might not even be anywhere on your computer anymore.

You see, Windows couldn't care less that we've done so much to differentiate this new installer from the trouble-making SU8 installer. The only thing it cares about is that there's a registry entry for a file by that name which stipulates that it must run in compatibility mode. That fact alone puts the scarlet letter on your newly downloaded installer, forcing you into an undesired compatibility mode that SketchUp 2013 doesn't support. It's absolutely ridiculous. If this "feature" were integrated directly into NTFS (imparted at the filesystem level instead of in the registry), or at least if the registry were updated to track any time a tagged file is moved or renamed, neither the installation problem nor this thread would ever have existed)!

Mitigation

If your registry contains a compatibility mode flag for a given file, there are only two ways to prevent it from causing a problem. Either you can follow the procedure mentioned in the previous post and turn off compatibility mode for the file, or you can rename it to fool the registry into forgetting about the compatibility mode.

Really, that's all? Just rename the file Yep.

Correction

I've come back to edit my original post on this point in order to correct an invalid assumption I made regarding the rename procedure. When I first made this post, it was entirely theoretical; I hadn't been able to verify any of the points I stated above. It just suddenly made such undeniable sense of what was previously such a baffling problem that I was certain this newly discovered explanation was correct. Well, I miscalculated one point.

I expected that if I were to tag file as needing a compatibility mode and then rename it, the registry would be updated to follow the file by the new name, meaning that simply renaming a file would never clear the flag. I likewise thought deletion of a file should clear the compatibility flag and assumed the observed behavior of persistence was merely an unintended bug. After all, hadn't anyone considered what would happen if a generic file like "setup.exe" ever got tagged with the compatibility flag? It would affect every file by that name thereafter and cause anarchy! It just seemed obvious that the only way to implement a reliable strategy for implementing compatibility mode would involve updating the flag updated with filesystem changes. But evidently Microsoft and I define "obvious" differently.

Once I finally had a chance to directly test all of these theories, I found that renaming a file actually does clear the flag, which means rename and delete are both working as intended and my guess on that point was wrong. To prevent confusion for future readers, this section is updated to remove those misunderstandings and explain things as they really are.

I contend that Microsoft failed to fully consider all of these possibilities in designing the compatibility mode features. But then again, I'm biased by the fact that this entire problem would never have existed if not for the failure to make the compatibility flag follow the file across renames and deletes.

Download Improvements

Now that I've taken you through the whole explanation about how this problem came about, there's just one last point to make about how we should handle this in the future. A straightforward solution on our end is to change the download name of the files we serve so that the name is different from anything it was in SketchUp 8, thereby preventing the sabotage. Then the next problem to tackle becomes the fact that for numerous reasons that shall remain unexplained, despite being straightforward, it's nevertheless difficult, time-consuming and un-fun to make changes in all the places that have to be coordinated to keep our whole download system working correctly. Yuck.

That's all, Folks!

I hope this helps anyone who runs across this problem again. And know that we will try to find a good solution to this so it won't keep happening forever.

Comments and questions are welcome.

Cheers!

Andrew

@samyell77 said:

Hi,
Im having lots of problems trying to install Sketchup 2013 Version 13.0.4xxx
I was only able to install the SU 2013 v 13.0.3xxx from the MSI file (the .exe thinks Im not running windows 7 which I definitely am).

Hello,

This is a known problem that we're working to prevent in a forthcoming release. In the meantime, see below for a procedure to correct this yourself.

Explanation:

Believe it or not, the code within our installers that checks the operating system version is correct. The problem is that although you have Windows 7, when the SketchUp installer performs its version inquiry, Windows lies and says you're running Windows XP SP 2. Since our installer wants you to have at least XP SP 3 or newer, it exits without installing.

This is the correct behavior in the event that your operating system really is too old, but in your case, we have to stop Windows 7 from lying so you don't get that message anymore.

[highlight=#ffff00:l0lymucg]Fix Procedure:[/highlight:l0lymucg]

*If you are running Windows Vista, 7 or 8 and are told it's not new enough for SketchUp 2013 to install.

1. Download the SketchUp EXE installer.
2. Locate the SketchUp EXE installer on disk. Its name will be something like "SketchUpProWEN.exe" and should be in your "Downloads" folder.
3. Right-click on the installer EXE and choose "Properties".
4. In the properties window, select the tab marked "Compatibility".
5. Notice the checkbox setting labeled "Run this program in compatibility mode for:", followed by a dropdown box that probably shows "Windows XP SP2". This is the offending setting that causes Windows to lie to the SketchUp installer.
6. Disable compatibility mode by un-checking that setting.

• If the checkbox is grayed out (disabled) and cannot be changed, do as follows:
• Click on the button "Change settings for all users".
• Disable compatibility mode by un-checking the setting.
• Click "OK" to close the "Compatibility for all users" window.

1. After compatibility mode is disabled, click "OK" to close the properties window and return to Windows Explorer.
2. Double-click on the EXE to launch the installer.

Although you were able to work around it before using the MSI installer, that is definitely not the preferred method. Please follow the procedure above instead, as it actually fixes the root cause of the issue.

I hope this helps you and anyone else who stumbles onto this thread.

Thanks,
Andrew

Hi, Jonathan,

It would help to know more about your specific problem. Where are you getting the texture? There are multiple methods for texture import; what are you doing? Also, what version of SketchUp are you using and can you tell us anything more about whether this has always been a problem or if it's new?

-A

TIG,

I apologize if my previous message was not clear enough on this point, but I never intended to criticize or chastise you or anyone else, nor did I ever use the word you in any of my statements where Google's terms were quoted. I am very careful about the words I choose and I meant them exactly the way they were written. Although my post addressed quotations from your message, the heart of the content was meant as a general notice to clarify the issues for everyone (as I explicitly stated). Please understand that there is no hidden agenda or meaning intended beyond just trying to help make sure everyone understands the issues. Doesn't it seem appropriate to you that I should respond to these sorts of comments immediately upon their first mention instead of waiting until potentially several people started trying or discussing the use of subversive techniques to do so? I think that's the point at which it does the most good, anyway.

@tig said:

I still fail to see why this current Plugin ended up being 'Pro only'.

As I mentioned in my first post to this thread:

@andrews said:

The plugin only works with the Pro product, not the Free one, because these tools are aimed at film and stage professionals, not everyday modelers. I personally believe that the argument to use SketchUp for film and stage work is greatly strengthened by access to LayOut, which only comes with the Pro product. I think it's in everyone's best interest if we ensure that folks who use SketchUp for film and stage work have access to the full suite of professional tools offered by Google SketchUp Pro.

Although I was an outspoken advocate for making this a Pro-only feature, it wasn't my decision that made it so. Whether anyone agrees with the decision or not, I can assure you that it was carefully considered by all of the right parties on the SketchUp team before the decision was made.

@tig said:

The previous 'version' of the very similar tool was never limited in this way...

I realize the previous version of the tool was not encrypted, making it more available for people to use on several platforms. However, I contend that the old "Film and Stage" plugin was "Pro only", as it was written in 2005 before there was a free product at all and was never repackaged for use in SU6 or SU7. This is the first opportunity we had since creating the free version of SketchUp to explicitly decide whether these tools should run on Pro, Free, or both.

@tig said:

There are many 'ordinary' people who have undoubtedly assisted Google in the testing of this tool and may now find themselves unable to use it [if they are not Pro users] without any prior warning that this might be the case when it was finally released...

I recognize that over the past few years, many folks have found workarounds to get the old F&S plugin installed and working with free versions of SU6 and SU7 and that some of those people probably provided feedback to us that was useful in the creation of the ACT. It is unfortunate that these users will not have access to the ACT plugin in the free product, but that's just the way it is. I am sorry that no warning was given, but I honestly don't see why one should have been expected.

@tig said:

I do/did not 'encourage' anyone to break the terms of any agreements

Agreed--I never said that you did. Again, my comments were meant to be read and understood by anyone who comes across these forums.

@tig said:

I suggested that any attempts to do so might well be regarded as being 'wrong'...

Agreed. You said:

@tig said:

but then you might have invalidated the user agreement

...which is precisely why I followed up by citing specific sections in the EULA that describe exactly why your assessment seems correct. If it hadn't been for you mentioning the user agreement, I probably wouldn't have thought to go into the details at all.

@tig said:

My comment about an 'empty registry entry' ... wasn't "recommended"

As I've already stated, I never claimed that you made any recommendations.

@tig said:

if that simple ploy compromises your tool then may I suggest that a more robust method should have been considered...Did they not think of that simple ploy to circumvent checking ? I hope they did ! You could have asked many users, like myself who might have had some advice...

I never addressed anything regarding the level of difficulty required to circumvent the security that is in place. We certainly have thought of many ways that a person might attempt to compromise the product and we employ a number of different strategies to defend against such attempts. We know our security isn't perfect, but that's not the point. The point is that I simply explained for the benefit of everyone, that it's probably not a good idea to subvert, or encourage anyone else to subvert, the protections that are in place, because to do so would be a violation of the EULA.

@tig said:

Also do you really suppose [as you have 'hinted'] that if I were able to 'crack' Google's encrypted rbs files I would publicize that fact ... please reread my post to see that I do not say this at all

Again (feeling like a broken record), there's no subtext in my original message; I never hinted you would attempt to crack an rbs file. I believe you're taking all of this way too personally. I don't need to re-read your post because I read it carefully in the first place (as I wish you had done with mine). I think if you were to take a step back and consider the intent of my post from an outside perspective, you would find that it really is as simple, straightforward, and un-targeted as I claim it to be.

Thanks for your understanding,

Andrew

TIG,

I'm struggling to understand your message, but I think you may be muddying the waters a bit. I'd like to take a minute to clarify some things for everyone.

@tig said:

As far as I can see there is nothing in the film/stage plugin's code to limit its use to just v8-Pro as suggested

You seem to be talking about the original "Film and Stage" plugin. The old plugin was written in 2005, before Google inherited SketchUp through the acquisition of @Last Software. Back then, there was no "is_pro" method in the API because there was no free product. Back then, everyone had to pay to get a license to use SketchUp, so it wasn't necessary to make a distinction. That's why that plugin doesn't contain such a limitation. If you read the blog post associated with the launch of the Advanced Camera Tools, you will see that the tools have been completely re-written, debugged, and enhanced. Although the ACT are related to that old plugin, it is misleading to suggest that these tools are simply a re-packaged version of it, or that you can know for sure what API methods are in use within the code.

@tig said:

The advanced tool is compiled so I don't know... However, the installers itself might only work for a v8-Pro installation [with both a version and a license check?]...

As I indicated in a previous post, the "Advanced Camera Tools" are written specifically for Google SketchUp Pro 8. Yes, the installers themselves, both on Mac and Windows, contain checks to prevent installation outside of GSU Pro 8. In addition, the plugin itself is also written to enforce the policy of only running with the Pro product.

@tig said:

I'm unclear about why it's felt necessary to limit its use this way - it could have had a is_pro? test in a compiled .rbs version and then there wouldn't be this mystery...

This is the sentence I'm having the hardest time understanding, because I do not see that there is any mystery. Just to clarify, the Advanced Camera Tools are designed to only operate with the Pro product. Yes, part of this involves using an "is_pro" check, among other things. As for why Google felt it appropriate to limit the use of the ACT to the Pro product, see my previous postings.

@tig said:

It might simply need an empty 'Sketchup8 Pro' entry in the Registry for it to run... So you could probably copy all of the plugin's files/folders from a Pro installation into the same locations in a Free version installation and it might well work... but then you might have invalidated the user agreement

I'm not a lawyer and I'm not writing the following in an official capacity as a Google employee, so you may take it with a grain of salt. I'm also not trying to chastise or criticize. I'm only trying to provide some clarification. However, in my reading of the Google SketchUp EULA, going to any lengths to attempt to make the Advanced Camera Tools operate in an environment other than that for which they were intended, would violate the user agreement. I also don't think it's a good idea to encourage anyone to subvert the protections that are in place to prevent unauthorized use of the software.

Some noteworthy excerpts from the EULA are as follows:

@unknownuser said:

Google SketchUp Pro consists of functionality available in Google SketchUp (free version) as well as functionality available only in Google SketchUp Pro. The Google SketchUp Pro functionality is made available to you without charge on a trial basis for a limited time, as may be determined by Google from time to time in its sole discretion. To continue using the Pro functionality after the expiration of the trial period, you must pay the applicable license fee at http://sketchup.google.com/intl/en/redirects/gsu8/buy.html, or other URL that Google may provide from time to time.

The Advanced Camera Tools constitute functionality only available in Google SketchUp Pro. Therefore, in my reading of those terms, one can only use those tools within the context of the trial period, or upon its expiration, after having paid to purchase a Pro license.

@unknownuser said:

You agree that you will not, and will not allow any third party to... (ii) take any action to circumvent or defeat the security or content usage rules provided, deployed or enforced by any functionality...contained in the Software

I should think that coaxing the ACT plugin to run under a pre-8 version of SketchUp, or in the free version, would constitute attempts to circumvent the security functionality of the software.

@unknownuser said:

You may not (and you may not permit anyone else to) copy, modify, create a derivative work of, reverse engineer, decompile or otherwise attempt to extract the source code of the Software

Finally, if someone were to attempt to unscramble the .rbs file to obtain access to the code it contains, these terms would be violated as well.

Again, I haven't written this message in an official capacity as a Google employee. I'm just pointing out how I would interpret the EULA.

I hope this helps to clarify things for you and for anyone else who was confused about the matter.

Andrew

@pixero said:

But why is it a rbs file?

The business model for this functionality is that it should only be available as part of the Pro product. That would be rather difficult to enforce if the tools were distributed unscrambled. Besides, if you bought a license for Pro so you could have access to the ACT and then learned that people were freely copying the plugin for use in the free product, you would probably feel a bit cheated. Therefore, this is in part, in defense of the rights of our Pro users.

Andrew

@massimo said:

As I said and as you can see on my profile, I have a pro version.

I was aware that you have a Pro version. Although my answer was addressed to you because you asked the original question, the purpose of mentioning Free vs. Pro was to provide as complete an answer as possible, preemptively answering the inevitable question of "Why doesn't it work with SketchUp 8 (free)?" for other forum users.

@massimo said:

"be patient with me I'm still on 7 version".

$95 gets you an upgrade from 7 to 8. Just sayin'...

@massimo said:

It says "for SU 8 pro", does anybody know if it works also with SU 7.1 pro?

It works with precisely the version it states: Google SketchUp Pro 8. This goes for both Mac and Windows, where the installer enforces those rules as well.

I'm not sure why the eye-rolling would be necessary, but in my mind, there are several reasons why this limitation is legitimate.

• The plugin was written to conform to the Ruby API of SketchUp 8, not 7.x.
• SketchUp 8 is the currently supported product. Although we reserve the right to release critical security fixes for 7.x if we deem it appropriate, we do not intend to perform "new" development for old products.
• The plugin only works with the Pro product, not the Free one, because these tools are aimed at film and stage professionals, not everyday modelers. I personally believe that the argument to use SketchUp for film and stage work is greatly strengthened by access to LayOut, which only comes with the Pro product. I think it's in everyone's best interest if we ensure that folks who use SketchUp for film and stage work have access to the full suite of professional tools offered by Google SketchUp Pro.

I hope this answers your question.

Dan,

@dan rathbun said:

I wanted to do a fresh clean install of the release...

This wasn't any more necessary an activity at release time than it was beforehand, since beta 6 is actually what we released for M1. It would probably have been best to leave it alone and allow the installer to automatically handle the details.

@dan rathbun said:

I ran the 8.0M1 installer
It created a new "%ProgramFiles%/Google/Google Sketchup 8" folder, as expected... BUT
it copied everything from my Backup folder heirarchy, ...
THEN ... overwrote ALL the Google supplied files (rb, rbs, skm, skp, etc...) in BOTH folder heirarchys !!!
It destroyed my backup copies !!!

I'm sorry to hear of the trouble you encountered. However, as one of two people who was responsible for creating the installer and someone who has spent countless hours testing it, I have to say that this is a pretty dubious claim. I'm not writing it off as impossible, but just as incredibly improbable. If I get a chance next week, I will try to take a look to see how much control we have over how the uninstallation is performed and whether there is an error to be found in how the list of files to remove is populated. It may also be a matter of either WiX or MSI conspiring to cause such havoc, in ways over which we have no control. I can tell you however that the uninstall logic has undergone very little change since its introduction in SketchUp 7 and this is the first I've ever heard of something even remotely like this being reported. It's far more likely that human error is to blame for the issue. One way to test this would be to repeat the exact same set of steps again. If your hypothesis about the name matching is correct, you'll get exactly the same behavior the next time around. Again, I'll see if I can find any evidence to support how this might happen, but given my experience with having written, tested, used and debugged the installer for the last several years, I just have to say that it's unlikely there will be anything to find.

@dan rathbun said:

It installed that BLEEPIN' Google IE Toolbar without asking if I wanted it.. causing me to uninstall it. (Hate this!) I am installing an application .. and your installer is messin' with another unrelated application!!

I'm sorry to say that this is rather more plausible than your first complaint. We actually go to great lengths to ensure this sort of thing does not happen, because we recognize how frustrating it can be. Apparently we have a bit more work left to do there. Our intention is to program this so that when running the installer, you are asked whether you'd like to have the IE toolbar. Regardless of your answer, we attempt to write a registry value indicating that we've asked you this question. Any time after that when you run the installer, it should locate the registry key, recognize you've been asked before, and then not prompt you about it at all. Of course, it should never, ever install something against your wishes. The behavior you're describing is something we would never like to see happen.

Unfortunately, ever since IE 8 came out, the way we detect whether you already have the IE toolbar or not, as well as the way we do some things like setting Google as the default search engine (if you've asked for that to be done), is much more complicated than it used to be. We've tweaked it many times and have spent quite a while trying to debug any remaining issues, but it appears that we have a bit more work to do there.

As an aside, one thing I'd like to make very clear though is that for those of you who run registry cleaners or similar utilities, you're taking your life into your own hands to do so. Without being aware of how every registry key in the system is being used, you always run the risk of causing damage by removing things outside of the context of the installer program. I have no idea whether that's relevant in this case or not (I suspect not), but it may be important for others to think about for the future.

@dan rathbun said:

And the installer turned OFF my "Links" bar !! WTF! (I am a wee bit ticked off.)

I'm not sure what you mean by the Links bar (and in what context). If you can clarify a bit, perhaps I can address your concern.

Andrew

@fuzzion said:

The developer admits that su8 was released too soon.

Huh, that's weird; I wonder why none of my colleagues let me in on that admission. There are multiple SketchUp developers, by the way. Got any sources to cite so I can be sure to tune them up?

@fuzzion said:

Once the SU team get the approval from upper management to stop creating additional tools already available for DL or purchase, and focus solely on developing a 3D CAD program that can utilise newer tech, the chance of SU becoming the Apple for the CAD world increases.

You're right; we really have waited far too long already for those upper management folks to remove the clause "never stop reinventing the wheel" from our mission statement. We've really got to start pushing on that one!

SketchUp could be more like Apple? I get where you're going, but be careful what you wish for, because we could be a lot more like Apple. Can you imagine? What if we didn't concentrate so much on liberating our users' data and providing it in a completely open format, or if we strictly locked down the Ruby interface so you could only run pre-approved plugins? Maybe then we could tie the 3D Warehouse to a single ISP's network and make everyone else jealous while charging our ISP's users out the nose for the exclusivity of it. Just for good measure, we could re-write the GUI to look like it's wrapped in aluminum and charge 3x more for it than what you'd expect to pay for any competitor's program.

Of course, I did type up this message on my MacBook Pro.

Doug,

As of SketchUp 8.0, we only support Intel CPUs on Mac. That means, no more PowerPC architecture (G3, G4, G5 CPUs) for any of the SketchUp software (SketchUp, Style Builder, LayOut, SketchUp Viewer).

Ending support for various CPU architecture, OS platforms and older graphics cards is always a bummer for someone, but it's a simple necessity of ongoing software development. Due to Apple abandoning their support for PowerPC (they did it before we did, actually), and the number of PPC users remaining in the world shrinking considerably every day, we ultimately determined that our engineering resources would be best spent pressing ahead with new technology instead of spreading our people thin to keep the PPC platform in-tact.

The decision to drop support PPC is similar in spirit to the decisions to disallow Windows 2000 in v7, to require at least SP2 for Windows XP in v7.1, and also recently changing the minimum MacOS version to 10.5. You see, at some point, the amount of extra work required to keep old platforms running, and the number of new and improved features that developers miss out on using by maintaining backward compatibility become too much to bear and we have to raise the bar.

As for the SU Viewer release schedule, ever since Google acquired SketchUp and started making the basic version free for anyone to download, the SU Viewer (which is only available in English now also) has become nearly obsolete. We know there are a few hangers-on who would argue against that, but the fact is that when push comes to shove and we don't have enough development or testing resources to go around, the SU Viewer will always get the short end of the stick. That's why it wasn't released at the same time as SketchUp 8.0 back in September.

Andrew

@honoluludesktop said:

Per Google: "/Largeaddressaware". Does this mean that 64 bit computers can now address bigger files, while 32 bit machines retain the benefit of speed?

Sort of. In short, the flag will help many people, but don't be surprised if it doesn't improve your specific situation.

For all of the reasons discussed a million times before, migrating SketchUp to compile natively as either 32 or 64-bit is a very difficult and incredibly time-consuming endeavor. However, when we heard about the possibility that the functionality of memory-intensive operations might be improved without going all the way to a 64-bit migration, we jumped at the chance to try it.

Those who brought the /LARGEADDRESSAWARE flag to our attention touted it as a magical cure-all. Indeed, we had high hopes that it would make a marked impact for those folks who really want to work with much larger files; we invested quite a lot of work in turning that flag on, ensuring we had done it correctly and consistently throughout SketchUp, and testing the results. Unfortunately, in the specific case of compiling and linking it into SketchUp, Style Builder and LayOut, that flag is more snake oil than miracle cure.

I did some pretty extensive testing with large images after we first introduced that flag to our compilation, on both 32-bit and 64-bit machines with Windows XP, Vista and 7, all with varying amounts of RAM from 1 to 12 GB. After all, we also needed to make sure the flag didn't break anything either.

Although I found many cases that showed improvements on 64-bit machines with more RAM than was usable in previous versions of SketchUp, overall, I was disappointed because it didn't make the staggering difference we all expected. Although many of you will find the improvements to your liking, SketchUp is still going to fall short for those of you who want to perform actions that are an order of magnitude beyond what SketchUp has traditionally been able to do, such as exporting 10,000 x 10,000 pixel anti-aliased images.

It is worth noting that in some cases, the threshold for seeing problems varies by the operating system. For instance, I was able to export high-res PDFs from LayOut under Windows 7, which failed on XP. Oddly enough, I even showed such a test case that worked really nicely on a Win 7 machine with 1 GB of RAM, while failing on Win XP with 4 GB RAM. Although we were not able to pursue that issue down to its root cause, we believe that in some cases, the inconsistency is due to differences in the system libraries distributed with each platform, or possibly, in the way the kernel of each OS manages memory. Apparently on Windows 7, even with 1 GB RAM, the memory management for that operation is much better overall than what happens with Windows XP. Strange, but true.

Andrew

Ken,

@unknownuser said:

I believe when I upgraded from 4 to 5 I lost all my plugins, materials and components. Never had the courage to try again. So, next upgrade I will save a copy of these three directory in another directory, and try your method to install over.

My colleague, Steve, and I were responsible for creating the SketchUp installers for Mac and Windows. I have only been on the SU team for just over three years, so I can't speak to what technologies were in place back in the 4 and 5 days. However, on Windows, for SketchUp 7 and 8, which were built as MSI-based installers using Wix, if you're just installing a minor release (anything where the major version number stays the same, like 7.0 -> 7.1 or 8.0 -> 8.0 maintenance release 1), you should be perfectly safe to run the upgrade in-place. The Windows Installer technology is supposed to be smart enough to replace just the files that differ in your current installation vs. the new installation, without removing extraneous files or replacing directories wholesale.

This does highlight the point that if you've made any modifications to files we provide, those modifications could be lost in an upgrade. However, you should never (99.999% of the time) need to overwrite any of the files we provide for you with your own modifications anyway. If you need to modify something like a LayOut template, copy the file and make a differently named version with your modifications so they can be preserved separate from what we've provided. And, in the cases when it is possible (such as with LayOut templates), store your own files outside of the SketchUp directory structure, just to be on the safe side.

Obviously, with things like plugins, you have no choice but to put the files inside the SketchUp directory, so if it worries you, make a quick backup of the SketchUp directory before proceeding with the upgrade, but do know that we expect it should work without such intervention.

Andrew

@chris fullmer said:

It is actively being worked on.

See these notes:
http://sites.google.com/site/3dbasecamp2010/unconference-sessions/sketchup-in-the-film-industry

The paragraph numbering appears to be broken in the document, although the content seems fine otherwise. It was correct when I wrote the original, so I can only assume something went wrong when it was converted to HTML by the site maintainers. Hopefully it's still helpful anyway.

Andrew

@thomthom said:

Will there be videos availible of these glimpses? And BaseCamp events in general?

I haven't been informed about the specific plans, but I do know that our in-house videographer was on-hand at the event and recorded the keynote session. I believe he also recorded some of the other sessions, but I am not sure about the brainstorming session we did at the end.

As for the remaining sessions, since it was an unconference format and there were so many small meetings, it was not possible for us to record them. However, members of the SketchUp team were tasked with fanning out and attending as many unconference sessions as possible and taking notes (I did three of them myself). We are in the process of collecting those notes right now, so I hope someone will make them available to the public in relatively short order.

Andrew