SU 9 Wishlist
-
@3rdeye said:
I don´t know if anyone already posted one of the following, anyway (i´m almost sure someone has):
- 64 bit
- Multiprocessor support
- UV mapping tools
You're right- these requests are frequently made, though they are usually masking other more general requests. I've discussed them in detail several times in our Help Forums. Here are a few links you might wish to review:
64-bit: "Google SketchUp Questions and Ideas: 64-bit version of SketchUp" and Make a 64 bit version for XP and 7
Multiprocessor support: Google SketchUp Questions and Ideas: Multithreaded version of SketchUp
UV mapping tools: Google SketchUp Questions and Ideas: Improve Texturing Tools
john
. -
There is to my mind one major SU task that can really take advantage of a MultiCore processor.
Autosave / Manual Save.
This is a memory read and Disk I/O process which I expect would be independent from the edit and rendering processes. The AutoSave function consumes a lot of time with large files, and is very disruptive to the train of thought when drawing, but is indispensable, and should happen more often than most people set it to. Passing this function off to a 2nd core would make any delay almost unnoticeable.
Now, how do you handle the ongoing edits/drawings during this save period, where the save function may or may not yet have read the memory locations being edited? That's the conundrum. 2 possible solutions..
1 - Well, that's what the Undo/Redo stack is all about. The 2nd core can post-save interrogate the stack to see if the save function has recorded the changes. If it has, go back to sleep, if not, append the file for the next save.
2 - Have the 2nd core copy the memory image to another area of unused memory, then do the save from that memory. In terms of memory management that would be no different than a user having to wait out a long save function before the cursor is released. The memory swap would be almost unnoticeable, and maybe even justify using 64bit ops to do just that.
I still maintain that saving the Undo stack appended to the last full save is a faster way to autosave.
-
I got a big wish here!!! I love new tools and other stuff, but they take a lot of space in the view. My idea is to allow sketchup view to be set full screen. I want to toggle it with one button, or some command. Ex: press F11 to set view full screen, hide the toolbars, and menus, and if click it again set the view back to standard position. I think I'm not the one who likes it, I think everyone else who read the wish would love it.
Hope that wish comes true, or something like that. -
I keep my toolbars along the top (2 rows) left side (double wide) and 1 row on the bottom of my screen.
I have a bit of room on the left for a few more icons I may need later.I also keep 4 dialogs open along the top of the screen just below the toolbars, Components, Materials, Entity Info and Layers. Comps and Mats are minimized until I use them, Entity and Layers are always maxed, in fact layers are at full length, as these 2 are used constantly. All that real estate takes about 1/2 the total screen area leaving me a smaller square as my work space. I even have my Windows XP toolbar at screen bottom minimized for a bit more work space. It rises up when by cursor hits screen bottom edge.
However, as Anton_S stated correctly, this does take a lot of space away from drawing, and there is no way I know of to toggle hide the toolbars with a single keystroke/shortcut, and I wish there was. There is a toggle for the dialogs, <Window><Hide/Show Dialogs> which is now a shortcut key
-
I don't know if it has been discussed yet or not, but simple arithmetic operations in VCB should be allowed.
Now, only working operation is division.
If you draw a line and input 1000/2 it will draw a 500 length line. But, if you try 1000*3 or 1000-10 or 500+500, it won't work. -
-
@unknownuser said:
I don't know if it has been discussed yet or not, but simple arithmetic operations in VCB should be allowed.
Now, only working operation is division.
If you draw a line and input 1000/2 it will draw a 500 length line. But, if you try 1000*3 or 1000-10 or 500+500, it won't work.This would be earth shattering. It would turn the "modeling by scaled component 'proxy' process" on its head.
-
Maybe they should optimize the core code, to stop that flickering of main window when restoring it from minimized, sometimes. Also that repeated refresh of Outliner, slow response on deleting materials... but most of all, that flickering and repeated "reloading" or "refreshing" ...i am not even sure what is happening there. I know just is annoying and sometimes it takes long for SketchUp window to be active again (especially when I have a large model opened, or rendering...).
-
@unknownuser said:
Maybe they should optimize the core code, to stop that flickering of main window .... and sometimes it takes long for SketchUp window to be active again (especially when I have a large model opened, or rendering...).
Me thinks that is a GPU/CPU artifact with your PC, not SU code. Maybe your GPU memory is not big enough (you need a minimum of 512mb for SU to operate smoothly) or your PC uses an on-board GPU and shared main memory for GPU functions. You may be able to check if this is true by turning off hardware acceleration to see if that factors in. I would not leave it off as that really slows things down. And if you do have shared memory, try turning off all unnecessary background applications when running SU. SU can use all the memory available, but needs at least 1gb to run smoothly.
On my PC, when coming out of "sleep" my SU active working area stays black for as long as 15 seconds, while the toolbars etc. come up fast. This did not happen on my older PC with a different GPU but same version of SU. I do not see any flickering either, at any change of state, nor did I on the old PC.
My old PC had 1gb main ram, and a 512mb ATI GPU. My current PC has 4gb ram and a 1gb NVIDIA GPU. It is dramatically faster and smoother, but the image quality is not quite as nice as the old ATI card.
-
I think SkechUcation is simply indispensable to any SU user, far more than the Models Warehouse or Google Earth. Those you can get to directly from within SU by their own toolbar Icon or menu item.
What would be nice is an Icon to get to SketchUcation directly from within SU, but as a bonus allow the direct share of the model being worked on to ferret out problems.
Make it part of the "Help" subset via "F1".I don't mean an auto upload of the whole model, that may be impractical, but it could be an option for smaller or non-proprietary models.
At least (multiple) screenshots should be directly uploadable, again as an option. That way a user could both explain and show exactly the error message or drawing problem as it happens, and from different angles in real time.
This would save valuable time and effort trying to explain a problem after the fact, or having to prepare the file (for various reasons) or photo exports to upload.
I realize SketchUcation is NOT part of the Google universe, so some reluctance will be expected.
However Google does have its own SU BBS, so they could go there as the default, but allow an alternate BBS (SketchUcation) as well. -
What I'd like to see is an option for automatically downsizing imported texture images.
Basically just a sort of function that would show you all of the images in your file with resolutions and how much memory they take. Then you could say you want a max dimension of 1000px with a jpg compression of 6 and it would run all of your images through a filter making sure they meet the dimension requirement and compressing the file.
Maybe you could even set a memory requirement as well and SU could decide what it thinks is the best way to get down to that requirement.
Currently I have to export the whole 3d model to a .kmz, change that to a .zip, and open it up just to see if I have any big textures. And if I do, I have to scrounge around through materials until I finally find those textures, then send it to open up in SU, downsize it, save it and do the same for the other textures that are too large. That's a lot of manual labor that could be automated.
-Brodie
-
@jgb said:
Me thinks that is a GPU/CPU artifact with your PC, not SU code. Maybe your GPU memory is not big enough (you need a minimum of 512mb for SU to operate smoothly)
On my PC, when coming out of "sleep" my SU active working area stays black for as long as 15 seconds, while the toolbars etc. come up fast.
Mine doesn't stay black but flickers ... like I would minimize and maximize it very fast and it's white. The toolbars appera last ones. And menu windows (materials, components, entity info, and so on) flicker as well, like I would select and deselect them very fast.
Is this behavior caused by not enough video RAM? -
@unknownuser said:
@jgb said:
Me thinks that is a GPU/CPU artifact with your PC, not SU code. Maybe your GPU memory is not big enough (you need a minimum of 512mb for SU to operate smoothly)
On my PC, when coming out of "sleep" my SU active working area stays black for as long as 15 seconds, while the toolbars etc. come up fast.
Mine doesn't stay black but flickers ... like I would minimize and maximize it very fast and it's white. The toolbars appera last ones. And menu windows (materials, components, entity info, and so on) flicker as well, like I would select and deselect them very fast.
Is this behavior caused by not enough video RAM?This flickering gets worse if your registry is filled with deadweight toolbar settings. Some times SU gets the toolbar settings messed up and end up creating more and more registry items. It seems to get worse as you restore and save positions once you gotten a few invalid entries. I ended up with about 2000 entries at one point. And I only had a few toolbars. But it caused the SU window to flicker and drag to a slow crawling snail. See this thread: http://forums.sketchucation.com/viewtopic.php?f=15&t=37990&p=335586#p335586
-
I have a simple one...
Please allow the hidden edges to be given a thickness in the style settings as with the profile lines.
When exporting large images the thin default setting and small dash scale given to the hidden edges makes them almost invisible...That's all for now...
-
Don't know if anyone's suggested this, but grouping layers.
eg I could put all "Frame-Left-Assembly-01, 02, 03" Layers under "Left Side Framing"
you know like we do in Photoshop, where you can group layers together
-
-
native sub-D modeling with quads
-
snap toggle (on/off)
(and - as usual - better texturing/unwrapping features, multicore support, faster save times or save in background, fixed toolbars)
-
-
@khai said:
Don't know if anyone's suggested this, but grouping layers.
eg I could put all "Frame-Left-Assembly-01, 02, 03" Layers under "Left Side Framing"
you know like we do in Photoshop, where you can group layers together
Have you tried "Layer Manager" rb yet??
Not quite the layer grouping/nesting several users including myself suggested long ago, but pretty good.
-
buy all these plugins and install them for us!!!!!!!
-
@sixingno1 said:
buy all these plugins and install them for us!!!!!!!
wtf ?? you don't know how to copy a file in C:\Program Files\Google\Google Sketchup X\Plugins ??
Any financial investment made by somebody (eg, Google) asks for recovering... maybe a not-so-free Free version of SU
-
@sixingno1 said:
buy all these plugins and install them for us!!!!!!!
Google, like so many other companies with paid creative help have a syndrome called the "NIH Factor" or better known as "Not Invented Here". Almost any "outside" idea cannot possibly be as good as what the paid help came up with.
Witness the countless good ideas made in this forum and in others over the years that are simply ignored or at best feebly explained away. Even the ones that WILL counter some obvious poorly thought out omissions and errors, and even some bugs.So the Ruby magicians fill the void, thank you.
But that being said, and having been in the s/w development game a lot of years (but not recently) there is a valid reason for not just simply incorporating the best externally developed Rubies into SU, aside from the accreditation and compensation issues.
Any large s/w development department has certain written or accepted standards of code structure and documentation, whether good, bad or indifferent, they have to have them. I can state unequivocally none of the external Rubies written follow those standards, mainly because those standards are not publicly known, and more likely, the Ruby magician has his own standards, or quite often, has to deliberately get around some standard that may impede performance or the function needed to make the Ruby work.
So the better part of the reticence to incorporate a really good solution is that the paid creative help have to transform that external code into the acceptable form, and the paid creative help really hate mucking about in somebody else's code. I've been there.
And, the Ruby magician is reluctant to reform his code to the standard, assuming he will be privy to it, because he has better creative fish to fry, and the transformation job is too much like real work, even if he is subsequently paid
and acknowledged for it. 
Advertisement