[Paraview] Exposing BlendMode through UniformGridRepresentation (was: vtkSMProxy: GetSubProxy is protected, but I need it outside the class)
Jérôme
jerome.velut at gmail.com
Tue Oct 20 04:34:15 EDT 2009
Hi,
thanks for your interest. Attached is a diff file between my rendering.xml
and CVS's one.
An idea to complete this would be to add a combo-box in the display panel
(such as the slider for slice representation,...). However, this is less
important, since when the BlendMode property is exposed through the
UniformGridRepresentation, the Comp. / MIP / MinIP rendering mode is
'toggleable'. Here is a code snippet that can be use in C++ from inside a
plugin to toggle BlendMode (Note, this could be more elegant by using
properly QList... ):
///////// Code-snippet: Toggle BlendMode
pqViewManager * viewManager = qobject_cast<pqViewManager*>
(pqApplicationCore::instance()->manager("MULTIVIEW_MANAGER"));
// Get the representations present in the active view
for( int repId = 0; repId < viewManager->getActiveView(
)->getNumberOfRepresentations( ); repId++)
{
pqRepresentation* rep = viewManager->getActiveView(
)->getRepresentation( repId );
vtkSMUniformGridVolumeRepresentationProxy* proxy = 0;
proxy =
static_cast<vtkSMUniformGridVolumeRepresentationProxy*>(rep->getProxy());
// Check if the representation proxy is a
UniformGridVolumeRepresentationProxy
if( proxy && rep->isVisible( ))
{
// Get the BlendMode property
vtkSMIntVectorProperty* blendModeProp = 0;
blendModeProp = vtkSMIntVectorProperty::SafeDownCast(
proxy->GetProperty("BlendMode"));
// If the Property is not exposed, it cannot be used!!
if( blendModeProp )
{
// Increment the current BlendMode (Comp -> MIP ->MinIP ->Comp
->...
int blendMode = blendModeProp->GetElement( 0 );
blendMode++;
blendModeProp->SetElement( 0, blendMode%3 );
// Render
proxy->UpdateSelfAndAllInputs( );
rep->renderView( true );
}
}
}
/////////////////// End Code-snippet: Toggle BlendMode
Thanks again,
Jerome
2009/10/19 Berk Geveci <berk.geveci at kitware.com>
> I don't have any problems with committing the changes you described.
> Would you mind adding a document element to the property XML though?
>
> -berk
>
> On Mon, Oct 19, 2009 at 10:50 AM, Jérôme <jerome.velut at gmail.com> wrote:
> > Thanks for your precisions.
> >
> > Well you are right! ParaView's proxy mechanism is robust and giving too
> much
> > freedom to developers could be really dangerous!
> > And effectively, my first try to have access to VolumeMapper BlendMode
> > property was to change the rendering.xml resource in order to expose it.
> >
> > What I did was:
> >
> > - adding a IntVectorProperty in FixedPointVolumeRayCastMapper SourceProxy
> > <IntVectorProperty
> > name="BlendMode"
> > command="SetBlendMode"
> > default_values="0"
> > number_of_elements="1"
> > animateable="0">
> > <EnumerationDomain name="enum">
> > <Entry value="0" text="Composite"/>
> > <Entry value="1" text="MaximumIntensity"/>
> > <Entry value="2" text="MinimumIntensity"/>
> > </EnumerationDomain>
> > </IntVectorProperty>
> >
> > - adding BlendMode as exposed property to
> > UniformGridVolumeRepresentationProxy in FixedPoint(...) SubProxy
> > <Property name="BlendMode"/>
> >
> > - adding BlendMode as exposed property to UniformGridRepresentation
> > PVRepresentationProxy in UniformGrid(...) SubProxy.
> >
> > I changed blend mode by using GetProperty("BlendMode") on the
> representation
> > proxy, and it works as well. But in both case (bad unprotected way and
> > exposing propoerty way), I have to change something in ParaView's tree
> and
> > recompile it. It makes my plugin working on my computer only...
> >
> > Is this BlendMode exposure interesting you and do you want me to send a
> diff
> > file of my local 'rendering.xml'?
> >
> > Thanks again!
> >
> > Best regards,
> > Jerome
> >
> >
> >
> > 2009/10/19 Berk Geveci <berk.geveci at kitware.com>
> >>
> >> > - Is there a reason (software design, maybe?) to protect the functions
> >> > that
> >> > give access to subproxies, whereas the access to properties are
> >> > -fortunately- public?
> >> > - Is there another way to access SubProxy without modifying ParaView's
> >> > sources?
> >>
> >> Yes, there is a reason for not exposing the sub-proxies. We wanted the
> >> access to the sub-proxies to be only through exposed properties
> >> because we want all proxies (whether they have sub-proxies or not) to
> >> behave exactly the same way. Allowing access to the sub-proxies makes
> >> it almost impossible to make sure that developers don't shoot
> >> themselves in the foot by changing properties of the sub-proxies that
> >> are supposed to be controlled by the super-proxy. For example, a
> >> property in the super-proxy may end up setting multiple properties in
> >> the sub-proxy.
> >>
> >> Isn't there another way of doing this? Maybe expose the property you
> >> are setting? Something like VolumeMapperBlendMode?
> >>
> >> -berk
> >>
> >> On Mon, Oct 19, 2009 at 2:50 AM, Jérôme <jerome.velut at gmail.com> wrote:
> >> > Hi,
> >> >
> >> > I wrote a plugin that enable a toggle between different BlendMode of
> the
> >> > FixedPointVolumeRayCastMapper that is used by ParaView for volume
> >> > rendering.
> >> > It catches a key event on a render window ('B' pressed) and toggle
> >> > BlendMode: Composite -> MaximumIntensity -> MinimumIntensity ->
> >> > Composite->...
> >> >
> >> > Here is my way:
> >> > - When button 'B' pressed:
> >> > - get view manager from core instance
> >> > - get active view from view manager
> >> > - for each representation 'rep' of active view:
> >> > - check if 'rep' has a VolumeRepresentation SubProxy
> >> > - if yes:
> >> > - check if VolumeRepresentation has a
> >> > VolumeFixedPointRayCastMapper
> >> > SubProxy
> >> > - if yes:
> >> > - get the vtkFixedPointVolumeRayCastMapper ('mapper') from
> >> > this
> >> > latter SubProxy
> >> > - mapper->SetBlendMode( (++mapper->GetBlendMode( ))%3 );
> >> > - Update and render.
> >> >
> >> >
> >> > For this to work, I need to call vtkSMProxy::GetSubProxy( char* ) from
> >> > my
> >> > plugin class. But unfortunately, these functions are protected member.
> I
> >> > modified the ParaView sources to make it public, and it work just...
> >> > fine.
> >> > My questions are:
> >> > - Is there a reason (software design, maybe?) to protect the functions
> >> > that
> >> > give access to subproxies, whereas the access to properties are
> >> > -fortunately- public?
> >> > - Is there another way to access SubProxy without modifying ParaView's
> >> > sources?
> >> >
> >> > Thanks!
> >> >
> >> > Jerome
> >> >
> >> > _______________________________________________
> >> > 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20091020/e447e12e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rendering.xml.diff
Type: application/octet-stream
Size: 1917 bytes
Desc: not available
URL: <http://www.paraview.org/pipermail/paraview/attachments/20091020/e447e12e/attachment.obj>
More information about the ParaView
mailing list