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

question: outline posteffect #1460

Open
farfromrefug opened this issue Apr 10, 2021 · 5 comments
Open

question: outline posteffect #1460

farfromrefug opened this issue Apr 10, 2021 · 5 comments

Comments

@farfromrefug
Copy link

First sorry if it is not the right place to start. I could not find a better place.
I am looking at porting this oultine posteffect(code) to luma .
Though i feel pretty lost in luma passes system. Is there any tutorial or easy example which would give me a good starting point to port this?

THanks

@JannikGM
Copy link

I believe the multi-pass rendering system was removed (it was moved from core to just being an example in #1278).
So, I don't think there's a good way to add an simple pass to generate the linear-depth. You'll probably have to do it similar as for the threejs sample (set up a framebuffer, and manually render to texture)

However, the fragment shader is the core of the technique anyway.
You should be able to move the shaders from the threejs codebase into shadermodules (in the luma codebase, for others to enjoy; or in your project).
I assume you'll end up with a handful of different modules (to calculate linear-depth, to calculate normal-diff and depth-diff).

@ibgreen
Copy link
Collaborator

ibgreen commented May 26, 2021

There was a big push in luma.gl 8.0 to simplify the luma.gl codebase. In retrospect, I think removing the multi step rendering system might have been a step too far.

I could certainly see it come back in e.g. the experimental module, or perhaps in its own multipass module.

I'd be supportive if someone made a PR around this, and would also be very interested in seeing new post processing effects added to the library.

@farfromrefug
Copy link
Author

@JannikGM Thanks. and i think you are right. For now i dropped deck.gl because it was getting complicating on too many levels.
I achieved what i want using THREE.js and the work we are doing on geo-three.
Here is a render example https://farfromrefug.github.io/geo-three/example/index.html

@ibgreen
Copy link
Collaborator

ibgreen commented May 26, 2021

@farfromrefug That looks great!

Would be interested in hearing what complications you hit. We are always trying to make our libraries easier to use.

The main vis.gl user base is on deck.gl and loaders.gl where we tend to respond to issues quickly and we do weekly patches with fixes for user reported issues. There is a relatively limited subset of the user base that needs to work directly with luma.gl.

FWIW - loaders.gl is designed to be framework independent, so if you need to load other geospatial formats into your three.js app, feel free to take a look. Would be great to see THREE.js apps using loaders.gl.

@farfromrefug
Copy link
Author

@ibgreen sure i van explain a bit more. first thanks for your comment on loaders. I actually use them already to parse peaks data from maptiler mvt tiles!
first I started with deck.gl. it was really to have a "navigating" map with martini tiles. but quickly I stumbled upon issues. the main one was I could not easily start to work on the outline effect. wasn't that easy to get "deep" and being able to customize passes and such (also it is important to mention I was still learning a lot about webgl and everything at that time)
Also I was having a hard time customizing the controls to something I like.
I was also trying to draw the "lines" and peaks with deck gl and was having issues with filtering the datas to show. for that I needed GPU picking to see only not occulted peaks.
this is when I discovered geo-three. it was simple enough and allowed to go very deep. Also one big thing which could be crazy interestong to you is that elevation is actually rendered through GPU. it is really fast and make loading tiles 10times faster and uses a lot less memory( very important to me as my main goal is to use this on mobile using offline data I get from the Carto Mobile SDK).
that s how I got to switch from deck.gl.

Now if you are interested there are many things you could take from what we are doing in geo-three:

  • GPU elevation and normals computation from rgb elevation tiles
  • "zoomDelta" to get tile texture data using higher level tiles. this allows to use mapbox elevation tiles (stopping at 15) with osm tiles at 18 for example.
  • over max zoom for elevation tiles allowing to generate elevation tiles from elevation tiles data at lower levels ( with some skirt issues for now). this also allows to go to higher levels. but with a lot lower cost in loading textures , images, merging them... the only issue is skirts which are not perfect.

you can see that by enabling map mode in my example. it uses it all.

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