Offline
@thomthom said:
Didn't realise Ruby would recreate the variables for each iteration. I'd thought it'd keep them for the duration of the loop...
The closure you create with curly braces is handled as a first class object and passed as an argument to the iterator. This means the scope of any variables you mention inside that block is limited to that block - it must create them each time. 
Seems an arbitrary (and wrong) assumption that inline code requires removing whitespace. Why not just leave in what the author wrote rather than trying to second guess? Whatever.
@driven said:
[0x0-0x45045].com.google.sketchupfree7[548] SketchUp(548,0xa015e720) malloc: *** error for object 0xa03eb6d8: Non-aligned pointer being freed
[0x0-0x45045].com.google.sketchupfree7[548] *** set a breakpoint in malloc_error_break to debug
Sketchup has always emitted these (scary) messages. I've never figured out why.
@driven said:
0x0-0x3b03b].com.google.sketchupfree7[373] /Library/Application Support/Google SketchUp 7/SketchUp/Plugins/Xyz/Abc.rb:218: warning: parenthesize argument(s) for future ver
You'd have to write a prtty sophisticated regular expression to catch and change all these. You'd be running the risk of screwing up the scripts if you get anything wrong..
@driven said:
[0x0-0x45045].com.google.sketchupfree7[548] (eval):4632: warning: don't put space before argument parentheses
A simple search and replace of " (" with "(" should work.
@driven said:
[0x0-0x45045].com.google.sketchupfree7[548] (eval):27: warning: already initialized constant ZERO_TOL
A script is being required/loaded twice.
@driven said:
[0x0-0x45045].com.google.sketchupfree7[548] #<NoMethodError: undefined method `rendering_options' for nil:NilClass>
This is just an error in the script. My total guess would be a script that is reading the rendering_options when there is no active_model and thus getting nil as the result.
OT: Any chance the forum administrator of SCF can fix the [ruby] tag to not remove formatting. Formatting is a big part of understanding code, and while for regular text collapsing whitespace down to a single space might work, for code it does not.
I see a lot of SU scripts using some of the more compact iterators Ruby iterators. So they might read nice, but they're often slower than just simple for-loops.
The other biggie to look out for is operations that involve copying when modifying in place would work just as well. Its slow and it generates lots of garbage.
LightUp - 3 minute render time.
I've added a couple of IES downlights too.
Also you really don't want 4 points as input as they may not be coplanar. 3 points are guaranteed to be coplanar.
Its just not efficient. A plane is commonly defined by a direction and a distance along that direction (the "D" constant). Keep in mind a plane is infinite so you just need "a point" - any point on the plane to define it.
So explicitly storing the Point3d is (groan) pointless. If you want a point on the plane from its plane equation you just do:
plane_normal.scale(D)
ie You just need to store 4 values not 6 as you are doing.
@chris fullmer said:
That looks super cool Jim! I am on it tonight! Give about 5 years and I will have some progress updates
Chris
FWIW This is essentially how LightUp works under the hood. I've had for some time realtime painting tools working in LightUp but I've never had time to productize them.
Adam
I realise this is all set for a flame war..
The thread is about producing Extensions for Ruby (which is written in C). So TBD comment about keeping it simple and using C/C++ is pretty reasonable.
Its all well saying Mono, but the reality is that on a Mac, Xcode has great support for C/C++ and not Mono/C#.
Given there are many fixes between 1.8.0 and 1.8.6 - and using 1.8.6 doesn't seem to cause problems - I don't know why Google are shipping quite so old a dll. In particular, I noticed a few fixes in the changelogs to Ruby related to memory leaks.
FYI Mac Sketchup uses 1.8.5
Adam
Yep, I see the same thing here. On windows it simply wont load. I've rebuilt it locally too.
I've build it on a Mac and works just fine. I had to remove some Rails stuff from the startup but it works pretty nicely too.
Whaat, you should have in you plugins folder:
ruby_prof.so
ruby-prof.rb
ruby-prof (folder)
ruby-prof.rb just loads all the ancillary files as normal.
Can you give the actual error you get.
Anyone have any photos of how the wall lights look in reality? I find the illumination they give pretty dim in my rendering.
FWIW I've used in anger most languages over the years and my problem with C++ has always been it gives you a ton of opportunities to really screw yourself over. I've seen it happen with inexperienced programmers countless times, so to that degree I'd suggest that sticking with C and keeping it simple is sound advice.
@chris_at_twilight said:
Last, don't underestimate the garbage-collection issue. If you have a single C/C++ method in which you make many ruby calls:
+10000
All the Ruby docs claim that the GC searches down your stack frame and ensures that anything referencing a Ruby VALUE will not be garbage collected. But my experience is that is simply not true.
What is true, is that as long as you don't call Ruby functions, it cannot run its Garbage Collector. So grab your info from Ruby, turn it into C data and then process without any calls to Ruby and you'll be good. The moment you call Ruby, you run (as said above) the possibility of the GC running (I believe it actually gets run every 256 internal opcodes Ruby executes - scary huh!).
Adam
+1 For sticking just with C. (BTW C is a procedural language, a functional language is something else entirely)
Ruby is itself written in C so even if you choose to use C++, you need to do C calls into Ruby.
Start with TBD example code. It deliberately starts with just doing some simple math to get your confidence.
The key thing for dealing with Ruby in SU, is that Ruby has been bolted-in (in a good way) to the underlying C++ SU application. This means in your Ruby extension you can call all of the Ruby functions you normally have.
eg
VALUE model = rb_funcall(sketchup, rb_intern("active_model"), 0);
will set model to a reference to the active model. You could then do:
rb_funcall( model, rb_intern("entities"), 0)
to get the entities of the active model.
Because Ruby automatically cleans up unused objects, you ask for the active_model object, use it for a bit and then move on, knowing Ruby will "Garbage Collect" the memory used for that by automatically working out when you're not using it anymore.
<gross simplification>You therefore cannot hold onto Ruby references beyond the scope of your function</gross simplification>
Notwithstanding Todd's comments in the other thread, Ruby Garbage Collection will remove objects from underneath you if you keep references around. There are ways around this but it makes things complex for anything but very simple Extensions.
I'd suggest you take an educated guess as to where the bottlenecks in your plugin are, and then write a single C function that does the heavy lifting just for that. But be aware that, walking every face in a model in Ruby and doing the same in C which is calling Ruby, is going to be the same speed. You need to identify areas that can be cast into pure C, do lots of calcs, then turn the answer back into a Ruby object.
Adam
alz, Sketchup handles textures in a different (I think better) way to most modellers.
The short answer, is that Sketchup does what you want 'right out of the box' because for each texture, you specify how much world space it should cover. Sketchup then ensures that the texture repeats sufficiently to satisfy that "texel density".
Just open the material editor and change the Width/Height fields which are World Units (eg meters / feet).
My plugin called Goldilocks uses the Sketchup material "texel:world space density" to check whether for a given viewpoint, that density gives a good "texel:pixel density".
In other words, Sketchup will automatically texture like your second image.
Adam
@whaat said:
@adamb said:
So much so, I've finally given up on using the Ruby<->C interfaces for Extensions. The next version of LightUp is talking directly to the underlying Sketchup object model and is completely stable for the largest of models, uses miles less memory and is around 10x faster.
How exactly do you communicate directly with the SketchUp model?
Sorry, I mean using the SketchUp C++ SDK for directly walking their structures rather than having some C that uses rb_funcall() Ruby calls to get a Ruby object that is created by SketchUp as a proxy of the "real" underlying C++ object - and therein is (I believe) the source of many problems when writing C-based Extensions.
I've avoided it (the C++ SDK) for many years because I detest COM with a burning passion - I dislike COM so much that I find if I meet anyone who has anything positive to say about COM, I immediately dismiss them as idiots.
And yes, I know my COM-ism is extreme. 
@unknownuser said:
Embedding C code is practical, and not that difficult. The examples in the Ruby Pragmatic Programmer (pickaxe) book work great. The only downside is the hassle with distributing the binaries and making sure the install process is idiot proof.
Todd, I think thats a bit misleading. Sure the fundamentals of calling some C API to interface with vanilla Ruby is trivial. However, there are many many problems dealing with SketchUp's underlying C++ based object model, which interfaces to transient Ruby representations which your C Extension then manipulates. GC issues are a nightmare.
So much so, I've finally given up on using the Ruby<->C interfaces for Extensions. The next version of LightUp is talking directly to the underlying Sketchup object model and is completely stable for the largest of models, uses miles less memory and is around 10x faster.
Ruby is great for running up a quick GUI, "power short cut" etc but it is just waaay too slow to do any kind of heavy lifting.
In some sense its no surprise. You can't have your cake and eat it. Simple as that.
