OficineRobotica wrote: ↑Tue Feb 23, 2021 5:52 am
I hate to be the annoying guy but I'm facing a problem and it could be related to the topo naming algorithm .
In the attached file there is an assembly that contains a link called "Bracket002". The "Bracket002" link references a body that has a configuration table set up for it. This link has the property <LinkCopyOnChange> set to <Enable> and also has some sublinks.
You are entering some no man's land there.
I'd like to correct some misconception first about this solution to the Topological Naming Problem. The first the most important thing to solve is to detect topo name changes. With upstream, the indexed based topo name can change arbitrarily because of model history changes, and the user is not notified about this, until he/she finds out that something looks odd in the final shape. And tracing back the origin of the problem becomes difficult. So, the first thing to solve is to detect changes exactly at the referencing site.
The secondary, or shall I say, the other good-to-have bonus feature is for the algorithm to auto deduce what the referenced geometry has changed into. This involves guess work, and there will never be 100% foolproof solution. There is some auto deducing implemented in my branch, but they are quite conservative. If the algorithm is not sure about the result, it will mark the referencing object as error, and in other word, ask for user intervention. Since the problem is reported at the source, it is relatively easy to correct.
Now back to your use case here. The direct cause of the element error is actually not the topo naming error, at least not there yet. It is because variant link will copy its linked object on configuration change. The copy only happens on first change. Once changed, it will become "Owned". The copied object will change its name, and that is what caused the element error. The linked element can be found in element's LinkedObject property. There you'll see string path leading to the referenced geometry. Any object along the path misplaced will cause an error. It is possible for me to add extra code to auto correct any existing links that refers any sub-object of the mutating link, but it won't solve your problem here. Because the copied geometry will have totally different topo names than its origin. The topo names encode inside the object ID for uniqueness and history tracing. Copied objects all have different IDs, therefore will form completely independent history. It is as if you have replaced it with an unrelated part.
The recommended way, when used inside an assembly, is to mutate the part before hand, and create a sub-assembly to wrap each mutated part, create element manually to be used by upper assembly for constraining. And most importantly, assign the same label for each element in those sub-assembly to create a common interface so that they can be used by upper assembly interchangeably. You can add any one of the sub-assembly to an upper assembly using link, and then create configuration for the upper assembly to dynamically change what this link points to.
The interchangable assembly/part is one of the main purpose of the Element
concept introduced by asm3 before I worked on topo naming. There is also a tutorial
4- Now that I'm here I wanted to report some problems with shadow. In the latest releases it seems that shadow on the ground is a bit hit and miss if the ground is transparent. I played with the <BoundBoxScale> and <Epsilon> but the shadows on the ground aren't there although the model itself receives them. I didn't want to report this but I think that the new renderer is not yet around the corner and shadows is what give visual punch to screenshots. That is important for PR reasons
Can you please post a video showing the problem in the shadow thread? Your bounding box is too big, which will severely lower the quality of the generated shadow. Consider that the shadow is drawn on a fixed size image. The bounding box defines how big the area to fit into this image. If it's too big, the shadow will be scaled down too much.