@jason_maranto said:

To clarify -- I'm always interested in performance benefits for all users...

Exactly, right? And that's what I care about as well. That's why I think it is worth spending time explaining these technical issues in such detail— I'd hate for folks to have the wrong expectations about the benefits available.

Whether you think of SketchUp as a toy or not, performance is really the key issue here. "64-bit" just isn't a technology which delivers the kinds of performance improvement you're looking for. Wouldn't you rather have our development team working on stuff that will make a material difference for you?

john
.

These 64-bit threads always seem to head in more or less the same direction— here's what I've gleaned from this one so far. People want the SketchUp team to work on:

performance improvements for all users: Users should be able to load, save, operate upon (ex: "explode") and render at interactive frame rates models with (some big number that gets bigger every time we increase overall system performance) of polygons.
Everyone always benefits from improvement to SketchUp's performance. The reality (for all software systems, not just SketchUp) is that performance is always bottlenecked somewhere. We're always working on removing the 'next' bottleneck in line. The 'last' bottleneck we worked on was rendering performance for large models— SU8 has an entirely new rendering pipeline. 'Merge' operations (implicated in 'ungroup', 'explode', 'import' &etc.) are a reasonable 'next' bottleneck to work on, though there are other

"64-bit" as a technology, however, really offers no panacea for performance in SketchUp. Specifically:

• **64-bit modeling operations don't execute faster than 32-bit ones.**Look to faster CPUs for improvement to execution speed for core modeling operations. A single fast processor core.
• 64-bit computing does not improve realtime rendering performance. Look to faster GPUs for improvement to realtime rendering performance. Lighter models will always render raster than heavy ones.
• 64-bit computing does not improve file open/save performance. Look to faster disk I/O (as with SSDs) for improvement to disk-access operations. Larger files will always be slower to open than smaller ones.
• 64-bit computing does not improve software reliability. 64-bit operations are just as likely to crash as 32-bit ones. Submit crash reports when you can— that's the only way we can know what went wrong.
• 64-bit computing can address more memory, but SketchUp modeling operations are not bottlenecked by memory. Models of 1-2m polygons still fit neatly within 32-bits worth of memory.

improvements for developers: Rendering engines (mainly, V-Ray; to a lesser degree, Maxwell) should be able to execute 'inside SketchUp' in a 64-bit environment, rather than running their rendering in their own thread.

3rd-party rendering engines are free to execute operations in 64-bit environments if they design their architecture to do so. Many of them have done so today— there are significant architectural advantages to doing so. Some renderers, like Maxwell, market the ability to execute in a 64-bit environment (as well as the ability to do things like distributed network rendering) as an advanced feature that justifies purchasing their "Maxwell Studio" rendering suite.

Oddly, perhaps, the single strongest argument for a 64-bit "version" of SketchUp hasn't really come up in this thread yet. Developers who implement .skp import|export in their applications using our freely-licensed SDK will benefit from 64-bit builds of our precompiled libraries when they begin shipping 64-bit builds of their applications. They don't strictly speaking need them, but it would simplify matters greatly if they could have them.

john
.

Maybe it would help if you were to describe the data you want to exchange with Revit users.

@pixero said:

some things like wals with window holes in them isn't automatically transferable so workarounds have to be made.

Alternately, Autodesk could improve their .skp import such that windows with cutting behavior are respected. I believe that both ArchiCAD and Vectorworks, for example, are able to do this.

john
.

@gilles said:

No what I we want for circle tool is chose center then pick any inference for axis then chose radius
the same way rotate tool and protractor tool work.

Sorry, but isn't that exactly the way the Circle tool works today?

edit:
@unknownuser said:

No, he probably means this: http://sketchucation.com/resources/tuto ... click-drag

Gotcha- you want to be able to set the working plane without using the inference system.

john
.

While I don't think Autodesk widely promote the capability, Revit does implement a .skp import path which uses a library (the SketchUp C++ SDK) that we provide to them.

Revit can import .skp models as either Mass or Family entities. It can also 'link' .skp files rather than importing them. A google search will uncover lots of tips and tricks to make this work.

I've seen some very successful workflows where all modeling is done in SketchUp, .skp files are referenced into Revit and all construction documentation is done in Revit.

john
.

According to the 2012 "AIA Survey Report on Firm Characteristics", of the 38% of U.S. architects who have purchased BIM tools for their firms, 91% are using those tools for "Design Visualization." I guess that's something that SketchUp does pretty well already.

edit: I should also mention that only 27% of them are using their BIM tools for "Quantity Takeoff" or other related data/analysis tasks.

@dale said:

Sorry, didn't mean to re-ignite the 32, 64bit debate with my comment

See this thread or any of the many others on the same topic.

@dale said:

I was just trying to understand the difference between what's under the hood in the core, and what I put into the gas tank in the form of plugins.

SketchUp's Ruby API exposes a broad range of SketchUp internals and it permits 3rd-party developers to build profoundly powerful extensions to SketchUp's core tool set. With power must come responsibility— it is entirely possible to write extensions which cause crashes and other sorts of general instability in the core SketchUp application.

While most Ruby developers are quite good about testing their code inside SketchUp, the interactions between extensions are almost impossible for anyone to test. Many of you reading this thread probably have dozens of Rubies installed at the same time. There really isn't a good way to ensure that these will all work well together.

You could argue that we should make it impossible for poorly coded Ruby scripts to crash SketchUp. In fact, we do two things in this area. First, we track down developers who have written code that causes crashes that we see in our crash reports— and we help them fix their code. Second, we modify Ruby methods inside SketchUp such that they are harder to crash. The reality is, however, that poorly coded Ruby scripts will always be able to crash SketchUp.

As you heard me say at 3D Basecamp this year (about 35 min in) we are working to bring some order to the chaos of Ruby development. The Ruby API has been a great success from my perspective. I have even studied it academically. I think you'd probably all agree, however, that a little bit more structure wouldn't hurt. You've seen us already launching things that will help.

There's a fine line between the work the SketchUp team does for Ruby developers and the work that those developers do for their user communities. Users love to have new features— but you can't have features without a solid platform underneath. We're all in this together.

john
.

@gilles said:

and also a circle tool wich works like the rotate tool

I'm not clear what you mean by referencing the Rotate tool. I think you mean you'd like a tool in SketchUp similar to LayOut's Arc tool— with which you set 'center point', 'arc start' then 'arc end'? Is that correct?

john
.

I figured the main point was that you guys would like to have a true arc entity added to the object model from which can be generated arc-arc and arc-line intersections. And some new arc drawing tools to make them. You've seen me acknowledge that I'd like to have those, too— and also seen me explain why they aren't there today.

The Ruby API exposes almost all of SketchUp's internals for the use of 3rd party developers. While it does allow them to write new tools that operate on the SketchUp object model, it doesn't allow them to make fundamental changes to that object model.

Adding a a true arc entity would have to be done by us... and it isn't something that can happen quickly, easily or without risk. There is a feature request filed on the subject.

john
.

Jeff: I suspect that the changes you want to see could be implemented in the Ruby API- someone would have to write a new offset (and FollowMe) tool that reverses the direction of the geometric tradeoff we made when we wrote our tools.

This is an interesting topic for me, and it speaks to a number of other discussions I have had around the internet lately. If SketchUp were to be "BIM", what entities, tools or other features would have want it to have?

sawhack: It sounds like you're thinking of a set of new parametric entities (wall, floor, roof, window, door, ..?) with new tools to make them? Is there more to BIM than this?

john
.

Really, guys- I checked out of this thread for a couple days and it... wow. I love the detail and the impassioned argument on all sides. Also, you're losing me with respect to the actual changes you want made. Maybe someone could summarize for me? It would be helpful.

john
.

@mike amos said:

If you use larger or more sophisticated models you will need 64 bit support

Really, you won't. Memory isn't the bottleneck that needs widening to make larger and more sophisticated models.

john
.

@thomthom said:

@jbacus said:

Wow... just... wow! Twenty-one pages of discussion on the vagaries of SketchUp's curve interpretation.

Got to do something while "it's rendering".

heh. +1

Wow... just... wow! Twenty-one pages of discussion on the vagaries of SketchUp's curve interpretation. Jeff: we've discussed this before, on Reddit. As you may remember from that thread, I shared your opinion that SketchUp would be improved with the addition of 'true arcs.'

@unknownuser said:

I agree- that would be a nice thing to have in SketchUp. When we designed SketchUp's object model in the early days, the thought was to keep it as simple as possible- more native entities required more tools to create them. And the interactions between different entities (arc-line, for example) are more complex to manage. So we came up with the solution that is in place today.

In another life, I was a student of Descriptive Geometry, and I learned that there is nothing that can't be drawn with a compass and straightedge. SketchUp only has the straightedge... and I can see how that is a hindrance. There's no way to construct, for example, an arc-arc intersection in SketchUp.

I agree this would be a useful thing to add in SketchUp, but it isn't something that we could add quickly or easily. I'm keen to see how other folks here would use "true arcs" if we had them in SketchUp, too.

Over the years there have been numerous ruby scripts built that add to the utility of SketchUp arc and circle entities- "point at center" was one of the first scripts I remember seeing. There are, however, limits to what can be implemented through our API without native arc support. I hope we're able to address that one day, but such low level modifications to SketchUp's object model are not to be made lightly.

john
.

For further comparison, here is Autodesk's answer to questions about multi-threadedness in Revit:

The following tools in Revit (all disciplines) take advantage of muliple processors and multiple core processors for calculations which increases the performance of the tool in Revit.

Vector printing
2D Vector Export such as DWG and DWF
Rendering (4 Core Limitation lifted in Revit 2011)
Wall Joins representation in plans and sections
Element Loading. Loading elements into memory is multi-threaded, reducing view open times when elements are displayed for the first time in the session.
Parallel computation of silhouette edges (outlines of a curved surfaces) in perspective 3D views. Engaged when opening views, changing view properties, and navigating the view and will be more noticeable as the number and complexity of curved surfaces increases.
Translation of high level graphical representation of model elements and annotations into display lists optimized for given videocard. Engaged when opening views, changing view properties and will be more noticeable as the number and complexity of model elements increases.
File Loading
Point Cloud Data Overlay

What you should notice in both these lists (from Graphisoft and from Autodesk) is that it isn't core modeling operations which are multithreaded. Instead, it is "rendering" kinds of processes and other peripheral operations which can be accelerated in this way. Multithreading just isn't a technological panacea for CAD applications.

john
.

@jason_maranto said:

I wonder how long the user base will accept the "it's too hard"/"we don't have the resources" excuses...

Actually, what you're getting from us is a clear discussion of the technological reality of 64-bit computing. Unfortunately, that reality does not match your expectation of the benefit that 64-bit computing should bring.

This is a topic that appears to defy rational discussion. That said, I will continue to argue rationally for real and appropriate performance improvements in SketchUp

john
.

Hi guys,

Please contact SketchUp Support for solutions to your single user network licensing issues. These changes were made in SU8m2, released last december- you may want to make sure you have the latest release installed as well- we're on SU8M4 now.

john
.

This question comes up now and again— usually right after someone like you installs some new system monitoring software I think we have some relevant documents in our Help Center. I can try to clarify here as well, if that helps.

SketchUp makes use of your system (including your network and registry) in a variety of useful ways. Rather than trying to itemize each one of them, perhaps you can point out specific concerns you'd like addressed. From the thread so far:

SketchUp accesses your network at launch: This could be any of a number of things. It could be the update service (SketchUp periodically checks for available updates), the activation logging service (SketchUp anonymously reports that it has been launched so we know how many people are using it) or it could be the licensing service checking for concurrent usage of you SketchUp Pro license. If you pick a particular event that is troubling you out of your firewall logs, I can clarify further.

SketchUp changes the registry: This, too, could be a number of different things. Remember that the Windows Registry was intended as a place where application developers could store various settings relevant to running their applications on a user's system. It should be expected that SketchUp makes changes to the registry. Again, if you pick out a particular troubling event from your log files, I can clarify further.

john
.

@bimmer said:

I feel sorry for the SketchUp team (or anyone being acquired by Trimble). I worked for a company that was acquired by these guys and let me tell you things will change in a big way and not for the better.

Your comments don't match my observations. Of which acquired company were you a part?

john
.