Adding geometry to model - speed issues

thomthom

I'm working on a plugin that generates some pieces of geometry.

I did some timing tests and found that methods that added geometry to an entities collection slowed down more and more as when the number of entities in the entities collection grew.

Incidentally, while I was debugging something I had my script add each part of the mesh I was creating into a separate group. That was really fast. But when I switched to create all the geometry in the same context, the time it took increased significantly.

In my case I also found that using PolygonMesh to generate my geometry was about twice as quick, entities.add_faces_from_mesh also appears to suffer from decreasing time as more geometry is added.
In my case, creating one large PolygonMesh and adding to the model was 5 times slower than if I created a number of smaller PolygonMesh'es into their own groups.

So atm it seems: generate one single mesh and take the time penalty, or split the mesh into a number of groups and benefit from the speed - with the disadvantage of making lots of groups.

Anyone had some experience with this?

fredo6

Unfortunately, the time you gain when creating geometry in small groups is then lost when you explode the groups.

Fredo

thomthom

If I explode them afterwards. I might just have use for them in this instance. But generally speaking - is there any other tricks to use?

TIG

Garbage Collection
GC true
?

thomthom

@tig said:

Garbage Collection
GC true
?

AdamB

[Though Ruby's mark and sweep garbage collector is pretty ropey, its likely to be linear in time and probably account for a few percent of total execution time.]

I suspect the fundamental problem is that there is a method inside SU that is doing a linear search - ie start the beginning of a list and walk along until you find what you're looking for - and so the longer the list, the longer the time.

My 2 cents worth, I think Ruby is great for quick tweaks and scripting UI etc. But its simply not up for doing large amounts of "heavy lifting" - just too slow. I had a chance the other day of using Whaats ProfileBuilder; dead cool, but just insane delays as it builds geometry for each mouse click.

I'm coming to the conclusion that if you want to deal with whole models / large amounts of geometry, you really have to use the COM interface - unless I find out the 'linear search' is deep inside the SU proper...

thomthom

I was suspecting that it might be SU trying to intersect geometry with the model as it was added. Or maybe it's something to do with the inference engine.

But what I do fine somewhat odd is that the add_faces_from_mesh method also suffers rather badly. I'd hoped that method would be been more optimized.

Adam, what is this COM interface?

TIG

I meant GC.start which collects garbage from group making etc...

thomthom

@tig said:

I meant GC.start which collects garbage from group making etc...

You use that after creating a group?

In my case here, it's creating geometry in a series of groups which is faster than adding all the geometry into the same context.

TIG

@thomthom said:

@tig said:

I meant GC.start which collects garbage from group making etc...

You use that after creating a group?

In my case here, it's creating geometry in a series of groups which is faster than adding all the geometry into the same context.

GC.start is Jim's baby - built-in - As I understand it you start if before making the groups ?

thomthom

But making groups isn't the problem. In my case it's faster to create a few smaller groups than one big chunk of geometry. That's even when the geometry is generated as a PolygonMesh. The geometry is then added by a single .add_faces_from_mesh. The time it takes to add the mesh isn't linear to the amount of faces generated.
And making a PolygonMesh seem to be twice as fast as generating each face using .add_face - which comes really slow.

AdamB

@tig said:

@thomthom said:

@tig said:

I meant GC.start which collects garbage from group making etc...

You use that after creating a group?

In my case here, it's creating geometry in a series of groups which is faster than adding all the geometry into the same context.

GC.start is Jim's baby - built-in - As I understand it you start if before making the groups ?

GC.start is Mr.Ruby's baby . It gets called automatically (every 256 instructions) by the Ruby interpreter and you generally don't need to call it yourself unless you really know what your doing.

@adamb said:

Adam, what is this COM interface?

Its a hateful, clunky and ultimately pointless way of calling C++ that was introduced by MS many years ago - and since largely abandoned in favour of regular OO solutions. My point isn't about COM, more about calling the SU API directly without using Ruby. AFAIK Google only provide a COM interface to their underlying C++ API.

Jim

@tig said:

GC.start is Jim's baby - built-in - As I understand it you start if before making the groups ?

I thought I learned of it on this forum!

I don't think it's the GC that's slowing adding geometry - more likely it is Sketchup looking to make faces and break overlapping geometry as geometry is either added or exploded. (pure conjecture.)

Whaat

I don't think I've tested this on SU7 but on SU6, using the add_faces_from_mesh method was way faster than adding individual faces using the add_face method. I thought it was 3-4 times faster (but I don't remember for sure). Maybe they have tightened the gap between these method in SU7.1?

For a quick test, just use SDS. Normal operation using the add_faces_from_mesh method, but if you choose the 'copy materials' option, it uses the add_face method.

thomthom

@jim said:

I don't think it's the GC that's slowing adding geometry - more likely it is Sketchup looking to make faces and break overlapping geometry as geometry is either added or exploded. (pure conjecture.)

That's what I was suspecting as well. Was hoping for different result with PolygonMesh - that's it's simple be inserted as-is. But seeing that we don't actually know what it is... ...just guessing.

But I take it there's no tricks hidden up in any sleeves?

thomthom

@whaat said:

I don't think I've tested this on SU7 but on SU6, using the add_faces_from_mesh method was way faster than adding individual faces using the add_face method. I thought it was 3-4 times faster (but I don't remember for sure). Maybe they have tightened the gap between these method in SU7.1?

For a quick test, just use SDS. Normal operation using the add_faces_from_mesh method, but if you choose the 'copy materials' option, it uses the add_face method.

Yes - I find add_faces_from_mesh to be faster than add_face to be faster as well. But comparing the number of polygons in the mesh with the time it takes to add the geometry - time does not increase linearly. It does seem that the time relates to the number of entities already in the context you add to.

AdamB

@jim said:

@tig said:

GC.start is Jim's baby - built-in - As I understand it you start if before making the groups ?

I thought I learned of it on this forum!

I don't think it's the GC that's slowing adding geometry - more likely it is Sketchup looking to make faces and break overlapping geometry as geometry is either added or exploded. (pure conjecture.)

Try this:

` def addfaces(ents = Sketchup.active_model.entities)

vertices = [Geom::Point3d.new(0,0,0), Geom::Point3d.new(1,0,0),Geom::Point3d.new(0,1,0)]

start = Time.new
1000.times do
	ents.add_face vertices	
end
puts "Same tris took #{(Time.new - start)}"

start = Time.new
1000.times do
	ents.add_face vertices
	vertices[0].z += 0.1
	vertices[1].z += 0.1
	vertices[2].z += 0.1
end
puts "different tris took #{(Time.new - start)}"


start = Time.new
1000.times do
	ents.add_face vertices
	vertices[0].z += 0.1
	vertices[1].z += 0.1
	vertices[2].z += 0.1
end
puts "more different tris took #{(Time.new - start)}"

end

addfaces`

Firstly adds 1000 triangles using the same coordinates, secondly adds 1000 triangles with unique vertices, lastly adds another 1000 triangles with unique vertices. Shows a 10x difference in performance, yet the geometry engine will be constructing the topology in all cases - ie doing work.

This would seem to indicate its an insertion bottleneck - which is consistent with thomthom findings.

What does it mean? It means its a brick wall and adding geometry in SU is slow and there is nothing you can do about it.

thomthom

@adamb said:

What does it mean? It means its a brick wall and adding geometry in SU is slow and there is nothing you can do about it.

thomthom

I ran that script four times:

` addfaces
Same tris took 0.05
different tris took 0.71
more different tris took 1.9
nil

addfaces
Same tris took 1.84
different tris took 1.68
more different tris took 1.87
nil

addfaces
Same tris took 1.85
different tris took 1.659
more different tris took 1.89
nil

addfaces
Same tris took 1.85
different tris took 1.69
more different tris took 1.86
nil`

Didn't delete geometry in between.

thomthom

Moved the geometry slightly away from original position and ran three more tests:

` addfaces
Same tris took 1.8
different tris took 2.64
more different tris took 4.13
nil

addfaces
Same tris took 3.62
different tris took 3.26
more different tris took 3.65
nil

addfaces
Same tris took 3.62
different tris took 3.26
more different tris took 3.68
nil`