March 20, 2019 at 19:50 #4616Ignacio Bevilacqua TrabadoParticipant
Hello, my name is Ignacio Bevilacqua. I want to develop a python grasshopper component that works in conjunction with some GDL code I wrote. Basically the GDL code is a series of for loops through the different NURBS commands that take the input from a txt file (that the python component creates previously) and put it in the parameter buffer to execute the command. The python component basically gathers in Rhino all the necessary information about the geometry in order to execute the GDL NURBS corresponding command, it works with LiveConnection and would be a great asset for the ArchiCad community.
The code seems to work fine on some geometry but crash on others. Checking my code and comparing it to regular 3dm file import as library objects I can compare the codes and I see differences in Domain span, sign, and sign of trim indexing, but I don’t understand why it behaves differently or what criteria it uses. This is not explained anywhere. I would need someone to explain to me how the import 3dm file as library object works and what criteria it uses in these problems I am running into. I have been trying to reverse engineer the problem but it is useless to do this without understanding the criteria, as soon as I get it to work for one geometry I see It doesnt work for another. Please help me, I’ve invested a lot of time and effort in this and It would be great for archicad users. For further details or contact info check with Haris Matthaiou from Technical Support at GRAPHISOFT HQ. I’ve been in touch with him. Thank you!
March 27, 2019 at 13:40 #4639András CsetriKeymaster
I can help you by explaining the criteria on the side of ARCHICAD.
Unfortunately I don’t know much about the topology in Rhino, but probably the following will be enough for you.
I assume you have already read the corresponding sections in the gdl reference guide (https://gdl.graphisoft.com/reference-guide/nurbs-primitive-elements and further).
The most missing thing in this guide is an illustration for our nurbs topology constraints. Now I made and attached one: NurbsFaceTrimDemo.png. Sorry for the poor image quality, as soon as I get back to it I will try to make it better.
The main points:
– The edges and trims are topological elements, each references to a nurbs curve (3D curve or 2D curve respectively) which are geometrical elements
– The geometry of the curve is not identical to the geometry of the edge or trim. The former contains the latter.
– The domain of the curve in the clamped case (curve goes through the first and last control points) is the interval from the first knot to the last knot. The domain specified by an edge or a trim is a sub-interval of this.
– The orientation of the edge is always the same as the orientation of the trims of it, and the same as the 3D and 2D curves of the edge and corresponding trims. That’s why curve indices of edges and trims and edge index of trims are always positive.
– The orientation of the edge and the loop of the face may be opposite, in this case it is indicated by a negative trim index in face
Please let me know if these helped or you need more information about the actual import workflow from Rhino. In that case I will redirect you to some expert in this field.
March 27, 2019 at 18:57 #4644Ignacio Bevilacqua TrabadoParticipant
Thank you very much for your answer. There is new inforamtion here and it explains some of my troubles. I will look into it, try testing and try to make sense of it. If I can´t manage I will come back to you.
I do have another particular question if you don´t mind: About the sign (positive or negative) of the domains, does this have anything to do with the negative indexing of trims in the face commands? How is it established? Because I do see some differences from the domains I get from Rhino, and I can’t quite understand why…
Thanks again, kind regards,
- The forum ‘Others’ is closed to new topics and replies.