-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2D Extract information for autocalibration from DWG file #695
Comments
In the database format we have a field for createdBy. I was wondering whether we would want to fill that with the name of the user uploading the model (and setting off the processing) or just with "bouncer" or "autocalibration" to make clear that this record was not user generated.
|
actually can we just omit the field? we can just assume it's auto generated if there's no author |
First-time mongo user here: the database will not be upset with me if I don't send anything for a column of the collection? I guess I can just send an empty string if that's the case. |
@FJThiel you don't need to send anything. Mongo is a noSQL database and is flexible with its schema 😉 |
@sebjf |
…el density so both sets of vectors are in the same unit.
Also: two assumptions for sanity checking:
Both are not large changes if I am wrong. |
Leaving this here since it looks like I am not finishing this before going on leave and in case somebody picks this up while I am away: Horizontal calibration should be fine, though is not tested yet. I was currently working on creating myself a bunch of debug outputs to investigate the block structure for the vertical calibration. After our discussion last Tuesday, I found that the individual elements (called Entities) are grouped by blocks and stored in the block table of the database. If we can get indeed the extents of the table, I think that could be a good starting point for the vertical calibration. Maybe the values can even be taken as is. If that does not work, one should try next to get the extents of the individual blocks. If they are available, the overall extents can be calculated from that. Also interesting, though probably out of scope: the blocks have a second method that offers best-fit extents after applying a transformation matrix. This could become interesting should we want the vertical calibration relative to the view. At the moment, I see no purpose for this, because we are only allowing top-down and can just look at the z-axis of the extents, but should that change in the future, this might come in handy. I will make one last push with my experimental code. Mind, it has not run yet, so some tinkering might be necessary. The area with the test code is bracketed by \Test and \Test end, so it's easy to remove. |
…ation of the draw strucutre. Just in case somebody has to pick this up while I am away.
Some notes for documentation: ValidationTo start with, validate the mapping between the test files. We can get this from Revit by exporting a floor view to a DWG. See this article for a primer on coordinate systems in Revit: https://revitpure.com/blog/13-tips-to-understand-revit-base-points-and-coordinate-system We can use the Annotate -> Spot Coordinate tool to inspect the coordinates of points in Revit, setting the Spot Coordinate Base to Internal Origin via the Edit Type menu. Similarly, using the WCS (World Coordinate System)In bouncer, the However, there are additional transforms in 3D that must be considered. 3D Viewer -> Project CoordinatesThe import pipeline applies a number of transforms in 3D at each stage. 1When importing Revit files, the method There is also a scale that transforms between the values read by ODA and the Internal Coordinate system. To read the Internal Coordinate system directly from Revit when importing, ignore the To get Revit to export with these set to Identity, move the Project Base Point to be aligned with the Internal Origin, and reset any Shared Coordinates. 2The next is the Scene transform. This may apply a further scale according to the units. It will also apply the following transformation matrix:
Revit uses a right-handed coordinate system. The above transform swaps the z and y axes, and inverts the resulting y-axis. The result is that the model is in a left-handed coordinate system, where the y-axis of Revit becomes the -z (backwards) axis of the viewer. Unity Unity uses a left-handed coordinate system, expecting z to point into the screen. This is achieved by applying a scale of [0,0,-1] at the root of all models at runtime, which effectively inverts the z-axis again for everything received from the database, so it points forwards. This is Unity's local coordinate system. 3Finally, there is the SummaryThe diagrams below show the three coordinate systems involved (as seen from the same perspective of a model) ConversionsWhen moving through Unity's public API (e.g. through the pick point alert), Unity will convert between Repo coordinates by inverting the z-axis. This inverts the transform made at the root of the scene graph and gives the result in the coordinate system used by the database. This is not the same as project coordinates however, as would be considered by Revit. To transform between project coordinates and Unity's coordinates, the y and z coordinates are swapped (which is what happens in the Implications for calibrationHandednessWhen drawings are imported via ODA, the The first thing to consider is that the SVG y-axis is flipped compared to the WCS. This transform is impossible to recover from the single vector approach. However, we don't want to store the calibration in the Project Coordinates, but instead in Repo coordinates for consistency with the database. Conveniently, from the diagrams we can see that this coordinate system is consistent with the handedness of SVG coordinate system when looking down. So, to generate the calibration pairs, we generate an arbitrary vector, get the corresponding SVG location, and then transform the original 3D vector into the repo coordinate system (mirroring what would happen to any 3D data from a file defined in the same coordinate system.) In practice, we can simply define the vector in the x-axis only, as this doesn't change with the handedness transform. ValidationTo test this out before the backend integration is done, we can get the frontend to print the calibration it tries to write at the end of the wizard to console.
Then the calibration can be recovered, e.g. with a script like below:
Providing the above calibration gets us a matrix to go from 3D to 2D. We can compare matrices produced by the parameters from the wizard, to those written to the database by bouncer: As well as use this to transform various points to check against expected positions in the SVG:
|
A few remarks on the above:
|
Exporting a DWG from Revit does not contain elevation data by default. Though it possible as a test to add it with the Change command:
|
As Felix found, all visual (geometric) elements of a drawing are entities. The extents of a given entity in the WCS can be found from its (As can be seen below in the OdaDgnApp sample, this can be retrieved without having to dig into the individual types of primitive). Using this we can get a vertical range for all drawings, and set the base of the floor, or the entire vertical range from these. |
Thanks for taking this over and catching my errors such as the assumption that the DB would contain data in the Unity CS. Maybe you can clarify a few things that I don't quite understand: 1. Initial OffsetOne import problem you highlight is:
However, further up you wrote:
The way I read this is that, while we don't get the actual offset, we can query both the aligned points (after the application of the offset) and their original coordinates in the internal coordinate system. Shouldn't that be enough to derive the transformation or are we talking different offsets here? 2. Elevation vs. HeightThis is probably just a terminology thing, but I wanted to check anyway. You write that DWG does not contain elevation data by default, but then we go and get the 3d coordinates from the elements anyway. Am I correct to assume that elevation does not mean whether there is a height component in the coordinates but is an overall vertical offset applied to the model based on real-world data? 3. Table extents vs. Element ExtentsI noticed that you do not query the geometry extents off the whole table, but build them yourselves from the individual extents. Am I correct to assume that the table extents do not provide the correct information? 4. Default Floor Height.You wrote: Shouldn't this be |
Hi @FJThiel,
My comments above are lacking in context a bit... It turns out the Project Base Point is actually not important at all, and the interesting point is the Survey Point. The Survey Point in Revit is the 'public' origin of the coordinate system. It is possible to export a DWG relative to this, and this is also what we import geometry relative to when importing via ODA. Revit in practice has an internal coordinate system, but when importing or exporting the best practice is to use the Survey Point. The coordinate system relative to the Survey Point is what we would know as Project Coordinates, and this is the same as Repo Coordinates in the database (with the axes swapped as above).
The problem was that we don't store the points in the RepoScene, we just get geometry relative to the survey point, so we don't know what the original offset was between Project Coordinates and Internal Coordinates in 3D for any existing files. However, this turns out not to be a problem because any properly managed project will have all its files relative to the Survey Point anyway, and that's what all Containers are imported relative to.
Yes, DWGs are a 3D file format, but they don't contain "elevation" in their metadata, and it seems tools do not write the Z coordinate by default, though its available for primitives to use in AutoCAD.
Yes!
It should be! Good catch. Though, we discussed yesterday and vertical calibration is being moved elsewhere so all this is moot 😄 |
@sebjf |
…to use our svgexporter which was inteferring on travis
Description
Extend the bouncer to extract information from DWG files that can be used for the automatic calibration with drawings down the line.
Goals
Tasks
/Zc:wchar_t-
flag is set on SVG Export but not on bouncer properRelated Resources
Product Ticket: #381
The text was updated successfully, but these errors were encountered: