- User Since
- Feb 11 2018, 12:27 AM (67 w, 1 d)
Thu, May 9
Apr 2 2019
Mar 18 2019
Mar 4 2019
Mar 1 2019
Feb 28 2019
*facepalm* sorry for wasting your time, I forgot to run make install..... closing now
Feb 27 2019
Feb 26 2019
Removed the poll function for selection-based proxy tools
@Campbell Barton (campbellbarton) The "enable proxies on selected strips" operates on all selected strips, therefore the poll function must iterate on all selected strips.
Feb 24 2019
Feb 14 2019
I agree that the many types of brushes is confusing, I think we should ideally get down to three types of brushes :
- Raster brushes : texture paint, image paint, weight paint (not sure for this one)
- Vector brushes : grease pencil
- Sculpt brushes : sculpt mode, but also gp sculpt
Feb 11 2019
Feb 4 2019
I read your updated doc, and here are a few notes :
- I think we can keep a single thread for prefetching : rendering a single frame should already be multithreaded in many cases (renders, effects, etc...). Would doing this remove the need for error-prone scene copying, or is it inevitable ?
- I have many issues with a simple color strip : it initially apprears black, then when I enable prefetching it turns red, but there is no prefetching... When i scrub it flickers from red to black, etc...
- I would love to see support for scene strips, disk cache, and per-strip selection (pretty much everything you mention in "TODOs" !)
- I would love for there to be a "Prefetch this whole strip" option, to enable pre-composition of scene or meta strips. It would have to cache to disk in this case, and prefetch even frames where the strip is not visible (when it is under another strip for instance).
Feb 1 2019
My patch is not outdated it should apply cleanly and partial review is still pretty much possible.
Sorry I mush have confused this patch with D3597.
Jan 31 2019
Hi @Richard Antalik (ISS), I would be glad to collaborate on this, and I'm sorry your patch was not merged before it got outdated. I think one of the reasons is it was very long (4 kloc !) and hard to review.
I cleaned up an old unused threading api : D4289
I implemented some pre-fetching using ImBuf's own caching system (which takes care of invalidation etc.) : D4288
Jan 29 2019
@Richard Antalik (ISS) Disk cache would be implemented at the level of IMB right ? Is this going to be enough to cache everything we need ? Do we need to implement cache invalidation code or is it going to work natively through IMB's reference counting ? I did a simple test with a blur effect and it looks like cache invalidation works fine as it is.
Jan 28 2019
@Richard Antalik (ISS) Hmm okay, so there will be caches on several levels when compositing. A RAM cache is already implemented, right ? Is it a strip-level or global-level cache ?
@paul szajner (szap) Proxy support for scenes has been temporarily removed in the master branch, because the proxy function was originally designed only for movie strips.
Jan 27 2019
Minor code cleanups
Improve the sequencer proxy UI : D4262
Added changes suggested by @Richard Antalik (ISS) : selection-based operators are greyed out when no compatible strips are selected, and other cosmetic changes.
Jan 26 2019
Jan 25 2019
Since proxies are only for movies, I think ot would make sense to add a "batch process" feature so the user can generate proxies for all his footage before even importing them in blender. I find it frustrating to wait for proxy generation each time I import a clip.
By the way, when generating several proxies (25%...100%) for a non-vse scene (3d render), the fastest way would be to generate the highest-res proxy first, then downscale it to obtain the other proxy resolutions, right ? How feasible would this be ?
Not applicable - as I said this will be done by cache management. *Only* movies will have proxies.
I'm not sure what you mean by that. I think it's important to separate proxies and pre-fetching.
First let's clear definitions: Proxy is close enough representation of original file, pre-processed to have required properties(fast scrubbing, scaled), so working with it is more time efficient.
Prefetching has nothing to do with dumping cache.
As cache is generated, it can be stored on disk. When cache is polled for frame, it will look first in RAM, if frame is not found, is can look at disk - still faster then re-render in most cases.
this dumped data however *have to be* stored individually, as it may be requested to be deleted/flagged as out-of-date (properties of strip has changed -> invalidate cache).
Yes I'd like to spend a bit of time on these issues, but I feel this patch is getting way too big and hard to merge/apply. I think it's important to separate proxy generation, pre-fetching and interface changes in several incremental patches (trying to keep their size to <100 lines).
I'm not sure how the blender git tree is organized, but from my perspective it would make sense to develop these features in a separate branch, and to make minimal (and documented) changes to the API, so it is easier to merge in the master branch later.
Some cleaning of old code, refactoring and updating UI to reflect reality
Small changes are good approach, but end goal should be discussed. With prefetching I changed same code number of times, because I was not familiar with basics, and therefore couldn't plan changes in detail.
You would have to look by date, but this patch needs to be reworked:
- to keep things simple, code cleanup done in this patch should be dropped
Hi @Richard Antalik (ISS) , I'm trying to test your patch, but I am unable to apply it to the master branch. What is the base commit for this patch ?
Jan 10 2019
In the newly introduced bug, the curves are initially not functioning, but "spring into action" as soon as any kind of animation data is changed in the strip (even a cancelled move - hitting G on a keyframe and hitting ESC) .
After a bit more testing, it looks like this patch indeed solves this bug, but also introduces a new minor bug T60194.
Sorry about that, it looks like I introduced this bug in my local build by applying a patch I made to solve this bug : T60194
After applying my patch, I was unable to reproduce T55668. It looks like each strip its given a unique name properly, even with nested Meta-Strips.
Jan 6 2019
Jan 5 2019
After investigation, I believe I can submit a patch that solves this issue. Please let me know what you think and how much testing this requires
I've been using my patch since Feb. without any issues, therefore I believe adding support for clip, sene and meta proxies is an easy task, although I'm not familiar enough with the Blender coding conventions to submit a commit myself.
Feb 15 2018
But are we really calling this proxy function with sound strips ? Maybe we should show a warning if we reach this point ?
Feb 14 2018
No, they should have a unique proxy path. I am not an expert, but for scene and meta clips, using seq->name seems to do the job.