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():
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
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,
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
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
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
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
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
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()))
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
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
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
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
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:
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
-
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
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
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
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,
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
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
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
22 matches
Mail list logo
