Skip to content
This repository has been archived by the owner on Nov 22, 2022. It is now read-only.

Submitting Changes

Francisco Avila edited this page Sep 8, 2020 · 2 revisions

Here are some guidelines on how to contribute to the library.

Example Scene

We use a comprehensive example scene that tests most features of the renderer. This scene can come in handy to preview changes or additions you've made to the code.

Setup

Comparing changes

When changing the code base or implementing new features, you should compare your changes with master branch using the test scene in order to catch regressions in your code. You may do this with the following the steps.

  • Run npm run dev on your working branch, and load the example scene in a browser tab.
  • Commit (or git stash) the latest changes to your branch.
  • Checkout master branch with git checkout master
  • Start the local server with npm run dev again.
  • Open a new browser tab and connect to http://localhost:8080/scenes/renderer-test/
  • Compare renders of the two tabs back-to-back for visual similarity. Due to the randomized progressive rendering of the renderer, the noise will differ between tabs. For this reason, let each tab render for several seconds until the noise between both renders converges to an appropriate level. Both tabs should appear the same, aside from small variations in noise.
  • Compare the frame rate of both renders. The example scene has a frame rate display at the top left. The frame rate of your working branch should be the same (if not better!) as master branch.

Any part of the render, aside from what you're changing, should render the same across branches.

Pull Request Guidelines

  • Create a separate branch for each new change or addition.
  • Follow the the steps above. Confirm your branch appears visually similar to master.
  • Your branch should also have an equal, or better frame rate, to master. If it doesn't, the decrease in performance should be noted.
  • Run unit tests with npm run test
  • If possible, include new unit tests with any additions you introduce.
  • Don't include build files.