I am working for a high end traditional Japanese timber framing company.
They use a traditional decimal system of measurement called Shaku, both to model in Rhino, and to build (all their tools and measuring devices are in this system).
Their drawing sets show Imperial (for the building department) and Shaku (for the carpenters).
I am building them a Rhino.Inside.Revit modeling->documentation workflow, which is working really well. However, I was surprised to find that Revit will not allow the creation of a custom project unit system of measurement, unlike Rhino and AutoCAD for each of which the company has already created such a custom unit.
Creating a custom unit system in Revit is the ideal way forward. Initial research makes me pessimistic about this possibility. Maybe an add-on could be written to add this function to Revit, if that part of the source code is open to the API. This would allow us to convert the Rhino model to Imperial in Grasshopper (Rhino.Inside) and then to use Shaku as an alternate unit on dimensions and schedules, which would be the perfect solution.
Failing to create a custom unit system in Revit, could I use Dynamo to convert the numbers in all dimensions and schedules? It is a simple multiplier: 1 foot equals 1.00584 Shaku.
Not going to be possible to change units, as those are hard coded in Revit.
Modifying the value of dimensions is possible via the dimension overrode, but not measurements in a schedule; for those you’ll need a new parameter to hold the value. It’ll be a big lift, and may not be feasible in the long run, as once overrides are set as values change the overrides will all need to be updated. For a smaller set it’s not too bad, but a larger complex form would be quite problematic. Exporting to DWG and modifying the dimension style (perhaps via Dynamo by use of Dynamo for Civil 3D) might be a better long term solution.
This is useful. When you say “quite problematic”, what sort of problems do you foresee? Are you talking about computing resources?
I understand that the overrides will need to update as values change. However, if I am running the script near the end of the project, I can limit the number of updates to a handful. I would simply run the dimension override again, no?
Correct. However all it will take is one person hitting print before running the graph, and you’ll be fabricating off incorrect drawings. Worse yet, unlike if you left it in another unit you wouldn’t be any wiser, as the data would look correct.
It would also be rather difficult from a compute standpoint.
All in I think you would be better off either using the other units (hard to retool I know), or export to a DWG and modify the dimension styles; anything in a schedule could be utilized by using a formula driven parameter, which would always be correct.
Because if every time you update the Revit file you have to export and update the style before printing the DWG, it would be hard to manage to forget one of the steps. Also modifying the dim style and then printing can be automated.