Nice.

And I guess it would be trivial to map skp:// requests into this automagically.

@unknownuser said:

@thomthom said:

Not following you on this one either. It's [ruby on rails] a web-framework. How much would that benefit SketchUp programming?

Ah, but if we dropped[sup:33hprjh2]†[/sup:33hprjh2] window.load for javascript<->ruby communication and used xhrs instead, having a web framework could be really useful! That said, rails (and most frameworks) for that matter might be a bit bloated - given the situation many features would likely never be used. What would likely be better would be to implement something like wsgi or rack and then allow developers to deal with requests appropriately (and hopefully a dominant method/framework will arise, which can then hopefully be made available on the extension warehouse as a requirement/dependency library)

I build a nano-webserver (1k code) into my tech both for debugging (point a browser at it to query stuff) and to better support integrated solutions. You can see an example by running LightUp Player and pointing your browser at http://localhost;8080

It would be straight forward to build a well-known socket into SU for WebKit comms.

Or would it better to finish off their original (not unreasonable) approach of having a skp:// scheme handler?

Adam

@unknownuser said:

Sidenote: I'd still love to see a newer ruby version (1.9.x, 2.x), a complete ruby install dedicated to SketchUp (no external installation required, full library available), and rubygems support (Possiblities: Add a custom named executable to the PATH skpgem install ... or give us a method to get the path of the executable #{Sketchup.GEM_PATH} install ...`` or give us a wrapper Sketchup::Gem.install(...) unless Sketchup::Gem.installed?(...)). Also, a single WebDialog implementation. Use something like WebKit or Gecko so we get the same behavior on both OSX and Windows, as well as some cool new toys (developer kit, HTML5 and CSS3 features, ...)

Yes, moving to 1.9 sound like a good idea. No idea how much internal SU work that would require in that clearly there is a lot of code inside the Ruby part which is handling the bridge to internal SU structures. I did a quick sniff test on 1.9 just now and it didn't leap out at me that it would break existing C++ Extensions.

But again if I were in their shoes, you'd have to ask the question as to what engineering gives greatest bang-for-the-buck. Is Ruby 1.8.6 actually blocking adoption of SU? Probably not, but as you say, it perhaps limits some new uses.

A fundamental problem Team SU need to figure is how you offer flexibility/extensibility while discouraging devs bolting on stuff that compromises performance. Perhaps some Extension Warehouse QA should have some "Performance Gates" that are required to go through?

The other thing I would say, having dealt with thousands of SU users, is that while models are getting much larger, it astonishing the number of users who still hang on to a 6-7 year old laptop with a very low power graphics card. Just investing in a modern computer - and certainly a modern graphics card will have huge effect on SketchUp performance.

FWIW I point my users at this website to compare their card and see how very slow they are compared to even a modestly priced modern card: http://www.videocardbenchmark.net/gpu_list.php

Adam

@chiefwoodworker said:

I am done on this subject. I have gotten this off my chest and I am going to do useful work.

Probably for the best as you haven't actually articulated anything but a few grumbles. You do know, nobody actually develops using the Ruby console.. We use an IDE like Visual Studio or Xcode or Eclipse.

"Integrated with Rails." that's insane! Why would you inflict a molasses-slow, bloated 'experiment' on a CAD package? Why? Just bonkers!

"The Ruby API may be dead in favor of the C++ API. ... I hope I am wrong, but that is the flavor of this release." Nobody has said that, you're just hearing what you wish to hear.

Can I just say "Bonkers" again. Ah, thats off my chest.

cadron: Works completely fine on the Mac.

But no idea why you'd put a plugin in your Material & Components folder !!

Copy the .plugin and .rb to the SU2013 Plugins folder:
/Library/Application Support/SketchUp 2013/SketchUp/Plugins

Adam

At the risk of pointing out the bleedin' obvious.. you have moved all the space navigator plugins to the the SU2013 plugins folder?

Adam

What concretely is it that you were expecting of this release?

What concretely do you think Ruby 2.x is going to give SketchUp?

@jiminy-billy-bob said:

@adamb said:

1. Dramatic changes/additions in APIs are generally a 'Bad Thing' in realworld software engineering. What you want is incremental (ideally backwardly compatible) progression. Think of it from the POV of the developers: having a new API for the latest version fo SketchUp is all fine and dandy, but you have N thousands of people out there on SketchUp 7 and 8 using your stuff. Having to develop multiple execution paths for different versions is a PITA and adds to instability.

I think most people are not complaining about the lack of "dramatic changes", but about basic methods still missing.

The litmus test for me is that I can walk the entire DOM and do.. whatever. Whether its in Ruby or C++. Yes, there are a small number of missing getter methods - Layer Color, Scene ordering - but the amount of gnashing of teeth I've seen posted the last couple of days around SU2013 seems totally out of proportion.

SketchUp is still a great, low-barrier-to-entry platform for modelling.

I'm pretty happy with SketchUp 2013 also. Like Thomthom, I'm not concerned that we didn't see big changes in APIs for two reasons:

1. Dramatic changes/additions in APIs are generally a 'Bad Thing' in realworld software engineering. What you want is incremental (ideally backwardly compatible) progression. Think of it from the POV of the developers: having a new API for the latest version fo SketchUp is all fine and dandy, but you have N thousands of people out there on SketchUp 7 and 8 using your stuff. Having to develop multiple execution paths for different versions is a PITA and adds to instability.

2. Software engineering is like a game of chess in that you have to plan many moves to get from here to there. So we have no insight into what work has been done that is invisible to users - but I'll bet they have been busy. Sure they want to impress their new owners Trimble by willingly add their requests - why the heck wouldn't they!

Adam

Just to lighten the mood a tad, don't make the mistake I did and google for "Rhino Extensions" .

Definitely NSFW!

actually, I don't think you even need atomic structures like semaphores.

All I'm saying is that in your *on_close()*or add_action_callback() methods, just set a flag.

So your (pseudo-) code is:

dlg.show
<wait until your flag has been set by the dialog callbacks>
...

@aerilius said:

Sometimes I want a method to wait until a webdialog is closed to give a return value. But all tries so far have frozen SketchUp and then also the webdialog. (Example usage: unit tests or API methods that don't work with async Proc callbacks)

Can you not just set a semaphore in the closure?

With the new release, we've added a registration-free 3 day demo so you can get a taster of realtime rendering inside SketchUp.

Lots of improvements including:

• support for SketchUp colored edges
• hot-swapping skybox
• improved energy transfer
• per-object backface culling
• improved support for older GPUs

LightUp Registration-free Trial

Enjoy!

Adam

#position_material is quite brittle and will die if you give it anything but clean parameters.

If memory serves, it will explode with either zero-area or degenerate geometry.

Adam

Just tried your model on a Mac here with just Ambient Occlusion and it took around 3 minutes to light.
Is it possible you have some other plugins installed that are interfering with LU in some way?

As to your model, the big featureless floor material is broken up with your lighting, but you may want to apply a texture to it to add visual interest. You see I added a little Fresnel with some Roughness on the floor.

Hi Kathryn,

In general, models built for realtime rendering are built with this in mind from the start. In a SketchUp context, thats not reasonable as folks use SketchUp because you don't have to worry about doing too much of that kind of planning.

So LightUp works very hard behind the scenes to ensure you don't need to change your model for realtime rendering - by doing it for you. Generally this works well however, it is certainly possible you have a model that has hundreds of small parts that are not being optimized automatically as they should.

Broadly, you'll want to use SketchUp Groups / Components at the top-level to organize your model.

Also try running the free plugin "Goldilocks" which can help track down assets you've perhaps dropped in that have wildly unnecessary amounts of detail - I've seen coat pegs in models with more faces than the rest of the entire model!

Lastly, you can contact help@light-up.co.uk if you've got a model that repeatedly shows problems and we'll see what we can track down.

Adam

I guess the docs could be updated to be:

returns true if it is Identity
returns false if its undetermined (ie, it might be)

@thomthom said:

Except testing the transformation to be an identity transformation is faster than iterating over thousands of points applying the transformation.

Sure, if that is your bottleneck. Which it probably isn't.

Adam

But if you apply an Identity, it is, by definition, a transform that changes nothing, so no harm done.

The method may not cover all cases, but its not really wrong either.

The problem, Dan & Thomthom, is floating point precision issues. You can't just compare to an array of 1,0,0,..., because, as you well know, comparing floating point numbers for equality is "A Bad Thing".

And sure, stick the test in #Set, and probably triple the execution time of that method and assume its not called often. And keep in mind its not actually catching all cases because of float precision...

So then you have to look to generate the full orthonormal transform and check it's unit length etc..

We've all been here, walk away. Really.

I gave up using select_tool as it doesn't play well with other plugins.

BTW If you want to know what method selectors are being fired at your Instance that are not implemented, just add:

def respond_to?(msg) result = super puts "unhandled respond_to(#{msg})" unless result result end

So add that to a Tool and see every method invocation you're ignoring!

Its an extremely common optimization to mark transforms that have never been assigned to skip processing. Rather than fiddle around deciding whether a transform "has an effect" based on some epsilon.

So the method is correct but not complete.