Should Trimble write plugins?
-
They already do.
DCs, Advanced Camera tools [previously 'File&Stage'], Sandbox tools, ShadowStringFix, SolarNorth, WebTextures etc...
Plus a number of 'example scripts'... -
So we're talking about "Trimble" as "SketchUp" here?
-
@adamb said:
Jeff, can you elaborate on why it would be cool?
not really.. just speaking strictly from a user pov.. i mean, i get it that most other devs will see this question in a different way than most other user..
but it's mostly developers responding so far in the thread..
@adamb said:
While its true there is always some jackass software engineer that "invents" the idea that "everything is a plugin" for a particular App, the result is almost always horrible performance and/or brittle software (ie breaks easily).
it's sort of like that now.. + super unorganized (in a variety of ways)
@thomthom said:
So we're talking about "Trimble" as "SketchUp" here?
right.. as in plugins that come directly out of the sketchup office..
-
I'll ask the dumb question that I may get notorious for.
What (perhaps technically) is the difference between adding a functionality to the core of the product versus doing this using a plugin? (understanding that not everybody has access to the core code)
I have many more dumber questions, but I will start here. -
@dale said:
I'll ask the dumb question that I may get notorious for.
What (perhaps technically) is the difference between adding a functionality to the core of the product versus doing this using a plugin? (understanding that not everybody has access to the core code)
I have many more dumber questions, but I will start here.
A plugin typically uses the Ruby API. This is slower than native C++ code used by the main app, although on simple tasks the time taken will not be that noticeable...
SketchUp has core additions like the 'solids' tools, and native Pro only exporters etc are also coded separately from the Ruby API.
Sometimes the Sketchup guys have decided to provide extra functionality built into the core code, and sometimes in the form of API 'script' add-ons.
We must assume that this is to do with their in-house resources and also what knock-on changes they might need to do to the core-code to accommodate any new functions - which can can be avoided by using the API connectivity... From the users view point the only major difference would be the API's slower execution; which, as I said, with a simple process might well go unnoticed by the user anyway... -
@tig said:
like the 'solids' tools
booltools was a super awesome plugin.. solid tools are ok..
but having solid tools is way better than having booltools.. they work better/faster/more options/way more stable..
does that make sense?
-
They can't upgrade for ever
maybe toolpacks is a better way for them. -
Thanks Tig and Jeff, Yes this all makes sense.
I guess my question comes, as I have heard John Bacus state both at BaseCamp and in the forums, in particular in reference to 32 versus 64 bit discussions, that a major rewrite of the core would be necessary to accomplish this.
So could is it a case where, when you start changing certain functions within the core coding, it has implications serious and otherwise) both within the core code, and API scripts? -
If it's a properly designed API, it shouldn't happen (but could). That's also the advantage of an API, a "programming interface", that it's a stable set of commands to connect to the core (no matter what algorithms work in the core or whether the core is rewritten etc.). All SketchUp features would ideally be written by using its API, where as processing-heavy algorithms (intersections, ray casting) would be added as API methods.
I think we can distinguish here two questions:
• Whether Trimble-provided tools should also use the API (and be equal to plugins).
• Whether the API and tools should be based on a scripting language or a compiled (binary) language (C++). Actually that soon won't make much speed difference anymore, since modern scripting languages are executed as super-fast binary code (produced by just-in-time compilers). -
Individual 'staffers' have written plugins and I hope that continues.
I think 'Trimble' should at least 'vet' scrambled rbs both free and commercial.
When we add 'plugins' it's to enhance their product in our workflow, having supplied both the API and the scrambler, I think they have a 'duty of care' to the end user to at least check the safety/security of those plugins.john
-
I see no conflict with Trimble writing plugins. If you take the basic ui as a start and then add 'packs' of plugins that would tailor the program to different uses (architecture for example), there could be a defferent sketchup for users in different professions. Always acknowledging that there will be writiers of scripts from within the user community. It might even be a method of increasing the sales of pro and be something that could (note use of the word COULD) be used to keep the cost of pro down, another method of increasing sales.
I would be a fan of this type of system as long as the age old issues of the core could be addressed. A more stable sketchup with hopefully 64 bit support and more control of the standard of plugins would be very welcome so perhaps a more stable system plus support for independent script writers would be a decent balance.
I agree that a ui full of wasteful icons would be a detrimental step so possibly this idea would make others happy too?
-
What is this Obsession SketchUp users have with 64bit?
Its not going to "make it more stable" or "make it faster".
I don't know who fed you guys this idea, but they should be slapped. And told to stand in the corner.There are some areas of SketchUp internals that (I suspect) could do with some refactoring and would likely result in less memory use and therefore better performance and stability, and with a code base this old, I can well understand the concerns "Team SketchUp" may have with the 'nuke and re-pave' option.
-
64bit should rather be seen as "another possibility" for those programs who need it. It does not mean that every program has to become sooner or later a 64bit version, without technical reasons or advantages. In fact, some/many programs are purposely released as 32bit version where it is faster or lighter on memory.
-
@adamb said:
What is this Obsession SketchUp users have with 64bit?
Its not going to "make it more stable" or "make it faster".
I don't know who fed you guys this idea, but they should be slapped. And told to stand in the corner.not sure but i pretty much guarantee if/when sketchup goes 64bit, they (trimble) will sure as shlt be touting "now 64 bit!!!!"
-
If you use larger or more sophisticated models you will need 64 bit support and it will not go away because some folk get personal when others mention it. If you want 32 bit fine, I happen to want 64 bit support. Now if you want to go and stand in the corner it is your prerogative. Personally I go for the right to chose. Clear enough kiddies?
-
@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
. -
@jbacus said:
Really, you won't. Memory isn't the bottleneck that needs widening to make larger and more sophisticated models.
We wouldn't run out of memory when rendering with Vray...
-
re: 32bit versus 64 -- So how come moderately large files take ages to open in Sketchup, versus in other software I use that is 64bit, super large files open very fast.
re: plugins -- I do hope that sketchup devs and other Trimble teams will write plugins, otherwise, I could imagine that this ecosystem would start to get less attention and resources, if it's not being used by the makers and owners of SU.
-
@unknownuser said:
So how come moderately large files take ages to open in Sketchup[...]
Something takes long (=time, not memory), apparently there is a lot of CPU processing involved.
Compare for example exporting a big model to stl vs. importing from stl. It seems SketchUp takes more time to initialize its internal model data structures, which can't be compared to other softwares. -
@aerilius said:
@unknownuser said:
So how come moderately large files take ages to open in Sketchup[...]
Something takes long (=time, not memory), apparently there is a lot of CPU processing involved.
Compare for example exporting a big model to stl vs. importing from stl. It seems SketchUp takes more time to initialize its internal model data structures, which can't be compared to other softwares.Interesting. So you think SU would take a long time to "think" about a model regardless of the bit depth of its files? Well, seeing how bogged down SU can get with loads of plugins, I guess it makes sense that the content of a model file can bog down SU as well. It just seems that there are an awful lot of events in SU that just "take the long way 'round". Oh well, so SU is fast and nimble ...until it's not.
Which I suppose argues against Trimble adding yet more plugins to an already sluggish program (at higher poly-counts of course - which is what terrain data is for example...)
Advertisement