Looking ahead to SU 8.

plot-paris · 13 Oct 2009, 10:25

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...

remus · 13 Oct 2009, 11:33

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.

plot-paris · 13 Oct 2009, 17:14

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

brodie · 13 Oct 2009, 18:00

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

BTM · 13 Oct 2009, 19:35

@unknownuser said:

remove ruby support from the free version altogether

Personally, I don't think that would be a good idea.

remus · 13 Oct 2009, 19:43

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?

brodie · 13 Oct 2009, 20:52

@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

remus · 13 Oct 2009, 21:29

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.

Master · 13 Oct 2009, 21:43

@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.

Gruff · 14 Oct 2009, 00:06

[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

ScottPara · 14 Oct 2009, 00:20

Texturing tools (UV unwrap)
Layered textures

The shadow bug can be a killer but I do not see this one being fixed anytime soon.

To be honest I think Google needs to take a look at how well Luxology has done with Modo. Set aside the rendering capabilities of modo and just look at the modeling and texturing. It is a very well rounded program and if very user friendly. I also like the ability to completely customize the UI.

I do not think Sketchup needs to add in a photoreal render solution. Having more than enough integrated or external render options in every price point from free to ridiculous is fine to leave them separate. I would much rather see Google place their efforts into the modeling aspects of the program and not add too much fluff.

Scott

remus · 14 Oct 2009, 06:46

Cheers for explaining gruff, see where your coming from now

as an intermediate solution, tigs 2d tools may be of use: http://forums.sketchucation.com/viewtopic.php?f=180&t=22091

plot-paris · 14 Oct 2009, 09:28

@remus said:

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.

fair point there, remus. absolutely true. the big ones, that really add completely new features to the program are probably better kept in the hands of the ruby coders.

Aerilius · 14 Oct 2009, 19:48

Include "repair broken lines", repair broken polylines, arcs and circles.

I still use many older versions depending on the purpose, especially important: the different collada exporters and the different handling of models on upload to 3d-warehouse.

genma saotome · 15 Oct 2009, 04:07

Global option to toggle on/off the line-break-at-crossings feature that was implemented in version 7.0; I'm still using version 6 because I've got too many older models that rely upon the non-break "feature" of version 6(and earlier).
Much improved UVW features. My models are exported for use in PC games and in that environment performance is highly influenced by the number of individual texture files (fewer being far better). It's really hard to use non-tiling textures in SU right now.

plot-paris · 16 Oct 2009, 09:38

in the material section I would like to see a few additions.

apart from better uv control and layered textures (these would be awesome!)
glossy materials would be really cool. they don't need a lot of rendering power, because they only have to show highlights (unlike reflections, that need a lot of machine power).
another one that would make SU images a far more interesting is roughness of a material. especially with transparent materials you could create frosted glass!

jeff hammond · 17 Oct 2009, 10:18

a simple one that i really wish they'd fix - (or maybe my technique is wrong.. if you have a way of doing this, please share! )

inferencing while rotating doesn't work right.. i feel like i should be able to rotate this cube and have it's corner end up on the line.. can't do it though because i can only rotate in degrees of 0.0 instead of freely.

[flash=640,385:jftx8ijz]http://www.youtube.com/v/q_UIu84_89g&hl=en&fs=1&rel=0&color1=0x2b405b&color2=0x6b8ab6[/flash:jftx8ijz]

remus · 17 Oct 2009, 17:08

Sketchup->model Info->units->angle snapping (turn it off.)

jeff hammond · 17 Oct 2009, 18:12

oh man, i was so hoping that was going to do the trick but nah.

i have my angle snapping at 15⁰ so i don't think that's going to matter anyway.

likewise, i have my line snap set to 1/2" but i can still inference to an infinite amount of points regardless of the length my line will end up (it could be 30 27/1024" for instance)..

i dunno, try a quick drawing like i've shown in the video and you'll see that the inferencing system won't grab the line.

remus · 17 Oct 2009, 19:58

Damm. As a crappy workaround you could place a point on the line, but its not the same as being able to infer straight on the line goes in search of feature requests