`vtkmodules.util.views_scivis`#

Pythonic overrides for the vtkViewsScivis module.

The wrapping layer already exposes snake_case properties (color, opacity, representation …) for every class in this module, and enum properties backed by Set<Prop>To<Name>() methods already accept strings (e.g. rep.representation = "wireframe", view.selector.mode = "frustum"). These overrides add the few things the wrapping does not provide on its own:

named colors – color="tomato", resolved via :mod:vtkmodules.util.colors
delegation of properties the C++ classes deliberately do not carry – setting rep.specular or view.key_light_intensity reaches the property, geometry filter or light kit that owns it, so the flat spelling that makes keyword arguments natural survives the smaller C++ API
the same in the constructor, including a dict per sub-object – vtkScivisView(selector={"mode": "frustum"})
a fluent view.show(source, color=...) helper that creates, configures, and adds a representation in one call
view += representation / view -= representation
view.size = (width, height)

The layer is registered for vtkViewsScivis in vtkmodules/__init__.py.in and loaded automatically when that module is imported.

Module Contents#

Classes#

`_Delegating`	Route properties to the object that owns them.
`SurfaceRepresentation`	`vtkSurfaceRepresentation` with named colors and property delegation.
`ScivisView`	`vtkScivisView` with named colors, `size`, `show()`.
`VolumeRepresentation`	`vtkVolumeRepresentation` with property delegation.

Functions#

`_make_representation`	Build a representation for representation_type.
`_resolve_color`	Return an `(r, g, b)` tuple for color.
`_check_property`	Raise for a keyword argument nothing on obj owns.

Data#

REPRESENTATION_TYPES

API#

vtkmodules.util.views_scivis.REPRESENTATION_TYPES#: None

vtkmodules.util.views_scivis._make_representation(representation_type)#

Build a representation for representation_type.

Accepts None (a surface representation), a name from :data:REPRESENTATION_TYPES, or a representation class.

vtkmodules.util.views_scivis._resolve_color(color)#

Return an (r, g, b) tuple for color.

color is either a 3-sequence with components in [0, 1] or a snake_case named color from :mod:vtkmodules.util.colors (e.g. "tomato", "steel_blue").

vtkmodules.util.views_scivis._check_property(obj, name)#

Raise for a keyword argument nothing on obj owns.

Attribute assignment on a Python subclass of a VTK object quietly creates an instance attribute, which would turn a misspelled keyword argument into a property that silently does nothing. Keyword arguments are checked here so that they fail where the mistake was made.

class vtkmodules.util.views_scivis._Delegating(**kwargs)#

Route properties to the object that owns them.

The C++ classes carry only what it takes to make data visible and legible; everything else lives on the actor, property, mapper or filter underneath. That is the right shape for C++, where reaching one object further is a method call, but it would spoil view.show(src, specular=0.3) in Python, where flat keyword arguments are the whole point.

So an attribute this class does not define is looked for on each delegate in turn, and set on the first that has it. rep.specular = 0.3 and rep.property.specular = 0.3 are then the same thing, and an attribute nobody owns still fails, naming the delegates it looked in.

Initialization

Accept in the constructor everything assignment accepts.

VTK builds its own constructor keyword handling from the properties a class declares, and it runs before any Python attribute assignment – so it never reaches the delegation below, and view.specular = 0.3 would work while Class(specular=0.3) did not. Anything VTK does not recognise is applied here instead, which puts the two back in step.

A dict value configures the sub-object of that name, so the grouping the C++ API has is available at construction too::

view = vtkScivisView(
    window_title="demo",
    selector={"mode": "frustum"},
    light_kit={"key_light_intensity": 0.8},
)

There is no way to spell that as a keyword name – selector.mode= is a syntax error – and a dict means nothing to an ordinary VTK property, so there is nothing for it to collide with.

_delegates#: ()

_delegate_owning(name)#

__getattr__(name)#

__setattr__(name, value)#

class vtkmodules.util.views_scivis.SurfaceRepresentation(**kwargs)#

Bases: vtkmodules.util.views_scivis._Delegating, vtkmodules.vtkViewsScivis.vtkSurfaceRepresentation

vtkSurfaceRepresentation with named colors and property delegation.

Initialization

Accept in the constructor everything assignment accepts.

A dict value configures the sub-object of that name, so the grouping the C++ API has is available at construction too::

view = vtkScivisView(
    window_title="demo",
    selector={"mode": "frustum"},
    light_kit={"key_light_intensity": 0.8},
)

There is no way to spell that as a keyword name – selector.mode= is a syntax error – and a dict means nothing to an ordinary VTK property, so there is nothing for it to collide with.

_delegates#: (‘GetProperty’, ‘GetGeometryFilter’, ‘GetActor’)

property color#

property edge_color#

class vtkmodules.util.views_scivis.ScivisView(**kwargs)#

Bases: vtkmodules.util.views_scivis._Delegating, vtkmodules.vtkViewsScivis.vtkScivisView

vtkScivisView with named colors, size, show().

Initialization

Accept in the constructor everything assignment accepts.

A dict value configures the sub-object of that name, so the grouping the C++ API has is available at construction too::

view = vtkScivisView(
    window_title="demo",
    selector={"mode": "frustum"},
    light_kit={"key_light_intensity": 0.8},
)

There is no way to spell that as a keyword name – selector.mode= is a syntax error – and a dict means nothing to an ordinary VTK property, so there is nothing for it to collide with.

_delegates#: (‘GetLightKit’, ‘GetOrientationMarkerWidget’, ‘GetRenderer’)

property background#

property background2#

property size#

__iadd__(representation)#

__isub__(representation)#

show(input, representation_type=None, **properties)#

Add a representation for input to the view and return it.

input is a vtkAlgorithm (its output port is connected) or a vtkDataObject. Keyword arguments are applied as properties on the created representation::

view.show(sphere, color="tomato", opacity=0.8,
          representation="surfacewithedges")

representation_type selects what to build: a name from :data:REPRESENTATION_TYPES, a representation class, or None for a surface representation::

view.show(wavelet, "volume", scalar_opacity_unit_distance=0.8)
view.show(wavelet, MyRepresentation)

class vtkmodules.util.views_scivis.VolumeRepresentation(**kwargs)#

Bases: vtkmodules.util.views_scivis._Delegating, vtkmodules.vtkViewsScivis.vtkVolumeRepresentation

vtkVolumeRepresentation with property delegation.

Initialization

Accept in the constructor everything assignment accepts.

A dict value configures the sub-object of that name, so the grouping the C++ API has is available at construction too::

view = vtkScivisView(
    window_title="demo",
    selector={"mode": "frustum"},
    light_kit={"key_light_intensity": 0.8},
)

There is no way to spell that as a keyword name – selector.mode= is a syntax error – and a dict means nothing to an ordinary VTK property, so there is nothing for it to collide with.

_delegates#: (‘GetVolumeProperty’, ‘GetVolumeMapper’, ‘GetVolume’)

vtkmodules.util.views_scivis#

Module Contents#

Classes#

Functions#

Data#

API#

`vtkmodules.util.views_scivis`#