Comments (5)
@hartwork I'm skeptical of how useful that is. I would prefer to pass a 'global clock' time to all actors in a given pipeline.
From my experience, most state update code do not measure time deltas and extrapolate from there because that only works well if you have well parameterised state equations. This is not always easy or possible, so most state updates are designed to work in fixed intervals, frame by frame.
from libvisual.
@hartwork I'm skeptical of how useful that is.
At least two actors are doing something like that, I can make a list, if you like.
I would prefer to pass a 'global clock' time to all actors in a given pipeline.
Might be nice in addition but maybe that's something we can provided via a call to an API function rather than passing every time. Also, just a clock would still need boilerplate work to figure one when you last "looked at the clock".
From my experience, most state update code do not measure time deltas and extrapolate from there because that only works well if you have well parameterised state equations. This is not always easy or possible, so most state updates are designed to work in fixed intervals, frame by frame.
We can quantify these two buckets and see if "most" is that bucket or the other, both currently and after adjustment (remembering lv_gltest).
from libvisual.
@hartwork, yes it would be good to quantify. I certainly would be quite surprised to learn otherwise because updating state based on a variable interval is always more work than a fixed interval.
It would also be good to look at what visualisations outside of LV do.
I don't find calling an API function just to retrieve time delta ergonomic. Come to think of it, another possibility is to pass the last frame time and current frame time together.
from libvisual.
@hartwork, yes it would be good to quantify. I certainly would be quite surprised to learn otherwise because updating state based on a variable interval is always more work than a fixed interval.
@kaixiong I'm not sure I follow. Anything that rotates and is not bound to move in pixel steps is a good example of something that will work better (as in perceived constant speed) with time delta.
would also be good to look at what visualisations outside of LV do.
Please go ahead, but I think we already know the answer to that, just not the quantity. I'm not sure if counting who does it "wrong" will help us here.
I don't find calling an API function just to retrieve time delta ergonomic.
We were talking about access to a clock not access to time delta with regard to the API function. Big difference to me.
Come to think of it, another possibility is to pass the last frame time and current frame time together.
That's good enough for me, as the delta can be extracted trivially.
Bonus points if we can ensure that it's from a monotonic clock.
from libvisual.
@kaixiong I'm not sure I follow. Anything that rotates and is not bound to move in pixel steps is a good example of something that will work better (as in perceived constant speed) with time delta. would also be good to look at what visualisations outside of LV do.
I've brought this up elsewhere before - transformations like those you see in lv_gltest
are very parameterisable with time - the state equations are relatively trivial to write down. Outside of that, it is not always easy or practical. For example, what do you do with actors that perform image filters e.g. convolutional effects like blurring the previous output?
Please go ahead, but I think we already know the answer to that, just not the quantity. I'm not sure if counting who does it "wrong" will help us here.
It's nothing to do with correctness per se but how expressible changes are in terms of a variable time delta. Which leads back to the question of the split among visualisations in their chosen approaches.
All else equal, fixed time deltas are just simpler and work with just about anything. Definitely if you can work with a variable time delta and have smooth transitions, it is best to do that.
We were talking about access to a clock not access to time delta with regard to the API function. Big difference to me.
I wasn't thinking of time deltas in particular - I just do not find 'callouts' as ergonomic as receiving the parameters directly. It's also a bit more work when we have complex pipelines involving multiple actors and morphs that need synchronisation. In such scenarios, we have to work with a pipeline-wide clock and the fact that some actors will be called later than others even though they're technically rendering for the same 'frame time' and composited together.
Come to think of it, another possibility is to pass the last frame time and current frame time together.
That's good enough for me, as the delta can be extracted trivially. Bonus points if we can ensure that it's from a monotonic clock.
Cool, this sounds like the way forward.
from libvisual.
Related Issues (20)
- Update lv-tool and examples to use SDL 2 HOT 1
- [0.4.x] Re-integrate or drop zombie plugins (that exist but are not being built) HOT 16
- MMX implementation of LV::Video's blit_overlay_alphasrc() is broken HOT 5
- Plans on release 0.4.2 (off branch 0.4.x, not master)
- macOS support / need your help with trying 0.4.x out on macOS (branch "0.4.x-macos") HOT 22
- Enable anti-aliasing for actor "lv_gltest"? HOT 6
- [0.4.x] Segfault in function blit_overlay_noalpha (lv_video.c)
- Enhancement of lv_analyzer HOT 6
- [0.4.x] Plugin "gforce": heap-use-after-free in method PixPort::Fade
- [0.4.x] Plugin "corona": heap-buffer-overflow in method Corona::genReflectedWaves HOT 4
- Support PipeWire HOT 4
- Port old GL code in actors to work with OpenGL 3.2+ core profiles HOT 9
- Throw out SIMD versions of memcpy and memset?
- Plugin (dancingparticles) - Signed integer overflows
- Provision Let's Encrypt certificate(s) for LV website
- [0.4.x] Plugin "gforce": severe warnings "no return statement in function returning non-void [-Wreturn-type]"
- [0.4.2] ./configure: 18070: Syntax error: word unexpected (expecting ")") HOT 7
- [0.4.2] [plugins] configure / bad substitution HOT 4
- RFE: port to `sdl2` HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libvisual.