Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom vtkFileSeriesReader Node #44

Open
NickGeneva opened this issue Mar 11, 2021 · 4 comments
Open

Custom vtkFileSeriesReader Node #44

NickGeneva opened this issue Mar 11, 2021 · 4 comments

Comments

@NickGeneva
Copy link

After having some issues with getting the animation to work in BVTK due to my data starting at time-step 100 instead of 0 I thought it may be useful to add some sort of node that would allow increased control over time-step to animation frame process. (Also noted this seems to be a particular area in need of improvements based on some of the issues).

Something I stumbled on was this vtkFileSeriesReader in Paraview which allows the user to set up a JSON file with time-step meta-data if you have a series of data coming from multiple files:

{
  "file-series-version" : "1.0",
  "files" : [
    { "name" : "foo1.vtk", "time" : 0 },
    { "name" : "foo2.vtk", "time" : 5.5 },
    { "name" : "foo3.vtk", "time" : 11.2 }
  ]
}

This type of support for custom JSON files labels as filename.series may be a good fall back to add in BVTK if the use currently needs more control over the time-series than the default time-selector offers.

Is there something like this present or being developed in BVTK? Because if not, I'll work on making a custom node with this functionality.

@tkeskita
Copy link
Owner

Hmm I think that the global time keeper in the dev branch of @thomgrand does a bit of a different thing, but it overlaps. I wonder if all time related features could be part of Time Selector node, where user could do time management in one place? So maybe not JSON file but instead e.g. text block in Time Selector? Not sure though..

@thomgrand
Copy link

The main idea behind the Global Time Keeper was to re-introduce keyframing of the properties in the node-tree. The time step of the Time Selector node could then be animated to the desired values. Actually many of the properties in the tree can be used for keyframes.
Since there is no official support for animatable properties in custom node trees, this faces several hurdles, e.g. editing the keyframes becomes very difficult since you can't access them through the dope sheet or graph editor. Everything would need to be done in an easy way in the Global Time Keeper node. I'm no expert on how time is handled in VTK and was not able so far to finish the feature in a satisfying way. If you have any suggestions, I'd be happy to hear them.

@NickGeneva
Copy link
Author

NickGeneva commented Mar 14, 2021

I think the keyframing would be a great addition, but as @thomgrand said this would be a huge feature that I could see requiring a some significant additions to the code base. Any contributions like that I think are out of my league as of right now.

Perhaps enhancing the current time selector is a better description of what I'm envisioning. Adding options for start/stop frames, the custom meta-info support, etc. Also perhaps manual control over using internal VTK time-stepping vs file names (this would fix problems seen in issue #32 )? I'll think about this for a bit but @tkeskita I think you are correct that perhaps adding this support to the current time selector would be good rather than a new node.

Another great feature would be to support baking of animations, so you can pre-compute the blender objects in one go as opposed redoing it every time you change key-frames... not sure how this works in blender though right now.

@NickGeneva
Copy link
Author

I will wait to work on any sort of support for a meta-info json file until keyframing if figured out in thomgrands PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants