I defined a dimension style in the TextDimStyles.dgnlib. I defined a color for the dimension lines (number 254) and the text (number 0) in the 'Symbology' tab. Our Drawing Seed has a different color table attached to it then this TextDimStyles.dgnlib.
When placing a dimension line using the dimension style as defined in the dgnlib in a Drawing, it doesn't use the color number (0-255) as defined in the dgnlib, but looks at the RGB value of this number in the dgnlib color table, and searches the nearest RGB color in the Drawing Seed's color table. This means the color numbers change.
This is just retarded since the color table is ment to create a visual difference between the numbers 0-255 (which are the real 'colors') and you use these numbers as 'colors' in the pen table to define the output color, not the RGB value in your color table.
I found out about this after a long search. I solved this by attaching the same color table to the dgnlib, which gives me the same numbers since the same numbers have the same RGB color, but it shouldn't work this way...
anyone else noticed this or had a simular problem elsewhere?
Unknown said: I defined a dimension style in the TextDimStyles.dgnlib. I defined a color for the dimension lines (number 254) and the text (number 0) in the 'Symbology' tab. Our Drawing Seed has a different color table attached to it then this TextDimStyles.dgnlib.
Then dont use that colour table from the seed , open the dgn lib and save out the color table and make sure it has a unique name
then return to your work file and reattach the said colour table used in the dgn lib file problem solved no ? perfect colour matching now...
if you need a colour blind grey scale table then make one and set it in the dgnlibGreyScale also set the same one for greyscale seed file
and make a new workspace called grey scale and define the grescale dgnlibgreyscale to it not your other one you first had with non matching colour table
and seed file for grey scale pointed to it too...
then educate everyone how this works...
This should now work in theory anyway....
Lorys
Started msnt work 1990 - Retired Nov 2022 ( oh boy am I old )
But was long time user V8iss10 (8.11.09.919) dabbler CE update 16 (10.16.00.80)
MicroStation user since 1990 Melbourne Australia.click link to PM me
^ If you mean what I think you mean, it should work, but make it aa bit complex.
The reason to use different color tables is cause we work with different visualisations of the same elements in 3D design, 2D drawing and sheets.
I 'solved' my problem by using a True Color, which is a workaround to avoid the numbers. Still I would prefer to use a number, and define the Color linked to that number in the Color Table (which would be possible if it didn't remap the numbers by looking for a matching color).
Windows 10 pro
OpenBuildings Designer Connect Edition 2023 | 23.00.00.114
When I was at a DOT, we adopted an IPLOT color table as our standard color table and would often have to reset a files color table. However, we did little rendering those days. But when I did, I would either pick from the colors in the table or assign a material where you could customize the rendered look without changing the element.
We also set all reference file to not use their own color table.
This helped, but is no guarantee.
On occasion it was necessary to modify a color table and when we did, we always wrote it out so if it was reset, you could reload it.
Charles (Chuck) Rheault CADD Manager
MDOT State Highway Administration Maryland DOT - State Highway Administration User Communities Page