facepalm! model.rendering_options.add_observer(self) - duh!

The syntax checking is a big plus. I've also just setup subversion control on it. Great to easily revert to previous version if I have messed up code. Commit once I know it is good. I also really like looking at differences between two versions. I can have both side by side, or on the active version, there is a notation of where I have made changes, and clicking the icon brings up a popup with the old code. I can then revert just that piece back vs. the entire file. The global searching is also nice. I'm working on someone else s code on a complex project, and it is great to quickly see where else specific code is being used.

Got one already: http://www.smustard.com/script/TextLabelOverride Todd

@chris fullmer said: AND 3rd aprty renderers do not appreciate the 16th element of the matrix being anything other than 1 also. So they often freak out when they come across these face-me's that have been incorrectly scaled. Previous version of VfSU didn't like that type of transformation. The new one seem to deal with it properly. @chris fullmer said: Yeah, this was a fun bug to track down Obcurity - thy name is SketchUp!

@wind-borne said: Initially, I will be looking at Lux for estimates of losses due to shading as program does face calculation if I understand the static reading. LightUp Insolation rendering gives 3 readings: A spot Kwh/m^2/day for the exact position from which you're taking the reading. (Static) A Face reading of Kwh/day (ie scaled by the area of the face). This is useful if you model panels with a single face. (Tracked) A Face reading of Kwh/day assuming the face tracks the sun (and is therefore more efficient). Adam

What I'm trying to say is this: If you add Q*(Face Normal) to each of your points you get a new face. If you align your texture to this new face but assign it to the old face it should be distorted. PS: sorry for my bad English... I'm not a native speaker.

@unknownuser said: I like the work put into the menu system Chris, I presume you're using that in a plugin you've created? (Or is SketchUp not capable of doing that?) Thanks. Both cgScenes and nsetSketchupAPI work as plugins and have been downloaded 130+ times. Here are copies of the download links. cgScenes R 1.051.zip nsetSketchupAPI 1.00 Nov15 1350.zip Here is how I introduced the API one: @chrisglasier said: I hope some people find the nset version of Alex's cheat sheet useful but really the main purpose was to demonstrate an alternative method of working that energerises names with computer code. Linked together in sets they provide machine-like support. Specific data is simply clicked into focus rather than the reader having to look through pages. . We thought that others might join in by adapting devices like Jim's web console [image: Rzjn_API012.png] and creating new ones using the same "name-based OS" that links everything together (the main menu is the model). But it seems web dialogs are not considered a serious solution, which is a great shame. I believe ignoring the real potential of the Net is very short-sighted. So I decided to concentrate on expanding cgScenes as I know there are SU people who would like to use hierarchies of scenes (views of their models) to facilitate design, present to clients/customers, submit to authorities, support purchasing, direct site work, explain timing and methods with diagrams and model animation, and handover useful and reusable automated information for ongoing activities.

"Adjust" is a Tool within the 2Dtools toolset - accessed from the Draw>2Dtools menu or the 2Dtools toolbar...

@jim said: Yeah, that's pretty much all there is to it. Make sure to read all the values; you can't skip them even if you don't use them. Because of variable chunk length? @jim said: I made a mistake when I said the values did not match - it works out no problem. You managed to recreate an SU camera? What's the lens value? AOV? FOV?

Use an inputpoint to get all the SketchUp inference points. This is a bare-bones code snippet that will make a tool, use an inputpoint and then draw that inputpoint to the screen. ` class SUC_IP_POINT def activate @ip1 = Sketchup::InputPoint.new end def onMouseMove(flags, x, y, view) @ip1 = view.inputpoint x,y view.invalidate end def draw(view) @ip1.draw view end end Sketchup.active_model.select_tool(SUC_IP_POINT.new)` So check that out, see if it helps. Chris

I'm running the latest SU Pro on a Mac. I think I did bypass an update-gram the other day, so I might not be on the latest.

@tig said: Are you sure you haven't got two duplicated 'Styles' folders ? Use the Finder to check - there should only be the one root folder - perhaps you have that 'Lin' style copied into another 'personal' one that's interfering ? Hello, Where would the root file be? Kind regards, Chuck

UI::WebDialog.set_file BUG found Found the problem on PC. It's a boo-boo using the File.join method. An extra SEPARATOR is getting inserted at the beginning of the URL string, so that whatever the pathname, whether you use the optional relative path (2nd argument) or not, the resulting URL passed to the browser begins with: file:/// For this test I have Rick Wilson's lil' html help file in the Support folder: Rename it to .html and put it in the Sketchup Support folder my_dialog=UI;;WebDialog.new('Smustard Organizer Compatibility',true,'test',800,600,100,100,true) SUpath=Sketchup.find_support_file('') #empty string needed! my_dialog.set_file('Support/Smustard_Organizer.html',SUpath) my_dialog.show On the PC this results in MSIE error dialog stating that 'Internet Explorer cannot find the file: "file:///C:/Program Files/Google/Google SketchUp 7/Support/Smustard_Organizer.html"_' Trying various combinations of the set_file method: 1 argument, 2 arguments, etc., I have also been able to get 2 types of error webpages, 'Internal Server Error' and the normal useless 'Cannot Open the Webpage error' with the likely reasons ie: No Internet connection, etc. LESSON UseUI::WebDialog.set_url instead. my_dialog=UI;;WebDialog.new('Smustard Organizer Compatibility',true,'test',800,600,100,100,true) SUpath=Sketchup.find_support_file('') #empty string needed! # Remove leading file separator on Mac (or Win without Drive;) SUpath.slice!(0,1) if SUpath[0,1]==File;;SEPARATOR # File.join will put it back in my_dialog.set_url( File.join('file;//localhost',SUpath,'Support/Smustard_Organizer.html')) my_dialog.show It is quite likely that .set_file actually just calls .set_url passing the latter improperly concatenated pathname string portions misusing the File.join method. (Obviously the set_file method could be fixed using the slice! technique above.) UI.openURL The same technique can (and should) be used with UI.openURL so that code is cross-plaform. On Mac, testing has shown that OSX wants 'file://localhost' at the begining of the URL or it can't find the file.* On PC, Windows will adjust the URL, stripping off the 'file://localhost' and passing the rest of the path to whatever application is registered for the file extension. (Not always the browser.) WebDialog.new Two things to note here. Comma Separated Parameter List form: IF the pref_key argument is nil or '' (empty string), the remaining arguments are ignored. (This is why I set the key to 'test' in the examples above.) So if you are attempting to make a WebDialog that does not save settings, and it is not showing at the position and size you want, this may be why. Hash as Parameter form: Contrary to what has been said that the dialog_title parameter cannot be set through the hash, it CAN be. However, there is a bug in this new Hash based functionality. In that the Google coder did not take into account that there are several ways of defining a Hash, ie, with Symbol keys or String keys. The coder should have just converted each key using to_s and then made the value assignments based on the keystring, but didn't. So the Hash based form is 'quirky'. You must use Symbolsas keys, NOT Strings: hsh=Hash[:dialog_title=>'Title passed by Hash', :scrollable=>false, :preferences_key=>'MyDialog', :width=>800, :height=>600, :left=>100, :top=>100, :resizable=>true] AND once again if you omit the :preferences_key value pair, it seems the remaining arguments are ignored.. ie default position is 0,0 and size is 250,250 instead of those specified in the hash. Conclusion: Because of the kwappy way the WebDialog API was coded, we must pass ALL parameters or Hash keys (which actually defeats the advantage of the Hash, over a Comma Sep'd Parameter List.) _

And here's the matrix returns for one component in the original and recreated view. [image: L2cr_camera011.png]

@thomthom said: Any clues to how to determine that? Check my FrontFace. I just compare normals. The global transformation problem is solved by shooting a ray. That allows you to get an array of all parents of a face.

@martinrinehart said: I've looked harder and seen that there is NO Mac issue. It's a Windows-only problem. That's heartening to hear! The amount of times I've heard windows developers moan that there is a fault, and it is Apple's fault!

@dan rathbun said: Well I do something a bit weird. Care to share some code?

@dan rathbun said: (7) The methods within the 'sketchup.rb' script were intended (for the most part,) to extend developer's use of the classes Module and Class. BUT they were not wrapped within the proper namespace(s) in the script, and so get defined as methods of Object, and so become inherited by ALL classes, such as the Numeric classes, the Sketchup::Entity subclasses, the Geom::subclasses, etc. where they will NEVER be used. Very informative post Dan! But i disagree that the problem boils down to a lowly script. This problem is inherent in the design of the Ruby language itself! @dan rathbun said: Open a new model, draw something simple a cube, select a Sketchup::Face object. Switch to the console, type (all 1 command): **Sketchup.active_model.selection[0].private_methods(true).sort.join("\n")** Look at the list, you will see that the Face object has inherited as private methods (which you will never call from outside the object,) all those methods defined in 'sketchup.rb'! What kind of drain of memory will this have when you get to a model that has tens of thousands of Entities it it? Exactly! this is what most of the folks in this thread have missed! Ruby just blindly sucks in every method it can find! In Python we have a system of using single and double leading underscores to indicate private and public methods. It's not a forced convention but we all understand and use it like a forced convention. But even more importantly Python objects have a dir "special method" that will return the appropriate list of methods when using the introspection function dir(obj). Python also (as i have mentioned time and time again) uses every file as "module" automatically so none of the name clashing occurs unless you import the module in a certain manner.

@unknownuser said: Would now be a bad time to point out i actually quite enjoy scripting in SU? Great punch line remus . Your keen sense of comic relief no doubt qualifies you as a mod. I always seem to get a good giggle from your posts. But seriously folks we have an issue here. Some people will say that tring to improve SketchUp is a lost cause. Well that may be slightly true but we cannot give up already. I think a lot of newer scripters (some may never had experianced with scriping before) are now joining the fray but have found major workflow issues that quite frankly are just impossible to overcome alone... @unknownuser said: Wait a minute Jesse! uhhh, excuse me a moment, Yes Joe! @unknownuser said: Jesse, why in the world would some people feel that SketchUp scripting (the way it stands now) is a good system? We all know it sucks eggs! Thats a good question Joe and one has many complicated and reveiling answers. You ever hear the expression "more than meets the eye" Joe? I think for one people just get so accostomed to something that the "fear of change" simply (in their minds) out-weighs the hassles they currently endure. So they just choose to endure it. What about the "Helsinki Syndrome", have you ever heard of that one Joe? Well some correlations can be drawn between that state of mind and the current state of SketchUp scripters. If you where to ask them privately you'll find that they are just scared Joe, they feel helpless, and like little children they need guidance to free their minds from this hell-state. For example, lots of people use Microsoft OS even when far better (and free) choices are available. But what is most entertaining is when you ask them WHY? Why do you choose to use a proprietary OS when a number of free alternatives exists? It's like a deer caught in headlights Joe, don't even waste your time. But sadly there is also evil afoot in the form of FUD mongers and jolly green greedies. Some people have capital gains to be made from SketchUp scripting and they will do anything to keep their piece of the pie even if that means stepping on the little people (thats you and me Joe) to get to where they are going. Sometimes just by making a system uncomfortable you can keep the noobies out and therefore curtail competition. This system has been successfully employed by many major corporations! But we are not here to talk about M$'s evil world domination practices, we are here for the wonderful SketchUp. @unknownuser said: This is all very sad Jesse , i'm beginning to lose faith in my fellow SketchUp brothers and sisters. Yes i know, but i believe in growth Joe, and i believe in change. i believe we can cultivate these confused chaps into productive scripters that produce SketchUp scripts with much ease. No more shall they lament the torturous trappings of the Ruby Console. No more shall they endure 3rd party patch-ware and windowing multiplicity! Heck, they may even start to enjoy this!

@cjthompson said: Do you know which version of Ruby you took the Win32api from? Just as a head's up, so you'll know... Win32API.so is not distributed with Ruby 1.9.x and up. It is replaced by Win32API.rb, which is a translator script, that 'fools' old calls to the Win32API.so, by translating those calls into DL library calls. It is supposed to work transparently, because most uses would load the so by simply: require 'Win32API' The require method looks for .rbfiles first, so it would load the new translator, instead of the .so, ... in a normal ruby install.