Who said SketchUp doesn't need to be 64 bit?

jiminy-billy-bob

@jeff hammond said:

look at everybody's wishes-- not just yours-- and you'll see that under the "add this from such and such program" train of thought, it's really "add everything from every application"

A lot of requests are about improving Sketchup as it is today. A good exemple: true curved lines/faces.
This wouldn't change how SU works, how we interact with it, how we use the tools, etc. But that would be a major advance in how the geometry is built.
I mean, Sketchup is "3D for everyone", it's supposed to be intuitive for absolute beginners. Yet you have to explain to them that when they draw an "arc" (as it's advertised by the software), it's actually a bunch of straight lines. How is that intuitive? And this has a lot of implications...
So yeah, I know that SU is a poly modeler, that it's not meant to be a nurbs software. But couldn't we go behond these naming conventions and actually have a truly intuitive piece of software? Who cares how the geometry is generated or processed by the SU, as long as it's what it's meant to be: an intuitive and accurate 3D modeler.

Curves are just an exemple of these requests aiming at what SU is today.

EDIT: Of course I'm aware that would need a massive rewriting of SU's core, and we'll probably never see it. My point is, there are requests shared amongst the community about the current state of SU.

jeff hammond

@jiminy-billy-bob said:

A lot of requests are about improving Sketchup as it is today. A good exemple: true curved lines/faces.
This wouldn't change how SU works, how we interact with it, how we use the tools, etc. But that would be a major advance in how the geometry is built.

hmm.. i think that changes everything with how sketchup works especially but also in how we interact with sketchup as well as how we use the tools..

it's a complete re-write.. but at least it would be 64bit after that

@unknownuser said:

I mean, Sketchup is "3D for everyone", it's supposed to be intuitive for absolute beginners. Yet you have to explain to them that when they draw an "arc" (as it's advertised by the software), it's actually a bunch of straight lines. How is that intuitive? And this has a lot of implications...
So yeah, I know that SU is a poly modeler, that it's not meant to be a nurbs software. But couldn't we go behond these naming conventions and actually have a truly intuitive piece of software? Who cares how the geometry is generated or processed by the SU, as long as it's what it's meant to be: an intuitive and accurate 3D modeler.

Curves are just an exemple of these requests aiming at what SU is today.

i'm with you.. i think sketchup would be awesome if an arc were an arc and an ellipse were an ellipse and a sphere were a sphere..

my skepticism comes from that being my main wish since 2003.. then boiling point in 2009/2010 where i finally just decided to learn an app that already has exactly that..
i just don't think it's a realistic want.. and more importantly, if you actually need curves-- drop what you're doing, quit worrying about sketchup, and start learning a different program.. thank me in 3 years

my best guess as to what could happen in sketchup regarding true curves were that they functioned more like guide lines.. a guide circle could intersect a guide arc at its real location.. a bezier guide could be a true bezier with control points and whatnot.. if you offset one of these guide curves, it offsets correctly instead of what happens with current offsetting.

but, subsequent geometry could not be created off these guides.. prior to geometry creation, a sketchup curve (polyline) would take over and everything would go from there as normal. (curved surfaces etc would still be meshes)

ruby writers could possibly have access to some of these maths and probably make use of them in geometry creation but at some point, everything would still be a series of lines and planes.

jeff hammond

@jiminy-billy-bob said:

EDIT: Of course I'm aware that would need a massive rewriting of SU's core, and we'll probably never see it. My point is, there are requests shared amongst the community about the current state of SU.

ha.. yeah, i see that.. i'm definitely over-exaggerating some of what i'm spewing today but i'll hopefully shut-up about it soon

in the meantime, mark me down for sharing your wishes regarding better curve integration.. they sound good to me and if any wishes were to come true, this is the area i'd most hope for..

(not talking about bug fix and/or buggy_ish UI type wishes-- those are more of expectations as opposed to wishes.. for me, there are about 5or6 of them which are mac related)

my take on some of the other more popular requests-

high poly support doesn't really affect me but i wouldn't mind some of that too.. though in my case, i rarely bump into or go over the limits and can work within the current constraints.. but if better poly support comes, i'd basically just be using it to make finer meshes / better looking visuals as opposed to bigger models.

fredo's thruPaint works perfectly well for my personal UV needs.. (in fact, it's still the one thing i use while thinking 'holy crap, i can't believe i'm doing this in sketchup' )

ruby (user pov) - i sort of wish there were a standard UI and a recommended set of guidelines for the writers to follow in order to have more consistent conventions/behaviors.

subD - would be fun

import/export -- still a bit bummed that 3ds import has recently lost 'at origin' option on mac.. native OBJ (i.e.- fast) would eliminate my need for 3ds and it's the format i'd personally rather use.. or getting a .skp out of another program might be better yet.. as i understand, it's hard for other developers to provide .skp export from their software so i wish that as new sketchup versions were released, sdks (or whatever it is that would be required) were updated and more freely shared to 3rd parties.. there was a point where i was hoping for .dae everywhere but so far, that doesn't seem to be the case.. at least not with the other programs i use.. seems to be the coolest though because osx supports .dae.. basically- i can make the thumbnails real big and navigate in them without needing to open one.

explode -- in conjunction with the 3ds import losing 'at origin' which sometimes adds around 2minutes of frustration getting an outside model in, the next step is often exploding.. that's a back-to-back round of frustration.

64bit- yes please.. i get it that it's a lot of work to switch.. but at the same time, i imagine that while the conversion is happening, some of the band-aided code which was added around y2k in order to just get the thing working could also be tuned up/refined.. or- we'd maybe get some noticeable enhancements due to the 64bit conversion process - even though the improvements arent directly related to 64bit.

--
ok.. i'm done.. next year-- same time same place. see you then

Hieru

@andrews said:

We made the decision a very long time ago to actively promote the extensibility of SketchUp through use of the Ruby API.

That's all very good, but it cuts both ways. The extensibility of SU sets it apart from a lot of the competition and has greatly helped to keep the software viable.

However, If plugin developers want to extend SU to meet user needs and there is something in the the SU architecture preventing that, then I think that it is reasonable to assume that the SU devs should try and accommodate those ambitions.

John Bacus insinuates that subD and quads are not something SU should even entertain, yet there are valuable plugin developers who are trying to achieve this in order to meet user needs. That's basic supply and demand.

Despite the superhuman efforts of the guys behind Artisan, Vertex Tools and the great advances made in UV plugins, I get the distinct impression that these plugin pioneers are fighting against the limitations of Sketchup's programming. Would it be possible to have a non-destructive bevel plugin without major changes to Sketchup!

When these guys put in so much effort to push SU to its limits, then I think they should be given something in return and be treated to changes in SU that will allow them to reach their real potential and make Sketchup even better than it already is. Snarky comments that make it sound like core users are insane for asking for features that are standard in other apps just won't cut it (that's not directed at you Andrew, your posts have been very encouraging and positive).

At the end of the day, despite all the griping and bitching, most of us love Sketchup, endorse it's ethos, love to contribute to it's development, and evangelise about the joys of working with such a great programme. We all happily take the slack from neigh sayers in the knowledge that SU really is a wondrous thing. I suppose that's why it hurts so much when we get talked down to and told that our expectations are misguided.

jason_maranto

@mike lucey said:

Maranto, its becoming tiring!

Jason, I imagine the above statement may not sit all that well with you. Possibly because of the 'Maranto' address. I imagine you would have no problem with the suggestion of you being 'tiring' as you are more than capable of arguing your point

Fair enough -- I know full well what I've been up to is abrasive, which was fully intentional.

There's plenty more that could be said on many levels, but at the end of the day it all comes down to each individuals tolerance. I reached mine already a while ago... and I have seen nothing to change my mind in the interim. So I will go back to occasionally lurking to see if anything has changed... but I certainly am not holding my breath.

Mike Lucey

Thank you Jason. I appreciate that.

Mike

jiminy-billy-bob

@jeff hammond said:

hmm.. i think that changes everything with how sketchup works especially but also in how we interact with sketchup as well as how we use the tools..

Well, I disagree. We would still draw arcs, push/pull them, etc, the same way we always did. What would change is the need for workarounds, the confusion, ... (Though, maybe we would have new features, like push-pull on curved surfaces)

@jeff hammond said:

if you actually need curves-- drop what you're doing, quit worrying about sketchup, and start learning a different program.. thank me in 3 years

Oh, I already do, don't worry about me Still, I never found the simplicity, the speed, and the inference engine of SU anywhere else.

@jeff hammond said:

but, subsequent geometry could not be created off these guides.. prior to geometry creation, a sketchup curve (polyline) would take over and everything would go from there as normal. (curved surfaces etc would still be meshes)

Why not? Is it a matter of display?
Sure, we will always have polys displayed, that's just the way 3D engines work. But that doesn't mean we have to interact with them.
Look at autocad, you work with true curves, and polys are displayed. Their size and number depends on the "REGEN" command.
In Rhino, it's pretty much the same, except it's an option setting controling the amount of displayed polys.
I really like how Revit handles it, the displayed geometry is regenerated everytime you zoom, so a poly is always at most the size a screen pixel. (And I guess it's rarely less, so you save ressources on distant geometry)
Etc... There are ways! It's simply a matter of will.

numerobis

@hieru said:

That's all very good, but it cuts both ways. The extensibility of SU sets it apart from a lot of the competition and has greatly helped to keep the software viable.

However, If plugin developers want to extend SU to meet user needs and there is something in the the SU architecture preventing that, then I think that it is reasonable to assume that the SU devs should try and accommodate those ambitions.

John Bacus insinuates that subD and quads are not something SU should even entertain, yet there are valuable plugin developers who are trying to achieve this in order to meet user needs. That's basic supply and demand.

Despite the superhuman efforts of the guys behind Artisan, Vertex Tools and the great advances made in UV plugins, I get the distinct impression that these plugin pioneers are fighting against the limitations of Sketchup's programming. Would it be possible to have a non-destructive bevel plugin without major changes to Sketchup!

When these guys put in so much effort to push SU to its limits, then I think they should be given something in return and be treated to changes in SU that will allow them to reach their real potential and make Sketchup even better than it already is. Snarky comments that make it sound like core users are insane for asking for features that are standard in other apps just won't cut it (that's not directed at you Andrew, your posts have been very encouraging and positive).

At the end of the day, despite all the griping and bitching, most of us love Sketchup, endorse it's ethos, love to contribute to it's development, and evangelise about the joys of working with such a great programme. We all happily take the slack from neigh sayers in the knowledge that SU really is a wondrous thing. I suppose that's why it hurts so much when we get talked down to and told that our expectations are misguided.

Thanks! I think i could sign almost every word.

jiminy-billy-bob

@numerobis said:

I think i could sign almost every word.

Same here!

jeff hammond

@jiminy-billy-bob said:

@jeff hammond said:

hmm.. i think that changes everything with how sketchup works especially but also in how we interact with sketchup as well as how we use the tools..

Well, I disagree. We would still draw arcs, push/pull them, etc, the same way we always did. What would change is the need for workarounds, the confusion, ... (Though, maybe we would have new features, like push-pull on curved surfaces)

oh.. yeah.. from a user point of view, it should/could seem like not much has changed though there would be instances when new/different techniques would need to be employed.. under the hood though-- i'm pretty sure it's radically different.. as in re-write from scratch different.. the guidelines idea i was talking about seems more like something which could be added to the existing application as opposed to throwing away much of the existing code and redoing it.

@unknownuser said:

There are ways! It's simply a matter of will.

well, that's the catch.. i'm not sure if the will is there or that the direction of sketchup even deems it necessary (like i said, i've been wanting to see curves in sketchup for over 10years.. finally this year, we get a tool that can rotate and intersect.. so at that rate, maybe by 2050, we'll get some curved surfaces ).. it's a tough thing from a user pov though.. i mean, these are computers we're dealing with.. they are aiding us in drafting.. but when it comes to curves in sketchup, it's a step backwards.. the drafting tools which are meant to be replaced by the software are actually superior in some circumstances whereas to me, i feel like a computer should be able to completely replace the compass/french curve and improve on them..

fwiw, i did a little example of how the display meshes in rhino work in this post.. it was meant as an example to show that a nurbs surface doesn't produce a 'better' render because visually on screen, a nurbs surface is still being represented by a mesh.

but that same example can be used to show the downfall of polygon surfaces in design.. generally, if you're doing, say, a single curved wall (i.e. draw an arc, extrude it straight vertically), you'll be just fine in sketchup.. you can make sure vertices are placed at key measuring points and draw the thing 100% accurate and build-able)

you may have to do some workaroundy type stuff in that situation but regardless, it's possible to get an accurate drawing with sketchup in those situations.

the problem, and the area in my own work which i needed to be able to deal with, is what happens when you need to use a curve or a curved surface to create further geometry.. at that point, in sketchup, you're pretty much screwed.. the intersect operation in the link above should make obvious the problem im trying to describe.

(oh. and @jiminy.. i'm not necessarily talking at you about this stuff.. i get it that you already know what i'm talking about )

jiminy-billy-bob

@jeff hammond said:

oh.. yeah.. from a user point of view, it should/could seem like not much has changed

Yes, I'm talking from a user POV.
From a dev's POV, it would indeed be a tremendous amount of work. That's why I'm pretty sure we'll never see this in our lifespan

jeff hammond

@jiminy-billy-bob said:

That's why I'm pretty sure we'll never see this in our lifespan

same here..
that's pretty much what i've been trying to get at in my last few posts.. about recognizing what sketchup is good at and further improving those areas.. 'changing' sketchup would probably introduce some negative issues in my personal workflow.. unless those changes could completely swallow another application but i just don't see it happening..

i mean, when i switched to rhino, it didn't mean i stopped using sketchup.. while it's not optimum to use multiple applications, it's incredibly common to do so.. we all do it..
even within sketchup's own ecosystem, there's an example of it-- layout.app.

i figure i use 8 applications in a typical project start to finish.. safari, mail, rhino, sketchup, pages, numbers, indigo, & pixelmator..

there are others too but that's the main 8.. 6 of which, in some form or another, are graphics based and/or something to do with the actual design or piece to be constructed.

on a side note re:import/export.. i found out that rhino actually does support collada.. it's just rhino for mac doesn't.. so i'm trying to get that implemented now
if that happens, it may just solve all of my personal import/export issues with sketchup.

tt_su

@jeff hammond said:

look at everybody's wishes-- not just yours-- and you'll see that under the "add this from such and such program" train of thought, it's really "add everything from every application"

This is very true. And "add everything from every application" would not make "3D for everyone". This is where the API platform comes into place.

@hieru said:

However, If plugin developers want to extend SU to meet user needs and there is something in the the SU architecture preventing that, then I think that it is reasonable to assume that the SU devs should try and accommodate those ambitions.

That would be the team I am working with. The Extensibility Team. For the first time ever SketchUp has a dedicated team of to the development and maintenance of the SketchUp APIs. Introduction of the new C API has been part of this new effort - so has the improvement of the Ruby API. Along with that there is the Extension Warehouse and we're working on much more in the background. One of the big goals is to attract more developers, professional developers who make their living out of creating new tools and transforming SketchUp. For that we need to make a lot of improvements, but we will get there.

@hieru said:

John Bacus insinuates that subD and quads are not something SU should even entertain, yet there are valuable plugin developers who are trying to achieve this in order to meet user needs. That's basic supply and demand.

You know my personal take on quads and subd - I love that stuff. Though I think some of the friction on the topic, and other proposed features, is what goes into the core product and what would be supported by extensions.
I have the impression that many people think of extensions as second grade tool sets - which is unfortunate. Maybe it's because the majority of current extensions is made by hobbyist (I have been) without the resources to provide dedicated support and full time development.
For the core, don't expect all features from all applications to appear. That wouldn't be SketchUp. But note that that doesn't mean SketchUp won't ever provide extended functionality. Sandbox Tools, Advanced Camera Tools, Dynamic Components are all built on the Ruby API. They can be disabled by those who feel they never need it. We even have a few more extensions that is available on EW that didn't make the cut for what was considered to be broadly available out of the box, but can easily be installed for those who need it.

@hieru said:

Despite the superhuman efforts of the guys behind Artisan, Vertex Tools and the great advances made in UV plugins, I get the distinct impression that these plugin pioneers are fighting against the limitations of Sketchup's programming. Would it be possible to have a non-destructive bevel plugin without major changes to Sketchup!

There are certainly a good amount of improvements needed to the API to allow more complex extensions. Parametric extensions are one of my personal favourites and I want us to make this easier for SketchUp extension developers. I'll post back shortly with an example of a personal project of mine that illustrates what I'm talking about.

@hieru said:

When these guys put in so much effort to push SU to its limits, then I think they should be given something in return and be treated to changes in SU that will allow them to reach their real potential and make Sketchup even better than it already is.

Exactly! This is the goal of the Extensibility Team. Unfortunately we have to built it all form the ground up. So many pieces are missing. (I wish we had those 1000 monkeys with infinite time that wrote Shakespeare. That being said - we have positions open! )

@hieru said:

I suppose that's why it hurts so much when we get talked down to and told that our expectations are misguided.

Much of the frictions stems from point of view. A user will see the SketchUp world from one point of view, while the product managers must see it in a much more broadly perspective. Adding a ton of features (to the core) does't give power - it gives bloat. And this is bit of a holy thing for SketchUp. It is the success that it is due to its simplicity. "3D for everyone". Observe how many of it's tools are very agnostic and generic. Take classifiers added in SU2014 for instance, we could have added IFC tagging - but instead a generic approach was taken - to allow arbitrary schema to be defined. Thus allowing a much more flexible and generic tool that could be used in a much broader context.

I hope the matter of new feature requests this will become less painful in the future when SketchUp as a platform of third party developers improve. These will be able to focus their efforts to their own specific niches within the SketchUp eco-system. "SketchUp Subd Edition"

Hieru

Thanks for the great response Thomas. I really appreciate you taking your time to allay some of my concerns.

From the sound of things, Sketchup is in good hands when it comes to enabling third party developers to push plugin development even further.

I definitely appreciate the need to avoid bloat. Everyone has a different set of core plugins they would prefer to come as standard, but we all vary in our modelling approach. Even if we were only talking about simple plugins like weld, by the time everyone chimes in with their request the list of core tools would be ridiculous.

Being able to customise Sketchup according to your focus of interest and modelling approach is something I wouldn't want to change. The flexibility is pretty much unrivalled and I can't think of another programme that I can modify as my skills improve and evolve.

The integration of plugins could be greatly improved, but given that the better ones feel like native tools, I suspect this is down to the authors rather than a problem with SU.

That being said, I do think that there is a strong demand for native non-destructive SubD, bevelling and proper UV mapping. I also think that these features are needed to keep Sketchup competitive with rival software. They may not be required when it comes to "3D for everyone" but as with the Sandbox tools, they could be disabled when not required.

Anyway, thanks again for the positive response. It's just a pity that the same message doesn't come across from product management.

thomthom

Taking off my Trimble hat for a moment - here's a peek at my latest personal project I do on my spare time. I showed this to people at BaseCamp so this is the first preview for those of you who where not there.

http://www.youtube.com/watch?v=e1MhcTknJWI

Quads and Subdivisions

This is all done with SketchUp 2014 using the current Ruby API. Non-destructive subdivisions with soft creases that support the pseduo-quads of QuadFace Tools (if you are like me who like to make geometry in quads.) Anything else will be triangulated.
Note that this is a very early development preview - not even in alpha stage.

This is the type of extension that would fit to a niche segment of SketchUp users and therefore not be fit for core product. It isn't something everyone wants or needs. This is specialisation. But as an extension it's great, as you just bolt it on and you got yourself a subdivision modeller.

I haven't profiled and optimized this thing yet - just getting it to do the right thing. But from some quick tests its not Ruby that is the main bottleneck. This means the core need to be improved, but also that extensions aren't second grade members. There are certainly lots of things in the API that can be improved to make the creation of such extensions much easier.

Krisidious

You sly dog...

numerobis

WOW! Really great response Thomas!
I never expected to see something like that so quickly (after following the discission of the last days)

Looking foreward to the release!!! I think this will be definitely the day, i will upgrade to 2014...

Really impressive work. Thank you!

Pixero

That look very cool indeed but it's not available for us...
I'm still waiting for a release of your Bezier Surface plugin...
Do you have any time working on these things?

I agree that much can be accomplished with better plugin integration but a thing like quads (and better editing without destroying UVs). Wouldn't it be better if integrated to the core program so all tools would benefit?
Otherwise there could be for example numerous 3rd party move tools that would do essentially the same thing? One with each plugin authors solution to move vertices without messing up UVs.
That could easily make SU bloated IMHO.

Also there has been talks here of real curves in SU.
Do you mean that could be implemented through 3d party or would that have to be a "core" feature?

thomthom

@pixero said:

That look very cool indeed but it's not available for us...
I'm still waiting for a release of your Bezier Surface plugin...
Do you have any time working on these things?

Time is a shortage, no doubt. And to be honest, Bezier Surface hasn't gotten a lot of love lately. There is a huge amount of challenges of making bezier surfaces to appear smooth and not end up with artifacts. Subdivisions on the other hand are much easier to consistently generate a smooth limit surface. You can find many white papers on these topics that mention these things. So I've been moving more toward focusing on SUbD. But quite a bit build upon the development of Bezier Surface - and an interesting property of a 3x3 patches of quads subdivided is that they normalize to a B-Spline patch - meaning an abstraction can be built on top of the subdivision tool.

Pixero

But does this means it would be possible to export this as a subd/bezierpatch or would it be exported as polys?