Why does App::MaterialObjectPython needs a Shape?

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
furti
Posts: 329
Joined: Mon Nov 27, 2017 5:27 pm

Why does App::MaterialObjectPython needs a Shape?

Postby furti » Fri Aug 23, 2019 4:29 pm

I don't know exactly when it happend but since some time a Material created with the Arch Workbench has a Shape.

This lead to a problem when texturing objects (https://forum.freecadweb.org/viewtopic. ... 22#p328398). It was an easy fix so no problem here.

But I'm wondering what the purpose of a Shape for a material might be?

Version: 0.19.17505 (Git)

Code: Select all

>>> mat = FreeCAD.ActiveDocument.getObject('Material')
>>> mat.Shape
Traceback (most recent call last):
  File "<input>", line 1, in <module>
AttributeError: 'FeaturePython' object has no attribute 'Shape'
>>> mat
<App::MaterialObjectPython object>
>>> 
Version: 0.19.17803 (Git)

Code: Select all

>>> mat = FreeCAD.ActiveDocument.getObject('Material')
>>> mat.Shape
<Shape object at 000002C15A1118E0>
>>> mat
<App::MaterialObjectPython object>
User avatar
DeepSOIC
Posts: 7145
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Why does App::MaterialObjectPython needs a Shape?

Postby DeepSOIC » Fri Aug 23, 2019 4:55 pm

It looks like everything 3d now has a shape property:

Code: Select all

>>> o = App.ActiveDocument.addObject("App::GeoFeature")
created object
>>> o.Shape
<Shape object at 000001B917B439D0>
>>> 
User avatar
DeepSOIC
Posts: 7145
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Why does App::MaterialObjectPython needs a Shape?

Postby DeepSOIC » Fri Aug 23, 2019 4:56 pm

No, it's literally everything:

Code: Select all

>>> o = App.ActiveDocument.addObject("App::DocumentObject")
created object
>>> o.Shape
<Shape object at 000001B917B42590>
User avatar
DeepSOIC
Posts: 7145
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Why does App::MaterialObjectPython needs a Shape?

Postby DeepSOIC » Fri Aug 23, 2019 5:08 pm

Here's the explanation:
https://github.com/realthunder/FreeCAD_ ... anges#part
PropertyContainerPy also contains a modification to return Shape attribute of any object that does not have a Shape property using Part.getShape(). This modification allows most Part Python feature to work with Link without code modification.
There's one strange thing though. Document is a PropertyContainer too. But:

Code: Select all

>>> App.ActiveDocument.Shape
Traceback (most recent call last):
  File "<input>", line 1, in <module>
AttributeError: 'App.Document' object has no attribute 'Shape'
>>> 
:?
User avatar
furti
Posts: 329
Joined: Mon Nov 27, 2017 5:27 pm

Re: Why does App::MaterialObjectPython needs a Shape?

Postby furti » Fri Aug 23, 2019 6:31 pm

I don't know the internals of the App::Link implementation. But why does everything need a shape to work with linking? What is the benefit of having a Null Shape over simply having no shape at all?

So why does a Material need a Shape to be linked? The Shape does not carry any information that defines a Material. But maybe I'm wrong here.
User avatar
DeepSOIC
Posts: 7145
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Why does App::MaterialObjectPython needs a Shape?

Postby DeepSOIC » Fri Aug 23, 2019 7:12 pm

furti wrote:
Fri Aug 23, 2019 6:31 pm
But why does everything need a shape to work with linking?
No idea. I would naturally expect Shape attribute for all App::Link extended objects then, not for all objects.
User avatar
DeepSOIC
Posts: 7145
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Why does App::MaterialObjectPython needs a Shape?

Postby DeepSOIC » Sat Aug 24, 2019 12:42 am

After thinking about it a bit, I think that everything having a Shape is a harmful change. Like, I think I used the presence of Shape attribute as a validity test too. Now, such a validity test is being bypassed, and a null shape is then fed to the algorithm instead. Which is very likely to crash, as I think there are still holes in our API that may let null shape pass to OCC algos, which usually crash then.
User avatar
yorik
Site Admin
Posts: 11574
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Why does App::MaterialObjectPython needs a Shape?

Postby yorik » Mon Aug 26, 2019 2:36 pm

DeepSOIC wrote:
Sat Aug 24, 2019 12:42 am
After thinking about it a bit, I think that everything having a Shape is a harmful change. Like, I think I used the presence of Shape attribute as a validity test too. Now, such a validity test is being bypassed, and a null shape is then fed to the algorithm instead. Which is very likely to crash, as I think there are still holes in our API that may let null shape pass to OCC algos, which usually crash then.
Agree, I use the same test in several places... And it's also not logical IMHO, we shouldn't suppose every FreeCAD object has a shape. @realthunder what's your take on this?
realthunder wrote: ping
realthunder
Posts: 1229
Joined: Tue Jan 03, 2017 10:55 am

Re: Why does App::MaterialObjectPython needs a Shape?

Postby realthunder » Mon Aug 26, 2019 11:30 pm

DeepSOIC wrote:
Sat Aug 24, 2019 12:42 am
After thinking about it a bit, I think that everything having a Shape is a harmful change. Like, I think I used the presence of Shape attribute as a validity test too. Now, such a validity test is being bypassed, and a null shape is then fed to the algorithm instead. Which is very likely to crash, as I think there are still holes in our API that may let null shape pass to OCC algos, which usually crash then.
I'll modify PropertyContainerPy to return the Shape if it is not null. If there is really a property called Shape, the code in PropertyContainerPy will not be reached, and it just returns whatever is inside. If there isn't, it uses Part.getShape() to obtain shape, so you can now simply use App.Link, App.Part, or even plain group to do modeling if you want, for Python code that is. C++ code such as PartDesign still need modification. But I have already modified Part to work with it.

On the other hand, you may also want to know that I have modified all PropertyContainer object to be able to accept dynamic property. Adding a Shape property is of course possible, so you might as well check for null when using the shape. I imagine this extended dynamic property to be especially useful for container type of objects, so that the container can inject any type of property to its children for various purpose. To avoid name conflict, you can form the property name by prepend it with the container's internal name.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
ezzieyguywuf
Posts: 635
Joined: Tue May 19, 2015 1:11 am

Re: Why does App::MaterialObjectPython needs a Shape?

Postby ezzieyguywuf » Tue Aug 27, 2019 2:43 am

yorik wrote:
Mon Aug 26, 2019 2:36 pm
DeepSOIC wrote:
Sat Aug 24, 2019 12:42 am
After thinking about it a bit, I think that everything having a Shape is a harmful change. Like, I think I used the presence of Shape attribute as a validity test too. Now, such a validity test is being bypassed, and a null shape is then fed to the algorithm instead. Which is very likely to crash, as I think there are still holes in our API that may let null shape pass to OCC algos, which usually crash then.
Agree, I use the same test in several places... And it's also not logical IMHO, we shouldn't suppose every FreeCAD object has a shape. @realthunder what's your take on this?
realthunder wrote: ping
While I'm not nearly as close to this "the big merge" as any of you are, I feel that I've mucked about in the internals of FreeCAD long enough to merit an opinion.

I agree that that it is not logical that everything have a Shape.

Rather, in keeping with general Object Oriented philosophy: something that is a Shape (or manages the lifetime of one), should contain a Shape.