pbowmar
IMO it's critical that an attribute applied to the point overrides the corresponding shader parameter at render time…. otherwise we can only apply single materials to whole objects which isn't especially useful. Again, if I'm missing something (Halfdan??) please let me know
The pickle here is that you can only have *one* material override per point, hence only set one material on the target instance. This can't be resolved unless you wrap multiple materials into one and switch between them using a primitive attribute on the instance. It might get quite unwieldy, however. Maybe string tuples in H12 (supported in GA, but not exposed in a SOP, so far) could save the day, but you'd still need some sort of mapping from tuple index to the target primitive material.
One idea I came up with to solve this would be to add a new set of object-level Mantra properties, which at render time would act similar to detail attributes (but with a different priority, probably higher). Then the point instancer could copy any desired point attribute as a corresponding object-level property, with the same name and type.
This would only require a small change to the materials (basically an extra parameter on the material that would tell it to, for example, pick up the base color from attribute X) but still work quite nicely with both in-memory and file procedural geometry. This might also solve the “pscale” conundrum, again, without having to modify a copy of the geometry, through some hypothetical CVEX file procedural.