50 lines
2.9 KiB
Plaintext
50 lines
2.9 KiB
Plaintext
Some notes about Entities, Entity IDs and the IdList structure
|
|
==============================================================
|
|
Sketch entities in SolveSpace are all of the same type without use of language
|
|
support for polymorphism. The entity class is defined in sketch.h. That class
|
|
contains an enum for each entity to define its type (line, arc, etc...) and some
|
|
other members that can be used to store different things depending on the entity
|
|
type. This means all entities are the same size, so some data may be reference
|
|
by pointers from the entity (font, extra points, etc...)
|
|
|
|
Entities in a sketch are kept in a global array (IdList) referenced by a unique
|
|
Id (handle) and can be looked up by Id in log(n) time via binary search. In
|
|
order to use binary seach the array must be kept in order sorted by Id. One
|
|
problem is that insertion takes O(n) time because half the list (on average)
|
|
must be shifted to make room for a new item.
|
|
|
|
The IdList class is a template and is used for more than entites.
|
|
|
|
EntityMap:
|
|
==========
|
|
Another important structure is the EntityMap and EntityKey defined in sketch.h
|
|
This is what allows SovleSpace to update groups when earlier groups in the
|
|
sketch are changed. If a rectangle is extruded to a box and items are
|
|
constrained to entites on that box, the user can go back to the sketch and
|
|
modify it. Entites can be added, modified an even deleted. So long as the
|
|
entites that are later used to build upon are kept the later extrude group will
|
|
pick up the changes from the 2D sketch and anything build on it will remain.
|
|
|
|
The way this works is that each group has a member called remap, which is one of
|
|
these maps. This is where my understanding is fuzzy. At the end of Group.cpp is
|
|
a function called Group::CopyEntity() which is used to make new sketch entites
|
|
when a group is created. These are generally copies of entities in the previous
|
|
group, but there are exceptions. A point will be used to generate a line when
|
|
extruding a 2D sketch. A point will also be "copied" to a circle for a Lathe
|
|
group. For this reason, the entity key is derived by combining its previous key
|
|
with something often called the CopyNumber or just remap (unfortunate).
|
|
|
|
When a group is regenerated (the first time, or after a previous one is
|
|
modified) entites are copied from the old group to the new one. For Step
|
|
Translating and Rotating there may be many copies, and the copy number is
|
|
literally N for the Nth copy except for the last one which gets an enum - it is
|
|
common to constrain the last item, so it gets a large unique number so that
|
|
constraints still refer to it if the number of copies changes. When an entity is
|
|
copied like this a new handle is created unless there is already an entity in
|
|
Remap that was created the same way. This is how constructions are preserved
|
|
across underlying changes.
|
|
|
|
There are some hard limits used in the hash table for the remap mechanism which
|
|
limit the number of entites in a group (but not the global sketch).
|
|
|