As you can see in the reference picture below, we have placed two Pivot Doors onto a AEC Wall Object. We have modified the door opening to 60*deg and 0*deg from the Parameters dropdown.
Our question is, would it be possible to target this parameter after the MAX file has been translated to SVF to visually close/open the door (by changing the Open parameter)?
Adding to Petr's answer, 3ds Max does not output even the properties, so the "open/close percent" is not available. The translator takes the current state of the geometry and outputs that. Another thought might be to duplicate the doors you want to control in desired state, and then hide the states you don't want, and show only the state you want.
About making the transform separately, it might work, but I think the challenge will be to discover the geometry as the entire assembly is treated as single element in 3ds Max scene.
Hope it helps.
Is there any chance you could share the MAX file with us? If you can't/don't want to share it publicly, feel free to send it to our email: forge (dot) help (at) autodesk (dot) com. That way we can do a bit more research on what could be done.
Without having a specific example file in hand, here's my two cents:
the SVF file format itself doesn't support any "parametric behavior" (like the "Open" parameter in your example)
if both the door and the door frame are converted into an atomic element in SVF, it would be very difficult to extract and modify the geometry
if the door and the door frame are converted separately, you might be able to emulate the desired behavior by manually changing the element's transform
Related
Background
We currently use AutoDesk Forge to display 2D models of floor plans. Users have the ability to upload new floor plans (which uploads to OSS, then translates the file) to replace existing ones, that may include new objects in the room, or slightly different positioning of existing objects. Currently, we grab certain object dbId's via viewer.getSelection() to "bind" (using the term loosely here) some external data to the object and perform certain interactions within our web app. We are using .DWG files.
Issue
When uploading a new floor plan that removes an object, it shifts dbId's of other objects, and our external binding is then inaccurate.
Question
• Are there any IDs that persist between the uploads/translations?
*We do not maintain control of the .dwg files prior to their upload, so adding attributes on the drawing before it's translated likely won't be viable for our particular case - but if that's the best (or only) approach, I would like to know to propose it as a possible solution to my team.
Example
Let's say there's a simple square room with 5 chairs, and it's rendered and visible in the viewer since it's been uploaded as room1 (object key). We identify 3 chairs by their dbIds and save that, so a user can jump right to the object in question, and we put a label on it. Then someone comes along and removes one of the chairs, uploads/translates the document again with the same object key. Now, the dbIds are changed and assigned to different chairs and as a result. Question is, is there something other than dbId that persists between the different renderings? Or, is there something that I haven't considered that would be a better approach of keeping the binding accurate between uploads?
EDIT: Same scenario happens with element ID's. An interesting finding is the element ID and dbId are tightly coupled (meaning if Object A's dbId is 3 and element ID is 6E, then a deletion happens, a new object will have 3 and 6E respectively). Also, I believe the designers creating the AutoCAD files are making these as polylines, if that makes a difference
Contingency Plan
If there's not an ID of some sort that persists, I'm considering storing the coordinates of the object we want to bind to, and later find the closest object to those x/y/z coords. Is that a possibility, to find an object close to or overlapping xyz?
Use external id.
Useful blog: https://forge.autodesk.com/blog/get-dbid-externalid
In Forge Viewer, the near and far calculation is done in an internal updateCameraMatrices method. In that method, there's a final heuristic to fine-tune the near value better near line 31320:
// One more attempt to improve the near plane: make it 1/100,000 of the distance of the
// far plane, if that's higher.
// See https://wiki.autodesk.com/display/LMVCORE/Z-Buffer+Fighting for reasoning.
// 1e-4 is generally good below, but inside Silver Cross we get a lot of near clipping. So, 1e-5.
dMin = Math.max(dMin, dMax * 1e-5);
In some BIM models I load in the viewer I can see Z-fighting for some viewing angles. If I change the value from 1e-5 (1/100,000) to 1e-4 (1/10,000) as noted in the comments, the z-fighting is gone.
This also seems like a much more appropriate value for large models (like buildings). It's maybe less suited for small-scale models like 3D CAD models.
Can I safely change this value to 1e-4 if all I intend to render is models in the scale of buildings (from Revit, Navisworks etc)?
Will the Forge Viewer allow to configure the near/far calculation in its API?
I'm afraid that you shouldn't modify this value directly in the viewer3D.js file. It's not recommended to do so. There also is no such API to modify this value as I know.
However, have you tried to change the bounds of the viewer? Here might be a similar case you can refer: Adding a skybox
If this doesn't match what you need, could you provide some snapshots and more detail information demonstrating this issue to me? If you do so, I 'm glad to pass it to our engineering team for further investigating. You can send those materials to forge.help#autodesk.com if it cannot be posted publicly.
P.S. Please remove confidential information from anything you sent to us.
I'm using Autodesk Forge to integrate with our remodeling tool. In particular, I need to count objects of different families and types and determine to what room they actually belong. I use Model Derivative API for this purpose. To keep the room/area information I convert .rvt files to .nwc files as suggested here. However, when I retrieve data with GET /modelderivative/v2/designdata/{urn}/metadata/{guid}/properties I face the following problems from time to time:
Room information sometimes disappears from Objects for some reason
Objects disappear from result data for some reason (but they seem to exist when I browse them in A360)
I have no idea, what can be the reason for this.
I have no explanation for the disappearance of room data or objects for you.
If you can provide a reproducible case demonstrating that, I will gladly pass it on to the development team for analysis.
If you are interested in an immediate reliable solution and full control, which I assume is the case, I would suggest following the second bullet item in the advice provided by Eason in the previous answer that you refer to above:
Extract all the room information and object relationships you are interested in via the Revit API, store that data somewhere yourself, and use it later on wherever you like to your heart's content.
Then you will be completely safe and independent of all other components and their unpredictable behaviour.
If the only information that you need is the room containing each family instance, I can even implement a suitable Revit add-in for you.
Another suggestion that might help, if that is indeed the data you require: determine that information in a Revit add-in and attach it to each family instance in your own personal shared parameter. That will ensure that it remains intact through the translation process. Afaik, all shared parameter data is retained, independent of other behaviour.
I need to generate a DEM (10m Cell Size) of the entire coastline for South Africa. I've tried to generate it within ArcGIS, but the Annudem Algorithm that ESRI is currently using within Top To Raster is not capable of generating my DEM.
Please can anyone let me know firstly if GRASS GIS can handle DEM's this large (i.e. millions of cells) and can use shapefiles: Contours; PointElevation and Coastline Mask.
Can anyone give me the necessary steps required to accomplish the following within GRASS GIS.
Please note that I've never used GRASS before.
Regards
Peter Wilson
Grass GIS CAN handle large DEM`s though I am not 100% sure about so huge territory. I can suggest you to divide all territory in subregions and process them separately and later on make mosaic using r.patch
In short, here is how I`d do.
All commands you can either find in GUI or launch writing them in console.
Prepare/Set up location and coordinate system for your desired place, e.g. South Africa
Upload your vector files using v.in.ogr . You can use GUI.
Upload your mask file.
Load uploaded vector file in map view display and right click in map list display and choose - set region from display (or something similar)
Use g.region and set your resolution (res=10) (actually here also you can set region from loaded raster or vector map)
If your mask is in vector format, convert it to raster file using v.to.rast giving any masking value, 1 or 9999 for example. You can use GUI.
Set the mask with r.mask and define previously set value. This is where I suggest to use console but I guess GUI also could work out well.
If you have multiple vector maps (points, lines) with values, you have to join them in one composite vector map using v.patch, but before doing it...
make sure all of them have equal column name where values are stored. If neccessary, for each loaded vector map rename column in which you have your values using v.db.renamecol. Now you can launch v.patch with "copy also attribute table" option so now you have composite vector map altogether which you`ll use for DEM generation.
Now all pre-works are done and continue with r.surf.rst or r.surf.idw or any other algorithm which takes values from specified column in your patched altogether vector map and generates that DEM.
Here you can find some specs about each DEM generation algorythm
I am trying to take a shapefile of subdivisions within a county that I have created and line it up with another shapefile that was given to me by the County Appraisal District (parcel data). When I try to get them to line up then my streets shapefiles is not aligned with everything else. They are all on the same coordinate system and I do not want to have to recreate the shapefile for the subdivisions. Any thoughts?
This is a question with answers that may be simple or may be very complex, depending on your situation. As a GIS developer, I've most commonly seen this as a symptom of an incorrectly defined coordinate system. However, whether this is the case or not, and what the solution is strongly depends on your environment. From here on, I'll assume that you're working in an ESRI package...
I agree with the other posters that your problem is one of mismatching projections and/or datum definitions.
The most important thing to understand as regards projections in ESRI software is this:
Manually setting the projection of a dataset (shapefile, geodatabase feature class, etc) in ArcCatalog does NOT reproject that dataset!!!
In order to reproject your data, you must EXPORT the data from an ArcMap session in which you've been working and where the data is obviously lined up correctly. During the EXPORT, you are given the choice of saving your data with the coordinate system of the underlying map or that of the original dataset.
Your best bet is to follow these steps to create a new dataset with the correct projection and then extrapolate what you need to do to fix your specific problem:
Create a new ArcMap session and set its coordinate system:
Do this in a fresh ArcMap session with NO OTHER DATA. Be sure to explicitly set the coordinate system of the ArcMap mapview to your desired coordinate system (I recommend the one that matches the data you're trying to overlay, or one from another well-established dataset).
Add one other dataset with a known good coordinate system.
Create your new dataset in this ArcMap session. Give your new data the same coordinate system as the ArcMap mapview and the one other dataset in the map. Set the XY domain of the new data to exceed the area defined by your other dataset, but don't go beyond the size that will reduce your desired spatial resolution.
Create your data. It can be any data at this point. Some lines, some polygons, etc. Save your work.
Export your new dataset. When prompted, choose to save with the coordinate system of the underlying mapview.
Create a new ArcMap session and add your new dataset. Then add your parcel dataset. They should now occupy the same space in your map window.
Edit your new data to your heart's content.
Some probable issues if this doesn't help:
You didn't follow these steps correctly - check the ESRI documentation; this is a well documented issue.
The parcel data you're trying to match doesn't have properly defined coordinate system. It's always possible that the keepers of this data don't know what they're doing and have munged it up. I've seen this problem more times that I care to admit.
You've matched the projection but have mis-matched the datum. Many municipalities are still using data in NAD27, which is way out of date. Some have moved to the modern NAD83. The difference can be up to 300 meters, depending on where in the country you are. Also, data that originates from surveying or GPS equipment is usually collected in WGS84 (the typical default for satellite surveying), which is for all practical purposes the same as NAD83, at least at mapping scale resolutions.
Try researching these issues and see how it goes. I'll say it again:
Manually setting the projection does NOT actually project that data!!
Good luck!
Your problem is probably one of projection
| projection: character string that names a map projection to use. See
| 'mapproject' (in the 'mapproj' library). The default is to
| use a rectangular projection with the aspect ratio chosen so
| that longitude and latitude scales are equivalent at the
| center of the picture.
`-----
Agree that your problem is projection. Is there a .prj file extension associated with either of your files? If not key first is finding out what projects you have. I would guess State Plane of some sort if you are dealing with U.S. centric local data from a local government.
Cadastral tools (surveyer tools) usually let you specify a handful of control points and will then "warp" the data to fit to your control points. This can be anything from a simple shift to something more complex. If everything is shifted by a few feet, you can also just use your "editor" to select all shapefiles and then move them however many feet necessary.
If you've verified that both shapefiles are using the same coordinate system, then projection is less likely to be the problem. It's fairly common for parcel data to be "offset" from other data sources (such as roads). This comes from inconsistent collection methods and points of reference.
Another source of error can be that one of the shapefiles has the wrong coordinate system specified. For example, if the roads were actually WGS 1984, but it's prj is set to NAD1983, you will see some significant errors. This usually happens if you had to manually set the coodinate system for a shapefile (i.e. it didn't include a PRJ and you created one).