Hi,
I’m using an educational version of Sofistik 2020
I create a composite cross section in Teddy->Aqua, the result is correct.
it’s square steel tube, the overall dimension is 1m, the thickness is 10mm. The concrete is filled in the hollow part.
Then I import the Aqua.cdb into Grasshopper and let GH output the Aqua dat file (Aqua - GH.dat).
I compared the original Aqua.dat and Aqua - GH.dat, and found two problems:
- The original Aqua has TWO materials, while Aqua - GH.dat has only ONE material.
- GH add “*(180/Pi)” in the Aqua by mistake.
Original Aqua.dat
| VERT |
NO |
Y |
Z |
|
1 |
‘=#D/2*COS(0 * 90)’ |
‘=#D/2*SIN(0 * 90)’ |
|
2 |
‘=#D/2*COS(1 * 90)’ |
‘=#D/2*SIN(1 * 90)’ |
|
3 |
‘=#D/2*COS(2 * 90)’ |
‘=#D/2*SIN(2 * 90)’ |
|
4 |
‘=#D/2*COS(3 * 90)’ |
‘=#D/2*SIN(3 * 90)’ |
Grasshopper generated Aqua - GH.dat
| VERT |
‘1’ |
=#D/2 * COS((0*90) * (180/Pi))’ |
‘=#D/2 * SIN((0 * 90) * (180/Pi))’ |
| VERT |
‘2’ |
=#D/2 * COS((1*90) * (180/Pi))’ |
‘=#D/2 * SIN((1 * 90) * (180/Pi))’ |
| VERT |
‘3’ |
=#D/2 * COS((2*90) * (180/Pi))’ |
‘=#D/2 * SIN((2 * 90) * (180/Pi))’ |
| VERT |
‘4’ |
=#D/2 * COS((3*90) * (180/Pi))’ |
‘=#D/2 * SIN((3 * 90) * (180/Pi))’ |
therefore the cross section in Grasshopper is wrong
Aqua files are attached
Aqua.dat (811 Bytes) Aqua - GH.dat (835 Bytes)
Hi netsonic,
there is indeed a problem at the moment with trigonometric functions like sin/cos.
In Aqua/SOFiSTiK it holds: cos(i*360) = 1
In the expression parser inside gh_sofistik: cos(i*2*Pi) = 1
There is already a workaround implemented for the direction gh to aqua: cos(x) -> cos(x*180/Pi)
However the direction cbd to gh has no adjustments yet and is therefore flawed.
We will try to fix this behavior in the next service release.
Thank you for that feedback.
With best regards
Emanuel
Hi Emanuel,
Thank you for the feedback.
Another issue I mentioned in the 1st post was:
In the original Aqua, I have two materials 1 and 2. The whole section is material 1, the tube is material 1, the material that is inside the tube is material 2.
In the GH generated Aqua, The whole section is material 1, the tube is material 0 (this is WRONG), the material that is inside the tube is material 2.
Hi,
yes, this seems to be a problem too.
There is a bug when classifying the loops and creating the faces of the section for the data structures used inside the gh_sofistik plugin.
As i see it, in GH the section has material 1, the tube gets classified as outer loop with no explicit material, so it gets the material of the section (1)(which should be correct). The inside of the tube gets classified as inner loop, although it has material 2 assigned, the generated Aqua code exports it with “MNO 0”.
An alternative Aqua specification would be to define the tube as outer loop 1, then define the hole as inner loop 2, and then the inside of the tube as outer loop 3. However this would currently also not work inside GH.
We will rethink this behavior and try to find a solution for the next service release.
Thanks again for that feedback.
With best regards
Emanuel
Hi again,
both problems should be fixed with SOFiSTiK Rhino-Interface version 2020-10.
- The conversion from GH expressions to/from SOFiSTiK expressions was improved (fixes the issue with trigonometric functions (GH: rad, SOFiSTiK: deg))
- The section face topology recognition was improved (fixes the issue placing a hole in the section where it should be filled with another material)
However, the section used in the first post might not create a valid Rhino geometry, as the thickness of the outer area could be below Rhino’s tolerance. Increasing the thickness should then produce the desired result.
With kind regards
Emanuel
