And not only is backwards compatibility not included on the roadmap, Autodesk has come out and pretty firmly said that they are not even considering it. I'm fine with this. One of the few perks of subscription based access is there is no reason not to keep up to date on the latest version of Revit. Might as well take advantage. And you don't have to update all of your current models if you don't want to. Just start new projects in R24.
I wish they would add backwards compatibility. It is annoying, because of clients using different versions of Revit and not wanting to update, I currently have six different versions of Revit on my work pc and have to switch between them depending on what job I'm working on.
I'm using AutoCAD Mechanical 2009, exclusively in 2D. I save drawings in AutoCAD 2000/LT 2000 Drawing format to maintain backwards compatibility with our legacy documents which are still in regular use.
If I interact with the dimension in any way, it will return to its set unit. For example, if I double click on it to bring up the Power Dimensioning window and just click Okay without altering anything, it will change back to its set unit. Likewise, if I move the dimension itself it will return to its set unit as well.
I've had thias problem but for the life of me can't remember how I fixed it, I know you could always purge everything and redimension it but I know there is a way to fix it, hopefuly someone else around here will remember lol.
I just set Visual Fidelity (though SAVEFIDELITY) to 0 instead of 1, and it appears to solve the issue. I've checked it with several drawings that have been giving me trouble and it appears to work with all of them.
Is there a way to control the size of labels within AutoCAD blocks during DWG rendering? The text looks smaller and is misaligned when rendered by FME (and therefore the inspector and, more importantly, the PNG writer), but it's the right size and aligned properly in AutoCAD.
FME's default rasterization when writing to PNG is pretty basic when it comes to text. You can get better results if you use the TextStroker transformer before writing, which allows you to choose the font for the text to render.
For the best rasterization results, please look at the MapnikRasterizer, which allows you to fully control the appearance of your lines, polygons and text in the output raster. The setup can be a little complex, but the results are definitely worth it. For more information on the MapnikRasterizer capabilities, please see:
Thanks @daveatsafe! I already use a Text Stroker feeding a MapnikRasterizer to produce my PNGs. The problem was more of a mis-alignment issue than a size issue. I just solved the problem by inserting an Offsetter to fix the former, and also by multiplying the font size by a factor of 1.4 to get the TextStroker and MapnikRasterizer to output something resembling what AutoCAD renders for the same content.
- AutoCAD stores the lower left location of the text, regardless of the justification set on the text, then recalculates the apparent placement point based on the font metrics. FME attempts to repeat the calculation to set the placement location as the attributes autocad_alignment_x, _y and _z. However, FME does not have access to the font metrics, and so this location is only approximate.
- AutoCAD's text size is based on the capital height of the font, while most other formats (and FME's rendering) use ascender plus descender. This results in the text shrinking to about .7 when converting to other formats. Unfortunately, DWG is one of FME's original 9 formats, and so we can't change this behavior without breaking 25 years of backwards compatibility.
Sure! Here are a couple of screenshots. One is of the [Text]Offsetter and TextStroker that feed the MapnikRasterizer Text input port, and the other is the ExpressionEvaluator that updates the text font size (I went with 1.2x in the end).
X +0.05 and Y -0.02. But that's dependent on the spatial reference system and the font I'm using, so your numbers will likely need to be different. I'd suggest you experiment until you get the image output you want.
Believer it or not, I am writing the same thing this year that I have for many years before: We are still working with the same, AutoCAD 2018 DWG format. This is the 8th release in a row to make use of this DWG format, which makes backwards compatibility a lot easier to manage. As before though, it is important to be careful when moving drawings between versions. Drawings can lose their ability to work fully with older versions if they are opened and saved in newer versions.
Autodesk worked hard this time around to improve the performance of Civil 3D in many aspects of the program. Lots of changes were made to help reduce the time needed for processes such as opening large drawings, creating Surfaces from large Corridors (now 3-4 times faster!), Surface regeneration when Level of Detail is turned on, contour regeneration, Corridor editing, and more. Some of these improvements are the result of the program no longer regenerating Corridors and Surfaces if no geometric changes have been made.
This item was actually added to the AutoCAD 2024.1 update, but many people were not aware of it. The Autodesk Assistant is chat support platform that is AI driven. A user can access this functionality to ask questions and obtain tailored support. Depending on the type of account they have, some users can even get direct access to Autodesk support, allowing them to chat with a product support agent, request a callback, or create a support case.The Autodesk Assistant can be launched from the Help menu (as show in the screen shot. However, if the user is logged into their Autodesk Account, a button will appear next to the Help drop-down that will also open the Autodesk Assistant
Even better, built elements such as Walls, Roofs, and Beams, now can have multiple materials - this makes your stream elements from Revit much prettier both in our viewer and also when received in other applications like Rhino and AutoCAD ?
Previously, within our Objects kit, Built Elements and Breps had a displayMesh property that was used to display the object in the web viewer, as well as a conversion fallback when receiving in connectors that don't have native support for that type.
Using a single Mesh has the limitation that only a single render material could be used per element (without having to resort to nested child objects).
With version 2.4.0 of our objects kit, Speckle objects that previously had a Mesh displayMesh property now have a List displayValue property.
The old displayMesh prop has been deprecated, and will stick around for a few releases to maintain backwards compatibility.
For maximum flexibility, all of our converters have been updated to accept the new displayValue prop, as well as the old displayMesh prop. We assume this prop could be a Base or a List (or subclasses of Base). This should provide maximum flexibility for those creating their own custom Base objects, as well as backwards compatibility, so you can receive your old streams the same in newer connectors.
Developers who are sending custom objects to speckle don't need to change a thing, since all of our connectors still accept objects with a displayMesh. However, you may want to consider using the "displayValue" property instead to align with our new naming.
Our ambition to better support materials doesn't stop here. We have plans to improve support for different PBR shader models, UV coordinate improvements, Light objects, and (eventually) have full textured material support. We would love to hear your thoughts and wants on our forums!
c80f0f1006