Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Ok this may be the most simple, rediculous question, but i cant seem to get the height of a tree or light pole to change. If I select the "height gizmo" and drag up or down to change the height of a tree or pole, the height changes, but then it wont accept the change. It just defaults back to what it was. Is there a setting i need to change somewhere?? Help or direction to other posts would be greatly appreciated!
Actually it doesnt. Another thing Im noticing is that the default height it say 195' for a light pole, when it seems like it should be more like 20' and so on for trees....is there a setting somewhere that is forcing the base height of these objects down below my DEM??
Could you provide some info about the source data of these objects (data source and how you imported it vs. are these drawn features)? Also, it would be nice to see a screenshot of the feature refusing to resize accompanied by the property inspector showing its properties.
they are just the default objects, furniture, from the out of the box infraworks. i just can seem to understand why the height is not at a normal height for the typical object. Does it have something to do with height-above sea level-based from my dem. it seems when i was watching a webinar when the teacher was editing the height of these furniture objects he was entering "real world" typical heights - as in 30' tree, instead of 196' tree. Whether i try to stretch or type in a "normal" height for these objects, it wont accept the "normal" height.
I couldn't reproduce this using InfraWorks 2014. Is there something logged that might point to the problem? Can you do other kind of data manipulations (in scene as well as from the property inspector - remember to trigger update in the latter after changing properties or enable "Auto Update"). If not maybe your .sqlite file is locked blocking any data manipulations.
I have not been able to. Ive double checked my units, model settings and re-imported elevation models from different sources to see if that may have been it, but no.
Im beginning to think that it may be a bug with the first release of Infraworks. I know in a couple recent webinars, reference was made to them running R2(release 2) and it was working correct, so that may be it. Havent had a chance to get tech to download the most recent version yet, so I cant confirm it.
Are you able to create proposals or do Undo/Redo for changes? If not, your model might have locked up.
For checking whether the model data is locked up against particular data changes one could have a look for index.lock files with the <MODEL_NAME>.files\.git folder and delete them.
If you did not create any proposals yet or can live with losing all of them the .git folder could also be deleted (you should switch to the master/proposal you want to preserve from within InfraWorks before deleting the .git folder then). Deleting the .git folders has the bad side effect of deleting all but the currently open proposal/master; and losing any ability to sync to InfraWorks 360 model that it was originally connected to.
The only "advantage" it can provide is that it can bring some corrupted models back on track (if the reason for the corruption is related to some hickup in the data versioning).
I am using AIM 2013, Undo/redo works fine. Can add and delete proposals. There was no index.lock file, but I deleted the .git folder anyway. Still am unable to grip edit furniture heights. Furniture is also referencing zero elevation, rather than height above terrain surface.
As I (and others I asked) can't reproduce the issue, is there a way we can get the terrain data (or even full model) you are using? The screenshots you provided kind of indicate that the root cause might have something to do with the source data or how they are imported/incorporated into the model scene (due to the bboxes going through your terrain).
I was having the very same problem and determined that it was specific to the model, since the sample model supplied with AIM worked fine. After rebuilding my model from scratch and having the same issues, I determined that the problem was that I had specified a coordinate system for my model (WA83-NF). I rebuilt the model using the AIM default coordinate system (LL84) and things seem to be fixed. So now my model works, but I wonder how that will screw me up for when I need to export to something our surveyors can use. Seems to be a rather fundamental flaw in the software.
Thats odd. I wonder why that would be? That was the first thing I did, set up the model in maine state plane. I havent had a chance to re-do my model in the default LL84, but ill be sure to let you know if mine fixes itself. That really just doesnt make sense to me why it would work that way...come to think of it the webinar i was watching (where it worked fine) was done in LL84 as well...hmmm, odd.
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")