The data set you currently work with is probably so small that you won't gain that much. But I'd think as the data set increases you'd see bigger and bigger differences.

@existme said:

Thanks so much It's a pity that you cannot glue to other component's faces via API.

Indeed.

@garry k said:

Currently I am applying this transform to each point:

t = Geom::Transformation.new( [ 0, 0, i * rise_per ] ) *
Geom::Transformation.rotation( [0, 0, 0], Z_AXIS, ( i * deg ).degrees )

profile.each { |val| mesh.add_point( val.transform( t ) ) }

What if you use PolygonMesh.transform! ?

<span class="syntaxdefault"><br /></span><span class="syntaxcomment">#&nbsp;Use&nbsp;for&nbsp;in&nbsp;loop&nbsp;at&nbsp;that&nbsp;doesn't&nbsp;create&nbsp;new&nbsp;local&nbsp;object&nbsp;per&nbsp;iteration.<br />#&nbsp;Creating&nbsp;objects&nbsp;in&nbsp;Ruby&nbsp;is&nbsp;slow&nbsp;-&nbsp;so&nbsp;try&nbsp;to&nbsp;reuse&nbsp;them.<br /></span><span class="syntaxkeyword">for&nbsp;</span><span class="syntaxdefault">point&nbsp;in&nbsp;profile<br />&nbsp;&nbsp;mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_point</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">point</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">end<br /><br />t&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Transformation</span><span class="syntaxkeyword">.new(&nbsp;[&nbsp;</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">i&nbsp;</span><span class="syntaxkeyword">*&nbsp;</span><span class="syntaxdefault">rise_per&nbsp;</span><span class="syntaxkeyword">]&nbsp;)&nbsp;*<br /></span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Transformation</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">rotation</span><span class="syntaxkeyword">(&nbsp;[</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">],&nbsp;</span><span class="syntaxdefault">Z_AXIS</span><span class="syntaxkeyword">,&nbsp;(&nbsp;</span><span class="syntaxdefault">i&nbsp;</span><span class="syntaxkeyword">*&nbsp;</span><span class="syntaxdefault">deg&nbsp;</span><span class="syntaxkeyword">).</span><span class="syntaxdefault">degrees&nbsp;</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">transform</span><span class="syntaxkeyword">!(&nbsp;</span><span class="syntaxdefault">t&nbsp;</span><span class="syntaxkeyword">)<br />&nbsp;</span><span class="syntaxdefault"></span>

Then you should be able to do bulk transformation of the points by doing iterative transformation for each profile step. I've never tested the performance for that - but generally the fewer operations the faster.

I assume you mean the soft selection? When you have the Select tool activated, enter a radius in the VCB.

With an Point3D version of the Oct tree I don't think the point comparison will be an issue any more. From the tests with vertices it scaled very well.
Though I have some more ideas for the PolygonMesh class.

We're actually working on a Hello World example for Visual Studio and Xcode for compiling Ruby C/C++ Extensions for SketchUp. We can expand that (create a work or extra branch) with SLAPI configured as well.

By the way can you post a Gist of your code? You got some syntax errors there that appear to not be related to linking to the correct headers.

Yea, if it's fast enough for what you do then now need to optimize. But just wanted to give a general idea of what's going on. In case you need to scale up. We should do a blog post on this topic.

I did in fact try recently with a Oct tree implementation we had for vertices - dirty hack. And it gave great performance improvements. But the memory usage was sky high - I suspect it was due to the overhead of using vertices (much more complex objects.).

So I cannot promise anything - other than tell you that we have been looking into it.

@garry k said:

Playing around with preallocation did not make any noticeable difference at all. I did not play around adding with mesh.add_point - this would have required a rewrite.

Every time to feed the PolygonMesh a Point3d object it will traverse all the existing points and check if is considered to have equal position. It does that to determine if it should merge points and reuse an existing index or add a new item. This process is currently not optimized so it's an O(N^2) operation. Now think of that when you create a triangle with three Point3d points.

Now, if you use add_point to populate the points you are going to user first - then use the indices collected when you generate your polygons you have performed the minimum amount of O(N^2) operations needed - and add_polygon will simply just add the indices to its internal list in O(1) time for each index.

@jolran said:

I persume Calling methods (polygons & Points) to Polygonmesh.class is a Little faster than using Ruby Array/Hash lookups as well ? Since I gather they are dealt in C ?

Not necessarily. A Ruby Hash lookup will be faster than the linear traversing the C code is doing. When I need performance in Ruby I often find that creating a Hash cache object yields the most performance gain.

As always with these things - never assume - test it.

@garry k said:

I believe that the add_faces_from_mesh will handle duplicate points etc.

The polygonmesh handles duplicate points.

The fastest way I found to create PolygonMesh is to feed all the 3d points you are going to use to the PolygonMesh and then use the index that mesh.add_point returns to build a set of indicies which you use to make the polygons (add_polygon). Also, if you have an idea of roughly how many points and polygons the mesh will consist of, specify then when you create the PolygonMesh instance.

@garry k said:

What is interesting is that if I use this it takes 24 seconds
model.start_operation "curved rail"
...
model.commit_operation

If I omit the start_operation and commit_operation then it takes 8 seconds.

What times do you get when you set the disable_ui argument of model.start_operation to true?

@jiminy-billy-bob said:

That's interesting.
But how can we force the last version ? Let's say I put <meta http-equiv="X-UA-Compatible" content="IE=10"/>, how will IE8 behave with this ?

It will use the newest it can - IE8.
I'd recommend you set it to: <meta http-equiv="X-UA-Compatible" content="IE=edge"/> - it will then always pick the latest mode available. Like a normal browser would do. (See example in the SKUI project: https://github.com/thomthom/SKUI/blob/master/src/SKUI/html/window.html#L4)

No way to omit operations form the undo stack. The API wasn't designed for geometry to act as UI elements.

Only way to remove an operation would be to abort it. If you start an operation before you display your geometry and then abort it before they trigger their command it should be gone from the undo stack. But it's prone to being interfered with by other operation thee user might trigger or other extensions that have observers active.

Unless you create a face flat on the ground then the direction of the face normal depends on the order of the point you use to create the face. you might want to check the order of these points when you create your mesh - getting then ordered correctly from the start would mean less post processing and faster script.

Some times? Not consistently?
Do you use the META tag to force embedded IE to use the actual IE IE render engine? Embedded IE is more conservative and it uses an older render mode even if you have a standard doctype. See the Lost Manual for more details: https://github.com/thomthom/sketchup-webdialogs-the-lost-manual/wiki/Doctype---Quirks-vs-Standard-vs-Superstandard

I also think that in one of the recent SU versions there was a registry setting set that would bump up this doc type one version (and that would affect older SU versions on the same machine.) So that might be the reason to why you get seemingly random reports of this. It might be they have versions that trigger the IE7 mode.

By the way, should you not be detecting older versions as well, not just IE7?
<!--[if lte IE 7]> <![endif]-->

@jiminy-billy-bob said:

• Adds an options to hide the warning for outdated IE versions (This is intended for people with the warning appearing even though their IE is up to date)

How are you detecting the IE version and which versions are detected incorrectly?

You cannot modify Entity Info itself. But you can create your own WebDialog for your custom UI.

Note that there is a few issues with WebDialog that might bite you, check out the Wiki at this GitHub repo: https://github.com/thomthom/sketchup-webdialogs-the-lost-manual

If you just want to do a quick start with some simple UI elements you might want to use SKUI: https://github.com/thomthom/SKUI
Note that it's not 100% complete yet - but for simple textbox editing it's ready.

Afraid not.

@unknownuser said:

If everyone is wearing hats maybe Tom won't.

Hard to match your hat - but I do have a cookie-monster hat!

@curator said:

However, I would like to have this sphere (and later other objects) as an own Entity, such that I can to specified stuff with it later.

You cannot create custom types of entities either. It's something that would be awesome, but it cannot be done as things are now. The alternative would be to create it as a Group, then perhaps add some attributes that add some meta data if you want to access some of the parameters you used to initially create it.