Wall Placement should be necessarily relative to walltrace placement?

[paullee]

Interesting

[carlopav]

Interesting

And dangerous indeed! Let's wait for some feedback, I don't want to mess up things without a serious discussion

[paullee]

Trying to find more about OriginGroupExtensionPython, not much, any idea ?

This is from Arch BuildingPart

Code: Select all

class BuildingPart(ArchIFC.IfcProduct):


    "The BuildingPart object"

    def __init__(self,obj):

        obj.Proxy = self
        obj.addExtension('App::GroupExtensionPython', self)
        #obj.addExtension('App::OriginGroupExtensionPython', self)
        self.setProperties(obj)

Thanks.

[carlopav]

Yorik wrote in another topic - I searched for it but didn't find it anymore - that his original idea was to derive BuildingPart from App::Part.
But he gave up at some point, mainly because the SyncPlacement feature was not already implemented at that time.
Anyway, let's not be hasty, just let's allow others to evaluate everything. It could be I'm making a big mistake and not considerating many things...

[carlopav]

I told not to be hasty, but I am! Last screenshot showing the possibilities of this approach before going to bed. Goodnight!

Cattura.JPG (98.1 KiB) Viewed 1030 times

[yorik]

The reason why I didn't go the App::Part way is that I wanted placements of objects inside BuildingParts to be always explicit. In App::Part they are hidden. A column placed at (0,0,0), if you put it in an App::Part that is at (0,0,300), it will still appear programmatically at (0,0,0) but visually at (0,0,300). If you remove the column from the App::PArt, it "jumps back" to (0,0,0).

In BIM workflows, I think it's important to carry real-world coordinates. If the column appears at (0,0,300), it should "physically" be at (0,0,300). If you remove it from the BuildingPart, it should remain at (0,0,300).

At least that's my opinion... Totally open to discussion.

Of course placement syncing fixes things, but again, why use a structure that introduces a thing that we don't want, and subsequently a fix to it, rather than a more simple object that skips these two operations.

About wall and walltrace, I have no strong opinion, and in some way this is an impossible problem to solve... wall traces can be just anything. There is no point trying to find the "correct" origin point that a wall should have...

[carlopav]

Oh, we should discuss this so, because this is a total non go for my solution...

In BIM workflows, I think it's important to carry real-world coordinates. If the column appears at (0,0,300), it should "physically" be at (0,0,300). If you remove it from the BuildingPart, it should remain at (0,0,300).

At least that's my opinion... Totally open to discussion.

I'm sorry but I don't get:

1) Why it is important.

2) Why it can't be achieved with App Part:
if an object (ex. a column that appears at (0,0,300)) is into an App::Part (placed at (0,0,200)) you can always:
- ask him for his Placement ---> and you get the placement relative to it's parent container (ex. (0,0,100));
- ask him for getGlobalPlacement ---> and obtain it's Placement related to the global coordinates system (ex. (0,0,300));
- you can move one object from one container to the other without making it jump, or even making it jump if you want (think about if you want to move something to one floor to the other: you can just move it into the upper part and it will jump on the upper floor! )

So, I'm stubborn, I know, but I really dont get your point, can you explain it to me again? I really want to understand this.

[yorik]

I think in 99% of the case you will need to use getGlobalPlacement because for almost anything you'll need world coordinates of the geometry and never "visual" coordinates... So I don't really see the point of using a structure that you basically won't use... Like, by using App::Parts we would need to subclass it anyway to handle moving stuff in/out of it without jumping... So I don't really see an advantage in using it.

But I also don't see any problem in introducing other solutions if you prefer... Why not work on yours? There is no problem in having several ways to do one same thing.

[carlopav]

Disclaimer: I do not want to convince you, I just want to understand the logic behind current implementation.

I think in 99% of the case you will need to use getGlobalPlacement because for almost anything you'll need world coordinates of the geometry and never "visual" coordinates... So I don't really see the point of using a structure that you basically won't use...

I think here there I did misunderstand something: why do you use "visual" coordinates? I would use "relative" coordinates instead. And I think they are really really helpful in BIM workflow. Imagine we have a chair at the 4th floor: aren't we interested to know if it's on the floor or is floating at 1 m height from the floor level?

Like, by using App::Parts we would need to subclass it anyway to handle moving stuff in/out of it without jumping... So I don't really see an advantage in using it.

I strongly believe we do not have to subclass App::Part. It would be a big error, I agree (I'm thinking at this approach exactly to minimize custom objects). I was thinking to something more similar to Assembly4: as to say to use a standard App::Part and to place inside an object that holds all the "Informations" we need for IFC and properties of that Part.

I'm not going to work on this right now, and perhaps never: i will never build my own Arch workbench also if this means i just have to give up to my plans: I'm more interested in sharing the efforts towards a common goal... so please let's continue this conversation, it's really interesting to me

[yorik]

Also don't want to convince you I really like the fact that several options are possible at the same time. You have a point about relative coordinates and "floating" objects, though. I guess it's rather two different mindsets. I like to think of a building as a whole, where I know the coordinates of every object and I'm interested in its Z coordinate. While it's also possible to think of a building by floor plan, and then you would wish to "start fresh" on each floor plan and have all coordinates relative to it.

In any case I totally agree supporting standard App::Parts throughout Arch/BIM would be great. As well as App::Links.