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

Some API and project thoughts! #1

Open
gkjohnson opened this issue Sep 20, 2022 · 1 comment
Open

Some API and project thoughts! #1

gkjohnson opened this issue Sep 20, 2022 · 1 comment

Comments

@gkjohnson
Copy link
Contributor

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
Copy link
Owner

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)

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

2 participants