Thread: [Pythoncad-developer] Draw in oo mode
CAD Application entire developed in Python
Status: Beta
Brought to you by:
matteoboscolo
From: Paolo Z. <zam...@gm...> - 2010-05-15 06:02:03
|
Hi developers, Let read the follow idea! Some days ago I bring my chief a draw, and he told me: “next time it’s better if you bring me a white paper with some random lines on it, so I can fix them on it!”. All times I mind about a list of entities in a document I ask myself: Now who does fix them? All you know everything about the difference between procedural programming and object oriented programming. And no matter, it is most useful the second one. Then, why we draw in procedural mode instead of oo mode? Geometric entities in a draw are the same as the lines in a printed program. Even less complex ones. In fact if I change the order in a printed code line in a program the program won’t even start, instead if I change the order of the entities in a draw nothing wrong happens. The entities in a drow are free from semantics and structure! All of us think about 3D drawings as special ones because of are visual and recognizable. But 3D drawing is special because the designer build and handle objects, and the computer software manage them easily. If you want to do it in 3D you don’t need to do it. You can build, handle and manage objects even in 2D environment. The geometric entities are 1D objects in a 2D environment. The objects we can handle are 2D surfaces in a 2D environment. The surface is the result of a 1D entity closed frame. I mean “frame” as a chain of entities: the end point of an entity is the starting point of the next entity. In a surface you can describe an inside or an outside, a filled side or an empty side. And you can have a function applied to the surface. You can have a hole on a surface. Even you can hide a surface on others and sketch the shadow on it. You can link two surfaces, intersect, add or subtract each others. The final result of all these functions is the projection (view) of the physical object, and you can relate it with other projection of the same object. The projections are positioned on the sheet and dimensioned. You can’t handle 1D entities outside a surface because if you do it you would create a non sense. The designer just have to mind about draw surfaces instead of draw random entities. You can do even more Each function own the tree of functions who generate it. You can generate a function and figure again it’s projection. You can even change the input surfaces of the functions and figure again it’s projections. The surfaces patterns may be parametric, I change one parameter and figure again the relative projection. One projection may be set in relation to the others. In this way if you move or change the projection even the son projections move or changes. It’s a new world! Why do we go on as usual and manage a simple list of entities? Best regards.. Paolo Zambetti |
From: Gertwin G. <ger...@gm...> - 2010-05-17 19:37:57
|
Hi Paolo, I think your ideas about surfaces are interesting. This is how I see this subject, correct me if I am wrong. As you said the boundary of the surfaces are made up from simple linear entities or circles, ellipses. We need functions to create and manipulate simple linear boundary entities. A single boundary entity can serve as edge between 2 surfaces, moving this single entity modifies 2 surfaces. Because entities can act as a boundary between multiple surfaces, these boundary entities itself can not identify the surface object. For instance a single line entity can act as the boundary between the street and a building, this line can not say anything about the surfaces to the left and right. You need to have a kind of way to describe the surface. On the other way not all linear entities can act as an boundary for surfaces. If you have an floor with an table, the table must not result in an island on the floor. So the boundary of the table is not used for the floor. I think all the actions on surfaces (or polygons) that you describes are handled by the GEOS (http://trac.osgeo.org/geos/) project. See the methods of the GEOMETRY object: http://download.osgeo.org/geos/doxygen/classgeos_1_1geom_1_1Geometry.html. I agree with you that we need a good set of functions to describe surface objects. Matteo and I had some discussion about this a while ago. Besides only surfaces, a cad drawing must contain simple linear entities, for instance lines can make up a sewerage system, by binding properties to this line like diameter and material it becomes an (linear) object. Regards, Gertwin 2010/5/15 Paolo Zambetti <zam...@gm...>: > > Hi developers, > > Let read the follow idea! > > Some days ago I bring my chief a draw, and he told me: “next time it’s > better if you bring me a white paper with some random lines on it, so I > can fix them on it!”. All times I mind about a list of entities in a > document I ask myself: Now who does fix them? > > All you know everything about the difference between procedural > programming and object oriented programming. And no matter, it is most > useful the second one. Then, why we draw in procedural mode instead of > oo mode? > > Geometric entities in a draw are the same as the lines in a printed > program. Even less complex ones. In fact if I change the order in a > printed code line in a program the program won’t even start, instead if > I change the order of the entities in a draw nothing wrong happens. The > entities in a drow are free from semantics and structure! > > All of us think about 3D drawings as special ones because of are visual > and recognizable. But 3D drawing is special because the designer build > and handle objects, and the computer software manage them easily. > > If you want to do it in 3D you don’t need to do it. You can build, > handle and manage objects even in 2D environment. The geometric entities > are 1D objects in a 2D environment. > > The objects we can handle are 2D surfaces in a 2D environment. The > surface is the result of a 1D entity closed frame. I mean “frame” as a > chain of entities: the end point of an entity is the starting point of > the next entity. > > In a surface you can describe an inside or an outside, a filled side or > an empty side. And you can have a function applied to the surface. You > can have a hole on a surface. Even you can hide a surface on others and > sketch the shadow on it. You can link two surfaces, intersect, add or > subtract each others. > > The final result of all these functions is the projection (view) of the > physical object, and you can relate it with other projection of the same > object. > > The projections are positioned on the sheet and dimensioned. You can’t > handle 1D entities outside a surface because if you do it you would > create a non sense. The designer just have to mind about draw surfaces > instead of draw random entities. > > You can do even more > > Each function own the tree of functions who generate it. You can > generate a function and figure again it’s projection. You can even > change the input surfaces of the functions and figure again it’s > projections. The surfaces patterns may be parametric, I change one > parameter and figure again the relative projection. > > One projection may be set in relation to the others. In this way if you > move or change the projection even the son projections move or changes. > > It’s a new world! > > Why do we go on as usual and manage a simple list of entities? > > > > Best regards.. > > Paolo Zambetti > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Pythoncad-developer mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer > |
From: Paolo Z. <zam...@gm...> - 2010-05-20 20:10:13
Attachments:
PytonCAD.svg.zip
|
Hi Gertwin, The design is not a puzzle surfaces. Design is an overlap of surfaces. >You need to have a kind of way to > describe the surface. A closed path is one and only one surface. I have attached a svg file with examples. I do not know GEOS. PyCairo is good!. Draw surfaces one above the other > Besides only surfaces, a cad drawing must contain simple linear > entities, for instance lines can make up a sewerage system, by binding > properties to this line like diameter and material it becomes an > (linear) object. If not a path then it is annotation (axsis, dimension,...) I thought the following classes: class sketch(): factory of path . . self._entities=[] # serialized in DB . . def get_path(self) . . return path #continually recalculated class path(): . . self._entities=[] # referece in DB . def get_entity(self,n) . . return path #continually recalculated class Function(): . . self._input_paths=[] # referece in DB . . def get_output_paths(self) . . return paths #continually recalculated def set_position(self,path,n) def set_rotation(self,patth,n,a) def translate(self,x,y) def rotate(a) class Projection(): . . self._Functions=[] # references in DB def set_position(self,path,n) def set_rotation(self,patth,n,a) def translate(self,x,y) def rotate(a) . . class Drawing(): . . self._projections=[] # references in DB self._annotations=[] # references in DB def get_image(self) #continually recalculated Regards, Paolo Il giorno lun, 17/05/2010 alle 21.37 +0200, Gertwin Groen ha scritto: > Hi Paolo, > > I think your ideas about surfaces are interesting. > This is how I see this subject, correct me if I am wrong. > > As you said the boundary of the surfaces are made up from simple > linear entities or circles, ellipses. > We need functions to create and manipulate simple linear boundary entities. > > A single boundary entity can serve as edge between 2 surfaces, moving > this single entity modifies 2 surfaces. > Because entities can act as a boundary between multiple surfaces, > these boundary entities itself can not identify the surface object. > For instance a single line entity can act as the boundary between the > street and a building, this line can not say anything about the > surfaces to the left and right. You need to have a kind of way to > describe the surface. > > On the other way not all linear entities can act as an boundary for surfaces. > If you have an floor with an table, the table must not result in an > island on the floor. > So the boundary of the table is not used for the floor. > > I think all the actions on surfaces (or polygons) that you describes > are handled by the GEOS (http://trac.osgeo.org/geos/) project. > See the methods of the GEOMETRY object: > http://download.osgeo.org/geos/doxygen/classgeos_1_1geom_1_1Geometry.html. > > I agree with you that we need a good set of functions to describe > surface objects. > Matteo and I had some discussion about this a while ago. > > Besides only surfaces, a cad drawing must contain simple linear > entities, for instance lines can make up a sewerage system, by binding > properties to this line like diameter and material it becomes an > (linear) object. > > Regards, > Gertwin > > > 2010/5/15 Paolo Zambetti <zam...@gm...>: > > > > Hi developers, > > > > Let read the follow idea! > > > > Some days ago I bring my chief a draw, and he told me: “next time it’s > > better if you bring me a white paper with some random lines on it, so I > > can fix them on it!”. All times I mind about a list of entities in a > > document I ask myself: Now who does fix them? > > > > All you know everything about the difference between procedural > > programming and object oriented programming. And no matter, it is most > > useful the second one. Then, why we draw in procedural mode instead of > > oo mode? > > > > Geometric entities in a draw are the same as the lines in a printed > > program. Even less complex ones. In fact if I change the order in a > > printed code line in a program the program won’t even start, instead if > > I change the order of the entities in a draw nothing wrong happens. The > > entities in a drow are free from semantics and structure! > > > > All of us think about 3D drawings as special ones because of are visual > > and recognizable. But 3D drawing is special because the designer build > > and handle objects, and the computer software manage them easily. > > > > If you want to do it in 3D you don’t need to do it. You can build, > > handle and manage objects even in 2D environment. The geometric entities > > are 1D objects in a 2D environment. > > > > The objects we can handle are 2D surfaces in a 2D environment. The > > surface is the result of a 1D entity closed frame. I mean “frame” as a > > chain of entities: the end point of an entity is the starting point of > > the next entity. > > > > In a surface you can describe an inside or an outside, a filled side or > > an empty side. And you can have a function applied to the surface. You > > can have a hole on a surface. Even you can hide a surface on others and > > sketch the shadow on it. You can link two surfaces, intersect, add or > > subtract each others. > > > > The final result of all these functions is the projection (view) of the > > physical object, and you can relate it with other projection of the same > > object. > > > > The projections are positioned on the sheet and dimensioned. You can’t > > handle 1D entities outside a surface because if you do it you would > > create a non sense. The designer just have to mind about draw surfaces > > instead of draw random entities. > > > > You can do even more > > > > Each function own the tree of functions who generate it. You can > > generate a function and figure again it’s projection. You can even > > change the input surfaces of the functions and figure again it’s > > projections. The surfaces patterns may be parametric, I change one > > parameter and figure again the relative projection. > > > > One projection may be set in relation to the others. In this way if you > > move or change the projection even the son projections move or changes. > > > > It’s a new world! > > > > Why do we go on as usual and manage a simple list of entities? > > > > > > > > Best regards.. > > > > Paolo Zambetti > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Pythoncad-developer mailing list > > Pyt...@li... > > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer > > |
From: Matteo B. <mat...@bo...> - 2010-05-20 21:08:39
|
Hi Paolo, I'm very interested in your approach.. it something out of the box.. But I think that manage this structure in python will be very difficult without a C library..or an external support and this is not what we want in Pythoncad.. As sent today .. we have the first qt version of the new kernel and after 6 month of work we start to see something interesting .. so I do not want to change again the PythonCad Structure .. We need to have a good and stable version for the end of this yard .This is my primary target for the project. So if you want to try to develop this kind of structure ..and see if it takes somewere .. You can build a new git branch in the repository called R38_experimental and do all your test there .. I can give you all the help you need to understand the actual kernel for managing your new structure. Regards, Matteo -----Original Message----- From: Paolo Zambetti [mailto:zam...@gm...] Sent: 20 May 2010 22:10 To: PythonCad Developer Subject: Re: [Pythoncad-developer] Draw in oo mode Hi Gertwin, The design is not a puzzle surfaces. Design is an overlap of surfaces. >You need to have a kind of way to > describe the surface. A closed path is one and only one surface. I have attached a svg file with examples. I do not know GEOS. PyCairo is good!. Draw surfaces one above the other > Besides only surfaces, a cad drawing must contain simple linear > entities, for instance lines can make up a sewerage system, by binding > properties to this line like diameter and material it becomes an > (linear) object. If not a path then it is annotation (axsis, dimension,...) I thought the following classes: class sketch(): factory of path . . self._entities=[] # serialized in DB . . def get_path(self) . . return path #continually recalculated class path(): . . self._entities=[] # referece in DB . def get_entity(self,n) . . return path #continually recalculated class Function(): . . self._input_paths=[] # referece in DB . . def get_output_paths(self) . . return paths #continually recalculated def set_position(self,path,n) def set_rotation(self,patth,n,a) def translate(self,x,y) def rotate(a) class Projection(): . . self._Functions=[] # references in DB def set_position(self,path,n) def set_rotation(self,patth,n,a) def translate(self,x,y) def rotate(a) . . class Drawing(): . . self._projections=[] # references in DB self._annotations=[] # references in DB def get_image(self) #continually recalculated Regards, Paolo Il giorno lun, 17/05/2010 alle 21.37 +0200, Gertwin Groen ha scritto: > Hi Paolo, > > I think your ideas about surfaces are interesting. > This is how I see this subject, correct me if I am wrong. > > As you said the boundary of the surfaces are made up from simple > linear entities or circles, ellipses. > We need functions to create and manipulate simple linear boundary entities. > > A single boundary entity can serve as edge between 2 surfaces, moving > this single entity modifies 2 surfaces. > Because entities can act as a boundary between multiple surfaces, > these boundary entities itself can not identify the surface object. > For instance a single line entity can act as the boundary between the > street and a building, this line can not say anything about the > surfaces to the left and right. You need to have a kind of way to > describe the surface. > > On the other way not all linear entities can act as an boundary for surfaces. > If you have an floor with an table, the table must not result in an > island on the floor. > So the boundary of the table is not used for the floor. > > I think all the actions on surfaces (or polygons) that you describes > are handled by the GEOS (http://trac.osgeo.org/geos/) project. > See the methods of the GEOMETRY object: > http://download.osgeo.org/geos/doxygen/classgeos_1_1geom_1_1Geometry.html. > > I agree with you that we need a good set of functions to describe > surface objects. > Matteo and I had some discussion about this a while ago. > > Besides only surfaces, a cad drawing must contain simple linear > entities, for instance lines can make up a sewerage system, by binding > properties to this line like diameter and material it becomes an > (linear) object. > > Regards, > Gertwin > > > 2010/5/15 Paolo Zambetti <zam...@gm...>: > > > > Hi developers, > > > > Let read the follow idea! > > > > Some days ago I bring my chief a draw, and he told me: “next time > > it’s better if you bring me a white paper with some random lines on > > it, so I can fix them on it!”. All times I mind about a list of > > entities in a document I ask myself: Now who does fix them? > > > > All you know everything about the difference between procedural > > programming and object oriented programming. And no matter, it is > > most useful the second one. Then, why we draw in procedural mode > > instead of oo mode? > > > > Geometric entities in a draw are the same as the lines in a printed > > program. Even less complex ones. In fact if I change the order in a > > printed code line in a program the program won’t even start, instead > > if I change the order of the entities in a draw nothing wrong > > happens. The entities in a drow are free from semantics and structure! > > > > All of us think about 3D drawings as special ones because of are > > visual and recognizable. But 3D drawing is special because the > > designer build and handle objects, and the computer software manage them easily. > > > > If you want to do it in 3D you don’t need to do it. You can build, > > handle and manage objects even in 2D environment. The geometric > > entities are 1D objects in a 2D environment. > > > > The objects we can handle are 2D surfaces in a 2D environment. The > > surface is the result of a 1D entity closed frame. I mean “frame” as > > a chain of entities: the end point of an entity is the starting > > point of the next entity. > > > > In a surface you can describe an inside or an outside, a filled side > > or an empty side. And you can have a function applied to the > > surface. You can have a hole on a surface. Even you can hide a > > surface on others and sketch the shadow on it. You can link two > > surfaces, intersect, add or subtract each others. > > > > The final result of all these functions is the projection (view) of > > the physical object, and you can relate it with other projection of > > the same object. > > > > The projections are positioned on the sheet and dimensioned. You > > can’t handle 1D entities outside a surface because if you do it you > > would create a non sense. The designer just have to mind about draw > > surfaces instead of draw random entities. > > > > You can do even more > > > > Each function own the tree of functions who generate it. You can > > generate a function and figure again it’s projection. You can even > > change the input surfaces of the functions and figure again it’s > > projections. The surfaces patterns may be parametric, I change one > > parameter and figure again the relative projection. > > > > One projection may be set in relation to the others. In this way if > > you move or change the projection even the son projections move or changes. > > > > It’s a new world! > > > > Why do we go on as usual and manage a simple list of entities? > > > > > > > > Best regards.. > > > > Paolo Zambetti > > > > > > -------------------------------------------------------------------- > > ---------- > > > > _______________________________________________ > > Pythoncad-developer mailing list > > Pyt...@li... > > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer > > |
From: Paolo Z. <zam...@gm...> - 2010-05-21 19:59:21
|
Hi Matteo, was just an idea. Do not have time to fully develop. Perhaps in the future. Regards, Paolo > Hi Paolo, > I'm very interested in your approach.. it something out of the box.. > But I think that manage this structure in python will be very difficult without a C library..or an external support > and this is not what we want in Pythoncad.. > > As sent today .. we have the first qt version of the new kernel and after 6 month of work we start to see something interesting .. so I do not want to change again the PythonCad Structure .. > We need to have a good and stable version for the end of this yard .This is my primary target for the project. > > So if you want to try to develop this kind of structure ..and see if it takes somewere .. > You can build a new git branch in the repository called R38_experimental and do all your test there .. > > I can give you all the help you need to understand the actual kernel for managing your new structure. > > Regards, > Matteo |