Wrong hidden lines computed by HLRBRep_PolyAlgo and HLRBRep_PolyHLRToShape in OCC 5.1

pbr
Thu, 07/15/2004 - 12:05

Forums:

My application was written under OCC 50 and uses HLRBRep_PolyHLRToShape and HLRBRep_PolyAlgo to compute hidden lines.
The code looks like this:
for (int i = 0; i {
BRepMesh::Mesh(Shape(i), Deflection);
.....
m_HLR_Algo.Load (Shape(i));
}

m_HLR_Algo.Update();
m_aHLRToShape.Update(&m_HLR_Algo);
.....

// Create the result shape
TopoDS_Compound Shape;
BRep_Builder B;
B.MakeCompound(Shape);

TopoDS_Shape VCompound = m_aHLRToShape.VCompound(S);
if (!VCompound.IsNull())
{
B.Add(Shape, VCompound);
}

VCompound = m_aHLRToShape.OutLineVCompound(S);
if (!VCompound.IsNull())
{
B.Add(Shape, VCompound);
}
It works great under OCC50. Under OCC51, however, all shapes, which were added to the HL algorithm seems to be transparent and all lines are returned as visible! Any ideas, what can be a problem?

Regards,

Paul

tnb
Thu, 07/15/2004 - 22:03

I *think* this is a bug in OCC5.1. After trying to get the HLR facilities to work with this release, I found someone else had filed a bug report describing a similar situation. Last I knew, the bug hadn't been responded to.

I gave up on 5.1 and reverted to 5.0. Let's hope 5.2 will solve our problems.

(Note to Forum Supervisor: I *really* miss having a searchable bugs database on this site!)

pbr
Thu, 07/22/2004 - 14:30

I was the one, who posted the HLR-bug you mentioned. And your are right, I haven't become any answer on my bug report.
I have tried the same thing with OCC52 and it is still wrong. It seems only we both are interested in a properly working HLR!
I'll post this bug again, but I am very sceptic ...

For supervisor: I didn't get any e-mail about new messages in thread although I've check the corresponding check box.

Paul

pbr
Mon, 07/26/2004 - 17:28

I spend a lot of time trying to fix the bug I have reported, but at last I had success with it!

A solution for my problem:
Open ModellingAlgorithms project and take a look in the
OCC5.2\src\HLRBRep\HLRBRep_PolyAlgo.cxx file:

...
3654 // Tri1Flags &= ~FMskBack;
3655 Tri1Flags |= FMskBack;//OCC349
...

now comment out the line 3655 and restore the line 3654:

3654 Tri1Flags &= ~FMskBack;
3655 // Tri1Flags |= FMskBack;//OCC349

Recompile TKHLR.dll.

That's all.

tnb
Tue, 07/27/2004 - 00:59

Paul,

You're my hero!

I've been working on other things but figured that sooner or later I'd need to dig into the HLR problem. I'm so glad you did it for me.

Thanks very much for posting your findings. I hope I can return the favor some day.

--Tom B.

Philippe CARRET (not verified)
Mon, 01/10/2005 - 11:57

What a great Job you have done Paul !

THANKS A LOT.

A simple "//" for an unbelievable bug that save our previous and precious work.

Open CASCADE Su... (not verified)
Wed, 01/12/2005 - 14:15

Dear Mr. Borowski!

Thank you for reporting this problem in Open CASCADE Technology, and your successful debug!

The problem you reported has been registered as bug with reference number OCC7691 "Wrong hidden lines computed by HLRBRep_PolyAlgo and HLRBRep_PolyHLRToShape in OCC 5.1".

The correction you suggested will be further processed (tested for non-regression and improved if necessary) with a view for integration into future releases of OCCT.

Please note that you will be able to track integration of fix on that bug consulting the Release Notes of Open CASCADE Technology. The Release Notes are regularly published on our web site at http://www.opencascade.org/getocc/whatsnew.

We remind to all members of the Community that we value your efforts and we are always glad to receive your helpful contributions.

Yours sincerely,
Open CASCADE Support Team