Support Forum

[Frage] Creating PythonPart with Interactor - Problem with reference point

Schlagworte:
  • Pythonpart
  • Interactor
  • Reference
  • Point
Diego_Somaini
Diego_Soma…
05.01.2025 - 19:13

Hi,

I would like to create a PythonPart within an interactor. This works fine so far, except that I can't control the reference point of the PythonPart.
The PythonPart is created with the following code.

pyp_util.add_pythonpart_view_2d3d(self.model_ele_list)
self.model_ele_list = pyp_util.create_pythonpart(build_ele, AllplanGeo.Matrix3D(), AllplanGeo.Matrix3D())
AllplanBaseElements.CreateElements(self.doc, mat, self.model_ele_list, self.modify_uuid_list, None)
# mat = Matrix3D with Insertion Point

The insertion point of the PythonPart is adopted correctly. However, a "strange" reference point within the PythonPart is adopted. I have tried to control the reference point of the PythonPart adding PythonPartViewData in pyp_util, but this does not work. You can use PythonPartViewData to control the visibility of the layers, but the reference point is not taken over.
Has anyone had similar experiences and a solution for this problem?

Many thanks and best regards
Diego

Hilfreichste Antwort anzeigen Hilfreichste Antwort verbergen

bmarciniec
bmarciniec
14.01.2025 - 12:51 *

Zitiert von: Diego_Somaini
Hi Bart
If the PythonPart is newly created, the new geometry is not adopted. This also applies if the old PythonPart is deleted from the model first. It seems as if the information of the first PythonPart is stored in the cache and cannot be deleted.

If the second PythonPart is created on a new drawing file, the modified geometry is adopted correctly. This means that the cache is linked to the drawing file.

Is there a way to delete the cache that influences the PythonParts? I am convinced that this would solve my problem.
I use Allplan 2024.

The problem you are encountering is a completely different one, than in the topic, but I can explain anyway: when you create a PythonPart element in the model, it becomes a hash. The hash is then used by Allplan to:

  • Determine the "identical" PythonParts
  • Determine, whether the PythonPart has changed and the database must be updated

The hash is generated from all the parameters.

The next thing to remember is: a PythonPart is saved in the database as one definition and multiple placements. A placement refers to a definition using the hash.

Now to your problem: when you place a single PythonPart in the DF, you create a definition (with a hash X) and a placement (also with hash X). When you then delete it right away, you only delete the placement, the definition remains. So when you change only the code and place the PythonPart again, you are again placing it with hash X. Allplan compares the hashes and see, that there is already a definition for the hash X, so it doesn't create a new one. Thus: you see the old state of your PythonPart, before the code change.

Solution: To clean up the definitions, that are no longer used by any placement, reorganize the DF (Ctrl + F5 , or File -> Reorganize Drawing File)

Best,
Bart

bmarciniec
bmarciniec
08.01.2025 - 17:11

Zitiert von: Diego_Somaini
Hi,
I would like to create a PythonPart within an interactor. This works fine so far, except that I can't control the reference point of the PythonPart.

The PythonPart is created with the following code.
pyp_util.add_pythonpart_view_2d3d(self.model_ele_list)

self.model_ele_list = pyp_util.create_pythonpart(build_ele, AllplanGeo.Matrix3D(), AllplanGeo.Matrix3D())

AllplanBaseElements.CreateElements(self.doc, mat, self.model_ele_list, self.modify_uuid_list, None)

# mat = Matrix3D with Insertion Point
The insertion point of the PythonPart is adopted correctly. However, a "strange" reference point within the PythonPart is adopted. I have tried to control the reference point of the PythonPart adding PythonPartViewData in pyp_util, but this does not work. You can use PythonPartViewData to control the visibility of the layers, but the reference point is not taken over.

Has anyone had similar experiences and a solution for this problem?
Many thanks and best regards

Diego


Hi Diego,

I think we need more information. First, what do you mean "strange reference point"? Is it located not in the lower-left corner of your geometry? If that is the case, the reasons can be pretty complex. E.g. I don't know, what is inside your model_ele_list. I ran this piece of code:

        mat = AllplanGeo.Matrix3D()
        mat.SetTranslation(AllplanGeo.Vector3D(1000, 1000, 1000))

        geo = AllplanGeo.Polyhedron3D.CreateCuboid(AllplanGeo.Point3D(), AllplanGeo.Point3D(1000, 1000, 1000))
        model_ele_list = ModelEleList()
        model_ele_list.append_geometry_3d(geo)

        pyp_util = PythonPartUtil()
        pyp_util.add_pythonpart_view_2d3d(model_ele_list)

        model_ele_list = pyp_util.create_pythonpart(build_ele, AllplanGeo.Matrix3D(), AllplanGeo.Matrix3D())

        AllplanBaseElements.CreateElements(doc, mat, model_ele_list, [], None)

And the reference point is correctly in the lower-left corner of my cube. But as you can see, there is only this simple cube in my model_ele_list. Can you maybe adapt the code step-by-step towards the moment, where you reach the effect you encounter and tell us, what was the step, that induced the problem? Or maybe you encounter the problem right away in your Allplan version (I ran this code in Allplan 2025)? Let us know.

Best,
Bart

Diego_Somaini
Diego_Soma…
11.01.2025 - 10:00

Hi Bart

Thank you very much for your reply.
I have made a test with your code. The cube is created correctly in the PythonPart and the PythonPart is placed correctly in the model.
I chose the following dimensions for the first cube:

geo = AllplanGeo.Polyhedron3D.CreateCuboid(AllplanGeo.Point3D(), AllplanGeo.Point3D(1000, 1000, 1000))

I then modified the py file and chosed the following geometry for the cube:
geo = AllplanGeo.Polyhedron3D.CreateCuboid(AllplanGeo.Point3D(), AllplanGeo.Point3D(2000, 1000, 1000))

If the PythonPart is newly created, the new geometry is not adopted. This also applies if the old PythonPart is deleted from the model first. It seems as if the information of the first PythonPart is stored in the cache and cannot be deleted.
If the second PythonPart is created on a new drawing file, the modified geometry is adopted correctly. This means that the cache is linked to the drawing file.

In the pyp file I have inserted the code that the last entry should not be read. However, this has no influence on the result.

<Script>
    <Name>901 Diego_Test\102 Bewehrungssymbol\102_Bewehrungssymbol.py</Name>
    <Title>Bewehrung Symbol für Beschriftung</Title>
    <Version>1.0</Version>
    <Interactor>True</Interactor>
    <ReadLastInput>False</ReadLastInput>
</Script>

Is there a way to delete the cache that influences the PythonParts? I am convinced that this would solve my problem.
I use Allplan 2024.

Many thanks and best regards
Diego

bmarciniec
bmarciniec
14.01.2025 - 12:51 * [Hilfreichste Antwort]

Zitiert von: Diego_Somaini
Hi Bart
If the PythonPart is newly created, the new geometry is not adopted. This also applies if the old PythonPart is deleted from the model first. It seems as if the information of the first PythonPart is stored in the cache and cannot be deleted.

If the second PythonPart is created on a new drawing file, the modified geometry is adopted correctly. This means that the cache is linked to the drawing file.

Is there a way to delete the cache that influences the PythonParts? I am convinced that this would solve my problem.
I use Allplan 2024.

The problem you are encountering is a completely different one, than in the topic, but I can explain anyway: when you create a PythonPart element in the model, it becomes a hash. The hash is then used by Allplan to:

  • Determine the "identical" PythonParts
  • Determine, whether the PythonPart has changed and the database must be updated

The hash is generated from all the parameters.

The next thing to remember is: a PythonPart is saved in the database as one definition and multiple placements. A placement refers to a definition using the hash.

Now to your problem: when you place a single PythonPart in the DF, you create a definition (with a hash X) and a placement (also with hash X). When you then delete it right away, you only delete the placement, the definition remains. So when you change only the code and place the PythonPart again, you are again placing it with hash X. Allplan compares the hashes and see, that there is already a definition for the hash X, so it doesn't create a new one. Thus: you see the old state of your PythonPart, before the code change.

Solution: To clean up the definitions, that are no longer used by any placement, reorganize the DF (Ctrl + F5 , or File -> Reorganize Drawing File)

Best,
Bart

cmaignan
cmaignan
14.01.2025 - 13:47 *

Thanks Bart for your explanations about clean up the definitions

Best
Christophe

Bertrand_C
Bertrand_C
14.01.2025 - 14:27

Hello,

One trick is to add a parameter that will receive a random value each time it is run.
In this way, each PythonPart will be unique and Allplan will not replace it with a previous one.


Diego_Somaini
Diego_Soma…
18.01.2025 - 16:25

Thank you very much for the explanations and for the trick with the random value. I will try this.
Best regards Diego