# Understanding Cascaded Attribute Evaluation Across Prototype Boundaries
Hi,
I’m implementing a CAD importer based on HOOPS Exchange and have some questions about the intended usage of `A3DMiscCascadedAttributesPush()` and attribute inheritance.
Background
During import, I build my scene using two different object types:
One reusable Part for each Prototype (PartDefinition / Prototype ProductOccurrence).
One Instance for each ProductOccurrence.
Therefore, my traversal order is:
```
ProductOccurrence
↓
Prototype ProductOccurrence
↓
Part
↓
RepresentationItem (RI)
```
Unlike the SDK samples, I explicitly visit the Prototype ProductOccurrence because I need to import both the reusable prototype geometry and the occurrence hierarchy.
My goal is **not** to reproduce the final rendered appearance of an occurrence. Instead, I need to import reusable prototype geometry and occurrence-specific overrides as separate objects.
My goal is:
The imported Prototype Part should contain only its own local graphics attributes.
Each Instance should contain the occurrence-specific overrides (color, visibility, etc.).
—
## Issue 1: CascadedAttributesPush() across Prototype boundaries
When using `A3DMiscCascadedAttributesPush()` as documented, everything works correctly while traversing a normal assembly hierarchy or piece part.
However, after entering a shared Prototype ProductOccurrence from different ProductOccurrences, the evaluated color and visibility inside the prototype appear to depend on the occurrence context.
For example:
```
Assembly
├── Occurrence A
│ Color override = Red
│
└── Occurrence B
No color override
```
Both reference the same Prototype.
If Occurrence A is visited first, the geometry imported for the Prototype may already contain the red color inherited from Occurrence A.
Similarly, if visibility is overridden at the occurrence level, the imported Prototype geometry may also become invisible.
This makes it difficult to import the reusable Prototype independently from occurrence-specific overrides.
My questions are:
Is this the expected behavior of `A3DMiscCascadedAttributesPush()`?
Is the API intended only to evaluate the final appearance of an occurrence rather than the original appearance of a prototype?
—
## Issue 2: How should a Prototype be evaluated independently?
For an importer, I need both:
1. the reusable Prototype geometry, and
2. the occurrence-specific overrides.
What is the recommended way to evaluate the graphics attributes of a Prototype independently?
Should I:
- evaluate the Prototype without any occurrence inheritance,
- create a fresh cascaded attribute context before entering a Prototype,
- or use another recommended approach?
—
## Issue 3: Implementing a custom attribute resolver
If `A3DMiscCascadedAttributesPush()` is not intended for this use case, I’m considering implementing my own inheritance evaluator.
The basic idea is:
- Cache the current entity path.
- Cache each entity’s local graphics data.
- Evaluate inheritance manually instead of using `A3DMiscCascadedAttributesPush()`.
- Preserve occurrence-specific overrides only for imported Instances.
Before implementing this, I’d like to understand the intended inheritance algorithm.
For color, is the following understanding correct?
* Does a node with SonHerit become the new propagation source?
* Does FatherHerit only control whether inherited values continue propagating?
* If neither inheritance behavior is specified, should the locally defined color override the inherited value only when explicitly defined?
Is there any documentation describing the exact merge algorithm performed internally by `A3DMiscCascadedAttributesPush()`?
—
## Issue 4: Visibility evaluation
The documentation states:
> Unlike other behaviors, the value is ignored if a kA3DGraphicsSonHeritShow or kA3DGraphicsFatherHeritShow flag is set.
Could someone explain how visibility inheritance is evaluated internally?
Although document recommends `kA3DGraphicsShow` itself is ignored whenever either inheritance flag is present, I found if `kA3DGraphicsShow` is `0`, the `kA3DGraphicsFatherHeritShow` will always been set for hidden instance.
A pseudocode description of the visibility evaluation algorithm would be very helpful for implementing a compatible resolver.
Any clarification on the intended design of `A3DMiscCascadedAttributesPush()` and the recommended approach for importing reusable Prototypes separately from ProductOccurrences would be greatly appreciated.
Thank you!