View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
0014011 | VES | ves | public | 2013-03-13 23:52 | 2013-06-29 19:20 | ||||||||
Reporter | Pat Marion | ||||||||||||
Assigned To | Aashish Chaudhary | ||||||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||||||
Status | assigned | Resolution | open | ||||||||||
Platform | OS | OS Version | |||||||||||
Summary | 0014011: Mapper bounds are not recomputed after assigning new geometry data | ||||||||||||
Description | If you assign a new vesGeometryData on a vesMapper, the mapper will not recompute bounds. After calling mapper->setGeometryData(data), you can workaround the bug if you do this: mapper->setBoundsDirty(true); actor->setParentBoundsDirty(true); VES should do this automatically whenever the geometry data changes. We could have a unit test for this, maybe use a vtk sphere source and then change its radius. | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files | |||||||||||||
Relationships | |
Relationships |
Notes | |
(0032624) Pat Marion (reporter) 2013-03-14 00:06 |
Here's a similar bug. If you add or remove a source data array from a mapper's vesGeometryData object, the VBO will not recompile if it has already been compiled. For example, if you had done mapper->geometryData()->removeSource(key), then you can force a recompile of the VBO with: vesGeometryData::Ptr geometryData = mapper->geometryData(); // store original mapper->setGeometryData(vesGeometryData::Ptr(new vesGeometryData)); // set dummy mapper->setGeometryData(geometryData); // reset original |
(0033409) Pat Marion (reporter) 2013-06-29 19:20 |
Here's an email posted by Eduardo on the VES mailing list. This might be a similar issue: I came across an interesting problem. I'm on stage/next, but I believe this happens with the current version as well. I have a class that is an ImageWidgetRepresentation, similar to vesKiwiImageWidgetRepresentation. It has a vesTransformNode, and underneath it, four children. The purpose of the vesTransformNode is so that I can rotate and translate the model with respect to the rest of the scene. However, whenever I translate the model, the bounds start to accumulate high values, affecting the outcome of a subsequent resetScene. I tracked it down to the updateBounds process. In vesTransformNode::updateBounds(vesNode& child), vesTransformNode looks at the bounds of the children, transform them with its own transform and then set these new values on the children. The problem is: in the children (vesActor::computeBounds()), there is a test for this->m_mapper->boundsDirty() before they reset their bounds according to the geometry. Since I never change the mapper, their bounds are never dirty. So, the children still have the transformed bounds that got stored there by the parent in the previous frame. The parent obtains them again, transforms them and stores them again, thereby accumulating the translations. I managed to figure out a fix: after I modify the vesTransformNode's transformation, I loop through all its children and set bounds dirty on their mappers. Is this a problem with the updateBounds process, or am I doing something wrong? The solution seems clumsy. Should vesTransformNode::updateBounds(vesNode& child) really set the bounds on the children? (see line that says child.setBounds(min, max)). What is the purpose of that? |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2013-03-13 23:52 | Pat Marion | New Issue | |
2013-03-13 23:52 | Pat Marion | Status | new => assigned |
2013-03-13 23:52 | Pat Marion | Assigned To | => Aashish Chaudhary |
2013-03-14 00:06 | Pat Marion | Note Added: 0032624 | |
2013-06-29 19:20 | Pat Marion | Note Added: 0033409 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |