I am trying to set the initial zoom in a dxf file.
I know that lines 12 and 22 set the center of the screen in VPORT table, but how do I set the zoom?
The DXF tag with group code 40 of the VPORT entity defines the height of viewing area in drawing units.
In the latest DXF reference of R2018 this tag has a group code of 45, but I am sure this is an error in the DXF reference (like many others).
Link to the Autodesk Reference of the VPORT entity.
All my knowledge about the VPORT entity is here.
Related
I am using the Edit2D extension on an svf created from a 2D dwg file and have a question about transforms. The Autodesk.Edit2D.Polygon's that are created have a getArea() method which is great. However it's not in the correct unit scale. I tested one and something that should be roughly 230sf in size is coming back as about 2.8.
I notice that the method takes an argument of type Autodesk.Edit2D.MeasureTransform which I'm sure is what I need, however I don't know how to get that transform. I see that I can get viewer.model.getData().viewports[1].transform. However, that is just an array of 16 numbers and not a transform object so it creates an error when I try to pass it in.
I have not been able to find any documentation on this. Can someone tell me what units this is coming back in and/or how to convert to the same units as the underlying dwg file?
Related question, how do I tell what units the underlying DWG is in?
EDIT
To add to this, I tried to get all polylines in the drawing which have an area property. In this case I was able to figure out that the polyline in the underlying dwg was reporting its area in square inches (not sure if that's always the case). I generated Edit2D polygons based on the polylines so it basically just drew over them.
I then compared the area property from the polyline to the result of getArea() on the polygon to find the ratio. In this case it was always about 83 or 84 times smaller than the square foot value of the polyline it came from (there is some degree of error in my tracing system so I don't expect they would be exact at this point). However, that doesn't fit any unit value that I know of. So remaining questions:
What unit is this?
Is this consistent or do I need to look somewhere else for this scale?
Maybe you missed the section 3.2 Units for Areas and Lengths of https://forge.autodesk.com/en/docs/viewer/v7/developers_guide/advanced_options/edit2d-use/
If you use Edit2D without the MeasureExtension, it will display all coordinates in model units. You can customize units by modifying or replacing DefaultUnitHandler. More information is available in the Customize Edit2D tutorial.
and https://forge.autodesk.com/en/docs/viewer/v7/developers_guide/advanced_options/edit2d-customize/
BTW, we can get the DefaultUnitHandler by edit2dExt.defaultContext.unitHandler
Ok after a great deal of experimentation and frustration I think I have it working. I ended up looking direction into the js for the getArea() method in dev tools. Searching through the script, I found a class called DefaultMeasureTransform that inherits from MeasureTransform and takes a viewer argument. I was able to construct that and then pass it in as an argument to getArea():
const transform = new Autodesk.Edit2D.DefaultMeasureTransform(viewer);
const area = polygon.getArea(transform);
Now the area variable matches the units in the original cad file (within acceptable rounding error anyway, it's like .05 square inches off).
Would be nice to have better documentation on the coordinate systems, am I missing it somewhere? Either way this is working so hopefully it helps someone else.
I created Forge viewer app w/ Transformation Extension based on GitHub sample "forge-extensions", for unknown reason, gizmo is not visible after I click on element, only very small yellow dot after zoom in, I believe it's element center point and gizmo size is too small, so my question is how to control it? in fact, all the coding is copied from that GitHub sample "forge-extensions", I must miss something simple!
Have you tried your code with different types of models, and does it behave the same for all of them? I believe it may have something to do with the scale of the particular model, especially when looking at these lines of code from the viewer extension:
_transformControlTx.setSize(
bbox.getBoundingSphere().radius * 5);
Try and put a breakpoint there, and see what the radius is. Or try adjusting the hard-coded value.
We recently updated one of our projects to use the latest version of the Autodesk Forge Viewer (v7.x).
In general, the migration went fine, however we noticed that for some models we have issues with the far cutting planes of the camera. I have figured out that this happens because the model contains some elements that are very far from the rest of the model and thus the bounding box of the entire model is magnitudes larger than it should be. This results in camera near = 1 and far = 10000. It seems that far should be higher in order to not hide parts of the model when zooming out.
For now, we have been able to workaround the issue be specifying a the "nearRadius" when loading the model, but since we have to set it to a value like 50 or 100 in order to not have far plane issues, we still have some near plane clipping issues.
I was wondering if there is any possibility to fix the model once it is loaded, so that the viewer uses a more realistic bounding box for the model. I have found out so far that during the load it already sets the variable verylargebbox to true and therefore is not using the nearRadius = 0 but either the passed value in the load options or 1. I was able to set nearRadius to a negative value to have the same behaviour as with nearRadius = 0, but due to the large bounding box of the model, we still experience clipping issues.
In order to fix the model I have already tried:
Excluding the ids of the elements that are far away with ids = [...] in the load options
Setting the visibility of these elements to off using setNodeOff()
Use NOP_VIEWER.navigation.fitBounds() to set the bounding box (as suggested in near and far calculation in Autodesk Forge Viewer)
However, getVisibleBounds() still returns the huge bounding box.
We would like to find a solution in which we don't need to modify the source model file before translating it to .svf.
The engineering team has confirmed that there are pathological cases where due to the bounding box of the model being extremely large, the computation of the near/far camera planes causes clipping artifacts. While this is being addressed, the suggested workaround is to set the near plane to 1:
viewer.impl.setNearRadius(1);
I wrote a tool which draws model curves on a view and adds dimensions to it. The tool when run locally on my computer it works fine, lines are drawn and dimension are added and visible.
But, when I upload the code to Forge Design Automation, the lines are drawn and dimensions added. However the dimensions are not visible. After I downloaded the rvt file I can see the dimension through Revit Lookup, but not directly on the view.
Any suggestions where I might be going wrong?
Here is my code...
mCurve.LineStyle = buildingLineStyle;
//Adding dimension
ReferenceArray references = new ReferenceArray();
references.Append(mCurve.GeometryCurve.GetEndPointReference(0));
references.Append(mCurve.GeometryCurve.GetEndPointReference(1));
Dimension dim = doc.Create.NewDimension(groundFloor, line, references);
//Moving dimension to a suitable position
ElementTransformUtils.MoveElement(doc, dim.Id, 2 * XYZ.BasisY);
Thanks for your time in looking into this issue.
Thank you for your query and sorry to hear you are encountering this obscure problem.
I have no complete and guaranteed solution for you, but similar issues have been discussed in the past in the pure desktop Revit API, and two workarounds were suggested that might help in your case as well:
Newly created dimensioning not displayed
Dimension leader remains visible after removal
One workaround consists in creating a new dimension using the Reference objects obtained from the non-visible one.
The other one, in moving the dimension up and down within the same transaction to regenerate it.
I have a simple Flex paint application which let the user draw anything they want. My problem is how can I save it into MySQL database without converting it to an image format. Moreover, I want it to be save and at the same time to retrieve in case there is an unfinished drawing.
Thank you.
Define what objects can be drawn, e.g. straight lines, points, polygons with controlled corners, etc. For each object, create serialization methods. It may be binary format (I guess you won't need search drawing in database by features used): object type first, then it's attributes. For line, it would be end points, color, maybe width and drawing style (solid, striped, dotted.)
Entire drawing will have some properties too, like width/height, format version. Write those in the header, then will go all drawing objects. If you need layers, you can make special tag for them, which will act like separator between drawing objects:
header - layer 1 tag - line - line - line - layer 2 tag - square - circle
Binary format also gives ability to save drawing into file (or in database as a blob.) Also, you can go with XML, it just will use much more bytes (but will be easier to debug.)