Added color map support for simulation renderer #10
Conversation
|
|
||
| file.close(); | ||
| return validParsing; | ||
| } |
There was a problem hiding this comment.
lunchbox::loadAscii( lexis::LookupTable1D& )
Or, in other words, I strongly object to yet another implementation of color map handling.
There was a problem hiding this comment.
2 things:
- That's two new mandatory dependencies that I'd need to add in order to replace 20 lines of basic c++ code, you'll need to convince me.
- The existing implementation of the LookupTable1D is very 'livre' specific and does not currently satisfy my needs: typically additional parameters such as light emission and ambient occlusion strengths, and of course more than 256 values to match those of the simulation. It's already implemented in my branch, but I am pushing things little by little to make the reviewing easier. So let's first decide on the event, and then I will use it.
There was a problem hiding this comment.
There's something I don't understand here. After the discussion the other day I thought we had agreed on trying to take the use cases related to colormaps as an attempt to have one real shared component (and here I'm referring to a full library solution, not just an event schema). When we talked the other day about the colormap in Brayns, I thought you just wanted to do a small experiment with hardcoded values to understand better how it could work in OSPRay, but now you want to merge in 300 lines of code with the full feature. I know you want to try things, but I don't understand why you want to merge into master our third implementation of the same thing instead of making the effort in converging into a common solution. With this approach, the convergence won't ever happen. Was any user pressing to get simulation mapping in Brayns?
There was a problem hiding this comment.
My undestanding of the common part is in the definition of the colormap, and how to generate it, not in the way it is implemented in the application itself. I am of course willing to define a common way to generate color maps, if of course this makes sense considering the features provided by the various renderers. The current implementation does not define the color map, it only takes a set of values and makes them available to the simulation renderer. In my opinion, the common part resides outside of the application, for example in the form of a python library that we could use in a notebook (just an idea). I understand you already have some code there that I will be happy to reuse.
Regarding the last question, there is indeed an urgent request for media production that requires this feature.
No description provided.