Color by parent tree

Instead of coloring by entity or direct parent it would be great to color individual blockreferences.

In general leaf entities have at least a default cad color (something like grey), partially individual colors.

We would like to add colors on any node in a block / blockreference structure.

Example: we have 4 screws and want to markup two of them for the worker. So we cannot change the mesh color, we need another instance color. Since we doing assembly documentations, the coloring information can be on any level, maybe add another color for the whole subassembly to show them in context

Currently we override the draw method, checking every parent node which is set transparent if it has a color applied, if yes, we change the draw color for the object. We store the information if an entity has different color to let the user decide which coloring should be applied per situation.

0

Comments

1 comment
  • Problem is in fact even worse than you are aware of. With the introduction of colour by surface in BREP, Eyeshot have added jet another layer of complexity to the colour and the transparency topic. Now Eyeshot entity is not only colouring method By Parent / By entity  / By layer, but also a BRep surface colour overrule.

    Our problem is how to add transparency to 2 screws (to keep it in your methodology) without changing the transparency of the other 2 screws. 

     As we see it, we need a new variable on the Model class let call it UseNewColorTransparencyLogic. If UseNewColorTransparencyLogic is set to true the following system logic should be used (CREO / Solid works style for transparency):

    Block reference needs a colour/transparency tree pointer list to all entities inside the block definition. Each tree pointer item will have the colour and transparency property that needs to be used to draw this block reference instance. In this way a single block reference can have individual colour and transparency.

    Perhaps the new flag UseNewColorTransparencyLogic is not needed. If the block reference colour/transparency tree pointer list exist then this system is used otherwise old system.

     

    But clearly as of today I agree with Kai that there are some limitation in Eyeshot to manage colours and transparency correctly when dealing with Block/Block references.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post