iv3d-users

Text archives Help


Re: [IV3D-USERS] Implementing a Reader Parallel to UVF


Chronological Thread 
  • From: tom fogal <tfogal@sci.utah.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: Re: [IV3D-USERS] Implementing a Reader Parallel to UVF
  • Date: Wed, 18 Jun 2014 11:38:39 +0200
  • Comments: In-reply-to Mathieu Malaterre <mathieu.malaterre@gmail.com> message dated "Wed, 18 Jun 2014 11:13:03 +0200."
Mathieu Malaterre writes:
> >> Ok. I am not very interested in volume rendering for now (mainly
> >> the 2x2 MPR view), so 0,0,0 is fine with me. Thanks for the
> >> explanation.
> >
> > oh, you should unfortunately be aware of a long-standing bug in
> > which the slice views only use the coarsest level of detail... :-(
> > apologies.
> >
> > i don't have time to dig into it right now, but i could show you
> > the code that would need fixing if you'd like to address this.
>
> I do not know if I'll be able to fix it, but since I need it I may
> tweak the code to see how it goes. What should I be starring at ?

It starts in GLRenderer.cpp around line 1093. You can see there that
we do a search for the first LOD that has only a single brick.

In reality, we *should* do something more akin to what goes on at line
1199: plan a new frame, setting the brick list to everything that makes
sense (the important part of PlanHQMIPFrame is the 'build sub frame
brick list'). Then loop through each elem of m_vCurrentBrickList and
render it.

> > ahh, okay, yeah; that's the core of IV3D's/Tuvok's model. Bricking
> > is an important missing component, though. You might consider a
> > frontend to the DynamicBrickingDS to get around this issue.
>
> I am not sure I understand what you mean. Should I be reading
> DynamicBrickingDS.cpp instead of uvfDataset.cpp to implement my own
> reader ?

ahh, no no, sorry.

> I can generate pertty much any brick size (power of 2 are much
> easier). So I was thinking to generate only on-demand brick size
> which match the current user setting (Edit>Settings>UVF File
> Parameters>Bricksize).

If you already have a mechanism to generate such bricks, it's probably
easier to just use your code.

But, essentially, that's what the DynamicBrickingDS does, without the
restriction of power of 2, just the restriction that it 'fits' nicely
in your original dataset.

The intent is that a user can click a checkbox and have the
DynamicBrickingDS replace the UVFDataset at runtime. The "checkbox"
is missing at the moment, unfortunately; the easiest way to do this at
present is to hack it through the Lua interface, like so:

-- load up some nonsense data, preferably small.
rw = iv3d.renderer.new(dummy)
-- now replace the data with a 'rebricked' data set.
rawr = rw.getRawRenderer()
rawr.loadRebricked(filename, {targetBrickSize, targetBrickSize,
targetBrickSize}, MM_PRECOMPUTE)

> > .. but that's a concern for later. It wasn't clear if you had
> > things working or just simply 'better'. Are you getting something
> > besides white volumes now?
>
> I do get a nice volume rendering of lod=0 (ts=0), but now even if I
> zoom nothing else gets called. However I did declare to have multiple
> LOD:
[snip]

this looks correct, offhand.. I am not sure what's wrong.

Could you turn on messages/warnings/etc. and send me a debug log?

-tom

Archive powered by MHonArc 2.6.18.

Top of page