For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings

 

Need to speed up your development?
Have a look at our:

Samples & Tools

 

Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

Lazy Presentation Update

Benjamin Bihler's picture
Forums: 

Hi!

I am using OCAF and I am creating documents with attributes of our own types and our own presentation drivers. Some of these presentations are very costly to compute. Hiding attributes is implemented here as getting the TPrsStd_AISPresentation attribute that is related to the particular attribute and calling its Erase() method with Standard_False as argument.

Now it may happen that the user modifies something that invalidates the visualization. For example he might change visualization options. I have reacted on that by calling the presentation's Update() method to trigger visualization recomputation. But actually this is too eager. Why recompute the visualization if it is hidden anyway???

So I have tried to improve that. Finally I have found a solution, but the solution is absolutely weird (see item 3 in the list below). The reason might be that I do not understand how TPrsStd_AISPresentations work. But it might also be that the OCCT methods are badly documented or not correctly implemented. I do not know what is the case, so I would like to describe my tries. Could someone tell me why they did not work? Otherwise I would register several issues in the bug tracker.

1. Attempt: Remove the Presentation from the Interactive Context

To get rid of the old visualization, I have called TPrsStd_AISPresentations::Erase(Standard_True) on the respective presentation. Strangely this method does nothing, if the presentation is not displayed (check code of TPrsStd_AISPresentation::Erase). Why? After erasing the presentation I could decide to remove it!!! As a workaround for doing that I have to call TPrsStd_AISPresentation::SetDisplayed(Standard_True) first. Anyway, I did that, but it didn't change anything. I have not been able to figure out the difference between erasing and removing a presentation. The documentation of AIS_InteractiveContext::Remove() states that it will remove the object from every viewer. Still if I call TPrsStd_AISPresentations::Display(Standard_False) later (when the user decides to show the attribute and I do not know anymore that there has arisen a need to update the presentation), then the OLD visualization is displayed.

To do: TPrsStd_AISPresentation::Erase should remove the presentation even if it is not displayed. If there is really no big difference between erasing and removing presentations, then one of these functionalities should be marked deprecated and removed.

2. Attempt: Set to Update

The interactive object stored in the presentation attribute has a method SetToUpdate() which it inherits from PrsMgr_PresentableObject. This looks tempting. I had expected TPrsStd_AISPresentation::Display() to check whether the interactive object has been set like that and then to update the visualization. Unfortunately it doesn't do that.

To do: Shouldn't TPrsStd_AISPresentation::Display() check whether its interactive object needs to be updated before displaying it the next time?

3. Attempt: Nullify the Presentation's Interactive Object

By chance I have found a way to do exactly what I want. If I call TPrsStd_AISPresentation::Restore(presentation), then the internal interactive object is nullified. I don't have to remember that an update is necessary. The next time someone calls TPrsStd_AISPresentation::Display(), the visualization will be recomputed. So this is a perfect way of doing a lazy presentation update. Unfortunately misusing the Restore() method is a dirty hack.

To do: If this is really the best way to do lazy presentation updates then add a method TPrsStd_AISPresentation::NullifyAIS() and write to the method's documentation that this can be used for invalidating the current visualization.

I am extremely excited about your comments.

Benjamin Bihler

Benjamin Bihler's picture

I have registered two issues regarding the described problems:

https://tracker.dev.opencascade.org/view.php?id=30214

https://tracker.dev.opencascade.org/view.php?id=30215

Benjamin

Eduardo Castillo's picture

Hello, I've been also trying to work with OCAF unsuccessfully, if you could give me a simple application source code I'll be very grateful 

Benjamin Bihler's picture

Hello Eduardo,

I am sorry, I don't have any simple OCAF code.

You could try the following:

- Take the Qt Tutorial sample (the one with the bottle).

- Modify the code such that the applications stores an OCAF document (see OCAF.pdf how to create an empty document).

- Store the bottle (it is a TopoDS_Compound) in the OCAF document as attribute of type TNaming_NamedShape at a new node.

- Define an interactive viewer attribute (see section "Visualization Attributes" in OCAF.pdf) and use its interactive context to initialize the View of the Tutorial sample.

- Add a presentation attribute to the label that contains the bottle shape attribute (see ocafsamples/TPrsStd_Sample.cxx around line 144).

- Now you should see the bottle in your 3d view and this could be a starting point.

Two more hints:

- Don't mix OCAF with XDE. You don't need XDE to work successfully with OCAF.

- OCAF is worth investing some time. It has really been done well. If you need more help, ask Open CASCADE for commercial support.

Good luck,

Benjamin

Eduardo Castillo's picture

Thank you very much your suggestion has been very useful, I hope I could help you, but as you can see I just starting using this framework and my thesis depend on this

greetings and again thanks...