Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0029570Open CASCADE[OCCT] OCCT:Visualizationpublic2018-03-13 08:122018-03-13 15:08
Assigned Tokgv 
PrioritynormalSeverityintegration request 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 7.4.0*Fixed in Version 
Summary0029570: Visualization, Graphic3d_Aspect - merge Graphic3d_Group aspects
DescriptionHistorically, 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.
TagsNo tags attached.
Test case number
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
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 - 2019 MantisBT Team
Powered by Mantis Bugtracker