postprocessing
postprocessing copied to clipboard
pmndrs
Roadmap
The purpose of this ticket is to track progress towards the next major release and to let people know where things are headed.
Before v7 (non-breaking)
- [x] ~~Modularize convolution operators~~ Implement different blur operators as passes
- [x] Implement bilateral blur (depth-based)
- [x] Implement Gaussian blur (for completeness)
- [x] Implement mipmap blur (for
BloomEffect) - [x] ~~Move effect analysis from
EffectPasstoEffectclass~~ - [x] Use internal timer, let user provide a custom timer
Into v7 (breaking)
See #419 for details.
- [x] Implement
BufferManagerandGeometryPass - [x] Create IO interface for passes and effects
- [x] Remove
EffectAttributes - [x] Reduce amount of predefined uniforms in
EffectMaterial - [x] Refactor
EffectComposerintoRenderPipelinefor pass grouping and swapping - [x] ~~Use render hooks to run passes, promote use of
renderer.render()~~ - [x] Drop support for older versions of
three - [x] Remove deprecated classes, fields and methods
- [x] Remove code that was added for backwards compatibility
- [x] ~~Move away from getter/setter properties~~ #349
- [x] Convert to TypeScript, add more examples to doc comments
- [x] Remove CJS bundles
- [x] Add support for
logarithmicDepthBuffer - [x] Implement GBuffer clearing
- [x] Implement GBuffer background rendering
- [ ] Port Effects to the new system: #600
Hi @vanruesc ! Thank you for the great library. Will the ssr effect be added in the near future?
The ReflectionEffect (alias SSREffect) will be added at a later stage because it relies on a geometry buffer (normals, metalness, depth, diffuse, etc.). The plan is to implement a proper buffer system first to pave the way for effects like SSR. Switching to MRT will be a non-breaking change as soon as it lands in three.
SSR will be added soon after v7, but I can't say when that will be.
Hello @vanruesc! Great library! Is rgbshift effect doable with the current release or it will available on a future release ?
Regarding TS migration, to make it easier I'd recommend to set allowJs and strict: false in the tsconfig file so JS code won't be filled with type errors :)
Awesome! We just implemented all your effects into our platform. We are wondering if there is an ETA for this roadmap? We are interested in the SSR effect more specifically.
Awesome! We just implemented all your effects into our platform. We are wondering if there is an ETA for this roadmap? We are interested in the SSR effect more specifically.
Dude... it's an open-source project, you don't ask for an ETA.
This issue has been on hold for a while now so I understand why people would like to know when things will start moving again. Since this is a hobby project with no financial backing, there is no ETA. I'd really like to continue working on this project right away, but work and other real-life issues take priority. I'm currently aiming for October/November to finally tackle this roadmap.
@marcofugaro I'm sure that @sayduck-daniel didn't mean to be pushy with his comment and I'm happy that people are interested in this project ❤️
@vanruesc have you considered adding a sponsors page or some other way for people to help fund this project?
@looeee Yes, I'd like to add a sponsors page at some point, but I haven't really looked into that yet.
It's pretty easy to set up - will take an hour or two total. But I guess if you want more than a couple of sponsors you'd have to start doing the social media circus.
@vanruesc I think what you're doing with this project is really cool! I have a bit of spare time and would love to contribute, but it sounds like you may be working on some major revisions in the background. Are there areas where I could contribute now or do you think it makes more sense to wait until some of the big things you're working on are merged in?
@lyonsno Thanks! Unless there's something you'd like to change, fix or add right now, I'd recommend waiting until the big things are out of the way because most of the planned changes affect the entire code base. One of the goals of these changes is to make it easier for people to contribute by making the concepts clearer and the code easier to read.
I'm currently aiming for October/November to finally tackle this roadmap.
It's now November and I'm still preoccupied with other projects so I'll have to adjust this to December, but I'll try to get some time in on the weekends.
please don't get it the wrong way, it's not my place to complain and i'm so thankful for what you're doing!
it's about the setter/getter thing, is it really critical? we would have to rewrite react-pp from scratch. that library gave effects into the hands of a large crowd of people that normally would struggle (think beginners, designers, frontend-devs etc). maybe 50-60% of the pp userbase comes from that lib. the maintenance burden, i honestly don't know how we can manage. i'm thinking this could be the end of it.
as for the technical side:
we won't be able to set and, more importantly, spread props over passes, we'll have to know all props beforehand and translate them to functions. functions in general cannot be expressed declaratively, they are not serializable either, and that is a quite a downside.
<bloomPass foo={1} bar={2} {...otherProps} />
is there any way we could be closer when it comes to drastic breaking changes, and give back and help overall? and again, i completely respect your every decision, you know best where to go with it.
@drcmda Thanks for sharing your concerns and the valuable feedback!
It was not my intention to make it harder for people to use this library. The problem I tried to address was that effects didn't only have configurable properties, but also methods for more complex settings. The goal was to normalize this landscape. If the mapping of properties to method calls creates too much work, we can revisit the usage of accessor properties. However, some settings are more complex, i.e. not single-value, so some mapping work will be inevitable.
Let's keep track of this in a separate ticket: #349
is there any way we could be closer when it comes to drastic breaking changes, and give back and help overall?
The recent changes should not have introduced any breaking changes. If something broke, please file a bug report!
@lyonsno Thanks! Unless there's something you'd like to change, fix or add right now, I'd recommend waiting until the big things are out of the way because most of the planned changes affect the entire code base. One of the goals of these changes is to make it easier for people to contribute by making the concepts clearer and the code easier to read.
I'm currently aiming for October/November to finally tackle this roadmap.
It's now November and I'm still preoccupied with other projects so I'll have to adjust this to December, but I'll try to get some time in on the weekends.
Are the changes you were referring to implemented yet? I certainly don't mean to pressure you, I just can't tell on my own because I'm not sure what you were planning to change!
@lyonsno Unfortunately, it's not done yet. I'm still wrestling with the architectural redesign but it's slowly coming along. The time I can spend working on postprocessing is limited and I had to prioritize other issues for the recent 6.25.0 release which slowed things down a bit.
The blocking issues are basically most of the bullet points under "Into v7 (breaking)". The main thing that keeps this from moving forward is to actually figure out a concrete API concept. I'm currently doing just that by drawing and scrapping diagrams.
I'm also in the process of reorganizing my working schedule to get more stuff done and I've created a Patreon page for financial contributions. However, I'm committed to maintain this project regardless of funds.
additionally, github sponsors and opencollective have been quite comfortable, you can add them to the project sponsor settings just like the patreon. these two allow monthly sponsorship and one-time donations. just putting it out there but https://github.com/pmndrs would also always be open for you.
I went with Patreon because they handle taxes, unlike GitHub Sponsors. And opencollective seemed more appropriate for teams.
just putting it out there but https://github.com/pmndrs would also always be open for you.
I'd be happy to join :+1:
just putting it out there but https://github.com/pmndrs would also always be open for you.
I'd be happy to join 👍
This is the way (I hope and will support monetarily). Our small team fits into the group of designers/front-end devs that @drcmda mentioned. We've been waiting with baited breath for the colorspace dust to settle while we integrate various combos of vanilla/vanruesc/react-pp to find a sweet spot between previous -> current -> future projects. For months, I've dreamed of how a more united collaboration between pmndrs and vanruesc might result in some sort of drei+pp type of situation. It could simplify the complexity of all this wizardry, while allowing those with lesser technical skills of you giants, but with big dreams, to push forward without the fear that the years of cobbling all these stones together might end in a dead end street (that leads back to babylon).
We appreciate so much of the nitty gritty that has been getting resolved over the past while, and are excited for the potential of tighter integration between your collective powers.
i would love to talk @vanruesc , i think it's super important that projects like this one get more attention and funding. how/where can i reach you? your twitter doesn't have dm switched on, no emails anywhere. 😄
I am currently using SSAOEffect. Is there any patch that temporarily supports logarithmicDepthBuffer. Thank you.🥹
@beginnerJq Unfortunately, I don't think there's an easy way to support log depth (https://github.com/pmndrs/postprocessing/issues/445#issuecomment-1419883040).
Just want to mention that I'd be happy to provide some heavy lifting on the typescript front whenever the dust settles enough to establish some style / structure plans for v7. I've spent a good amount of time rewriting most of the passes and effects to TS for another project this year so I think it'd be fun to make it happen for the new version!
Hi, is there any plan to support WebGPURenderer?
@lviggiani WebGPU is not widely available yet, so it's not the focus right now. WebGL 1 has only recently been deprecated in three and v7 will rely mostly on WebGL 2 with limited WebGL 1 support. When WebGPU becomes more prevalent, there will be another transition from WebGL 2 to WebGPU.
@FractalHQ Thanks! You can follow the most recent development progress by checking the v7 branch. I still need to consolidate the base API and finish implementing the buffer management. After that I want to split the remaining work into smaller tickets so that anyone who'd like to help can pick them up.
Hi, @vanruesc
In terms of new feature "alpha hash" https://threejs.org/examples/?q=alph#webgl_materials_alphahash that was implemented along with Three.js r.154 which for improve visual "quality" requires antyaliasing methods like SSAA or TAA are there any plans to support it?
Current alternative to implement those effect in react-three-fiber is tu use three-stdlib and extend SSAA or TAA but as I posted the issue here https://github.com/pmndrs/drei/issues/1601 it is not working properly (it's changing colors of scene) as many people use this great lib in their projects it would be helpful to use it through it.
@Russo-creation Interesting, I didn't know there was support for alpha hash in three. TAA is planned to be added after v7 is done.