@anton_s said:

Derei, if I understood you correctly, you want to reduce the zooming intensity, right? You can decrease the zoom factor by going to Plugins->AMS Smooth Zoom->Options and reducing intensity, to say, 0.1. Thanks for your feedback!

Factor 0.1 from what i could see, actually makes the zooming intensity equal to "sketchup default". Higher values will make zooming faster (in bigger steps).
I was hoping to go under sketchup's default. To have a smoother zoom in terms of precision, not only visualization.

@krism said:

There is a third location at work here and that is the right click context menu which is becoming increasingly large. Plugins are SketchUp's greatest asset and it's greatest curse. I would hesitate to suggest that Trimble enforce some kind of order so as to not stifle the creativity which happens with the plugin authors. However, there must be some way to have a rational structure to this issue.
KrisM

I believe that enforcing anything will lead eventually to limiting freedom (of creativity, plugin development, people willing to participate, etc).
Best would be to wake up awareness... like a guided topic and also maybe a team of volunteering people to "review" the plugin when is launched and to suggest to the author the proper location in case it was poorly chosen.
But then, the author should be willing to accept this suggestions.

I made a similar post a while ago, people seemed to appreciate the idea, but as the things went afterwards, it seems that it wasn't really taken seriously and I wonder why...

The point was as it follows:
Most of the honorable plugin makers ( thank you for all your effort) tend to place their plugins in Extensions (Plugins) menus... which is understandable, as they are... Extensions. But again, those extensions could be easily classified for other menus (camera/view, draw, window, etc).
There is the second trend of the plugins placed under Tools, which again is understandable if you think to them as tools used in your work. But again, some could be distributed in other menus...

Why this trend doesn't catch? I ended up having to scroll the Extensions Menu and I am sure I am not the only one here (unless I have the smallest display of you all).

Examples:
JF Custom Toolbar - could go in View, where are other Toolbar settings

Keyframe Animation - could go in Camera, as it's about placing and controlling cameras

Extension Store - could go in Window, where is the Extension Warehouse too (if Trimble decided to put it there). But it also could go in File, as it's very rarely used and the File menu is rather short.

Weld - could go in Draw, as it's about lines and curves

cgScenes - could go to View, as it manages scenes/styles/visual properties

Export to DXF (from Tools) - could go to File, where other importing/exporting options are

And of course, the examples can continue.
I believe that paying more attention to where plugins will be located will actually improve user's experience with SketchUp both by making them easily found and also making the menus less crowded which will again make them easier to spot in the menu.

Some of you will say that i can do that myself, which is true...but what then when there is an update for that plugin? Will be rewritten and moved back to where the developer thinks it belongs. Better the developer to put the plugin where it fits best from the first time, what do you think?

Maybe this time, the idea will catch.

Just tested the plugin. I like the fact it makes the zoom smoother, but from what i could see, this plugin can't make the zooming factor smaller than sketchup's default, although it can increase the factor. Is fun to play with those inertial modes when the transition is sensibly longer.

Few suggestions:
-see if the zooming factor can be DECREASED, this would help in case of precision zooming needs.
-please consider moving it in Camera Menu, because everybody is putting their plugin in Extensions, as there is no other place in SketchUp. And that menu becomes longer than some screens height...

Good Luck.

Thank you all for the solutions !

@ntxdave said:

I think we are each addressing a different aspect of the original post.

My response was concentrated more on the aspect of presenting the model via a web page/link. The tools I suggested provide the ability to view a SU model on a web page. In particular, the first set of tools I mentioned allow you to view, pan and rotate your model without doing anything special in SU (I.e your model can be a single scene). I think that the solutions are also more efficient in that you do not have to have a bunch of image files that you would then manipulate via javascript.

Again, just some thoughts

Thanks. What I really needed was a way to set the cameras/scenes. Not to use it in web browser. But thanks for your idea. I may find it useful.

Still not null match, pilou. Because both sculptris (btw, i use sculptris) and zbrush work wonderful. But in case of SU, both free and pro suffer from the same weaknesses: they are underdeveloped and the pro is still overpriced for what it offers.

The point of this topic was to draw attention to how others sell their software: they meet price with quality.
I expect by the time when SketchUp will reach the robustness of any other major software to cost like AutoCad. And by robustness i don't mean to be complicated, but to really do properly what is supposed to do already.
-proper uv-mapping
-fix scenes renaming bug
-faster and more responsive LayOut
-text mismatch fixed between SU and LO
-text mismatch fixed in LO between edit mode and rendered mode
-less bugsplats
-some really important features introduced by default instead of being needed contributed plugins (like Layrrs Panel)
...and many others.

Can you imagine SketchUp's price then? Like $$$$... and this was my point: zbrush can do much better and syill keeping price low. One more thing: zbrush users are a very narrow niche, another reason to increase price. SU can be used by artists, hobbysts, architects, engineergs, teachers, psychologists... etc.

And your comparison would have been closer to reality if you had chosen Edison, not Tesla ... because Edison was a prick that used Tesla to make money and didn't repaid accordingly )) ...kind of what Trimble does with SketchUp.

I believe I will have to go for such tricks eventually. That old plugin (made by google, i believe) is lost gone... if nobody remembers it.

@ontaotto said:

I know where your comments go, yeah to me is pricey too what Trimble asks for SketchUp license, obviously is not the same vein in no single order, both programs are quite different.

Autodesk offers Maya for education purposes and is a very professional program, with no limitants and that is for free, why Trimble don't do some similar?

I wish that SU license be cheaper....

Please read again, I don't compare them in "organic modelling", I am aware that each of them is for SOMETHING ELSE... but I compare the robustness of the program itself, how well is made, how reliable, how good it handles ITS OWN TASKS. I mean, if i try to do the things i do in SU by using ZBrush, it would be a pain... also to model such complex things in SU as they can be done in zbrush... so, this point is out.
I was just saying: Look a very robust and reliable program for $800 and look one that awaits some basic fixes for 5 years yet and almost nothing was done... yet the price lately reached $700. See my point?

So, here we have: SketchUp and Zbrush - of course I won't compare them in terms of functionality. Each is for a completely different purpose and they address totally different needs. But nevertheless both are 3D modelling programs.

My (rhetorical) question is: DO THEY COMPARE IN TERMS OF ROBUSTNESS ? I mean, do both "do as it says on the tin", sort of speaking? Are they both equally solid, coherent, reliable in terms of what both are doing?

I am asking this because i was literally SHOCKED to see the prices are almost the same and I would love to see SketchUp performing to the same level of professionalism as ZBrush is doing in its field... for the same money.

...say your thoughts about

yes, I had many faces in the model (organic modelling)...
But why there are 2 different uses for ENTER (when cursor on face, or not on face?) Is possible that is why I miss it many times... because i move the cursor around. I am not used to pay attention to it when i don't actively use it to manipulate geometry. Do you think this behavior is actually useful?

Thanks for all explanations

I know it was a plugin which one could use to export a series of images taken all around a object, then you could embed that with a js code in a web page to have like a "turntable view" of that item.

I am in need of such a plugin to set cameras (or scenes) around a object at regulate intervals.
Maybe you can point me to one.

Cheers.

Two changes would be great for this plugin, as it works somehow against "intuition":

-first would be Press RETURN to exit (that's the ENTER key, and usually is used to CONFIRM a action, not to cancel it) - best would be to use ESC Key

-second would be the obligation of inserting push value with (-) AFTER the push action was initialized. It is great to let the option there, in case the user really needs to revert the direction, but it would be better that once a number was introduced, to take "by default" the pushing direction already initialized by the user.

Another thing is that AFTER doing a JPP operation, I must be very careful what tool or key I press, or I risk to have my operation canceled... this is extremely frustrating, as there is no intuitive action. As I said before, I am tempted to press ENTER - but guess what? I cancel my work. If I press Space Bar (to go to select tool) it happens the same, if I click on screen I also cancel the operation... every time is "lucky guess". In my opinion should be clear: ESC= Abort, ENTER=Commit. Nothing around. To not exit from operation until ESC or ENTER was pressed. This way there is no chance of mistake.

I hope this suggestions make sense.
Thank you.

@rv1974 said:

@david_h said:

well .. .Im a tad underwhelmed. I think I will hold out for 2017 where I am sure ALL the major wish items will be finally included.

Frankly. . I have been wishing for one feature since version 5 and it doesn't seem to get any traction at all. I don't know if I know how to describe it very well or what. . but the one thing I would love sketch up to is to Hide visibility of nested components when you ware working on them. If I have window C and I have multiple C's in that component to able to hide all but the next C up in the tree for clarity sake would be awesome. right now with "hide rest of Model" it's an all or nothing thing.

Odd wishes. Why only 3, not 4?
If it so crucial you could copy 3 instances of the component you are tweaking to the empty file on the next display and tweak there more discreetly. And paste it back when its OK.

Is TREE (like branched hierarchy), not 3 !! ))

@slbaumgartner said:

I believe there may be a little i/o for caching the undo stack, but other than autosaves, not a lot.

Humm... sometimes, undoing complex operations (eg, Artisan) will be a pain... so for this it may be useful. Any ideas how this operation could be moved to another drive? Where is the location of the file that stores the undo stack?

@slbaumgartner said:

Most OS's cache file data in RAM after each read. Some even anticipate by reading ahead when you start loading a file. So, unless you are running short of RAM or reading enough data to overfill the cache, a second read of the same file comes from the cache not the hard disk. Until you reboot or wait long enough for something else to fill the cache, a second load of the same files will go much faster than the first. This effect may be causing confusing results for you, as the RAM cache will be the same speed as your RAM disk. That is, the RAM disk will cause faster load the first time, but not necessarily on subsequent launches.

Yes, I agree with you. Was my assumption too.
So, there is no real benefit for any of the SU resources to be located in a RAMDisk, you say? Amost all SU activity happens in RAM, once it was launched (exception the autosave) ? There isn't much I/O to the drives during work?

@pedrinalex said:

Do you know mklink ??

I use this combination

RamDisk and mklink.

Yo must made a backup of your information. If you haven't a nonbreak.

Regards

Pedro

Yes, I know. This is how I actually do the symlinks or the junctions (hard-links). I was just saying that I don't fully understand the mechanism behind this, to be able to decide which is best for this particular situation.

And as i said in my post:

1. I already set up a 3GB RAMDisk
2. RAMDisk is set to save image on shutdown

The issue is now to know which files are using the most I/O on my drives, which could benefit of the fast access.

I tried with plugins folder, assuming that it takes long to parse all of them and interpret before US launches... but from my tests I observed that there was no significant speed-up.
First time when you open SU after windows start it loads slower, but the next runs are almost twice faster. And with the plugins in RAMDisk was exactly the same.

I am thinking to put my Models folder in there, to speed-up the Autosave process. (Of course i won't actually keep my models in there, i suppose...is just to make SU to save in there).

What is your configuration? What do you keep in ramdisk ? Does really improve your SU speed?

Hy, I'm trying to speed-up a bit SketchUp, especially loading speed by using a RAMDisk. I have configured a RAMDisk of 3GB.

I moved my Plugins Folder on the RAMDisk and I made a symbolic link in its usual place. For some reason, symlink doesn't seem to work. SU loaded with no error, but without plugins too. Smart Copy worked and Symbolic Link Clone also worked (I didn't completely understood the complexity of this mechanism)

With Plugins on my SSD drive, loading time was 11.33s
From RAMDisk, the loading time was 5.88s

Maybe some of you which also tried this, or have better understanding/more experience, could provide more details, some suggestions.

Which files I could also move to RAMDisk, from sketchup, to increase its performance?

EDIT
I forgot to mention that RAMisk is backed-up on shutdown and loaded again on startup... so technically no information is lost (except if BSOD). I am just saying this in the eventuality of negative ideas concerning volatile nature of RAM

EDIT 2
Further testing shown me that is actually no difference if I move plugins on ramdisk... the only speed difference was between first load (after boot) and next loads.. i assume windows keeps those files "at reach" after the first accessing.

So, still open to suggestions if SU could really benefit of a RAMDisk.
Thanks.

@pbacot said:

I didn't think you paid for a version, but subscribed to updates and maintenance for the year.

I don't think people deserve input into a product. Nice when it happens. We can just go elsewhere. On the other hand it doesn't take special interests or particular input to know what needs doing in SketchUp ; like ability to handle weightier models, better rendering (just something like Visualizer integrated--not full rendering). That is, graphic, UI, and performance improvements, which are not use-specific.

Yes, you are right partly... subscribed to updates, so everyone got what they paid for (maintenance releases were always free, if i know right).

But then, if they throw you an extra icon, or just small adjustments and they say "here it is, your updates you subscribed for", makes it right? There shouldn't be any control of at least decent amount of updates you get? There is customer protection for all goods you physically buy, why shouldn't be for software too?

And about customer input, let's see... this forum is the eldest in matter, I would bet here are the best SU specialists you can find, so when you do a niche program (because SU is a niche program - for 3d makers/artists of all kind), you'd better hear what they have to say.
I agree they "don't have to listen", but again, they don't have to have success with it either... is up to them if they choose to listen, or not. But who knows what future will bring?

@jql said:

There was one major thing that made all the difference for people using complex stuff and rendering... 64-bit...

That soothed a lot of criticism but since then all seems to be about sketchup plugins: creating the right enviroment for plugin developers to specialize sketchup.

Quite frankly I can understand why. Sketchup is used by too many people with too many scopes.

What the trimble folks could do is, keep doing that as a side task but select from the stuff all people are needing, no matter what they're doing, and develop that way.

Things that have been suggested here and have been on wishlists forever seem to be pointing there, however and unfortunatelly, it seems those things are being regarded by trimble as utopic.

Sincerelly, the problem is that Sketchup simply works and even if it could be way better than it is, it is still fit for everyone.

Trimble are certainly aware of that.

If I understand correctly what you want to say, is that "Trimble knows best and we should relax and trust the Master".
If is that, I have to disagree. Trimble knows s#it. They only know their pocket. So, why to pay developers to improve sketchup when they can use them in other projects where more money come? And just to have reasons to push a new license, to ask for new money, they just added quickly some changes... which I hardly suspect it took all maybe around one month with testing/debugging and fee weekends. But yey, one week work and some $$$$$ in their account.

How things SHOULD be, would be COMMON SENSE. Yes, I agree that everyone asks for their own scope... and apparently isn't a common request. But in reality there is. Just need to look for it.
Other platforms and websites (weebly) have a very nice system: you can post a number of requests. And you also have a limited number of votes which you can use to vote for other requests. And in time, some of the requests will start to rise above, to reveal the true needs. Is so simple...

I strongly believe that everyone who paid a subscription for this new version should make a claim for refund, because this is really NOT a new version. As it was said earlier in this topic, is merely a Service Pack, a Maintenance version. Which normally would be a free update.