Thanks for the confirmation Jeff. I did have a couple runs same as yours.

I run makefaces on SU 8 on Windows XP against an 11 x 41 grid of wire frame rectangles. Speed = 0.23 seconds for 451 faces. Not too shabby.

I run SU 8 on Mac 10.5.8 on the same grid (and the same scripts). Speed = 23.48 seconds. 100 times as long. No other processes running, no other scripts even loaded.

Oh, Windows is running on my Mac under VMware Fusion.

Did I miss the memo that SketchUp Ruby performance on a Mac sucks? I've opened a bug report.

Why this works has to be because an Animation runs in its own thread, separate from the thread of the SU UI and Ruby.

It just goes to prove that as we've been screaming for our own (Ruby) thread for 7 years, we really do know why.

There's overhead. Nothing is free. It seems the most overhead is in the Ruby-to-javascript path through execute_script.

I did a sampling of the execution of a do-nothing script to exercise Progressbar 2.0 (merely count to 5000), for a small period of time on my Mac, and the WebCore / Javascript engines in webkit actually appear to be calling compilers and assemblers and linkers internally to prepare the #execute_script calls. Big overhead there. After studying that trace, it convinced me to reduce the traffic between Ruby and Javascript as much as possible, as all those transactions have to be compiled and evaluated. Expensive processing - long code paths. Too bad they can't be cached.

Todd

Two very key and underutilized methods: #nextFrame and #stop.

Progressbar fills in the blanks that #pause and #resume were supposed to address.

Yes, I'm still writing it up. In a nutshell, progressbar is a class that you create an instance of in your tool (nothing new here).

Then, for the new part, you call a new method in progressbar, passing a method reference in your tool, that drives your processing-intensive loop/logic.

Progressbar then performs a callback to your method. Each time your method is called, you'll perform 1 (or "n") iteration of your loop. When you exit your loop and give control back to progressbar, you'll pass the new iteration count to update the progress. Progressbar updates the progress, and calls your method again, and again, and again, until the iteration count reaches the total count you passed when you created the progressbar, and then progressbar returns control to your script, where you can continue processing, start another progressbar, exit, or do whatever.

They'll be other callbacks to your tool for user-initiated events like cancel, stop, start, resume, etc., and you, the developer, will choose what to implement.

That's it - in a nutshell.

It works.

Here's the fun story...

I had a user in France that was running CloseOpens against a MONGO topo. He had to cancel SU after 3 days. He sent me the model and I ran against just a portion of it, and I cancelled SU after >8 hours, and it had not yet registered 1% complete.

So, I rewrote CloseOpens. My >8 hour test case would then run in 18 minutes. I was SO excited! I was doing the happy dance. I went to bed, and then realized I had a bug in my code. So I fixed it. OMG. My script now runs in < 1 minute (yes, over 8 hours down to less than 1 minute - I can't believe it either), and the whole model processed in 46 minutes (that would run for > 3 days with no end in sight).

While my sleeves were still rolled up, I decided to tackle how to interrupt the script while it was running. I figured out a way to combine technologies that would allow the user to start, pause, resume, stop and cancel a script while it was running, and at the same time, allow user interaction with the model (orbit, pan, zoom, select another tool, etc.). It's very slick.

Then, I ported this technique back to Progressbar. The way Progressbar 2.0 sits right now, it's not just "drop and play" to get the new functionality, unfortunately, so yes, existing scripts will have to be changed to use it, if they so choose. The old Progressbar technology will remain available in Progressbar 2.0, so I can just have one solution that works with all scripts. (In other words, if (when) you download the new Progressbar 2.0, and you have existing scripts that use the old Progressbar.rb, they will continue to work the same.)

So, both CloseOpens 2.0 and the Progressbar 2.0 will be released soon. I'm doing the final polishing on both.

Here's what the current development copy of the new CloseOpens 2.0 console looks like.

Here's a shot of the full topo of the lake that my user was trying to work with.

And this is the section I ran against for > 8 hours. The square is about 100m x 100m.

Here's a real close up, showing the massive broken lines. This was created from a raster scan of an image and then run through some vector-izer. The average length of most of those short breaks is about 200mm. (7-8 inches).

Todd

In my tools, I use this:

if !@wd.visible?    # get the dialog back 
	@wd.show()
else 
	@wd.bring_to_front()
end 

I don't do the "start and stop SU" piece, unless I'm working with menu items. If I have a static scene I'm working with, and the script corrupts it, I'll just delete everything in the scene and reload the model. Then, I reload the script, and keep going. (unless of course there are pieces of the script that require restarting SU, like constant definition changes, etc. During development, I'll usually put logic aroud constant definitions (et al) to not re-execute if they are already defined)

Got a model that works differently between the two versions?

Todd

I captioned them this time.

http://web.me.com/toddburch/NewSite/Our_Albums/Pages/3D_Basecamp_2008.html

Todd

Finally found the time (~10 minutes ) to put a web page together with the photos. Enjoy!

Todd

http://web.me.com/toddburch/NewSite/Our_Albums/Pages/3D_Basecamp_2010.html

Hi Dermot - thanks. Looks like this outfit might be able to help you with screens: http://www.millerg.ie/ and if not, perhaps they can tell you where to go.

I created the checkerboard image in SketchUp, and exported to PDF. I emailed the PDF to my screen printer, he printed it on clear film and then made the screen and stretched it over the 26" x 26" frame I made. The film, screen and squeegee came to about $150 US with tax. I used this outfit: http://www.leessupply.com/

My supplier had suggested an enamel ink to use over the milk paint, and when I said I was top coating with lacquer and the enamel would not work, he suggested a lacquer based ink. However, he said it would take several days to cure before I could topcoat. I then decided to just use black milk paint. He had never heard of using milk paint, but figured it might work. It worked great.

In reviewing my technique, I believe I should have had a lower angle when dragging the paint across, and perhaps thinned the paint a bit more too.

Todd

Well, the tables are finished. They'll get delivered next weekend. I ordered 4 chairs today - 2 for each table. Should be in on Wednesday. I've attached a couple photo-montages of the processes. The first is a documented screw-up... but nicely recovered via a "do-over". The second is the finishing and some final pics. In the still photo, the closest table is Salem Red, and table with the chess set is Barn Red. (The chess set is a set I commissioned several years ago from a woodcarver in Albuquerque, New Mexico - Cowboys and Indians)

Just got an order for 2 more... for the Mrs!

Thanks for looking. Todd

Silk screen screw-up
Final photo montage

Hey Phil - missed you at Basecamp.

Well, change in plans. Second table is changing from Salem Red to Barn Red. Already got two coats on it. Now, out to the shop to screen the checkerboard!!! (And, when I got home from basecamp midnight Friday night, my son was already home (surprise to me!). So, delivery will be next weekend.)

@jo-ke said:

@honoluludesktop said:

I imagine the future will be with some form of holographic projection based on 3d modeling.

This was exactly the question I was asking myselfa few days ago. 3D Television is no problem anymore.

Is there any plugin to get an 3D Output of the renders? This would be surely convincing for the customer to see his own future interior in a 3D modell...

We have a Stereo.rb script on Smustard. Perhaps that will help you out.

http://www.smustard.com/script/Stereo

Todd

Very nice!

Thanks everyone.

Yes, I have not been visiting very much. Been busy with life.

Next project: bathroom remodel.

I'm making a couple matching small dining tables. My son just changed colleges (from OU to Texas A&M) and his apartment this year is a little bigger than last year's dorm. But, there's no real place to sit, except the couch, and the only place to set anything is the "coffee table". So, I told him he needed a table, but he didn't think so. His buddy, (buddy since 1st grade), hearing our conversation, said "I want one!" Well, I decided to build 2 tables, and they will be a surprise for both of them. They are identical (for all practical purposes, if you don't consider wood grain itself). First, I drew them in SketchUp:

Then, I scrounged some wood I harvested back in 2001 and started cutting. Came up with these:

I decided to finish them with milk paint. I thought red would look nice. Then, I thought about putting a checkerboard on top. I came up with this:

Each square is just over 2" square. Kinda oversize, but not too big.

I'm not finished with them yet. Friday evening, I pick up the silk screen for the checkerboard pattern from the silk screen guy. Then Saturday, I'll screen the pattern in black milk paint, let that dry, then shoot some lacquer on them to finish them off. Delivery will be Sunday. Here's what they look like as of this afternoon:

They'll darken up some once the lacquer hits them.

The drawer is pretty good size. Almost 18" x 22". From what you normally get for a drawer of a table this size (27" x 27" x 30" tall), the drawer is enormous.

And yes, the dog approves.

I'll post pictures Saturday evening of the "twin" finale! Thanks for looking. Todd

If you are using entities.add_face, the new face created is returned as the result. You can create the face with either lines (edges) or points. No big deal.

To successfully transfer UTF-8 (or any encoding) back and forth from Ruby to a WebDialog, the easiest approach is to convert your characters to printable hex in javascript and pass that back. Then, in Ruby, pack it. Works great. If you search this forum, I believe you'll find some examples.

Todd