MantisBT - Community
View Issue Details
0028253Community[OCCT] OCCT:Visualizationpublic2016-12-20 16:192020-07-14 14:41
Timo 
bugmaster 
normalminor 
closedfixed 
[OCCT] 7.1.0 
[OCCT] 7.2.0 
Not needed
0028253: Incorrect treatment of transparency if a spline face overlaps itself in 3D view
When a spline face is strongly bent it can occur that some part of the face is in front of another part of the face in the 3D view. In this case, if transparency is used, there occur ugly artefacts.

The problem does not occur if two different faces are behing each other.

Also, it could not be reproduced with simple geometry like box or sphere. So, it might be specific to more complex surfaces.
pload ALL
restore shell.brep s
vinit
vdisplay s
vfit
vsetdispmode s 1
vsettrans s 0.4
No tags attached.
duplicate of 0027716closed bugmaster Community Visualization - incorrect treatment of multiple transparent objects in 3D view 
duplicate of 0027925closed bugmaster Open CASCADE Visualization - implement order-independent transparency algorithm within rasterization rendering 
png transparency artefacts.png (93,860) 2016-12-20 16:19
https://tracker.dev.opencascade.org/
? shell.brep (322,579) 2016-12-20 16:20
https://tracker.dev.opencascade.org/
Issue History
2016-12-20 16:19TimoNew Issue
2016-12-20 16:19TimoAssigned To => kgv
2016-12-20 16:19TimoFile Added: transparency artefacts.png
2016-12-20 16:20TimoFile Added: shell.brep
2016-12-20 16:32kgvRelationship addedduplicate of 0027716
2016-12-20 16:32kgvRelationship addedduplicate of 0027925
2016-12-20 16:33kgvNote Added: 0061927
2016-12-20 16:33kgvAssigned Tokgv => bugmaster
2016-12-20 16:33kgvStatusnew => feedback
2016-12-20 16:33kgvResolutionopen => duplicate
2016-12-20 16:35TimoNote Added: 0061928
2016-12-20 16:35TimoNote Edited: 0061928bug_revision_view_page.php?bugnote_id=61928#r15643
2016-12-20 16:43kgvNote Added: 0061929
2016-12-20 16:45kgvNote Edited: 0061929bug_revision_view_page.php?bugnote_id=61929#r15645
2016-12-20 16:45kgvNote Edited: 0061929bug_revision_view_page.php?bugnote_id=61929#r15646
2016-12-20 16:45kgvNote Edited: 0061929bug_revision_view_page.php?bugnote_id=61929#r15647
2016-12-22 11:32apnTest case number => Not needed
2016-12-22 11:32apnStatusfeedback => closed
2016-12-22 11:32apnTarget Version7.2.0 =>
2020-07-10 13:41MatthiasNote Added: 0093082
2020-07-10 13:41MatthiasStatusclosed => feedback
2020-07-10 13:41MatthiasResolutionduplicate => reopened
2020-07-10 14:45kgvNote Added: 0093087
2020-07-10 14:45kgvAssigned Tobugmaster => Matthias
2020-07-10 14:46kgvNote Edited: 0093087bug_revision_view_page.php?bugnote_id=93087#r23131
2020-07-10 14:46kgvNote Edited: 0093087bug_revision_view_page.php?bugnote_id=93087#r23132
2020-07-10 14:47kgvNote Edited: 0093087bug_revision_view_page.php?bugnote_id=93087#r23133
2020-07-10 16:15MatthiasNote Added: 0093091
2020-07-10 16:15MatthiasAssigned ToMatthias => bugmaster
2020-07-10 16:15MatthiasResolutionreopened => fixed
2020-07-10 16:20kgvNote Added: 0093092
2020-07-10 16:20kgvNote Edited: 0093092bug_revision_view_page.php?bugnote_id=93092#r23137
2020-07-10 16:21kgvNote Edited: 0093092bug_revision_view_page.php?bugnote_id=93092#r23138
2020-07-10 16:21kgvNote Edited: 0093092bug_revision_view_page.php?bugnote_id=93092#r23139
2020-07-14 14:41bugmasterStatusfeedback => closed
2020-07-14 14:41bugmasterFixed in Version => 7.2.0

Notes
(0061927)
kgv   
2016-12-20 16:33   
Dear bugmaster,

please close the issue as duplicate of 0027716.
(0061928)
Timo   
2016-12-20 16:35   
0027716 seems to be a slightly different problem because it is about different objects behind each other, where I'm speaking about different parts of the same object behind each other. But maybe it has the same reason.
I cannot see 0027925, so cannot comment on that.

(0061929)
kgv   
2016-12-20 16:43   
(edited on: 2016-12-20 16:45)
> 0027716 seems to be a slightly different problem because
> it is about different objects behind each other,
> where I'm speaking about different parts
> of the same object behind each other.
Scenarios are different but the reason is the same - order-dependent transparency without any ordering.

Issue with several transparent objects can be worked around more simple (sorting objects)
than issues within the single transparent object
(which would require sorting triangles - and even this sorting might be not enough in case of their intersection).

General-purpose order-independent transparency algorithms can solve issues within both scenarios.

(0093082)
Matthias   
2020-07-10 13:41   
Reported issue still exists in OCCT 7.4.0.
(0093087)
kgv   
2020-07-10 14:45   
(edited on: 2020-07-10 14:47)
Dear Matthias,

please elaborate what exactly doesn't work as expected in use case.

Rendering semitransparent objects requires sorting and order-independent transparency (OIT) techniques. Within the current state (since 0027925 linked to the bug), OCCT implements one such OIT technique - Weighted OIT eliminating the main artifacts of unordered transparency at the cost of blurry transparency and a little bit slower framerate. There are other OIT techniques available in a wild providing better visual quality at lower framerate, which are currently not available in OCCT 3D Viewer. OCCT 3D Viewer also provides Ray-Tracing engine, which handles transparency more naturally.

OIT is disabled by default in OCCT 3D Viewer, so that application experiencing artifacts should enable it explicitly.

pload VISUALIZATION MODELING
restore shell.brep s
vinit View1
vdisplay -dispMode 1 s
vaspects s -setTransparency 0.4
vfit
vrenderparams -oit 0


(0093091)
Matthias   
2020-07-10 16:15   
Thank you Kirill,

it was unclear to me, that it's not a default, but has to be activated explicitly. There is a comment on the bottom of 0027925:

*Patch also simplifies processing of transparent objects for standard method:
rendering priority of transparent graphical structures is managed automatically,
therefore there is no need to care about it at application's side.*

The issue can be closed. Thanks again!
(0093092)
kgv   
2020-07-10 16:20   
(edited on: 2020-07-10 16:21)
> Patch also simplifies processing of transparent objects for standard method
Previously opaque and transparent objects have not been sorted, so that it was easy to draw something completely broken like opaque object overriding transparent one. The sorting have to be done manually via priorities (like it was done in AIS_Shape). Now transparent presentations are implicitly drawn after opaque ones, so that this specific kind of issue does no more occur (but it is irrelevant to the issue of combining several transparent presentations).