You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have discovered that there is a logic flow issue with the ObjSurfMap (OSM).
The OSM is designed to keep a map of all objects and signed surfaces so that rapid line tracking can be carried out. (i.e. only check objects that actually share a surface of opposite sign). This obviously needs two things (a) the surfaces are unique (b) the reversed planes are removed. That is believe to be ok.
However, in the OSM build up -- it is possible that an object has surfaces removed and added BUT there is no explicit way to remove those surfaces. E.g. an object with surfaces 1 -2 3 4 is modified to be
1 2 101 -104 then the OSM will reflect 1 -2 3 4 101 -104 which is clearly wrong.
I am not aware that this actually causes the code to fail in any place [I accept it could in principle] but it is clearly inefficient, so should be removed. It can occur very badly as an object is split via a mergeTemplate or via the action objects, LD3 / LD1.
I have a rather tight deadline tonight so can't fix it until later this week -- but I wrote this issue so the work around I am doing in portItem etc is clearly not something to copy. (and it is such a horrific oversight -- the general reason for the oversight should be looked at [i.e. I made OSM is a singleton -- which was a very poor decision and should be addressed]).
Any comments / suggestions etc would be much appreciated.
The text was updated successfully, but these errors were encountered:
I have discovered that there is a logic flow issue with the ObjSurfMap (OSM).
The OSM is designed to keep a map of all objects and signed surfaces so that rapid line tracking can be carried out. (i.e. only check objects that actually share a surface of opposite sign). This obviously needs two things (a) the surfaces are unique (b) the reversed planes are removed. That is believe to be ok.
However, in the OSM build up -- it is possible that an object has surfaces removed and added BUT there is no explicit way to remove those surfaces. E.g. an object with surfaces 1 -2 3 4 is modified to be
1 2 101 -104 then the OSM will reflect 1 -2 3 4 101 -104 which is clearly wrong.
I am not aware that this actually causes the code to fail in any place [I accept it could in principle] but it is clearly inefficient, so should be removed. It can occur very badly as an object is split via a mergeTemplate or via the action objects, LD3 / LD1.
I have a rather tight deadline tonight so can't fix it until later this week -- but I wrote this issue so the work around I am doing in portItem etc is clearly not something to copy. (and it is such a horrific oversight -- the general reason for the oversight should be looked at [i.e. I made OSM is a singleton -- which was a very poor decision and should be addressed]).
Any comments / suggestions etc would be much appreciated.
The text was updated successfully, but these errors were encountered: