|Anonymous | Login||2018-12-10 11:18 MSK|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0029570||Open CASCADE||[OCCT] OCCT:Visualization||public||2018-03-13 08:12||2018-03-13 15:08|
|Target Version||[OCCT] 7.4.0*||Fixed in Version|
|Summary||0029570: Visualization, Graphic3d_Aspect - merge Graphic3d_Group aspects|
|Description||Historically, OCCT declares dedicated aspects per rendered primitive type:|
- Graphic3d_AspectFillArea3d / OpenGl_AspectFace for rendering Triangles/Quads.
- Graphic3d_AspectLine3d / OpenGl_AspectLine for rendering Lines.
- Graphic3d_AspectMarker3d / OpenGl_AspectMarker for rendering Points/Markers.
- Graphic3d_AspectText3d / OpenGl_AspectText for rendering text labels.
As consequence, OpenGl_Group stores 4 aspects at once (myAspectLine, myAspectFace, myAspectMarker, myAspectText) and OpenGl_Workspace provides 4 sets of methods for managing aspects of different kind.
In reality, such differentiation leads to redundancy of information and ambiguity, because final GLSL programs are based not on primitive type, but rather on combination of attributes (the only special case is a program for Point/Marker implying gl_PointCoord/gl_PointSize in its syntax).
E.g., lighting can be enabled for Lines and Points when vertex attributes include normals, however material and shading properties are defined only within Graphic3d_AspectFillArea3d, while Line width within Graphic3d_AspectLine3d and Point size within Graphic3d_AspectMarker3d - hence, explosive combination of parameters is cherry-picked from various aspects.
At the same time, all aspects define own Color property, as well as GLSL Program, making final definition ambiguous, when combination of aspects is in effect. And all 4 aspects should be applied somehow at once before rendering, to avoid unexpected behavior - e.g. active GLSL Program should be clearly specified, and properties like Alpha test and Blending (which currently buried within Graphic3d_AspectFillArea3d) affect ALL rendered primitives regardless of their type.
Therefore, it is proposed to merge all 4 aspects into single one combining all properties, so that only 1 aspect can be active at the same moment within OpenGl_Context/OpenGl_Workspace/OpenGl_Group/Graphic3d_Group.
Graphic3d_Group::SetGroupPrimitivesAspect() will disallow setting 4 aspects at once - only 1 aspect will be associated with Group, while multiple aspects can be specified sequentially through Graphic3d_Group::SetPrimitivesAspect().
Differentiated classes per primitive type can be preserved for compatibility (and clarity) as sub-classes of new consolidated base class.
|Tags||No tags attached.|
|Test case number|
|2018-03-13 08:12||kgv||New Issue|
|2018-03-13 08:12||kgv||Assigned To||=> kgv|
|2018-03-13 08:14||kgv||Description Updated||View Revisions|
|2018-03-13 15:08||kgv||Relationship added||related to 0027977|
|Copyright © 2000 - 2018 MantisBT Team|