SU 9 Wishlist
-
@tfdesign said:
@thomthom said:
I find the zooming over blank space to be too aggressive - too big jump.
Really?? Maybe we're both missing something? Is there a missing variable somewhere, that can change this? Mine is painfully slow.
When you zoom while the mouse if over an entity to goes slower - and I wonder if the speed depends on how close it is to the camera - so when you get closer it goes slower.
Zoom in while the mouse if over empty space and the zoom goes into hyperdrive.
-
Ability to sort and file Plugins!
-
@thomthom said:
@tfdesign said:
@thomthom said:
I find the zooming over blank space to be too aggressive - too big jump.
Really?? Maybe we're both missing something? Is there a missing variable somewhere, that can change this? Mine is painfully slow.
When you zoom while the mouse if over an entity to goes slower - and I wonder if the speed depends on how close it is to the camera - so when you get closer it goes slower.
Zoom in while the mouse if over empty space and the zoom goes into hyperdrive.
Thom, I've just tried again, and I get the problem when I'm zoomed right in (something I do a lot). I can't seem to replicate what you are getting. There however doesn't seem to be a problem for me when I'm zoomed out. I also never use the zoom tool. Always the wheel on my Logitech Trackball Marble.
Tom
-
Yea - I always use the mouse scroll wheel as well.
-
Sketchup 9. I wish to have a set of tab, similar to the scenes tabs, but for layers. This way I could pass my model to co-workers and I could have a set of layer Tabs across the top along with the scene tabs. They could select a scene tab, and then make selections of the layer tabs to add more less to the model in that particular scene. Unlike scenes, where you could only have one tab on at a time, the layer tab you would be able to have more than one on at a time. And the layer tabs could be all the layers or just a select few.
Ken
-
Ken, what would be the difference between that and having the layers manager open?
-
@remus said:
Ken, what would be the difference between that and having the layers manager open?
Well, I model with multiple layers, and I would want only the upper layers, that would be completed parts in the layer tab. To me it would just make it easier to send to people who have a limited knowledge of how Sketchup operates.
Ken
-
I would also like multiple core support.
You can't even buy a computer anymore that does not at least have two cores anyways.
I really would like SU to be able to utilize my machines resources!
And yes, 64 bit please! -
@sir.sanio said:
And yes, 64 bit please!
I think we've already been over this subject enough already. SCF had SketchUp Central here over the last couple of weeks assuring us that apart from rendering (which SU doesn't possess- apart from in plugins- which work independently from SU anyway), a 64 bit boost will achieve very little. Having a dual (or more) processor, believe it or not, has very little influence over speed as well.
-
you can read about it here, if your so inclined: http://forums.sketchucation.com/viewtopic.php?f=15&t=30490
-
The impression I got from the discussion is that the current SU architecture won't benefit from multi-core or X64.
The implication being that SU would have to be rebuilt from the ground up to take advantage of multi-core and X64?
-
@hieru said:
The implication being that SU would have to be rebuilt from the ground up to take advantage of multi-core and X64?
for 64bit yes - for multi-core it's not possible for many of the tasks.
Most of the other modelling packages the claim multi-core support are the ones with render engines and multiple cores are used only for the rendering process. -
In theory could SU be rebuilt so that it uses the CPU for its real-time rendering of models? Or even a CPU & GPU combo?
If so, then presumably multi-core support would be of some benefit and allow for better handling of high poly models?
I don't really understand that much about software, so I'm probably talking a load of nonsense.
-
@hieru said:
In theory could SU be rebuilt so that it uses the CPU for its real-time rendering of models?
In theory - but it'd be a completely different application.
@hieru said:
allow for better handling of high poly models?
Using multi-core for rendering doesn't mean it'll handle more polygons for a smooth navigation in the viewport.
SU renders a sketchy view of the model in real time - as oppose to most other modelling application that reply on some render system. Because of that design difference it can't be directly compared to other apps. SU is a WYSIWYG kind of modeller - most other modelling applications aren't - they diaply simplified proxies of what you get when you eventually render.
Comparison of SU vs Max/Maya etc is an apple vs oranges comparison.
-
@unknownuser said:
In theory - but it'd be a completely different application.
That's what I thought.
@unknownuser said:
SU renders a sketchy view of the model in real time - as oppose to most other modelling application that reply on some render system. Because of that design difference it can't be directly compared to other apps. SU is a WYSIWYG kind of modeller - most other modelling applications aren't
I appreciate that. I was just throwing ideas out there and wondering how SU could be modified to better handle high poly models.
A lot of people seem to think (I know I used to) that moving to 64 bit and multi-core would be a simple measure that would provide a magic bullet to deal with all the demands/requests people have for SU. Since it appears that this isn't the case, it does beg the question, how exactly can SU be changed to greatly improve performance? Is it even possible without starting again from scratch?
More importantly, would all the things we love about SU go out the window if the entire focus of redevelopment focused on better performance with high poly models etc?
-
@tfdesign said:
@sir.sanio said:
And yes, 64 bit please!
I think we've already been over this subject enough already. SCF had SketchUp Central here over the last couple of weeks assuring us that apart from rendering (which SU doesn't possess- apart from in plugins- which work independently from SU anyway), a 64 bit boost will achieve very little. Having a dual (or more) processor, believe it or not, has very little influence over speed as well.
Thanks for bashing my wishes.
I disagree with you, having built massive models which would have profited from more processing power and ram. They still tend to crash a lot. Lack of ram also prohibits me from exporting any still image above a 7000 pixel resolution, even though the magical number of 10000 appears in the export dialog.
Disagreements aside, this is a wish list, i can wish for whatever i want.
So beside 64bit, multiple processor support and the obligatory pony, i also wish for a time counter that tells me how much time i have spent on the model.Best regards,
sanio -
It's not bashing - but there's been extended discussions on this topic. 64bit isn't a magic bullet and multi-core simply isn't possible for most tasks. Most modelling applications that state they have multi-core support only do so in their render engine. The actual modelling process doesn't.
However - requesting being able to export larger images and faster is a perfectly good one. But the assumption that 64bit or multi-core is the technical means to achieve this is not. That is best left up for the developers to decide how to achieve it.
@sir.sanio said:
i also wish for a time counter that tells me how much time i have spent on the model.
I believe I've seen this mentioned at the forum - should be a plugin somewhere.
-
@unknownuser said:
I believe I've seen this mentioned at the forum - should be a plugin somewhere.
Thanks, found it!
-
@tfdesign said:
Oh yes, fix the bl**dy layers management!! Why is it that within a grouped object, several entities can co-exist on different layers all at the same time? This is utterly crazy! I can understand for whole objects, but single little things? It's silly. Perhaps I'm missing something here?
You ARE missing something here. I use the ability to assign multiple objects (groups or comps) to separate layers all within a grouping on a top level. That way I can control the visibility of any one object, or ALL the objects at once by turning on/off any specific layer. As long as all the raw geometry of any object remains on layer 0, this is an effective tool.
For example; my big airplane project has an internal elevator that uses a pair of telescoping control arms rather than rails to get around some immovable structures. In order to see the various positions and fix any interferences, I have a top layer assigned to the overall elevator (see layer list below). That way I can turn on or off the entire elevator as needed. Then I have a sub layer at the top, a few interim layers for transitional positions and a layer at the bottom. Now I can see the elevator descend/ascend at each transition position, comparatively or independently, or in a scene animation.
Layer management......
6.00 Elevator (note: All layers below are within this master group)
6.01___At Top (note: Each transition group contains 1 copy of all the elevators components)
6.02___Trans 1
6.03___Trans 2
:
:
:
6.09___Trans 9
6.10___At Bottom
6.20 Elevator box (note: There are 10 copies of these comps positioned at their respective transition points and within a transition group)
6.30 Control Arms
6.40 Drive Mechanism
etc......This may seem cumbersome, and at times it really is, but since SU does not have a native animation capability (joint linkage, fine control and positioning) this is the only workable simple solution I can come up with.
-
@tfdesign said:
My wish for 9 is that the mouse zooming is just as effective over blank space as it is over a space that contains vector information (solid). It drives me crazy sometimes trying to zoom like mad, and just not to get very far.
Anyone else suffer from this? (Or has TIG made a plugin to remedy the situation?)
I've been bitching about this for 3 years now and nary a step has been taken in V7, V8 and probably in V15 to correct it. This hyperzoom drives me nuts when I am in close and working on lines rather than faces. It ain't easy to keep the cursor on a line while wheeling in or out or panning. Then it's "To the moon, Alice!" and the air around me turns blue.
There is an easy fix to the zoom s/w module. While panning/zooming ON an object is immediately followed by a pan/zoom OFF the same object but still "nearby"; MAINTAIN THE SAME PAN/ZOOM RATE. The pan/zoom rate hold is released if the cursor is placed over any other object, or is moved some distance away from the held object, or (say) 2 seconds pass between zoom actions.
But the SU devel.team seems far more consumed with new bells and whistles than fixing problems bitched about by solid users.
Advertisement