@alpro said:
Any chance of making it a seperate commercial ruby?
Mike
Sure. I'll need to get some feedback from LightUp users first - and get the next version out too! But after that, I don't see why not.
Adam
@alpro said:
Any chance of making it a seperate commercial ruby?
Mike
Sure. I'll need to get some feedback from LightUp users first - and get the next version out too! But after that, I don't see why not.
Adam
I'm guessing that these plugins are registering onOpenModel() observers that are doing significant work - which isn't a brilliant engineering decision.
Would be interesting to know what exactly they're doing.
Adam
These are very tough to track down.
It sounds like stale data. Classic one is referencing duff data as SU tears down the parts hierarchy of a model. My general rule is never hang on to references; I know you've been digging deep into Observers recently.
Adam
[BTW What you building in there!]
Thanks.
No, its part of that glorious LightUp plugin..
I think kwistenbiebel's toptip about not going nuts with nesting is a good one. Not particularly from a technical standpoint - there is no reason why a 3 nested model works but a 5 nested does not - but because its deceptive just how much geometry you're generating by adding a top level with many nested parts.
One thing I added to my stuff is a Context (right-click) menu that will flip any component to a bounding box proxy component. So you can select your toplevel nested components and flip them into box proxies for positioning and fast navigation but they get rendered using the original geometry. The flip is pretty much instant (unlike exploding) so it doesn't break the workflow.
So if I highlight all my top level complex nested components, it looks like this:
Then I can orbit/navigate really fast using simple proxies
And to flip back to the original geometry
Adam
Here you go. Put this in your Plugins folder and restart SU.
Now you can right click over a Group and either Set the file to link to, or Open an already set link.
Enjoy,
Adam
Not on my WinXP laptop. Just crashes.
@whaat said:
@adamb said:
Ha. I find totally the opposite so in LightUp I have to do:
UI.openURL("file;//" + File.expand_path(filepath)) if filepath and not(PLATFORM.include? "mswin")
> >
So this works to open an App or file on a Mac? (I can't test right now)
OK, it looks like PC just can't handle being given a scheme handler. If you just give the path on PC it works fine. On the Mac, it (correctly in my book) expects a scheme handler for the URL.
Adam
A good little learning exercise for the Tool protocol, is to see what messages SU tries to fire at it.
Add this to your class to log whenever SU queries your Tool instance to check its capabilities. You'll be surprised how much querying goes on!
def respond_to?(msg)
result = super
puts "unhandled respond_to(#{msg})" unless result
result
end
On a Mac they live in
Macintosh HD:: /Library/Application Support/Google SketchUp 7/SketchUp/plugins
(ie not from your Home folder)
[Slightly OT]
I've always been very careful to use Object#kind_of? rather than Object#class so that code works with any derived classes too. (Rather than just testing for an explicit class).
Good idea? Bad idea?
Adam
Ha. I find totally the opposite so in LightUp I have to do:
UI.openURL("file;//" + File.expand_path(filepath)) if filepath and not(PLATFORM.include? "mswin")
On (my test) PC, it just crashes.
Un*x systems have very flexible 'batch files'. They can be arbitrary languages too but adding a line at the beginning of the batch file. Starting with:
#!/bin/bash
means run this batch file using this flavor of shell (aka Cmd.exe in Win32)
So I saw this thread and spend half an hour playing with building a WebDialog progress bar.
What I planned to do was have a Javascript driven animated progress bar and a simple call from Ruby to update the percentage.
The html/js is trivial but I came unstuck because the WebDialog stops when Ruby runs. Now I don't understand because I supposed that the browser would be running in separate native thread.
Somebody mentioned they'd experimented earlier with this and failed. Was this the same issue?
Adam
Can you not just keep a reference to the dictionary and twiddle key-value pairs without calling set_attribute?
Yes, I believe it does. I've spent weeks trying to track some crash bugs for LightUp users that appear to be directly related to having wxSU loaded.
The most simple case I found was having wxSU installed and typing "sleep 10" at the console for a crash with some plugins that use it.
Today I've been talking on email with Peter (author of wxSU) and he's on the case - so lets hope it can be fixed asap.
Adam
The basic technique is to have the ability to set up light sources in your model and then evaluate the lighting on every point in your model surfaces. The high dynamic range results you get need to be mapped down to a linear color space which you use to actually paint the results.
Now I appreciate you might reply "well of course you'd say that", but.. doing what you ask requires quite a lot of infrastructure to support - ie its a lot of work. And as you've found from the APIs, there isn't much there to help in this respect because they (not unreasonably) focus on geometry manipulation and not light transfer.
Adam
edit: I must be a devil to have avoided the blockade in Calais.. Just arrived after 1400km in a car with 2 small children.. luuvely. No really it was, no really. I'll leave now.
Or why not make it very simple and have a thread that wakes every few seconds to check whether XXX.instances.count has changed.
Probably computationally cheaper than having N instances of Observer.
Adam
Or you could monitor just the object being edited driven off onOpen, onClose ie dynamically add an observer then remove it on close.
Adam
But fundamentally, the semantics of some of the observer patterns is a bit pants. But the Boulder guys are well aware of this and I'm sure they'll get around to freshening it up.
Any reason you don't just look for all instances being added and do something its "your" definition?
Cool plugin.
However, I think wxSU isn't really ready for primetime. Specifically, it doesn't manage Ruby threads correctly wrt SketchUp.
If you have a look at lib/App.rb there are some moderately scary comments. It seems to assume its the only plugin running - I think this is why it causes so many problems.
Adam