Blah. What a dumb problem.

So, despite my assertion to the contrary, the problem seems to have been exactly that I wasn't correctly dealing with Groups/Components after all. The problem only seems to manifest itself if the geometry is located in a nested group -- top-level groups didn't seem to have this problem. It's probably related to the admittedly very messy way in which I apply the transformations and inverse transformations to export the geometry in the right place.

Anyway, sorry for wasting everyone's time with a dumb problem. If nothing else, perhaps this post can serve as a warning: Never trust a Group!

K.

Hi all,

I'm having a problem exporting textures from models. It may or may not be related to the problem described by Tomasz in the "Material with coloured or distorted texture" thread, but I didn't know what a "distorted texture" is. (And in any event, I didn't see an answer that would help.) I'll try to summarise the problem, 'cause the whole story is a bit long. If I'm skipping too many details, I can try to supply more later.

Essentially, I'm trying to export all the geometry of a model, including texturing information, and store it in an XML-like file format. I originally wrote the script in January. Most of the testing used the SketchUp Warehouse's Western Canadian Place model (a.k.a. "the Husky Towers") in Calgary (Warehouse --> Cities --> North America --> Calgary --> Western Canadian Place). The Texture-related part of the algorithm used the uv_at method in PolygonMesh. (The PolygonMesh's are generated using Face.mesh.) (PolygonMesh's were used for a couple of reasons.) This approached worked perfectly fine for Husky.

I recently started more rigourous testing on the script, and found that there's a whole subclass of models that the script actually fails on. The Capitoline Hill Warehouse model (Warehouse --> Featured Google Earth Collections --> Ancient Rome --> Capitoline Hill, Capitoline Museums [...]) is an excellent example of this. Essentially, the Texture mapping is wrong. I figured, "Hmm. This must be what that UVHelper class is about." (One of the reasons why I didn't use UVHelper in the initial version was that I simply didn't understand it at the time.) I re-worked that part of the script, and the Capitoline Hill model exported perfectly. "Good guess!" I proudly thought to myself.

As a sanity-check, I ran this new, UVHelper-based algorithm on the Husky model. To my dismay, export fails on /this/ model. Most Textures are indeed mapped correctly, but a couple of them (like the terrain, and the front face of the small tower) get "shifted" by about a quarter of the Texture's width.

I'm at a bit of an impasse right now. I can't seem to identify any meaningful different between the Capitoline Hill model and the Husky model. In particular, both are "complicated" models, with several levels of nested Groups/Components. The Groups shouldn't be the problem, 'cause I've already figured out how to handle them. What /does/ seem to be the problem (although this is only a guess) is that the Capitoline Textures were "Tweaked"(?) (is that the right word?) with the "Texture Pins"(?) (my vocabulary is failing badly now), whereas the Husky Textures were all very simple ("square") applications. This is just a guess though. Even if this is indeed the problem though, I don't know to detect whether or not a Texture has been applied using the pins.

Any input would be greatly appreciated!

K.

Edit: Actually, I just realised that the description I wrote above is slightly incorrect, albeit in an important way. If you run the export script on an unedited version of Husky, both versions of the script (UVHelper-based and uv_at-based) actually work fine. The one that's failing is actually a version that I've edited. I'm not sure why editing the model would affect anything (I didn't manipulate the textures -- only the geometry changed), but at least I sorta have an avenue to explore, I guess.

In any event, I know all the missing information makes this question a little tricky to address. On the outside change that anyone can think of something of the top of their head, I'd still very much appreciate it. Alternatively, if I end up solving it myself, I'll post a reply here letter people know what the problem was (in case anyone runs into a similar problem in the future).

That's not a bad idea as an alternative, TIG. I've thought of something similar myself, though mine was admittedly less sophisticated. (I was just going to change the edge colours and throw away the original value.) I'll certainly add that to my growing list of fall-back plans.

Thanks again for all the input,

Kevin

Hi again TIG,

The selection is for visualisation purposes. That's a neat suggestion to use the win32ole library, although it's true that it would make it machine-dependent. Still, it might lead to spin-off thoughts. Meanwhile, I'll keep completely different visualisation solutions in mind.

Thanks again,

Kevin

As an (unhappy) addendum to my original post, I've discovered that view.zoom nested_entity has similar behaviour. If you're editing the immediate parent to nested_entity when you call view.zoom, it works beautifully. However, if you call view.zoom nested_entity from any level higher than nested_entity's parent, Sketchup zooms in on what looks like a random location. It turns out, this "random" location is actually nested_entity's location within its Group/Component, without the transformations of the Group/Component having been applied.

Kevin

Thanks very kindly for the reply, TIG.

I should maybe clarify a bit though.... I actually already have the "select all single-faced edges" part working (it's vaguely similar code to what you suggested, though with recursions to capture nested groups). As you noted though:

@unknownuser said:

You will note that this selects any edges in their 'original' location - rather than the current transformation... If you need that you need to delve into transformations a bit more...

That's actually exactly the question I was trying to get at in my original post (though in a very contorted way): I've been trying for about two weeks to get the Selection object to recognise and apply the transformation tree, but without any luck. I was therefore wondering if anyone had any clues how to get that part working.

Thanks again though, TIG.

Kevin

Hi all.... Me again (with a hard-to-put-in-text question, I'm afraid),

I'm trying to write a script that selects all Edges in a model that have exactly one Face attached to them. I've got the basics of the code right: it works fine, provided that the Edges that are being selected are in the same "hierarchical level" as the "level" that the call is being made from. That's possibly a confusing sentence; let me try to explain it by example. Suppose that I have selection = Sketchup.active_model.selection, and that top_level_entity = Sketchup.active_model.entities[0] is a Face. If I call selection.add top_level_entity, then there's no problem.

However, I seem to have a problem if I call selection.add nested_entity, where nested_entity is part of a composite Entity (e.g. Group, ComponentInstance). For example, if group_ent = Sketchup.active_model.entities[1] is a Group, then I'll have problems calling selection.add group_ent.entities[0] (suppose, just for the purpose of this example, that group_ent.entities[0] is a Face, but the behaviour is the same for any Entity). The call does "work" -- i.e., I don't get an error or a nil or anything. However, it exhibits some "weird" behaviour: in particular, Sketchup doesn't actually highlight the Face represented by group_ent.entities[0]; instead, it highlights "where the Face would be in the world coordinate system if you forgot to apply the Group's transformation". Again, trying to give an (overly simplified) example: suppose the Face is centered at [3,2,5] within the Group, and the Group itself is centered at [5,5,5], then this means that the the Face is actually located at [8,7,10] in the world coordinate system; however, selection.add is highlighting a "phantom Face" at [3,2,5] in the world coordinate system.

I haven't been able to figure out a way around this behaviour, programmatically. The only thing I have discovered is that selection.add seems to work if you're editing the deepest level Group/Component to which the Entity you want to select belongs. "Easy enough then," I figured. "All I have to do is programmatically tell Sketchup to edit the parent of the Entity I want to select." Unfortunately, although I found the call Sketchup.close_active, I can't seem to find the inverse method (something like Sketchup.active= or Sketchup.set_active).

I've looked in other places (including calling [Sketchup_class].methods on virtually every class in the Sketchup API that I've run across [fun exercise, but didn't produce what I wanted]), but I haven't found an answer to "is there an inverse to Sketchup.close_active?". More generally, I haven't seen a thread that deals with this "nested selection" problem. (I don't know if that's a bad sign or not.) I've thought of some other tricks to get Sketchup to select a nested Entity, but all of them are a little kludgey. For example, I've thought of creating a copy of the target Entity and adding that copy to the top-level model (maybe in a different Layer) and selecting that copy -- but now that means I've got duplicate Entities floating around. Other "solutions" I've come up with are similar slight-of-hand kludgey affairs.

If anyone has thoughts on either matter (nested selection in general, or Sketchup.set_active specifically), I'd be interested to hear them. Also, let me know if I need to elaborate on the description of the problem: it's one of those things that's really easy to describe if you're sitting next to the person, but comes out really incoherent when you try to explain it in text alone.

Thanks,

Kevin

Hi Al,

You were right: I am indeed trying to get the Scrambler. (I'm not interested in unscrambling scrambled files.)

As for "self-scrambled" files being easy to unscramble by a determined person, I sorta intuitively agree. (That was another reason why I was trying to avoid that path.) For myself in particular (being a complete non-expert at encryption), I'm positive this would be the case.

Fortunately, I seem to have been pointed down the right road to getting the one from SketchUp. Not surprisingly, the documentation by SketchUp itself (http://download.sketchup.com/sketchuphelp/gsu6_ruby/Docs/Ruby-Sketchup.html#load) seems to have been the one with the correct contact info. Hopefully I'll get an answer back!

Thanks again everyone,

Kevin

In fact, creating my own scrambler was an option I was toying with. I was hoping to avoid that route though, just because it's a little bit outside the scope of what I wanted to do. Still, it's true that it's nonetheless an option.

In any event, thanks kindly to everyone for the confirmation. I'll keep my hopes up that I get an answer from SketchUp themselves about it.

Kevin

"[...] or Marvel"? -- Yeah, sorry... I couldn't find anything better to alliterate with "Myth".

Anyway! A question about the legendary Ruby Scrambler! I've been hunting for this fabled beast for two weeks. I've come across tantalising clues that it does in fact exist -- for example, here:

410 Gone

(www.sketchucation.com)

and here:

http://groups.google.com/group/Ruby-API/browse_thread/thread/85239d5695a1d162/9cb933f0e4784c6d?lnk=st&q=sketchup+scrambler#9cb933f0e4784c6d

and most promisingly here:

http://download.sketchup.com/sketchuphelp/gsu6_ruby/Docs/Ruby-Sketchup.html#load.

Several of these point to an e-mail address, all of which I've written to, and none of which have bounced (which is auspicious). On the other hand, I've also gotten replies from exactly none of them (which is less auspicious). I've also written to technical support (I have a Pro license), and Sales, also with no response. I'm not exactly sure how to interpret this. Is it just that SketchUp is getting swamped with queries, or do they just provide generally bad (or non-existent) support? Have I maybe stumbled across some X-Filian conspiracy cover-up? Has the Scrambler been eaten by the Legendary Beast of Aaauuuuuuggggggghhhhhh ("It is the rabbit!"), or has it been discontinued? Or perhaps has someone tainted my coffee such that it's causing me to write only vaguely coherent posts to public forums? (Perhaps this isn't mutually exclusive of the mythologicalness of the SketchUp Scrambler though.)

In any event, if anyone has concrete proof that the Scrambler isn't a red herring (for example, if someone's actually using it), I'd very much appreciate hearing about it. As an added bonus, I wouldn't object if you let me know how you went about actually getting it. I promise I won't follow up with: "Can you send me a copy of it?" -- I just want to know if I'm wasting my time e-mailing every SketchUp address that seems promising.

As always, thanks a bundle,

Kevin