Posts made by Garry K

I'm not sure what you are asking.

I have added a selection of handrails. You can also add your own handrails. Simply create a handrail profile for level rail. Profile must be on the x and z plane - y is ignored.

select the handrail and choose the Add Handrail icon. You will be prompted for a handrail name ( it will over write a handrail if the name already exists ).

These are the ones that I have added and given names to.

---

I want to say that if there isn't any interest in a free version of the stair builder (meaning no comments) then I will concentrate just on the pro version.

I've built the treads this way - using an outline for the top and bottom faces and taking a copy of the tread profile and scaling, rotating and moving into place. The tread data then fills in a polygon mesh - and we have a tread.

I had been using Fredo6 round over - but this strategy will allow me to add different tread profiles - I will not be limited to just round over.

---

---

I have now finished the bullnosing of the treads. This needed to be automated so that the routing of the housed stringer would be correct.

I am deciding which features will be offered in a free version of the Stair Builder. I will then continue adding more features to a pro version which will have a cost associated with it.

I am currently considering having a free version for basic curved stairs. The features that will be left out of the free version and included in the pro version are:

1. profiled handrails
2. adjusting tread nosing, thickness and amount dadoed into stringer, no bullnosing
3. adjusting riser thickness and amount dadoed into tread
4. stringer thickness
5. flared treads - progressive and continuous
6. No dadoing of treads and risers into stringer.

Please provide feedback on what I am considering.

Sorry - bad terminology. I was talking read and write access.
the only write access we have is mesh.add_point.
I'm still thinking as a C / C++ programmer.

You could render the mesh after the timers to maintain benchmark validity.

Have you tried traversing your polygons?
mesh.polygon_points_at( index )
Shouldn't this give you the same results as an outer_loop on a face?
The question I would have is although you can get the points for each polygon - Is there a way to tie in a reference to the faces in the model once you have rendered the mesh?
I would hope that the entities in the group immediately after a fill_from_mesh would be in mesh polygon index order. So there should be a 1 to 1 relationship.

I haven't played with hashes yet - so my question is probably confusing to you. Although I've programmed for many years and also played with CAD for many years I've only logged 3 or so months with Sketchup since I got serious about it (guess I caught the Sketchup virus).

What about a benchmark for a hash?

That is why I suggested it would be a viable option in some circumstances.

I think that we gain performance in the actual transform but may loose it accessing the points in the mesh.

If there was a bulk operation to move points from one mesh to another without invoking the built in check - then you would probably benefit even on a smaller data set.

I just tried your suggestion of using an incremental transform as opposed to a differential transform ( point by point from profile )

I change my timing so that it avoids the start up code which is the same for both strategies and I also avoided the smoothing algorithm on the entity after fill_from_mesh.

I performed the benchmarks 12 times for each strategy and threw out the highest and the lowest.

This resulted in a 3% improvement using the incremental transform over the point by point transform.

Incremental 0.1043
0.129
0.107
0.106
0.106
0.106
0.105
0.104
0.104
0.104
0.104
0.097
0.095

Differential 0.1077
0.131
0.112
0.111
0.109
0.109
0.108
0.108
0.107
0.106
0.104
0.103
0.101

I would still be in favor of the differential as the incremental will be prone to a slight fp (floating point) shift. It may not be noticeable with only 40 segments - but then neither is 3/1000 of a second!!

I did change the "profile.each" to a "for pt in profile" and that hardly made a difference.

So bottom line is that the bulk transform of points using a mesh is slightly faster - however it is more complex and most likely requires more memory. But it is certainly something to consider as a viable option in some circumstances!

Tig,

What I have are the points that describe the handrail profile (the face at the bottom of the picture). The picture is only for clarification. None of this is actually in the model at this time.

I keep the points that are in the bottom face and apply a transformation that rotates and moves a copy of the original points. These points are then added into the PolygonMesh.

In this case there are 53 points that describe the handrail profile (could be any profile).
And there are going to be 39 filled in segments.

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 ) ) }

This example puts 2120 points into the mesh 40 * 53 = 2120

I have tried adding the first profile into a second polygon mesh so that I can apply a bulk transform. It works - but the entire operation is much slower than just transforming one point at a time.

All I am trying to do is see if there is a faster way than I am doing - or if this is "as good as it gets"

Hopefully this is sufficient clarification.

---

I've had the best results so far doing this:
profile.each { |val| mesh.add_point( val.transform( t ) ) }

What was interesting is I didn't have to change my code that creates triangle or quad polygons. Instead I changed the array to hold indexes instead of points. For the handrail profiles I simply keep 2 arrays that contain indexes. The length of the array exactly corresponds to the number of points for the handrail profile.

For this project I can guarantee that the points are all unique. So I don't have to store all the indexes since I already know what they are. For the first handrail segment I have one array containing 53 integers (indexes) 1..53 and the second array contains 53 integers 54..106. The array's simplified logic as I could make use of [-1] which wraps around and completes the face.

It might be cheaper to dispense with the 2 arrays and do the math. But it isn't as obvious and I'd have to handle the wrap as a separate condition.

You probably already know this, but you can traverse the points this way:
pt = mesh.point_at( index )
You can then store your indexes in an array or hash and work with them instead.

Sorry Chris - doesn't work.

It appears that the reason is my point3d objects are not in the model - so they are not considered entities. If I put them in the model then this works - but I loose all the speed benefits that I currently have just by putting them in the model and manipulating them there.

What I am doing is transforming points and then adding them to a PolygonMesh. Currently I am transforming the points 1 at a time.

I've been looking for a method to transform an array of Point3d objects. It appears that the array.transform is for a simple array of 3 numbers representing x,y and z.

I know you can transform many entities or a group or a polygon mesh.

I've added a bunch of points into a polygon mesh and transformed them but I get similar performance by transforming a point at a time.

It would certainly be nice to transform in place an array of points.

Thomas,

Another thought - you could provide an option with add_point that bypasses checking for duplicates. Only use if you are certain that you have points that are not duplicates.

That could easily speed things up for situations like brick work, latices etc.

Having said that - perhaps we could load the polygon mesh without checking PolygonMesh.points = pts

Thomas,

I've done C and C++ implementations of a number of different 3D index schemes, quad tree, rtree, bsp and oct trees. I'm thinking that you would have to implement this right in Sketchup. The issue isn't with the tree - it is with your == to determine if a point is a duplicate or not - that is already in sketchup. The key bits are whether to fully balance the tree or not - time vs memory. I wouldn't see the need to put the entire vertex into the tree. The x y z and index should be sufficient. Just use the tree to avoid O(N^2)

Anyway - I did switch over to add_point and then after sufficient points are in the mesh then I added in the polygons. Essentially it was add 53 points, add 53 points add 90 polygons add 53 points add 90 polygons.

Time reduced from 0.375 down to 0.175. So - I believe that I've now pretty much hit the wall. No further optimizations make any sense.

The BLOG idea makes sense - I really didn't feel that I had enough information to do all this until yesterday. Mind you I've only been programming in Ruby a short time. Although 20 years with C / C++ didn't hurt.

Thomas,

That explains why a very large mesh starts taking a long time. For a small mesh there may be very little noticeable benefit using add_point. But for a large mesh it would.

With my handrail example - I go up the rail 1 section at a time adding polygons to the mesh. There are 53 points describing this handrails profile and there are 40 cross sections of 53 points describing the 39 sections. I am reading that the index increments in create order ( providing that there aren't duplicates ). So I will know up front how many unique points to add. I could do 2 passes - the first one adding in ALL the points and the second one adding in the polygons using the indexes. I might even be able to predict the number of polygons in the first pass before I actually start adding in the points.

The other strategy I could try is add 53 points (first time) then add 53 points for second profile then add in the polygons.

I believe that law of diminishing returns has set in - 1/3 of a second is very acceptable. But I am intrigued by this strategy.

So when can we expect some form of 3D tree, KD, AABB, BSP, Oct tree ... ???

The polygon mesh structure sounds very similar to ESRI's TIN structure (Triangular Irregular Network). I've used these strategies very successfully with huge data sets such as map topology containing more than 10 million points polygons. TIN stores unique points. Poly's can share points via common indexes. The neat thing about this is you can edit 1 point and all poly's that have that point in common automatically adjust themselves.

This data is stored in far memory which may or may not be fragmented. Memory fragmentation depends on other applications that are running concurrently. Borland implemented their own memory management which insulated our applications from external fragmentation. Of course as programmers we often created our own memory fragmentation issues.

Thus memory preallocation for the mesh may be more or less helpful. When a data structure grows beyond its memory capacity - it requests more memory. I will assume that most of these data structures require contiguous memory. If there is available free memory then the C realloc grabs more memory ensuring that the memory is still contiguous. If however there is no free memory immediately preceeding its own memory then a new block is aquired and all the data must be moved over to the new block and finally the old block is freed.

The TList that I have mentioned before aquires memory at the beginning in blocks that can contain 16 pointers (4 or 8 bytes depending on 32 or 64 bit OS). As you keep adding items into the list (contiguous array) and it grows and grows the algorithm changes and grabs bigger blocks. 16 to 32 to 64 ... up to 256 element blocks.

With my handrail - I ended up with 2067 points and 3420 polygons (lots of point sharing).
There was a huge difference moving from individual add_face to add_faces_from_mesh 24 seconds to 1 second. Changing to fill_from_mesh dropped it down to 1/3 of a second.

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.

I think I've read that fill_from_mesh bypasses a bunch of checking. In my case I am totally confident that the faces the mesh generates are good to go.

I believe that the add_faces_from_mesh will handle duplicate points etc.

Thanks Jolran,

I've got the fill_from_mesh code working and I can now generate the handrail in 0.326 seconds and this is using commit with the disable UI argument.

Thanks Thomas,

I'm sort of beyond that now. Everything is working like a dream. I'm going to go back to my stair code and move to meshes. There should be a significant improvement here as well.

Here's a better closeup of the handrail. You can see that I have started with a reasonably complex one to make sure that it works.

---