Fixed transfer function according to new Lexis event #115
Conversation
| std::bind( &ZeroEQPlugin::_colormapUpdated, this )); | ||
| _remoteColormap.registerSerializeCallback( | ||
| std::bind( &ZeroEQPlugin::_requestColormap, this )); | ||
| _httpServer->handlePUT( _remoteMaterialLUT ); |
There was a problem hiding this comment.
rename to _remoteColorMaps?
There was a problem hiding this comment.
_remoteMaterialLUT is more consistent with other class member names I think. And no GET for now since the renderer is not the 'owner' of the colormap.
There was a problem hiding this comment.
Then you should not create a default color map. You'll always have to receive one from the outside then to be consistent.
There was a problem hiding this comment.
materialLUT was the old name. The consistency so far was to name the variables close to the class name.
There was a problem hiding this comment.
As discussed, kept only the PUT command, and removed the default values.
|
|
||
| Vector2f colormapRange = DEFAULT_TRANSFER_FUNCTION_RANGE; | ||
| const auto& range = _remoteMaterialLUT.getRange(); | ||
| if( range[0] != range[1] ) |
There was a problem hiding this comment.
It's not, it's a temporary hack. I removed it.
| /** | ||
| * @brief This method is called when the colormap is requested by a ZeroEQ event | ||
| * @return True if the method was successful, false otherwise | ||
| * @brief This method is called when the material lookup table is updated by |
There was a problem hiding this comment.
colorMaps. No more material lookup table
| */ | ||
| bool _requestColormap(); | ||
| void _materialLUTUpdated(); |
No description provided.