Yea - this is a good topic. I've been thinking that it's be beneficial to have an official UI/UX guide for extensions. I aired the idea internally recently as something that would be a good project to do. Personally I'd prefer to host it on GitHub such that it's possible to use the issue tracker. Maybe make use of GitHub pages. (but that's details)

We certainly see a lot of different approaches when we moderate the extensions on Extension Warehouse and some times makes suggestions in order to encourage extension developers to follow the existing SU conventions. But there is a need for a descriptive guide.

@blruuska said:

Dan, Thanks for verifying. It is surprising that NotImplementedError wasn't raised, if that is the case here.

Ackh! Yea, something is amiss here. Not sure if we intended to support enumeration type in the initial release of the API - but if that's the cause it should have been NotImplemented. However, I might confuse this with the "choice" type. Maybe something changed in the last moment. I need to investigate.

Can you describe some more the overall concept of what you are doing?

Sorry - I should have clarified - the vertex normals depend on whether the edge between the faces are Smooth. Soft doesn't matter - because only Smooth affect shading. The normal is a representation of the surface shading.

@jim said:

[...] but those normals will be the normal of the Face and not any calculated value. This is why you get multiple normals from a vertex in your code and why they are all aligned with each Face normal.

They are calculated if and only if the mesh came from face.mesh. When building your own there will be no calculation. This is because PolygonMesh itself doesn't do the calculation, but SketchUp will set the vertex normals as it builds the mesh returned to face.mesh.

Under the hood there is a set_normal function similar to set_uv. But this has never been exposed - probably because entities.add_faces_from_mesh and entitites.fill_from_mesh would never use it.

@oajfh said:

I was getting different results after exploding groups and creating the mesh after making a component out of the exploded ex-groups. So the comparison might not only be coordinate-based.

When you explode the coordinates of the vertices are transformed to it's parents - so you will see different values then before they they where local to the component definition.
(Also, entities in model.active_entities) are transformed into global coordinates.)

@oajfh said:

I'm building it from an existing component, so I'd simply be copying existing normals. Why would the vertex normals be incorrect ?

If you query mesh.normal_at(i) on a mesh you created yourself (Geom::PolygonMesh.new) vs face.mesh the normals won't be computed for you.

@oajfh said:

Also, are you sure about the point to point comparison ? If you create different groups within a component, won't it duplicate the points ?

You can observer this in action by inspecting the indices and point count:

<span class="syntaxdefault"><br />mesh&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">PolygonMesh</span><span class="syntaxkeyword">.new<br /></span><span class="syntaxcomment">#<Geom;;PolygonMesh;0x0000000936e850><br /><br /></span><span class="syntaxdefault">index1&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_point</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">2</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">3</span><span class="syntaxkeyword">))<br /></span><span class="syntaxdefault">1<br /><br />index2&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_point</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">2</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">3</span><span class="syntaxkeyword">))<br /></span><span class="syntaxdefault">1<br /><br />index3&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_point</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">2</span><span class="syntaxkeyword">,&nbsp;</span><span class="syntaxdefault">3.5</span><span class="syntaxkeyword">))<br /></span><span class="syntaxdefault">2<br /><br />mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">count_points<br />2<br /></span>

Or by adding polygons using 3d points:

<span class="syntaxdefault"><br />mesh&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">PolygonMesh</span><span class="syntaxkeyword">.new<br /></span><span class="syntaxcomment">#<Geom;;PolygonMesh;0x0000000a70ec48><br /><br /></span><span class="syntaxdefault">mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_polygon</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">),&nbsp;</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">5</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">),&nbsp;</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">5</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">5</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">))<br /></span><span class="syntaxdefault">1<br /><br />mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_polygon</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">),&nbsp;</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">5</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">),&nbsp;</span><span class="syntaxdefault">Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Point3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">5</span><span class="syntaxkeyword">,-</span><span class="syntaxdefault">5</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">))<br /></span><span class="syntaxdefault">2<br /><br />mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">count_polygons<br />2<br /><br />mesh</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">count_points<br />4<br /></span>

Btw - if you build your own PolygonMesh from scratch the vertex normals won't be correct I believe...

@oajfh said:

ThomThom, doesn't the add_polygon method simply add any new points at the end of the point array ? That's the behaviour it's exhibited for me so far, so wouldn't applying what Dan said be alright ?

PolygonMesh.add_point will add a new point only if there isn't an existing point for the same location (within tolerance). This means it looks up the existing points (which unfortunately is a linear look up.)
PolygonMesh.add_polygon will internally call this same function.

The linear nature of add_point I assume is because internally this class is for use with individual faces - so you're not going to have that many points nor duplicates.

To get max performance when building a PolygonMesh you add all the points first - collecting the indices you get in return. Then add polygons using indices instead of points - this reduce the number of linear lookups.

I usually use a Hash to build a source => polygon_point_index lookup. This can be vertex => index for instance.

@oajfh said:

Hmm. How would that fare performance-wise ? If I want to recover vertex normals, I probably end up checking vertexes multiple times and making sure I don't get a normal from the same vertex more than once, but on the other hand calculating face normals is faster than calculating weighted vertex normals.

Yea - that's a good point. I don't think you can rely on 100% that the order of the points in PolygonMesh to match the face it came from.

If performance is critical I think you will get best results from calculating in C/C++ via A Ruby extension which then only iterates the vertices (though you need to collect that from edges or faces - but collecting that into an std::set or something shouldn't affect your performance too much.). You then do the calculations with native code.

By the way - what version of SU are you developing in?
In SU2015 the polygon_mesh should return correct vertex normal - as we make sure to rebuild the cache if it's invalid when the mesh is built.
http://www.sketchup.com/intl/en/developer/docs/releases

@unknownuser said:

Fixed a bug where Geom::PolygonMesh.normal_at would not return correct vertex normal if the model was modified in the same processing loop as the script obtaining the PolygonMesh.

@oajfh said:

Also, just in case, could you clarify this statement :
"PolygonMesh will in fact return vector normal. It depend on the edges connected are soft+smooth or note."

Sorry - I think I confused polygon meshes normals vs the ones I made up in Vertex Tools (There the faces will contribute to a vertex normal only if the edge separating them is soft-smooth. So that the normal depend on the smoothing of the surface. but the PolygonMesh shouldn't do this.)

Yea - exporters do tend to have a need for this. I think they generally are able to use PolygonMesh for this. But I think there was issues for live render engines - which queried the polygonmesh in the middle of operations (at which point the cache might be invalid.) We should have an issue file for this to look into.

@sdmitch said:

This seems to work

Have a look at this thread: http://sketchucation.com/forums/viewtopic.php?f=180%26amp;t=39625

Yea - fully understand. I wish I could say that the PolygonMesh returned a reliable vertex normal, but as it is right now I think there are issues if you happen to query it after the cache is invalidated and generated. (This is a result of Geom::PolygonMesh tapping directly into the polygonmesh we use for triangulation and the vertex normal cache is controlled by SU when it needs it - which can leave the API in the dark... :/)

@youngosg said:

t = Geom::Transformation.scaling 2

There is an issue with this method - it doesn't produce the same transformation as
Geom::Transformation.scaling(2, 2, 2)
The former change the 16th value in the matrix - instead of scaling the components.

I'm not sure why it was implemented as such, but several render engines have had issues with that. I think even SU have issues in some cases. Think we have an issue filed to change it.

@oajfh said:

If I'm not mistaken (I could be, but API doc is down for me atm), the PolygonMesh.normal_at method will return the normal of the face it was created from (if it was created from a mesh).

PolygonMesh will in fact return vector normal. It depend on the edges connected are soft+smooth or note.
However, not too long ago we followed up on a developer support request where it turned out that the internal vertex normal cache some times was invalid when the mesh was obtained - in which case the normals wasn't what you expected.

I don't recall the exact detail right now.

For Vertex Tools, I added a feature to visualize vertex normals, but I wrote my own method to calculate this. This is currently done in Ruby - which isn't the fastest way to compute things. If you need a bulk set of vertices to calculate normals for then a Ruby C extensions might be useful to get some better performance.

Can you provide some info to what you want to use the vertex normals for and when you are trying to obtain them?

Did you make that buttom a Submit button? By default I think that will make a POST request to the same page it is on. You need to either capture that event and prevent the default action, or make the button a non-submit: <input type="button"> or <button></button>.

Take care Anton - make sure you don't get burned out.

You might find it useful to use the Transformation Inspector to visualize the matrix:
http://extensions.sketchup.com/en/content/transformation-inspector

@anton_s said:

By examining other extensions and stuff I learned how to use C++. Now, I take CS162 at college and C++ becomes an easy language to use. My knowledge of Windows API is all from my long experience using it. It took some effort developing useful methods and optimizing them over time. It was all worth it though .

C++11 yum yum!

Sorry Fredo for the late reply. I just looked up the source for this. Though it looks like you deduced this yourself, here's confirming it:

selected_style refer to the style selected in the Style browser. However, the user might have modified that style after selecting it. So it's properties doesn't reflect what's being used in the viewport.

active_style refer to the "working" style.

The API interface is a reflection off the underlying system. But it's certainly awkward. Better documentation and examples are needed. And I guess there is a need for some new API methods.