[vtk-developers] vtkLookupTable::Build() behaviour ?

[Sebastien BARRE]

Hi

I was wondering if the vtkLookupTable::Build() behaviour is accurate, or 
enough documented.

It seems that if one wants to *rebuild* a table that has been built and 
modified using SetTableValue(), then one has to issue this strange series 
of commands to get it rebuilt correctly :

	Build
	Modified
	Build

Here is why :

Suppose that my app creates a LUT called lut with opacity = 'x'. The only 
thing I know is its name, and its nb of colors. I do not know about 'x' 
(although I might, of course, GetxxxRange(), but I do not want). From time 
to time I'd like to manually insert values in that table to change the 
opacity of a specific range of entries to 0.0. Therefore, I'd like the 
table to rebuild itself to set the old 0.0 range back to 'x' (I do not know 
about the properties of the LUT, then I must use ::Build()) , than set the 
new range to 0.0 :

step 0) : create the lut (vtkLookupTable), and set it (SetxxxRange and so on)

then from time to time :

step a) : rebuild the lut (lut Build) to set alpha to 'x'
step b) : insert 0.0 alpha values (SetTableValue) in a specific range

But step a) will fail ! Thus, I'll get a LUT where the old range and the 
new range are merged, and at the end my LUT will probably be full of 0.0

step a) fail because of the implementation. As it has not changed since 
3.1, I'm quite sure it has been done on purposes, but I do not understand why :

void vtkLookupTable::Build()
{
    [...] init

   if ( this->Table->GetNumberOfTuples() < 1 ||
   (this->GetMTime() > this->BuildTime && this->InsertTime < this->BuildTime) )
     {
	[...] code that perform the build
   }
   this->BuildTime.Modified();
}

Notice the test :   (this->GetMTime() > this->BuildTime && this->InsertTime 
< this->BuildTime) )

This means that in order to allow the build, the LUT must have been 
modified since the last build (which seems logical), AND the last insertion 
must have been done before the last build (<=> the last build has been done 
after the last insertion).

The last condition is strange. In fact, it states that once insertion has 
been done (which has been done after an initial build, otherwise it's 
stupid), it is no more possible to rebuild the LUT ! Very strict...

But this can be circumvented because the last line :

   this->BuildTime.Modified();

is run even if the build is not done ! (it's out of the test).

Therefore :

- I have performed an initial build, then an insertion :
	GetMTime > BuildTime && InsertTime > BuildTime

- I try a this->Build() :
	this *fails* (because of the previous condition) BUT now :
	GetMTime < BuildTime && InsertTime < BuildTime

- This leaves us the first condition to fix, so let's : this->Modified()
	now :
	GetMTime > BuildTime && InsertTime < BuildTime
	which is the required condition to Build()

- this->Build() : will work

Summary :
	Build
	Modified
	Build

Strange, huh ?
I do not know if it's a feature. If it's a bug (the last line should be in 
the test), then I'd be curious to know how I might rebuild a table and 
perform new insertion without destroying/recreating an object...

Thanks