[Paraview] Desktop-delivery and LOD settings: no influence?

Utkarsh Ayachit utkarsh.ayachit at kitware.com
Thu Jun 21 07:46:17 EDT 2012 

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.melis at 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.melis at 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_cast<int>(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.melis at 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.melis at 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.melis at 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.melis at 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.Melis at 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. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than "10 per direction" (or per data piece assigned per process, when showing Process Id Scalars).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>>>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>>>
>>>>>>>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>>>
>>>>>>>>>>>> Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView
>>>>>>>>>>>>
>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-BUG-13255.-LOD-Resolution-was-not-having-any-effect..patch
Type: application/octet-stream
Size: 4290 bytes
Desc: not available
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120621/e29deb68/attachment-0001.obj>

More information about the ParaView mailing list