search

lucas-jones / three-lightmap-baker

132 stars 9 forks source link

Some API and project thoughts! #1

Open gkjohnson opened 2 years ago

gkjohnson commented 2 years ago

Hello! Love the work. You asked for a few thoughts on twitter so I thought I'd share here if you're interested. I know you're just getting started on this so I may be getting ahead things but here are some thoughts to consider as the project grows!

Class / Process Separation

Right now I see that when rendering an AO map, a new BVH is generated, a lightmap is generated, and then the denoiser is applied. I've always preferred to break these steps up and let the user apply them in the order / way they want. The BVH, for example, can be constructed for multiple reasons including physics, raycasting for a game, etc and is a fairly expensive process. So if you let the user construct the BVH as they please and provide it to your API then they will be able to use it for multiple purposes. This is how the pathtracer API is structured - it's may not "just work" with one function call but it's designed in a way that lets people use it flexibly and performantly for their app needs.

API

For the API for generating the lightmap and applying the denoiser - I imagine affording the user the ability to call "update" as needed to slowly resolve the lightmap over time at the rate the user calls update. And the complexity of raycasts per update call can be be toggled and then the number of "samples" is determined by the number of times that the user calls an "update" function. This way would also enable a workflow of letting the user watch the lightmap resolve until they determine it's "good enough" instead of having to pick the samples ahead of time.

The example

I think it would be fun to see the lightmap improve and fill in over time as more samples are taken. And then the map can reset on parameter change with no need for the user to press a "regenerate" button. It can just improve over time along with a progress bar until the target number of samples are taken and gives a level of feedback that even most desktop tools don't show. Something like this raytraced ao demo. To me, at least, that kind of responsiveness always feels good in a demo and shows the performance.

Really looking forward to seeing this evolve!

lucas-jones commented 2 years ago

Great idea, moving forward I will start transitioning this project to an API that includes a lightmap generation tool (as an example & for dev/debugging)