Looking ahead to SU 8.
-
@remus said:
Sorry, i meant number 3
remus, it only works to an extent.
if i'm trying to enter a fraction, it will only work if it's for my default unit (in my case: architectural/inches)
i can enter 48/9 in the vcb and will end up with a line at ~5 5/16"
i can't however make a line 5-4" using the same method unless i switch my units to decimal/feet which will leave me with a line of 5.333' (but then i can't do inches now)i'd be nice, as jean suggests, to be able to enter 6 1/2' in the vcb and have a line drawn at 78".. (6 1/2' may be a bad example because it's an easy enough fraction to simply convert to 6.5' which will be accepted)
further, i'd like to be able to enter 6*24 3/8 (or something similar) instead of drawing a line at 24 3/8 then copy/move 6x or resorting to a separate calculator..
-
about the new cutting capabilities... some sort of 'live booleans' would be fantastic. and, as Gaieus suggested, with the capability of cutting through nested groups. although this might take a lot of processing power and may slow down SU a fair bit.
-
Since this hole cutting feature does not really cut the geometry, only adds some sort of visual effect to SU, I could imagine that to cut through nested geometry wouldn't add considerable processing task. (And let's face it, although Eugenio's wish to cut several faces, too, would alsobe cool, most people would use it "simply" for windows with two faces to cut only).
-
Hi Remus, hi folks.
Sorry, my example was badly choosen since, of course, the Line Tool, the Circle Tool, the Arc Tool, the Polygon Tool and even the rectangle Tool allow a division in the "Dimension box" DB.
I should have elaborated more.
What I have in my mind is a complete set of mathematical operators like + - * / in the "Dimension box" while entering any value, be it linear or angular to allow multiplication, addition and sutraction in supplement to division.
For example, when entering a dimension for a rectangle you could enter 1000;500+320 to get a rectangle with dimensions of 1000 x 820.
Some person will tel me : why not enter the final dimensions first. To that I will answer : suppose that a carpenter is told to draw a desk that must accomodate two drawers of 24 1/2 inches by 6 inches with a spacing of 2 3/8 inches between then and with a border of 1 3/4 inches outside each of the drawers. The heigth of the desk being 32 inches.
Of course, one can simply draw a large rectangle of 32 by, say, 60 inches and position the drawers using guides and then adjust the final width. In this process, all these dimensions will need to be imputed in the DB to obtain the drawers and then to position the required guides.
It could be simpler to enter :
24 1/2+24 1/2+1 3/4+1 3/4 +2 3/8;32
or even better:
2*(24 1/2)+2*(1 3/4)+2 3/8;32
Maybe this is too complex and would require a very good string parser for the DB and then a complete mathematical engine able to sort parentheses and the operators precedence if I was to omit the parentheses, etc.
OK, forget it and lets focus on more important demands.
Just ideas.
-
@jean lemire said:
What I have in my mind is a complete set of mathematical operators like + - * / in the "Dimension box" while entering any value, be it linear or angular to allow multiplication, addition and sutraction in supplement to division.
For example, when entering a dimension for a rectangle you could enter 1000;500+320 to get a rectangle with dimensions of 1000 x 820.
Jean,
Obviously we cannot alter the native SU tools.
However, some of my scripts supports formulas, in the VCB and in the dialog boxes. For instance ToolsOnSurface 1.5, Roundcorner and FredoScale. They also accept indifferently the dot or comma as decimal separator, irrespective of your language settings. For length, you can specifiy the units, irrespective of your current model units (for instance "33.5cm" or "4.5mile". In TOS 1.5, I also introduced the support of angle units, with postfix 'd' for degree, 'g' for grade, 'r' for radians and '%' for slope.
I fully agree that SU should provide this in native versions (especially the comma / dot support)
Fredo
-
I think it would be very usefull a revision of the "Cut openings" option inside components.
Every one can feel the restriction of cutting just one face.
There are many workarounds but the problem of inserting a component window into a 2 sided wall is still there.
That would come in handy expecially if you need to move and adjust your openings inside a facade project.
Or just think how many times you need to put an elevator tube inside your building. Would be great if you wouldn't have to make cuts on every storey, even because just after a couple of days you might realize that its position is needed to be modified...
That is the same with columns, staircases, and so on...The idea is to put a component that create just the right openings in the model.
Could be done setting some cutting options directly on the faces of the component, through the Entity Info palette.
Here below I've done some examples that show how can be done.What's your opinion about that?
-
-
Explode tool made into three options.
a) Explode as it is today
b) Explode groups but do as today but do not explode Arcs, Circles or Curves
c) Explode only selected Arcs, Circles or Curves -
Construction Planes
a) Various methods to create them.
b) Ability to show/hide/delete them.
b) Some method to lock/unlock the drawing tools to them. -
Ability to load a Ruby script from the command line when starting SketchUp.
-
-
@gruff said:
- Explode tool made into three options.
a) Explode as it is today
b) Explode groups but do as today but do not explode Arcs, Circles or Curves
c) Explode only selected Arcs, Circles or Curves
Exploding shouldnt explode arcs, circles etc. Chances are they were already exploded before you exploded your group. You can already explode selected arcs/circles/polylines by right clicking them->explode curve.
@unknownuser said:
- Construction Planes
a) Various methods to create them.
b) Ability to show/hide/delete them.
b) Some method to lock/unlock the drawing tools to them.
When you say 'various methods to create them,' could you be more specific?
You can already show/hide/delete section planes, all done through the right click menu.
@unknownuser said:
- Ability to load a Ruby script from the command line when starting SketchUp.
Already possible, although i dont do it often enough to remember the code.
- Explode tool made into three options.
-
I believe you open the ruby console and it's
load 'weld.rb'
-Brodie
-
@remus said:
You can already show/hide/delete section planes, all done through the right click menu.
remus, I think gruff ment 'construction planes' as opposed to 'section planes', similar to construction lines but only as planes
although I would find it only mildly useful, for most of it can be achieved already, simply by holding down shift (eg. hover with the circle tool over a plane and then hold down shift. it will keep the orientation of the plane, no matter where you go). but on the other hand, having the option to employ construction planes wouldn't hurt either...
what I would really like to see is an option to switch the axes' orientation from 'world' to 'object'.
meaning, that if you enter a group or component that is at an angle to the world axes, all the inferencing, rectangle tool, outline orientation of newly created groups etc. are alligned to the axes of the group/component instead of to the world axes... -
sorry gruff, completely misread that
-
I also like calculations in the measurements box.
The scale tool and measurements box can do something like '5' = five times as large, or '10m' = 10m long, but not yet '+2m' = 2m longer as it is.
This is very useful when we have a fraction number or a irrational number as current length. I tried it already to make Sketchup show dimensions with maximum precision, calculate with this precision and then type it in the measurements box. This way, lines will never snap.
In some threads I read also the idea of a "smooth selection" for making smooth tools. Just like it is standard in 2d-graphic editors. Most of the existing tools could be much more universal, especially for organic modeling. Imagine you scale or move a smooth selection: the faces/points in the selection's border area will only undergo a fractional amount of this transformation. This would allow great possibilities for ruby developers.
@plot-paris: modifiers
This would be a great (SU only) feature, when exporting to another format, it could be necessary to apply the modifiers irreversibly (make unique components...). A subdivide modifier could easily be changed for creating a high-poly or low-poly version of the model!!! Currently, I can achieve this only with intelligent component usage and modifying the geometry inside components by hand. -
Key-frame animation would be amazing.
-
@linea said:
Above all else I would like to see Google buying shed loads of all the plugins out there, polishing them and incorporating them properly into the core product. No need to reinvent the wheel.
I agree with you to a certain extend. not all tools make sense to be implemented into the core SketchUp. but there are many tools that are so native to my workflow now (and surely I am not the only one) that it would make perfect sense to incorporate them.
just take 'select instances' (lets you select all copies of one component just with one click) or Chris' 'arc centerpoint finder'. these are already native tools to me. and when I work on another machine thad doesn't have these scripts, I feel utterly crippled in my workflow.
I would like to think of it as a great 'open beta area'. all the plugins are being thoroughly tested and developed by the community and the ruby master minds. once it becomes clear, that one script is extremely useful to the majority of SU users, Google could really buy the plugin from it's creator, and properly implement it. it doesn't have to be all the plugins (there are far too many)
but take as an example fredo's on surface tools, paired with joint push pull (which is sort of a ':pushpull:-on surface'). Google could buy these plugins (and fredo would at last be properly rewarded for his hard work (appart from the gratitude and worship from thousands of members)). and by properly implementing it into the SU user interface, they could create one toggle-button to swich from 'normal mode' to 'on surface mode', making all the native drawing tools work 'on surface'. thus you only had one more button added to the UI, instead o a whole new set of drawing tools...
so in some cases, the implementation of a plugin would make SketchUp a lot more powerful, while keeping it's simple and easy workflow...
-
I can see where your coming from with plugins like arc centre point finder, but i think including tools like jpp and tos as standard would seriously hinder a new users ability to learn how SU (and polygon modellers in general) work, and thus hinder the ability of users to produce good, usable models.
Having said that, in the right hands these tools are extremely useful and can save a huge amount of time and effort. They can also create a truly horrible mess if used in the wrong situation and i think that is something that should be avoided at all costs.
-
ok, what about a compromise then: Google buys these plugins (the ruby masters will be happy). they pollish them up and implement them into SketchUp. and then they disable them by default, like with the sandbox tools. thus a new user wouldn't even know they are there. but more experienced users only had to enable these perfectly integrated tools via preferences>extensions...
like that both interests will be secured, the simplicity for beginners and the power for pros -
I've always been in favor of a bigger gap between the free and pro versions. In particular the pro version should have a lot more tools geared towards pros in it and the free version should be basically how it is now. In that vein if I were Google I'd buy up a bunch of rubies, remove ruby support from the free version altogether, and integrate the purchased rubies into SU Pro. It'd push many people who are power SU users but simply don't need to pay $500 for a couple exporters (a la SU Pro) to take the plunge. Google could use that money to further develop both the free and Pro versions.
To compensate for the lack of ruby support for the free version though, I feel they'd probably need to clean up a lot of the issues that still exist (tool bar issues, progress bar, etc) as well as incorporate some of the most basic rubies functionality into the free version (weld, purge, etc).
-Brodie
-
@unknownuser said:
remove ruby support from the free version altogether
Personally, I don't think that would be a good idea.
-
Indeed, it would decrease the usability of the free version to the point that it is essentially useless for getting anything done, and would thus force huge number of users to switch. And losing large portions of the user base isnt a good thing in my opinion.
jakob, what would happen with upgrades to the plugin? who would be tasked with going through the code? itd be a monster job and one thats better left to plugin developers themselves, in my opinion.
Personally i think whats needed is a better way of downloading and accessing scripts, theres plenty of them out there most of which are readily maintained by willing authors, so why go to the trouble of devoting precious resources to redoing whats already been done and what already works. Basically the point im trying to make is why should google take on these plugins when they already exist in a very usable fashion at the moment. What would be gained?
-
@remus said:
Indeed, it would decrease the usability of the free version to the point that it is essentially useless for getting anything done, and would thus force huge number of users to switch. And losing large portions of the user base isnt a good thing in my opinion.
jakob, what would happen with upgrades to the plugin? who would be tasked with going through the code? itd be a monster job and one thats better left to plugin developers themselves, in my opinion.
Personally i think whats needed is a better way of downloading and accessing scripts, theres plenty of them out there most of which are readily maintained by willing authors, so why go to the trouble of devoting precious resources to redoing whats already been done and what already works. Basically the point im trying to make is why should google take on these plugins when they already exist in a very usable fashion at the moment. What would be gained?
I disagree that without rubies SU is essentially useless for getting anything done. There are people on this very forum who don't use rubies and produce very good work whether it simply starts and ends with SU or even for renderings (I seem to recall that Richard doesn't really use any rubies. correct me if I'm mistaken). I think SU on it's own is quite a powerful tool actually. As I mentioned perhaps there are a couple rubies that should have been integrated with SU long ago and should be in the free version but I don't think there are many. If you NEED jpp, subdivide and smooth, copy along path, etc. you're probably the type of user that would get there $500 worth out of buying SU Pro.
As for what would be gained by integrating the rubies into SU, I'd say there would be stability improvements and UI improvements. SU almost never crashes for me unless it's because of a ruby. And integrating rubies into the UI has long been a headache. Perhaps that's something that could be fixed without direct integration but I think more integration is always better and tends to be more streamlined.
-Brodie
Advertisement