AI generated subdivison plugin

sashapepperspray

In the past view weeks, I worked with ai to make a subdivision and mesh reduction plugin. I started off with this old plugin (https://github.com/NB70/sketchup-loop-subdivision), and got the ai to improve it, and then I got it to make a dynamic subdivision plugin, and a mesh reduction plugin. I don't really know ruby coding, so I can't say it will work, but it works for me. I will attach it here, hopefully someone finds it useful. I also am attaching a manual, generated by ai (obviously) from the code.
mesh tool manual.pdf
Mesh Tools.rbz

Rich O Brien

Impressive result.

Tons of Ruby Console errors

#<TypeError: reference to deleted Face>
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:190:in `edges'
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:190:in `block in dyn_loop_getvertices'
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:188:in `each'
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:188:in `dyn_loop_getvertices'
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:345:in `block in dyn_loop_subdivide'
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:343:in `times'
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:343:in `dyn_loop_subdivide'
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:555:in `loop_dynamic_build_result'
C:/Users/rclub/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/mesh_tools/Dynamic_Subdivide.rb:581:in `block in loop_dynamic_schedule_rebuild'

TIG

Works well.

But I have a few observations from a non-AI view-point...

The Dynamic_Subdivide.rb file uses several $xxx... global variables - these are frowned upon because they can pollute all other Ruby files [and are not acceptable in extensions submitted for review in the EWH].
It's a simple fix - replace them all with @xxx... variables that then work across methods in the same modules, but not 'globally' in unconnected scripts.

That Dynamic_Subdivide.rb file also has potential trip-hazards as Rich pointed out -
e.g. in line#190 it's possible for it to reference an edge of a face that is no longer valid, as specified in an earlier line, so it falls over.
This not valid issue occurs when your operation does something to geometry that affects a previously made collection of things -
e.g. adding a new face [or edge] overwrites an existing face [or edge] so a reference to it is no longer valid.
Again it's a simple fix - add a 'skip' trap near the start of the block -
e.g. like this
faces.each do |face| next unless face.valid? ... end
which skips any invalid faces and so the errors are sidestepped.
You can do a 'find' in the code to add in similar traps like this for any non-valid face, edge, vertex etc.
Also note that the various blocks have an inconsistent format, swapping between
xxx.each { |e| ...xxx... }
to
xxx.each do |e| ...xxx... end
But editing either of them is possible with a little care.
Both forms are acceptable, but choosing to use just one for consistency is recommended...

sashapepperspray

@TIG thank you very much for your tips, I will hopefully fix them soon.

sashapepperspray

here is the new version, hopefully it is fixed (I gave the feedback to ai, and asked it to fix it .
mesh_tools_1.0.1.rbz

TIG

I think you've trapped almost everything.

However in the self.loop_dynamic_purge_ghost_material method you look at ent and then manipulate its material if it's a face or a group or a component-instance.
But if those are no longer valid for some reason [I do suspect that could be an incredibly rare chance?] then it could throw an error and fall over.
A simple check at the start of the method's do-block that is searching through the model.entities e.g.
next unless ent.valid?
skips any invalid ent

Incidentally, without analyzing the whole code-set, firstly why not use model.active_entities which potentially reduces the list length, and secondly what about any faces within nested groups etc not inspected by this method that might still have that material ?