Looking ahead to SU 8.
-
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
-
I agree it is possible to work without rubys, it is certainly not an efficient way of working though. To be frank i think the power of SU lies in rubys and by forcing people to shell out $500 for that power your going to seriously slim down the number of people who use SU. Its also worth noting that it would be impossible to render anything beyond the straight SU output without the ruby api.
I dont agree that large stability improvements would be made by integrating some plugins in to SU, as any instability is most likely the cause of a wayward bit of the api and as such should be addressed whether or not it is being used by an 'official' ruby.
I also dont agree there would be much in the way of UI improvements. The main problems at the moment (from my point of view, at least) is sheer overcrowding of menus and toolbars. This wouldnt be fixed by internalising the better ruby scripts.
-
@numerobis said:
-
64 bit!!!
-
multi core support! ...the GHz race is over - now we're on the core track (for several years already). or what should we do with the other 31 cores sketchup doesn't use next year?!?
-
better texturing tools!
-
better file handling - it's really annoying to have 200mb files that need 5 minutes to load or save... 3dsmax can do it within a few seconds
Those are pretty much the only things I look forward to. Everything else is fluff IMHO.
-
-
[quote="plot-paris"][remus, I think gruff ment 'construction planes' as opposed to 'section planes', similar to construction lines but only as planes
I've been in solid modeling for many years.
The biggest pain I have with Sketchup is the fact that think you have drawn a flat sketch but when you rotate the model parts of your sketch fly off in z or other directions.
By construction Plane I mean a see through plane you define in space that you may draw 2D entities upon similar to drawing on a model face. They would need a toggle to lock/unlock the 2D sketch tools to them. infered snap points from the model would be projected to the plane.
Redefining the 3D Axis in Sketchup sort of gets you there except it doesn lock you to the plane.
Construction plane creation
- Parallel at a distance. (Similar to push/pull but without the join)
- Angled from (Select an face or plane an axis to rotate about.)
- Three point
- Line and a point
- two lines
Advertisement