Skip to content

feat: Post-processing #52

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

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open

Conversation

RudyBlack
Copy link
Contributor

Details

There are two main ways to apply postprocessing.

First way is using Post-processing of built-in three.js.
Second way is using Post-processing of library

Since each has its pros and cons, I decided it would be better for the user's can be choose one of two theyself.
(Of course, can't be use mixed it.)

Built-in three.js Post-processing of Library
SSR v Not yet
Bloom v
But have a background issue (mrdoob/three.js#14104)
v
Variety Normal Have a variety effects
Perfomance Normal Expect good performance by optimizing itself
Documentation Only basic examples exist Have a detailed document page.
Community A lot of discussion is taking place on its own community site. -

And bundle sizes result. (Before / After)
before (Before)
after (After)

@RudyBlack RudyBlack changed the title Post processing feat: Post-processing Dec 28, 2022
Copy link
Member

@WoodNeck WoodNeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like the idea that we can use the other post-processing library directly,
but the overall usage of it looks quite complicated.

To use post-processing, especially when using the three.js one, the user has to:

  1. Install three.js (even though View3D has a dependency on it)
  2. Import post-processing effects & EffectComposer to View3D

While doing this, the user must know all about both three.js & View3D
Like, for example, in the example of using SSRPass:

const camera = view3D.camera.threeCamera;
const renderer = view3D.renderer.threeRenderer;
const scene = view3D.scene.root;

const ssr = new SSRPass({renderer, scene, camera, selects: view3D.model.meshes, groundReflector: null});

The user has to know all the internal components of the View3D, which can be hard for newcomers.
I'd prefer simpler usage like this:

// "optionsForSSR" is options for SSR effect itself, like thickness, opacity, etc...
view3D.renderer.addPass(new SSRPass(optionsForSSR));

// Or...
view3D.addPass(new SSRPass(optionsForSSR));

In this case, the user only has to know:

  1. How to add a post-processing pass in View3D
  2. Which post-processing effects can be used with View3D
  3. Options for post-processing effects

Also, it looks a bit hard when we have to add a custom post-processing effect.

Well this is just my thought, I'd like to hear your opinions :)

@RudyBlack
Copy link
Contributor Author

RudyBlack commented Jan 4, 2023

Thank you for your reply despite your busy :)

I agree with your opinion as have to be used more easy for users.
Looking back, It seems customizable for post-processing but is hard to use.

I will more think about the between Performance (by low bundle size), Easy to use and Customizable although It is hard to achieve all of them perfectly.

So I will get find the best balance through various experiments in work such as It is easy to use, It is customizable for effects, bundle size has not been stretched too big, etc...

@RudyBlack
Copy link
Contributor Author

RudyBlack commented Jan 8, 2023

@WoodNeck

I thought about that...

How about offing 2 ways for users? one is only basic post-processing in View3D and the other offers customizable post-processing API.

First way is like this as you said:

import View3D, { SSRPass, BloomPass, DoFPass } from "View3D";

view3D.addPass(new SSRPass(optionsForSSR), new DoFPass(optionsForDoF), new BloomPass(optionsForBloom));

In this case of important is, Users do not need to install THREE.JS. because of offered basic post-processing in View3D, Users be easily use post-processing.
Also, the bundle size will not get bigger because only basic post-processing is provided.

The second way is like this:

import { EffectComposer, SSRPass } from "three/~~"

or 

import { EffectComposer } from "post-processing"

view3d.setEffectComposer(new EffectComposer());
view3d.setPass(({renderer, camera, scene, effectComposer, model, ...})=>{

 // This callback function is offered params that need to make for post-processing or custom post-processing.
 // So users can customize even not know inside view3D.

 const ssr = new SSRPass({renderer, scene, camera, selects: model.meshes, groundReflector: null});
 const customEffect = new ???(...);

 effectComposer.addPass(ssr, customEffect);

})

In this case, Users have to install THREE.JS or post-processing library.

Summary

  1. Only offer basic post-processing. (SSR, DoF, Bloom, SSAO, ... ). Basic post-processing will be provided with modifications to make it easier to use.
  2. Another is it, Provides API which allows users to freely add post-processing with post-processing library or custom post-processing. But in this case, Users have to install THREE.JS or library.
  3. Users can use either or both as they want.

Thinking of good balance for usability, scalability, and bundle size, I came to the above conclusion.
Is there anything I missed or do you have a better idea? If not, I will work on that :)

@WoodNeck
Copy link
Member

WoodNeck commented Jan 8, 2023

@RudyBlack
That looks promising, you can keep up with that!

One concern is, model can be changed at any time, so the post-processing pass won't work on the new model load.
So, please add something that can refresh the selects field of the effect for the second approach.

@RudyBlack
Copy link
Contributor Author

@WoodNeck

I found some issues while I was working.

Post-processing that built-in ThreeJS is not working or something issue on using each other. For example, can't use SSR and SSAO together. and have to apply tone mapping but If using bloom together, is to appear issue. and DoF has to be the last pass index. and etc... I am worried that offering basic post-processing to users is given to confusion.

So how about just providing only an interface that can use post-processing? ( Not provide basic post-processing )
or do you have some idea?

@WoodNeck
Copy link
Member

@RudyBlack

If it's not available, I think it would be helpful enough to establish an interface for using post-processing as you say. Specifically, I don't think you need to feel like you need to support all effects at this point.
However, for the issues you mentioned, it would be good to check these things out.

  • Are things like not being able to use multiple effects at the same time, not being able to use tone mapping, etc. officially unsupported? If there's something that's not working well with the View3D implementation, I could look into that.
  • Why don't you try implementing some simple post-processing effects of your own that aren't provided by three.js, that might help us get a better idea of what's causing the issues you're describing.

@RudyBlack
Copy link
Contributor Author

@WoodNeck

Why don't you try implementing some simple post-processing effects of your own that aren't provided by three.js, that might help us get a better idea of what's causing the issues you're describing.

I have a plan to implement simple post-processing effects myself. But it looks need knowledge of custom shader, glsl, math, etc. (I am studying hard for this...) and I think it will take a long time. so It's better to go step-by-step rather than implement it all at once. I'm sorry for the confusion.

Therefore, I will only make an interface to use post-processing and then implement the basic effects in the future.

@WoodNeck
Copy link
Member

@RudyBlack

It's better to go step-by-step rather than implement it all at once.

I completely agree with that.
Just, I would like you to check two things.

First, for libraries, it's not easy to change the interface.
View3D follows Semantic Versioning, so any interface changes that might affect users would require a major version update, which we try to avoid if possible.
So you have to be very careful when writing the interface. I like your approach, so go ahead and try it out, I'll keep reviewing it.

Secondly, I think it would be difficult to use if you don't provide basic effects at the library level.
It will be difficult for users to configure their own effects, because they will have the same issues you are having now.
So if possible, it would be great if you could include at least the ones that are working now, so that I can check them out and fix the ones that aren't :)

@RudyBlack
Copy link
Contributor Author

@WoodNeck

It's kind of you to say that. Thank you very much.
It was a little hard at the same time as the company work, but I'll try as much as I can and ask for help if it really doesn't work.
So I'll keep going :)

@WoodNeck
Copy link
Member

Keep up the great work!

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

Successfully merging this pull request may close these issues.

2 participants