[Paraview-developers] vtkSMTransferFunctionManager->GetColorTransferFunction

[Mathieu Westphal]

Hello

Well, something like , in pseudo code
"arrayName.RepresentationGlobalID.PVLookupTable"

getColorTransferFunction( arrayName, representation )
{
    lookupTable = FindProxy( arrayName, representation ); // Find exact lookuptable to use
    if( lookupTable )
    {
        return lookupTable
    }
    else
    {
        anotherLookupTable = FindProxy( arrayName ) //Find first lookuptable with this name, does'nt care for representation id
        if( lookupTable )
        {
            lookuptable.new( anotherLookupTable )
        }
        else
        {
            lookuptabel.new()
        }
    }
}

Sorry for dirty pseudo code. If i have some time i will try to scrap a real code and test it.
The idea is never share a loopuptable between representation, but copy lookuptable with same arrayName.

This work only if the user first set up the lookuptable for the simulation, then create another representation of the same array.
So it's clearly not perfect.

Mathieu


On Fri, May 30, 2014 at 09:08:55AM -0400, Utkarsh Ayachit wrote:
> Guys,
> 
> I understand your frustration, but the decision to adopt this way of
> setting up LUT was done a long long time ago and for good reason. In
> most use-cases, users typically are visualizing results from a single
> simulation and no matter how many filters you apply, or how many
> readers you create a variable with the same name typically means the
> same.  To avoid misinterpretations where Temperature from two
> different sources was colored differently the decision was made to
> color with the same array.
> 
> Mathieu, I see your point. The reason why representation is not pass
> in is simply because LUTs themselves are independent of
> representations. Let me think about this a little. Currently, it is
> indeed tedious to change the default behavior. If you guys have any
> ideas, I am all ears.
> 
> Utkarsh
> 
> 
> 
> 
> On Thu, May 22, 2014 at 11:36 AM, Joshua Murphy
> <Joshua.Murphy at lasp.colorado.edu> wrote:
> > Hi Utkarsh,
> >
> > I was running into the same problem with a source I wroteŠ Basically the
> > source defaults to the arrays being named ³Data² regardless of what is put
> > in it.  Thus, even if the data is vastly different, with multiple
> > instances of the source, everything is getting the same color scale, even
> > if I assign them different within python.
> >
> > So, if I read what you are saying this post, in order to separate the
> > individual instances of the source, it is necessary to name the arrays
> > differently between instantiations?  That is a world class pain. :)  I
> > guess I have some re-coding to do.   Glad I saw this post before I spent
> > all day troubleshooting!
> >
> > -Josh
> >
> > On 5/22/14, 7:17 AM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com> wrote:
> >
> >>Yes, that's exactly what's expected in ParaView, by design. All arrays
> >>with the same name get the same color transfer function. If custom
> >>applications want to change they, they can override (using VTK's
> >>factory mechanisms) the vtkSMTransferFunctionManager.
> >>
> >>Utkarsh
> >>
> >>On Thu, May 22, 2014 at 7:35 AM, Mathieu Westphal
> >><mathieu.westphal at gmail.com> wrote:
> >>> It seems to me this method associate an arrayName to a
> >>> ColorTransferFunction.
> >>>
> >>> It works well, but it appears that two array from completly different
> >>> dataset with the same name will be displayed with the exact same
> >>> ColorTransferFunction, including color, range and opacity.
> >>>
> >>> Is this normal ?
> >>>
> >>> Thanks
> >>>
> >>> Mathieu
> >>> _______________________________________________
> >>> Paraview-developers mailing list
> >>> Paraview-developers at paraview.org
> >>> http://public.kitware.com/mailman/listinfo/paraview-developers
> >>_______________________________________________
> >>Paraview-developers mailing list
> >>Paraview-developers at paraview.org
> >>http://public.kitware.com/mailman/listinfo/paraview-developers
> >