Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division, division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote:
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your
sphere are the same it seems.
On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote:
Something's amiss. Attached are images of what I see when I interact
with a default sphere.
Utkarsh
On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl wrote:
Does the LOD render use quadric clustering by the way?
And if so, should the LOD resolution setting produce the same mesh
during interactive rendering as when applying a Quadric Clustering
filter to the same input with the same resolution settings?
On 06/20/2012 03:40 PM, Paul Melis wrote:
Hmm, maybe not a good test, as depending on the sphere resolution a the
quadric clustering will produce the same results for a range of
dimension settings (i.e. 10^3 and up)
On 06/20/2012 03:36 PM, Paul Melis wrote:
I actually get the same result when using the builtin server.
On 06/20/2012 03:34 PM, Paul Melis wrote:
Same result, I see no difference in meshes used during interaction
between 10x10x10 and 160x160x160 for LOD Resolution. Just to make
sure:
- LOD Threshold is checked, set to 0.00 MBytes
- Remote Render Threshold is checked, set to 0 MBytes
Paul
On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote:
Try reproducing with sphere source. Any luck?
On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl
wrote:
It's already at 0 (see below).
Paul
On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote:
WHat is the LOD Threshold set to? Try setting it to 0.
Utkarsh
On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl
wrote:
Hi,
I'm doing remote rendering with PV 3.14.0, with quite a large set
(isosurface of 98M tris) on 16 render nodes, each with a GTX460
and 12 GB RAM (Linux 64-bit cluster btw).
This model renders like a dog when interacting. I've checked the
subsampling settings, compression settings and LOD settings to
see make sure I'm actually using lower resolution rendering and
model decimation during interaction.
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division, division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote:
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your
sphere are the same it seems.
On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote:
Something's amiss. Attached are images of what I see when I interact
with a default sphere.
Utkarsh
On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl wrote:
Does the LOD render use quadric clustering by the way?
And if so, should the LOD resolution setting produce the same mesh
during interactive rendering as when applying a Quadric Clustering
filter to the same input with the same resolution settings?
On 06/20/2012 03:40 PM, Paul Melis wrote:
Hmm, maybe not a good test, as depending on the sphere resolution a
the
quadric clustering will produce the same results for a range of
dimension settings (i.e. 10^3 and up)
On 06/20/2012 03:36 PM, Paul Melis wrote:
I actually get the same result when using the builtin server.
On 06/20/2012 03:34 PM, Paul Melis wrote:
Same result, I see no difference in meshes used during interaction
between 10x10x10 and 160x160x160 for LOD Resolution. Just to make
sure:
- LOD Threshold is checked, set to 0.00 MBytes
- Remote Render Threshold is checked, set to 0 MBytes
Paul
On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote:
Try reproducing with sphere source. Any luck?
On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl
wrote:
It's already at 0 (see below).
Paul
On 06/20/2012 03:16 PM,
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division, division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote:
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your
sphere are the same it seems.
On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote:
Something's amiss. Attached are images of what I see when I interact
with a default sphere.
Utkarsh
On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl wrote:
Does the LOD render use quadric clustering by the way?
And if so, should the LOD resolution setting produce the same mesh
during interactive rendering as when applying a Quadric Clustering
filter to the same input with the same resolution settings?
On 06/20/2012 03:40 PM, Paul Melis wrote:
Hmm, maybe not a good test, as depending on the sphere resolution a
the
quadric clustering will produce the same results for a range of
dimension settings (i.e. 10^3 and up)
On 06/20/2012 03:36 PM, Paul Melis wrote:
I actually get the same result when using the builtin server.
On 06/20/2012 03:34 PM, Paul Melis wrote:
Same result, I see no difference in meshes used during interaction
between 10x10x10 and 160x160x160 for LOD Resolution. Just to make
sure:
- LOD Threshold
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division, division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote:
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your
sphere are the same it seems.
On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote:
Something's amiss. Attached are images of what I see when I interact
with a default sphere.
Utkarsh
On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl
wrote:
Does the LOD render use quadric clustering by the way?
And if so, should the LOD resolution setting produce the same mesh
during interactive rendering as when applying a Quadric Clustering
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote:
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of
your
sphere are the same it seems.
On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote:
Something's amiss. Attached are images of what I see when I interact
with a default sphere.
Utkarsh
On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl
wrote:
Does the LOD render use quadric clustering by the
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
With git-master, I verified that changing the slider indeed changes
the LOD refinement for a Sphere (phi/theta resolutions = 800). Also
try running ParaView with -dr option just to avoid any anomolies due
to the settings (for me, however, it works fine even when -dr isn't
specified.)
Utkarsh
On Thu, Jun 21, 2012 at 8:18 AM, Utkarsh Ayachit
utkarsh.ayac...@kitware.com wrote:
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl
wrote:
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
I applied it to the 3.14.1 sources. Perhaps I should indeed switch to
the git version.
Is the 3.14 client compatible with the server code in git?
On 06/21/2012 02:22 PM, Utkarsh Ayachit wrote:
With git-master, I verified that changing the slider indeed changes
the LOD refinement for a Sphere (phi/theta resolutions = 800). Also
try running ParaView with -dr option just to avoid any anomolies due
to the settings (for me, however, it works fine even when -dr isn't
specified.)
Utkarsh
On Thu, Jun 21, 2012 at 8:18 AM, Utkarsh Ayachit
utkarsh.ayac...@kitware.com wrote:
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() +
10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl
wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is
the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Argh, I see that git needs Qt 4.7.x :-/
On 06/21/2012 02:26 PM, Paul Melis wrote:
I applied it to the 3.14.1 sources. Perhaps I should indeed switch to
the git version.
Is the 3.14 client compatible with the server code in git?
On 06/21/2012 02:22 PM, Utkarsh Ayachit wrote:
With git-master, I verified that changing the slider indeed changes
the LOD refinement for a Sphere (phi/theta resolutions = 800). Also
try running ParaView with -dr option just to avoid any anomolies due
to the settings (for me, however, it works fine even when -dr isn't
specified.)
Utkarsh
On Thu, Jun 21, 2012 at 8:18 AM, Utkarsh Ayachit
utkarsh.ayac...@kitware.com wrote:
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() +
10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a
printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(),
this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl
wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is
the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my
case.
Especially for a
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Forcing delivery (whatever that means ;-)) in
vtkGeometryRepresentation::ProcessViewRequest() seems to solve it with
3.14.1:
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
this-Decimator-SetNumberOfDivisions(division, division, division);
// ADDED PM
outInfo-Set(vtkPVRenderView::NEEDS_DELIVERY(), 1);
}
this-LODDeliveryFilter-ProcessViewRequest(inInfo);
Paul
On 06/21/2012 02:22 PM, Utkarsh Ayachit wrote:
With git-master, I verified that changing the slider indeed changes
the LOD refinement for a Sphere (phi/theta resolutions = 800). Also
try running ParaView with -dr option just to avoid any anomolies due
to the settings (for me, however, it works fine even when -dr isn't
specified.)
Utkarsh
On Thu, Jun 21, 2012 at 8:18 AM, Utkarsh Ayachit
utkarsh.ayac...@kitware.com wrote:
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() +
10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM,
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Ah ok.its a very bad thing to do, but it's no longer needed in
git-master so I'll not think too much about it :).
Utkarsh
On Thu, Jun 21, 2012 at 9:04 AM, Paul Melis paul.me...@sara.nl wrote:
Forcing delivery (whatever that means ;-)) in
vtkGeometryRepresentation::ProcessViewRequest() seems to solve it with
3.14.1:
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
this-Decimator-SetNumberOfDivisions(division, division, division);
// ADDED PM
outInfo-Set(vtkPVRenderView::NEEDS_DELIVERY(), 1);
}
this-LODDeliveryFilter-ProcessViewRequest(inInfo);
Paul
On 06/21/2012 02:22 PM, Utkarsh Ayachit wrote:
With git-master, I verified that changing the slider indeed changes
the LOD refinement for a Sphere (phi/theta resolutions = 800). Also
try running ParaView with -dr option just to avoid any anomolies due
to the settings (for me, however, it works fine even when -dr isn't
specified.)
Utkarsh
On Thu, Jun 21, 2012 at 8:18 AM, Utkarsh Ayachit
utkarsh.ayac...@kitware.com wrote:
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() +
10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a
printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(),
this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
