Here is a very generalized overview…it’s going to be lengthy and long winded though, so I apologize in advance.
Rhino has/uses the concept of “Display Modes” to define specific visual appearances and effects. Each display mode is a huge collection of values and states that define how the overall frame buffer generation will look if/when that mode is provided to the pipeline. The mode describes “everything” about what can be drawn inside Rhino’s pipeline; from every object type and state, to the world axis icon and background color, to line thicknesses and color, etc…, everything is there. Making specific changes to these settings is what forms the differences between each of the display modes in Rhino. For example: “Shaded” vs. “Wireframe”, “Rendered” vs. “Shaded”, etc, etc… All display modes have exactly the same definition, but their values differ slightly (or a lot), and are what define each specific mode. So from Rhino’s display pipeline perspective, these settings are known as the “display attributes”, and are managed and moved around within the pipeline via the m_pDisplayAttrs
member. Note: Rhino comes with several “built-in” display modes, but you as user and a programmer can define and create however many different display modes you want, which are referred to as “custom display modes”…which is a topic for another time.
Rhino’s display pipeline is divided up into logical phases called “channels”, and each channel has a very specific and dedicated purpose and functional responsibility within a single frame buffer pass. Since plugins, commands, and even Rhino itself may want to change, modify, are even disable specific things within that pass, a secondary set of attributes exists called “channel attributes”. However, in order to better manage the logical break up of each channel, Rhino also uses the concept of a “Conduit”, which provides ways to entirely override or slightly modify the behavior of each channel. Modifying channel behavior is done by modifying the channel attributes within your conduit through m_pChannelAttrs
…Some of the channel attributes are actually used to communicate and translate specific information across different channels. You will find that there are specific channel attributes that coincide with specific pipeline channels, so when in a specific channel, only those channel attributes are used and payed attention to. Modifying different channel attributes outside the scope of their given channel(s) usage, will have undefined behavior. But that’s not all conduits are for, as you’re discovering…conduits are also used to provide much more than just channel behavior, they also give you the ability to provide all kinds of additional and different functionality to the pipeline.
So when a viewport is updated it starts by giving the display pipeline its “display mode” or more specifically its “display attributes”. From there, the pipeline does the following (again, this is a very generalized overview):
The pipeline is “opened”, and then the logical phases/channels are executed in the following order:
- Object culling
- Bounding box calculation
- Near and Far clipping plane setup and adjustments
- Viewport Frustum is defined and set
- The “lighting model” is setup and initialized
- The frame buffer is initialized and cleared
- The “background” is drawn
- The “middleground” is drawn (which is where all object drawing occurs)
- The “foreground” is drawn
- Post processing of the current frame buffer is performed
…the pipeline is then “closed”, and the resulting frame buffer is ready to be presented to whatever “device” currently initiated the draw…most of the time that will be the screen/monitor, but there are many other forms of output in Rhino to where the frame buffer can go.
As Rhino moves from channel to channel, both the channel attributes and the display attributes can and will change, depending on what is needed.
Given that, there are also some transient display attributes that exist in order to convey specific states at specific times. Note: These transient settings do not exist in the “Display Modes” (i.e. you as a user can’t set them), but they do exist within the same set of attributes and definition. An example of this would be the m_isHighlighted
attribute…that attribute can change from one second to the next depending on what is happening and what is currently “selected”, and it is part of m_pDisplayAttrs
, but as I mentioned, it really has nothing to do with a given “Display Mode”, which is why I would call it a “transient” attribute. I mention transient attributes here because the m_pMaterial
is also somewhat of a transient value. I say somewhat because display modes can and do define specific material settings, however, the material can change over the course of the entire object drawing phases. The material is what defines “how” a given object is going to look, and is usually only used when drawing some kind of shaded polygon mesh. Take Rhino’s “Shaded” mode for instance. It defines a customized material such that when Shaded mode is in use, all shaded objects look exactly the same…their colors might change, but the overall shading will be exactly the same. Ghosted mode is like Shaded mode, only it also specifies a transparency value so that all objects are drawn using the exact same transparency value… The Rendered mode is where things start to really differ, because in Rendered mode, each object can have its own material defined and assigned to it, which means the shading can differ from object to object, and in most cases, every object looks completely different from the other. The pipeline handles this by copying the object’s material into the display pipeline’s material just before the object is drawn…so if the object doesn’t have a material, the pipeline simply uses the one defined in the given display mode. This allows the pipeline to function and operate exactly the same regardless of which display mode is in use…in other words, the pipeline doesn’t care where the material comes from, it only cares about which material is currently set in m_pDisplayAttrs->m_pMaterial
. What’s actually in m_pMaterial
is determined by differing logic within the pipeline and is why I sort of consider it a transient setting. So for example, you could create a conduit that turns everything to a shiny red simply by setting m_pMaterial
appropriately and at the appropriate time. It wouldn’t matter what display mode was currently active, because you’d be overriding what the pipeline is using to draw the mesh… I hope most of that made sense.
So having said all of that…
Knowing what each attribute does, and when to set or reference a specific attribute is just something that you will learn over time. There are so many possibilities that I cannot and will not list them here…most of those possibilities are ones that you probably will never need to know or come across as a developer, which is why it’s just better to address and ask about specifics each and every time you come up against something you can’t quite figure out or understand.