It looks like you're new here. If you want to get involved, click one of these buttons!
How do you use trans to rotate a object at a certain degree. Using something like code below with r0,r90,r180,r270 works fine.
t = RBA::Trans::new(RBA::Trans::r90,mirror, x, y)
How would I rotate at 45 degrees or 22 degrees. Code below does not work, it seems like it rounds to some 90 degree angle.
t = RBA::Trans::new(22,mirror, x, y)
From the transformation page it says a arbitrary angle is fine. In the GUI if i select object properties->Geometry->Rotation angle and set it to 22 degrees it works fine. Is there no way to do this with scripting?
Thanks,
Keil
Comments
You need to use CplxTrans or ICplxTrans class instead. Trans only supports those four rotations.
Why? My guess is the reasoning is this. Trans will always map a polygon on to a polygon, perfectly snapped to the grid, without changing any of the vertices. CplxTrans on the other hand has the potential for slightly changing your polygon, by snapping its vertices to the new grid points. Therefore there is some (small, depending on what matters to you) risk involved. So, it is a separate class. So that you know whenever you use Trans you are safe from that. In practice this rarely matters since your grid is usually 1nm and your shapes are usually many microns large, so a snap change of 1nm over many microns doesn't matter.
The code below works when using trans.
This code below does not work using ICplxTrans. I get error of "No overload with matching arguments in CellInstArray::initialize".
What has to be done different for LCplxTrans?
Hi David (and all),
the reason for the differentiation between the different transformation types is twofold: historical and efficiency. I guess I should go for the efficiency claim - that looks smarter :-)
Anyway, the RBA::Trans object
In contrast to that, the RBA::CplxTrans object is more general, but also less efficient and in the strict sense will transform integer coordinates into floating-point ones. Hence there are more variants for that transformation:
As you can see from the description, the RBA::Trans transformation is a good-natured one while the RBA::CplxTrans ones are alightly stubborn objects. Using them comes with some side effects in general although of course the simple transformation is a special case of them. I think it makes some sense to encourage using the simple transformation where possible. If you don't care about efficiency and you are prepared for a few surprises, you can also use the complex transformations of course. I think, all functions accepting a simple transformation will also accept a complex one.
This is basically the long explanation of what David was already suspecting. Not having to deal with rounding topics contributes to efficiency since you don't have to toughen your code against rounding differences.
Thanks and best regards,
Matthias
Ok that makes sense and gives good reason to have multiple different methods. Should this code below work with ICplxTrans.
I get error of "No overload with matching arguments in CellInstArray::initialize" when using ICplxTrans but works fine when using Trans.
Thanks,
Keil
Yes there is no initializer for ICplxTrans as the 2nd argument of CellInstArray -- just one for Trans as the 2nd argument, or for CplxTrans as the 2nd argument. Docs
Can you use CplxTrans instead? Usage should be similar.
David
Hi all,
yes,
RBA::CplxTrans
is the object mainly used within the database. It's the one that takes the integer-typed database objects and provides a transformation to a floating point object without loss of precision. But strictly speaking the result of such a transformation is not an object that can be put into the database without casting it to integer coordinates again.If you need an
RBA::ICplxTrans
which provides a lossy, but type-preserving transformation, you can useRBA::ICPlxTrans::from_trans
to create one from aRBA::CplxTrans
.Matthias
Thanks guys. Changing to CplxTrans works great.
Thanks,
Keil