@jeff hammond said:

thing is, sketchup itself is moving files in/out of the bundle.. if i create a texture, in sketchup, and place it in the material list "Wood", that .skm will go to .app/contents instead of ~/Library... Likewise, if i delete a material from any of the bundled lists, it will delete from the bundle.

Jeff,

I did not realize SketchUp is doing this. IMO, it's a bug. All of the content created by the application during the course of its use should be created in the user's folder, not in the app bundle. Thanks for bringing it to my attention.

@jeff hammond said:

if i put that Materials folder at ~/Library/Application Support/SketchUp 2014/SketchUp ,most of these materials will not be available in sketchup.. (only those in the folders: Indigo,Surface_Layer, & HiRes will be recognized)

This also seems like a bug to me. I will open a report about it and see what other people think.

Andrew

@driven said:

why not have empty User path folders included in the instal? I know they are 'made' on demand, but people do go looking for them to add things manually, and resort to all sorts of things when they are not there...

John,

I understand and agree with your complaint, but there are some complications preventing us from providing the empty directories at install.

• On Mac, there is no "installer"; there's just a drag-and-drop bundle. Therefore, we can't create anything in other directories at "install" time, but only afterward--upon first run or later.
• On Windows, although we do have an installer, we still can't necessarily handle this at install time due to issues of the execution context of the installer. If user "A" runs the installer on a shared machine and we create the empty content directories in the folder for user "A", that doesn't solve the problem for any of the other multiple users like "B", "C" and "D". This same problem would exist on the Mac if we had a "real installer" for that platform as well, which again means we're stuck creating each user's directories sometime after the install is done.

As I've shown, the very earliest we can create the empty user directories is upon first launch. I see no way around the fact that anyone going to look for those folders before first launch will be out of luck.

Now, having said that, it's my understanding that we don't actually create these folders at first launch, but rather, on-demand--when they're needed to store newly created templates, downloaded extensions, etc.

I agree it would be a straightforward matter for us to create those folders all on first launch of the product even though we don't do so today. I'll open a feature request for it.

Andrew

@jeff hammond said:

can't ask a mac user.. the last two OS releases have been 64bit only.. ... also of note (maybe) is that even apple's lesser hardware (phones and tablets) are 64bit now... obviously, i'm not a developer but from a user pov, they're sending a pretty clear message.. quit making 32bit applications.

Jeff,

I think the perceived message of "quit making 32-bit applications" is just a side-effect of Apple's circumstances.

Apple's switch from PowerPC to Intel CPUs in 2006 marked a perfect opportunity to simplify development substantially by beginning the universal adoption of 64-bit CPUs. The funny thing though was that even they didn't make the transition quickly. Although there were already 64-bit PowerPC CPUs available, they weren't universally so, making Apple continually drag their 32-bit stuff along in the OS until they felt comfortable dropping PowerPC support. They also didn't release their new hardware with full 64-bit support as they could have. For example, our "Apple Xserve1,1" build servers from that era had 64-bit CPUs (as have all Intel Macs ever released), but not the 64-bit EFI necessary to utilize them. As such, they only supported the 32-bit kernel!

Finally abandoning 32-bit platforms altogether required Apple to consciously drop support for all of the old PowerPC architecture, which we saw them do a few years after switching to Intel, but then also had to abandon several of the first generation of Intel-CPU-based Macs in order to get to a complete level of universal 64-bit kernel support across the board. That only just happened within the last 18 months, IIRC.

Even so, this transition was lightning fast in comparison to what's happening in the Windows world. 15 years ago, people hoped Alpha and then Itanium CPU platforms for Windows would signal the end of 32-bit Intel domination in the PC market, but those both fizzled. Intel still reigns supreme and the fact that they still manufacture 32-bit CPUs, coupled with the open architecture of the Windows platform means that unlike Apple, Microsoft doesn't get to dictate the death of the 32-bit platform, whether on desktops or on less powerful embedded systems like ATM machines or tablets. As such, as long as the hardware is out there, it's in their interest to keep making software for it. This symbiosis means there's still a very large market of 32-bit machines being sold (I think it's around 10-20% of new PCs).

I think we see the same thing echoed in iOS vs. Windows tablets. Apple has the luxury of dictating 64-bit across the board, which just serves to simplify their lives massively, so they do, and then--BOOM--that's the way it is.

But my point here is that I think that the reason Apple is making everybody do 64-bit applications now is not because there's an incontrovertible technical advantage, but because of the massive simplification they created across their whole hardware and software development business by leveraging their god-like ability to dictate a single hardware platform across their kingdom. Third-party developers needing to fall in line with what they do is just a side-effect of a move Apple made to greatly benefit themselves.

...

Now, consider this: If only SketchUp had the luxury of being able to drop 32-bit support altogether, how much easier it would be for us to make the jump to 64-bit. With no 32-bit, there'd be no doubling of our testing surface, no making separate installers, no need to write all kinds of help center articles to explain to the masses how to differentiate the two releases, no modifying our store to provide different products, no educating our resellers about the differences, no translating all of that junk into a dozen languages, etc., etc., not to mention the cost savings associated with all of that.

I can't blame Apple for ditching 32-bit; that's the world I'd like to live in, too! But maybe this helps explain why adopting 64-bit while still supporting 32-bit would really suck, just like Apple saw for the 5-6 years they were in transition to the 64-bit-only approach.

Again, this means opening the 64-bit can of worms is even more expensive than just the effort required to create a 64-bit capable SketchUp.

Andrew

@solo said:

May I ask if SU works better on a 32bit machine than on a 64bit machine as a 64bit needs to emulate 32bits which in essence slows it down?

All else being equal between two CPUs where one is 32-bit and one is 64-bit, a 32-bit application will run at the same level of performance on both. Therefore, the underlying architecture of the CPU is irrelevant for a 32-bit SketchUp executable.

Here's where it gets fun.

We are absolutely certain that if we were to compile identical SketchUp code for 32-bit and 64-bit, and then benchmark the performance of the two on the same 64-bit computer, the 64-bit version would be slower.

-- "How much slower?"

We don't exactly know. Making that determination involves some very complicated analysis and a great deal of investigation that we don't think is worthwhile. After all, since I mentioned that we're somewhat resource-constrained, it would make more sense just to spend that effort in a real migration instead of making a prediction about it. The quick glance we did at this suggests there could be a slowdown of as much as 25%, or as little as 5%. Regardless, all else being equal, many of the CPU-based activities in 64-bit SketchUp would be slower than their 32-bit counterparts.

We hold in very high esteem the fact that we have continually improved SketchUp's performance with every single release. We are not opposed to releasing a 64-bit version of SketchUp in general, but in light of this, I think you can understand that we would be incredibly averse to releasing a new version of SketchUp that performs more poorly than its predecessor, no matter whether there's a mitigating reason. I can't say we'd never release something with a backwards step in performance, but it'd be a hard pill for our team to swallow.

Therefore, you can assume that the production of a 64-bit SketchUp would precipitate the need to invest even more resources in performance improvement than we normally would, in order to try to make up for the added deficit imposed by 64-bit compilation. This would of course increase my previous manpower and time estimates.

My point in explaining all of this is simply that, while those of us on the SketchUp team really do understand the frustrations of our users who run into problems due to the current 32-bit memory limitation, we must also be keenly aware of the massive investment required to produce that change, including all of the other desired fixes and features that would have to be sidelined in order to make it happen.

Andrew

Hi, John,

@driven said:

I also think native 'Help' menu items for 'Open My Plugins [folder]', 'Open My Materials [folder]' would save much confusion...

I understand how your suggestion would improve things and agree some folks would really benefit. I will submit the feature request and we'll see what happens.

On the other hand, I can personally understand why the request might be denied.

First, the Trimble Extension Warehouse was designed to alleviate these concerns for the average user, and I think you can understand our wanting to really promote that system. Viewed in that light, adding that feature could be seen as a step backwards from the sort of 'ignorant bliss' we'd prefer for the overwhelming majority of our users have about the inner workings of the plugin system.

Second, it seems like those who would really need to know the location of the plugin folder are plugin writers. I think anyone who has enough programming, logic and general computing skill to create a plugin should inherently be able to seek out the information to find the plugin folder without such a menu item--particularly since it's stated right in the SketchUp Ruby docs. This hypothetical user would possibly find the info in a relevant Google search faster than they'd self-discover the associated menu item.

Third, if we're going to the trouble of adding this feature, it becomes complicated by the technical fact that there's more than one plugin location (the user and system locations). Clearly, this feature would need to open only the user's folder (my plugin folder, as you phrased it). We'd have to hope this doesn't serve to confuse folks who go look for a plugin there and don't find it (because maybe their sysadmin installed it to a system location instead). So it wouldn't really solve everything surrounding plugin location questions. That makes me think if a change is indeed needed, a better solution must exist.

All of that's just playing devil's advocate. Like I said, I'll submit the request and see what happens. I will also include my own suggestion for an alternative lesser feature of making sure SketchUp automatically creates the empty plugin folder in the proper user-specific location with every launch. This would solve the issue of a user drilling down through the file system to the expected folder location and not finding it (because they haven't installed any Extension Warehouse plguins, and thus it hasn't been created yet).

@driven said:

what are the chances of SU providing a migration assistant that scans all 'previous' locations and relocates 'orphaned skm's and skp's' into the appropriate User Folders...

Without having more time to consider the potential difficulties of doing this, I can't comment on it too much.

Off the top of my head, there are obviously some more complex issues to investigate, such as how to handle potential incompatibilities, duplicated filenames, files living in multiple users' directories, etc. Sometimes such a program could cause more harm than good, such as if we somehow migrate some "broken" templates or something.

I think that even if we don't implement the feature in the exact way you have in mind, there is clearly room for improvement of the user experience that comes with migrating to a new version of SketchUp. Just as with your other suggestion, I'll open an official request and we'll see what happens.

Thanks,

Andrew

Hey, everybody,

I want to make sure you all know how to submit bug/problem reports for the SketchUp Mobile Viewer.

The primary "official" method for such a submission is by posting about the issue in the official help forum.

The secondary method is to post a reply in this SketchUcation thread. The support team will periodically take a look at this post for problem reports, but won't look for them elsewhere.

Therefore, please keep an eye on the forums here and direct anyone with bug reports for the Mobile Viewer to this message thread.

Thanks,

Andrew

@bowesy said:

I have somehow downloaded a couple of other people's models on to my iPad to take a look ... there doesn't seem to be any instructions on how to delete/remove them.

Bowsey,

We regret the accidental omission of deletion instructions from the in-app support page. Thanks for bringing it to our attention. In response, our support team is working to update the article with that information.

In the meantime, here's how to perform the deletion.

Summary:
Within the home screen thumbnail grid, find the model you want to delete, then click its info button, then the trashcan button.

Details:

1. Open the SketchUp Mobile Viewer.

2. Go to the home screen. I'm not talking about the "3D Warehouse" screen within the mobile viewer, but rather, the home screen. The title heading will read "SketchUp Mobile Viewer" if you're in the right place.

3. The home screen includes a grid of thumbnails for the models you've saved to your device. Find the model you want to delete and click on its info button (a lowercase "i" with a circle around it, located in the lower left-hand corner of each thumbnail).

4. Clicking the info button will cause the thumbnail for that model to disappear and switch to showing an extended information window. That window contains a trashcan icon.

5. Click the trashcan icon to delete the locally saved model from your device.

I hope this helps!

Andrew

@bowesy said:

Have had problems trying to sign in on Mobile viewer

Hi, bowesy,

Here's some info I hope may help you or others who have login problems.

First, the Mobile viewer uses a Google ID for identity management. It's the same method that's used for all of our products: the SketchUp desktop application, Extension Warehouse and 3D Warehouse. Please make sure you have your Google ID set up properly. One way to test this is by logging into the 3D Warehouse website.

Second, we have discovered a bug dealing with 2-step logins (only affects those accounts which have this login method enabled). 2-factor authentication is a more robust login method that only allows login to an account upon providing not just username and password, but an additional key of some kind. More info here. If your Google account requires 2-factor authentication, then please be aware that this is a known bug that we are presently working to remedy. I do not have an ETA for the fix.

You may be able to work around this bug by disabling 2-step login for your Google account. Note that if your account is managed by your employer's corporate IT department, you may be administratively prohibited from changing this setting. Second, knowing the importance of 2-step authentication to those of you who have it, we realize you might not want to disable it. That is why we are pursuing a fix for the problem. Sorry.

I hope this helps.

Andrew

@jeff hammond said:

instead of encouraging moving stuff into .app/contents, do it the other way..
merge the content into the user directory then delete the stuff in .app/contents..

this is all pretty easily scriptable or done via terminal.. can you do something like that in ruby?

I'm going to throw in my two cents and say this isn't a great idea.

I haven't fully figured out the entire current story regarding code signing on the Mac, let alone its future, but this idea worries me. AFAIK, when we run our digital signing on the Mac .app bundles, those signatures only affect the executable parts of the bundle. However, I can certainly see a time coming when it's possible Apple may include all contents of the bundle in the digital signature calculation.

If Apple suddenly starts making their digital signatures include all files in the bundle and you write a script to change the bundle after we've signed for its contents, then you would invalidate the digital signature. Depending on the system settings, this could cause the bundle to be denied executable access by the OS. Again, this isn't an issue right now, but it very well could become one. The current state of signing on Mac leaves open gaping security holes.

I'd suggest never modifying anything within the bundle to be safe.

Andrew

@kjolesz said:

I am hoping someone on this board can help. I migrated my materials folder from google 8 to google 2014 just as the direction said. Yet when I open my new 2014 version none of the materials are there. It seems as if it does not recognize my .skm files that where in the 2008 version. Is there a reason for this? I tried to manually put an .skm file into my materials via new texture, but .skm files are not selectable and faded out. This led me to beleive that my new 2014 does not take .skm files and thus the reason for the migration to not be working. Any suggestions? I am putting this all under the Users folders...Library... Application Support by the way under the correct google skethcup folder. This is hard because all my old models are not showing correctly and my sketchup 2008 has already expired. Thanks!

I don't know what directions you followed, so it's hard for me to say with any certainty what's wrong. Can you point us to the set of directions you followed?

I'm guessing part of your problem may be the fact that SketchUp is no longer owned by Google. So you shouldn't have the word "Google" anywhere in the path you used to set up your 2014 materials. So when you say it's under the "correct Google SketchUp folder" (although I corrected the spelling), I don't believe it.

Andrew

@pixero said:

Today I got the proof and I have an image to prove it.
SketchUp ran out of memory.
[attachment=0:n8sxhz9s]<!-- ia0 -->SUoutofmemory.jpg<!-- ia0 -->[/attachment:n8sxhz9s]

Nuf said.

You can claim it's enough said if you want, but I'll disagree.

Yes, it's true that SketchUp ran out of memory, obviously. The part that isn't clear is how much it was using at the time, and why it ran out. Without more details, it simply isn't possible to know whether it was truly a result of the 32-bit allocation limits.

For instance, it's possible that SketchUp was well below the 32-bit allocation threshold and that other misbehaving apps or a bug in the OS prevented SketchUp from allocating any additional memory when there was still plenty of ceiling available. As an example, there was a leak in the Apple WindowServer process on the Mac a few years back that caused out-of-memory errors with SketchUp 8 if the user remained logged in for too long without a reboot. Severe memory fragmentation and poor management by the OS can cause this problem as well; if SketchUp were to ask for too large a chunk of memory to be serviced in a contiguous allocation, a failure would result. Finally, it's also possible that SketchUp ran out of memory due to a memory leak in SketchUp that caused it to chew up all of the 32-bit mapped memory incorrectly. Of course such an issue would clearly be a bug in SketchUp that we'd need to address, but while it's true 64 bits worth of memory would help, there's no guarantee it wouldn't simply run out again after exhausting the whole machine memory (which for most people is what, maybe double what they can access via 32-bit, particularly considering that SketchUp is compiled for large address awareness).

It's absolutely possible you hit the 32-bit ceiling and that a 64-bit binary would fix it. However, without further details, it is not possible to know the nature of why this problem occurred with any certainty, or to have any clear proof that a 64-bit application would be immune. That's why say it's just not quite "enough said." I'm not trying to be contrary, just scientifically accurate.

For all those insisting a 64-bit SketchUp binary is the holy grail, although I won't go into the details that we engineers have turned blue explaining in the past, I'll add one more data point that I don't think anyone has openly considered. Given the size, complexity, organization and nature of the SketchUp application code, I personally estimate it would take on the order of two to three man years to reliably port it to 64-bit and achieve an equivalent level of reliability from the end product. That means that even if we were to apply our entire SketchUp client engineering team in that endeavor, it's probably a still several months worth of work just to perform the appropriate modifications, say nothing of the testing effort. One must consider that to add 64-bit support would increase our testing surface by at least 2X, taking time away from anything else QA might light to test.

To put this differently, the point is that one must consider whether the production of a 64-bit binary alone provides enough benefit to warrant sacrificing all of the other things that might be accomplished with such effort. Although many SketchUcation users are traditionally very outspoken about their preference for a 64-bit application (even if many of them don't actually understand the full implications), this community is only a drop in the ocean compared to the multiple millions of active SketchUp users in the world, and I very much doubt that anywhere near even 5% of world-wide Pro users would see tangible gains from adding 64-bit support (let alone Make users).

Don't get me wrong, I'm not suggesting that we should never port to 64-bit; in fact, I have been a long-time proponent of the notion that we should. I'm just pointing out the incredibly high cost of that effort. It's not something to be undertaken lightly.

Andrew

@aerilius said:

Which still does not justify prefererism. In the country where we live, authorities and companies care about to avoid any bias towards their customer base. They need all their customers equally and would for heaven's sake never get the idea to like some customers more than others.

Please understand that no offense is intended, but I think you're taking this argument far off the deep end. It simply doesn't hold up to any scrutiny.

The fact that a company releases a new product with support for "platform A" on the first day of launch does not automatically mean that there are no plans to ever support "platform B". And just because one plans to support multiple platforms does not always mean doing to in a totally platform-agnostic way is the best approach, either. For instance, those who know what Qt was like a dozen years ago will thank SketchUp's early designers for avoiding it.

Even though I'm typing this on a Mac, I've never used an iOS device of any kind in my life--not once. So yeah, of course I want an Android version of this new SketchUp mobile viewer, as do most of my colleagues. But that doesn't stop us from using some basic logic to figure out how to prioritize the work we have to do along the way.

Yes, prioritizing one thing above another has the effect of marginalizing the thing of lower priority. But this is life, and it's nothing personal.

Case in point, two summers ago, my favorite band did a small tour that didn't include a stop in Denver, so I didn't get to go see them. Apparently several other cities were all prioritized above mine. The fact that they didn't come to Denver doesn't mean they marginalized me--for whatever reason, that's just the way it worked out.

The overwhelming majority of tablet users in all of our key markets use iPads. As such, it makes sense that we would focus on native iOS as the first target platform. Furthermore, I think most people would agree that if a company has a viable, stable, working product for one platform, they should release it as soon as possible, even if there are eventual plans to add support for a second platform. I personally see no reason to make one wait on the other.

After all, by that logic, if @Last had waited until SketchUp for Mac was ready before releasing SketchUp for Windows, the product never would have existed, because it wouldn't have gained enough traction or exposure in the dominant platform to warrant porting it to the minority platform.

I know this will upset those who demand equal representation for all, but here's another dose of reality. We have no immediate plans to add support for Farsi, Klingon, Esperanto or Swahili languages in SketchUp. We're also not going to put the new SketchUp mobile viewer on "HP WebOS", the "Apple Newton", or the "Compaq Portable", either. And by the way, the SketchUp client software has never been on Linux, and someday we're going to drop support for MacOS 10.7 and Windows XP, too. While some say that represents more preferential treatment, I say these are simple matters of economics.

All of the details aside though, those who can read between the lines will understand there's no need to get upset about the mobile viewer only supporting one platform today...

Andrew

Just announced at 3D Basecamp 2014:

http://extensions.sketchup.com/en/content/trimble-scan-explorer-extension

Andrew

@tt_su said:

Can you reproduce the crash reliably? If so, can you do so and submit with some info we can look up. I cannot correlate the Event Log data.

I was able to correlate the crash from the provided data. If we're talking about the same one, it came from an IP address in Bulgaria on 2014-03-25 at 11:38:06. The name of the Windows login account is "cadmaster". The BugSplat ID of the report is 10592. The rest of the message is in reference to this specific BugSplat.

That BugSplat shows that SketchUp crashed while executing a Ruby script. It is possible that there's a bug in the Ruby API that allowed a well behaved script to fail. More likely though, the Ruby script that was executing did something wrong and killed SketchUp as a result.

Normally it is very difficult for us to figure out which plugin is misbehaving when it dies. I was able to see that a plugin called "jf_trim_and_keep.rb" was executed before the crash, but I think it completed successfully. I don't think there's a clear indication of the problem-causing plugin in the undo log.

As I said, it's normally very difficult to figure out which plugin crashed from BugSplat data. However, in this case, two big clues stand out which point to the likely cause. First, the list of currently loaded libraries contains Thea4SU_core.so. Second, the call stack shows that there is an active thread on the CPU working inside the Thea4SU_core library at the time of the crash.

I'm guessing Thea wasn't necessarily being actively used or that fact would have been mentioned. Regardless, it actually might not matter. I believe ThomThom has documented elsewhere that Thea is known to cause problems when it's run in the background but isn't being used. If my recollection of that is correct, it would seem that the workaround to this specific crash is to disable Thea when you're not rendering, then save everything and quit before re-enabling Thea when you want to render.

Also for the record, one of the previous messages in this thread which contained excerpts of event logs showed one of the crashes not to be in SketchUp.exe, but something called SketchUpConverter.exe, located in a folder called "Rhinoceros 5 (64-bit)". I wrote the SketchUp installer and I know I didn't ship a file by that name or anything installed to a folder named after a wild animal, so that one isn't our fault.

I hope this helps.

Andrew

@draner5 said:

bonjour,
je rencontre un problème de lenteur avec sketchup pro 2014 avec un modèle de 57 Mo, ce qui est normal vue la taille; mais avec un autre modèle de seulement 700 Ko cela devient une éxtrème lenteur (plusieures minutes quelque-soit la commande utilisée) ce qui n'est pas normal vue la faible taille du modèle conçu de la mème façon que le modèle 57 Mo.

Bonjour,

Il s'agit d'un forum anglophone, donc s'il vous plaît poster en anglais, ou post dans le forum français. En outre, votre question est sur ​​SketchUp 2014, ce qui n'est pas approprié dans ce fil de discussion, ce qui est pour SketchUp 8.

Néanmoins, vous devez savoir que la taille du fichier et la complexité géométrique ne sont pas les mêmes. Petits fichiers qui ont de grandes quantités de géométrie ou qui font usage de modèles sommaire de pointe peut être plus difficile à utiliser dans SketchUp que les fichiers qui sont grands que parce qu'ils contiennent des textures photo.

Merci!

Andrew

@howling wolf said:

Another question I have is regarding a good source for plugin downloads...Is there any one, trustworthy site for downloads?

Your profile indicates you're using SketchUp 8. If you upgrade to 2014, you'll get automatic access to a feature called the "Extension Warehouse". As eneroth3 cited, you can use the Extension Warehouse to install plugins directly within SketchUp. That takes all of the guesswork out of it and makes plugin installation dead-simple!

Andrew

@bartho said:

hello is there a application to use sketch up 8 on android system ? to use it on my Samsung galaxy note?

I'm sorry, but SketchUp is only available for Windows and Mac at this time.

Andrew

@olaydigitaldesign said:

This is some serious nonsense, am I right ladies and gentlemen?

Yes, it was down for a little while on Sunday because the database server backing the warehouse filled up. A monitoring system was supposed to alert us before it caused a problem so we could address it proactively, but the alarms were configured to the wrong threshold and didn't fire. That meant we didn't know about the impending problem until it was an actual problem. We've resized and reindexed the database and fixed the alarm threshold, so all is well again. Sorry for the inconvenience.

Andrew

@greg24k said:

The problem I'm having is when I select get model, the window opens but its blank except a few lines and a blue line at the bottom, and its not connecting to 3d warehouse.

Try clearing your cache and cookies in Internet Explorer. Then try again. If that doesn't work, make sure you can connect directly at http://3dwarehouse.sketchup.com.

@colem said:

Does anyone know what is planned for this awesome viewer? I would love and be willing to pay for an unbranded version as well.

I don't understand what you're getting at. Why would you desire to pay for someone else to make an unbranded SketchUp web viewer when you can just embed the official SketchUp viewer that's provided for free?

Are you not aware of how to embed a model in your own website?