Frustrated with rubies
-
1: I haven't really experienced this. Other than SU's explode function, if I explode a large model all in one go things tend to choke. If I explode one by one it's faster. ...what gives...
But generally for plugins I've not noted this. Got any examples?2 & 3: Yea, it's hard provide a proper status for plugins which takes time to compute because the SU UI doesn't run separated from the scripts. I don't think there's any workaround for that.
4: Does happen. Though, I've mostly experience this during the development stages of my own plugins. I don't experience many bugsplats while working though. My most frequent bugplat occurs when I close or minimize the SU window.
-
Brodie
I share some of your pain. I guess you are using Vista too? But it doesn't affect all Vista users.For instance I have never been able to get sketchy physics to run and as for crashing or locking up GML texturiser and make-faces are two plug ins I would love to use but can't. there are some others that cause problems too. I have a well specced machine and have uninstalled and reinstalled many times, all to no avail, so now I've just accepted it. I'm positive it is Vista related as I have an xp machine (lower spec) at one of the places I work and everything runs fine on that.
-
I also tend to not download too many rubies. Many that I have downloaded are just for testing, then I rarely use them again. I also find that I can do lots of things rather quickly by hand. But there are definietly rubies I can't live without.
I rarely have bugsplat issues, but maybe thats due to the lack of rubies I use.
Overall, I have very few complaints about using rubies personally. Except that I've seen what happens to people's Plugins and right click menus when they install every ruby they can find
I don't have those issues,Chris
-
Thomthom,
- Hard to say for sure without having done any tests. I wouldn't be surprised if most of the rubies I might put into this category really belong in #2. Watching your SU screen seemingly do nothing for 5 minutes with no progress bar FEELS like a lot longer than if I'd done the same thing even if that took me 10 minutes.
I don't know where this fits in necessarily buy my latest issue is with groupbytexture.rb from Smustard. I've got a large building with about 13 textures that I run the script on. I see it make about 3 different groups (via the outliner) and then it just cranks away and thinks. After about 10 minutes I come to a fork in the road where I have to decide whether I should just let it run (the longer it runs the more time I have invested and the more I lose if I force close to the SU window), or I can close it and try again, or I can close it and try and change some stuff blindly (blindly, because there is no error message to say why it seemingly stopped working) hoping that it'll work better next time. The end result is that I often spend an hour + trying to get the ruby to work instead of just doing things the "hard" way.
That's just the latest example but it's pretty typical of my ruby usage. Mostly what I use now are the few simple ruby's that are useful to me and "just work." PurgeAll, MakeFaces, and JointPushPull are the main 3. I have a few others that I'll use if I'm doing something on a small scale (like flatten or some such thing).
-Brodie
-
Yea, it's frustrating when a plugin is doing heavy work and you can't tell if it has hung or not.
But mind you, close the Outliner when you run plugins that does heavy operations. That thing really slows things down. You can often see it flicker like mad. -
@linea said:
Brodie
I share some of your pain. I guess you are using Vista too? But it doesn't affect all Vista users.I use XP, Vista and Windows7. I experience no difference with SU on the different OS's. And with what you say, it doesn't affect all Vista users, I'd guess it's a hardware/driver problem if there's an unusual high number of crashes.
-
Linea,
I think the Vista vs. XP issue may be dependent on the ruby/scale of model/etc. I actually have 2 computers in adjacent cubicles and have seen similar issues on both. I don't really get a lot of Bugsplats, but usually when they happen it's at the most inopportune moments so they feel weightier.
My main problem may very well be that I'm inpatient. I'm unwilling to sit at my desk for 10 minutes HOPING that something will happen in less time than it would have taken me to do it without a ruby. If there's no progress bar then I get to just stare and hope something's going on. If there IS a progress bar I have to stay diligent, making sure to not click the mouse outside of the SU window else the progress bar goes away and never comes back - but I still have to move the mouse occasionally out of fear that my screen saver should kick on to similar affect. I think if there were a reliable progress bar that would give me a quasi-reliable time estimate (something like the typical Windows progress bar that pops up when you download files) that would probably solve 80% of my issues.
I know that's not something the the ruby programmers can control. I don't really think most of the issues I encounter have much to do with the programmers. It seems more like a SU issue. I'd like to see SU take the time to integrate some of the more used rubies into the program itself or find a way to get a good progress bar.
-Brodie
-
@thomthom said:
But mind you, close the Outliner when you run plugins that does heavy operations. That thing really slows things down. You can often see it flicker like mad.
Exactly! Also, in version 6, there was a version that was released that is NOTORIOUSLY slow with rubies due to the outliner. You might also close the layers window and the layers toolbar if you are doing stuff with layers. I see them flicker a lot too. That mighth help.
Thom, I've noticed the same thing about exploding taking longer when you do it all in one shot. I was thinking to write a ruby that selects everyting to explode and then divides it into chunks to explode it. Maybe it would be faster than SU's built in method. I'm guessing it has something to do with the idea that a single command with 10,000 identical operations will take much longer than 1,000 commands of 100 identical operations. Just a thought.
Chris
-
I'll take your advice on the outliner. I typically don't use the outliner anyway but I often have the layers pallete open. The flip side though is that sometimes the only "progress bar" you have is the blinking layer menu.
-Brodie
-
I'm not a big ruby fan. Some of the early basic scripts are great but I have found those that I have tried recently a little bloated, inconsistent in the way they load, and unpredictable. My modeling skills have improved greatly and so, as has been mentioned, many rubies take longer to set-up and clean-up then my normal manual workflow in many cases.
I am also concerned with the large poly count some use to get simple things done. I used rubies everyday a year ago. I would say my use has dwindled to once a week.
Some of my favorite rubies are more for play than anything else. They don't often get into the work-flow for customer work anymore.
I appreciate the hard work of all who contribute rubies. I believe that it is probably a good idea to purchase your rubies though (from Smustard or equiv). Freebees sometimes come with more than you bargain for in headaches.
-
@chris fullmer said:
Thom, I've noticed the same thing about exploding taking longer when you do it all in one shot. I was thinking to write a ruby that selects everyting to explode and then divides it into chunks to explode it. Maybe it would be faster than SU's built in method. I'm guessing it has something to do with the idea that a single command with 10,000 identical operations will take much longer than 1,000 commands of 100 identical operations. Just a thought.
I've also been contemplating on working on an alternative to the explode. I wanted to try to read the entities in a group/component one by one, then rebuild it in the group's parent and afterwards delete the group.
Back to the topic, it would help so much if SU implemented a proper progress API which gave a UI which didn't lock up and had an cancel button. A neat bonus would be a pause button that would freeze the script's operation. Though, this is something the SU team would have to implement.
Though, I have been theorising on this issue as well. I'm wondering if it would work to pop up a webdialog with a progress bar, or a spinning wheel, which would give indication of work. Of if the webdialog would freeze as well. -
Todd mentioned a while ago that he was planning a massive overhaul for progressbar. I think he said it would include a cancel button, webdialog, and a progressbar that would not lock up. I don't know if he's working on it or not, but there is hope that it might happen.
Chris
-
Brodie,
I understand your frustration with things going slowly. I've never personally experienced #1, and have only seen #4 when developing.
I can tell you, though, that in regards to GroupByTexture, you'd wait at least as long for SU to explode all groups and components if you manually started the procedure as with a ruby script exploding them (though you do save time by not having to manually select and initiate the explode process - I've tested it).
When exploding a large number of high-poly (relatively speaking) groups or components, SU will bog down, period. That's just the nature of the beast.
The lack of feedback is marginally fixable (I can put in status messages), but your #3 item defeats that effort, and that's an internal SU issue that no ruby author can control.
@thomthom said:
Back to the topic, it would help so much if SU implemented a proper progress API which gave a UI which didn't lock up and had an cancel button. A neat bonus would be a pause button that would freeze the script's operation. Though, this is something the SU team would have to implement.
Though, I have been theorising on this issue as well. I'm wondering if it would work to pop up a webdialog with a progress bar, or a spinning wheel, which would give indication of work. Of if the webdialog would freeze as well.I've requested (multiple times) a native Progress Bar for the API. It just hasn't been added.
I've tried webDialog-based PB's and they don't work (at least I haven't gotten one to work, and that with direct Google input). -
@rickw said:
When exploding a large number of high-poly (relatively speaking) groups or components, SU will bog down, period. That's just the nature of the beast.
This is the odd thing. If you manually go through and select each individual and explode the process will be faster.
As for native progressbar API, maybe we should be more vocal about this? Do you know what the team's stand on this is? Do they think it's a non-issue, or are they fully aware of it? I'm wondering if it'd help if we suggested it in the "Way of Coding" thread as well as sending direct feedback. I find this to be a pretty big show stopper and it'd make things much much easier to the users and coders.
-
@unknownuser said:
I've requested (multiple times) a native Progress Bar for the API. It just hasn't been added.
I've tried webDialog-based PB's and they don't work (at least I haven't gotten one to work, and that with direct Google input).Bummer! I had high hopes for a new progressbar.
-
@thomthom said:
@rickw said:
When exploding a large number of high-poly (relatively speaking) groups or components, SU will bog down, period. That's just the nature of the beast.
This is the odd thing. If you manually go through and select each individual and explode the process will be faster.
i've noticed that too and i just checked it out to confirm.. using a grid of spheres:
Edges 157872
Faces 82368
Component Instances 286
Guides 0
Guide Points 0
Groups 26bomb.rb took 45 seconds to blow it up while doing it manually took 20 seconds (and by manually i mean - select all/explode which takes care of the groups and then repeating that to handle the components)
another thing.. on macs, you get the spinning beach ball during the process so you at least know something is happening..
-
@unknownuser said:
bomb.rb took 45 seconds to blow it up while doing it manually took 20 seconds (and by manually i mean - select all/explode which takes care of the groups and then repeating that to handle the components)
Some times, if you have a large model, even selecting multiple items to explode bogs down. But selecting one item one by one completes the task faster than selecting all and exploding. And that's with the overhead of moving the cursor, click(select), rightclick(contextmenu), click(explode).
@unknownuser said:
another thing.. on macs, you get the spinning beach ball during the process so you at least know something is happening..
On XP you have the hourglass in addition to the white screen. On Vista and Windows7 with Aero enabled, the screen doesn't do while and you have just the hourglass. (spinning blue circlethingymajiggy) But in either case, you never know if the script or SU has gone down the drain...
-
Just a note for developers.
I have started looking at wxSU for developing dialogs which ties into the native operating system dialog generation routines. I find Web dialogs a pain having to implement a mixture of ruby and javascript as well as the web page. wxSU is written in ruby so less levels of translation. Dialogs can be flexible with auto resizing of the content. Takes a bit of getting used to though.
Relating to the topic, there is a progress bar dialog in the examples folder "ProgressDialog.RB"
wxSU can be found at http://sourceforge.net/projects/wxsu/
-
@thomthom said:
@unknownuser said:
bomb.rb took 45 seconds to blow it up while doing it manually took 20 seconds (and by manually i mean - select all/explode which takes care of the groups and then repeating that to handle the components)
Some times, if you have a large model, even selecting multiple items to explode bogs down. But selecting one item one by one completes the task faster than selecting all and exploding. And that's with the overhead of moving the cursor, click(select), rightclick(contextmenu), click(explode)
in this case (300+ individual groups/components), i think it would take much longer than either bomb.rb or select all/explode to explode everything one by one..
it does make me curious about what exactly bomb.rb is doing though because it took more than twice the amount of time to explode everything at once compared to doing the groups and components separately... i'm wondering if bomb would be faster if it was set up to do what i did manually.. apparently, if i have groups with components nestled inside, select all will not actually select the components.. only the groups.. exploding the groups first then the components next speeds up the process by 2x+..
regardless, i never have a real .skp with that many groups/components and bomb.rb is an instant process for the models i'm working on.. (well, it does have the confirm dialog that pops up and slows down the process & just like weld.rb, i wish the dialogues wouldn't show up)
-
oh.. and why does the progress bar work well with certain rubies and not others?
joint push/pull for instance has a great progress report.
Advertisement