Skip to content

Commit

Permalink
Merge branch 'dev' of https://github.com/Orillusion/orillusion into dev
Browse files Browse the repository at this point in the history
  • Loading branch information
ZenderJK committed May 10, 2023
2 parents c6cb5ed + b24d84f commit 5d4991f
Show file tree
Hide file tree
Showing 43 changed files with 1,147 additions and 190 deletions.
128 changes: 128 additions & 0 deletions .github/CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
# Contributor Covenant Code of Conduct

## Our Pledge

We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, religion, or sexual identity
and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.

## Our Standards

Examples of behavior that contributes to a positive environment for our
community include:

* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the
overall community

Examples of unacceptable behavior include:

* The use of sexualized language or imagery, and sexual attention or
advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email
address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting

## Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.

Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.

## Scope

This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
info@orillusion.com.
All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the
reporter of any incident.

## Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:

### 1. Correction

**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.

**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.

### 2. Warning

**Community Impact**: A violation through a single incident or series
of actions.

**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or
permanent ban.

### 3. Temporary Ban

**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.

**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.

### 4. Permanent Ban

**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.

**Consequence**: A permanent ban from any sort of public interaction within
the community.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.0, available at
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.

Community Impact Guidelines were inspired by [Mozilla's code of conduct
enforcement ladder](https://github.com/mozilla/diversity).

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.
91 changes: 91 additions & 0 deletions .github/commit-convention.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
## Git Commit Message Convention

> This is adapted from [Angular's commit convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular).
#### TL;DR:

Messages must be matched by the following regex:

```js
/^(revert: )?(feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip)(\(.+\))?: .{1,50}/
```

#### Examples

Appears under "Features" header, `component` subheader:

```
feat(component): add new component xxx
```

Appears under "Bug Fixes" header, `component` subheader, with a link to issue #28:

```
fix(component): remove update lifecircle hook
close #28
```

Appears under "Performance Improvements" header, and under "Breaking Changes" with the breaking change explanation:

```
perf: improve store getters performance by removing 'foo' option
BREAKING CHANGE: The 'foo' option has been removed.
```

The following commit and commit `667ecc1` do not appear in the changelog if they are under the same release. If not, the revert commit appears under the "Reverts" header.

```
revert: feat(theme): add home page feature
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
```

### Full Message Format

A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**:

```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```

The **header** is mandatory and the **scope** of the header is optional.

### Revert

If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body, it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.

### Type

If the prefix is `feat`, `fix` or `perf`, it will appear in the changelog. However, if there is any [BREAKING CHANGE](#footer), the commit will always appear in the changelog.

Other prefixes are up to your discretion. Suggested prefixes are `docs`, `chore`, `style`, `refactor`, and `test` for non-changelog related tasks.

### Scope

The scope could be anything specifying the place of the commit change. For example `theme`, `compiler`, `ssr`, etc...

### Subject

The subject contains a succinct description of the change:

- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize the first letter
- no dot (.) at the end

### Body

Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
The body should include the motivation for the change and contrast this with previous behavior.

### Footer

The footer should contain any information about **Breaking Changes** and is also the place to
reference GitHub issues that this commit **Closes**.

**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
147 changes: 147 additions & 0 deletions .github/contributing.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,147 @@
# Orillusion Contributing Guide

Hi! I'm really excited that you are interested in contributing to Orillusion. Before submitting your contribution, please make sure to take a moment and read through the following guidelines:

- [Code of Conduct](./CODE_OF_CONDUCT.md)
- [Issue Reporting Guidelines](#issue-reporting-guidelines)
- [Pull Request Guidelines](#pull-request-guidelines)
- [Development Setup](#development-setup)
- [NPM Scripts](#scripts)
- [Project Structure](#project-structure)

## Issue Reporting Guidelines

- Welcome to use [Github](https://github.com/Orillusion/orillusion/issues) to report a issues, request a feature, or ask a question

## Pull Request Guidelines

- Don't directly send PR to `main` branch, unless it's a urgent bug fix/patch.

- Checkout a feature branch from a dev based branch, e.g. `dev`, and merge back against that branch.

- [Make sure to tick the "Allow edits from maintainers" box](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork). This allows us to directly make minor edits / refactors and saves a lot of time.

- If adding a new feature:

- Add accompanying unit test or sample case.
- Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it approved before working on it.

- If fixing a bug:

- If you are resolving a special issue, add `(fix #xxxx[,#xxxx])` (#xxxx is the issue id) in your PR title for a better release log, e.g. `update entities encoding/decoding (fix #3899)`.
- Provide a detailed description of the bug in the PR. Live sample/demo preferred.

- It's OK to have multiple small commits as you work on the PR - GitHub can automatically squash them before merging.

- Make sure CI tests pass!

- Commit messages must follow the [commit message convention](./commit-convention.md) so that changelogs can be automatically generated.

## Development Setup

[Node.js](https://nodejs.org) **version 16+**, and [PNPM](https://pnpm.io) **version 7+** is perferred.

First, you need to clone/flok repo:

```bash
$ git clone git@github.com:Orillusion/orillusion.git
$ cd orillusion
$ git checkout dev # `dev` branch is perfered to start your development
```

If you need to run samples, you may need to init the `assets` submodule to load models, images and other resources:

```bash
$ git submodule update --init # init /public assets folder, it may take a long time due to large file size
```

After cloning the repo, run:

```bash
$ pnpm i # install dev and optional deps of the project
$ pnpn i --no-optional # skip optional deps, install dev deps only if you don't need run ci tests
```

A high level overview of main tools used:

- [TypeScript](https://www.typescriptlang.org/) as the development language
- [Vite](https://vitejs.dev/) and [ESBuild](https://esbuild.github.io/) for development bundling
- [Rollup](https://rollupjs.org) for production bundling
- [Electron](https://www.electronjs.org/) for CI unit testing
- [TypeDoc](https://typedoc.org/) for API docs generating

## Scripts

### Start a Dev server
After install all dependenceies of the project, just run `pnpm run dev` to boot up a dev environment locally, with live relaod of the soure code.

```bash
$ pnpm run dev
```
After executing the above command, visit http://localhost:3000 and try live samples from `/samples`

### Build production libs
To build a production package:
```bash
$ pnpm run build
```
After executing the above command, the production libs (`orillusion.es.js` and `orillusion.umd.js`) will be generated in `dist` folder, along with all types `*.d.ts` in `dist/src` subfolder.

### Unit Test
To start an auto unit tests:
```bash
$ pnpm run test
```
This will start an electron window to run all tests in `test` folder.

If you need to test in a docker/linux enviroment without GPU drivers:
```bash
$ pnpm run test:ci
```
This will force Electron to use a CPU based software Vulkan driver to process all tests with WebGPU APIs

### API docs
To generate API docs:
```bash
$ pnpm run docs # generate all docs, including core and packages
$ pnpm run docs:core # core docs only
```
All `md` docs will be generated in `docs` folder.

## Project Structure

A overview of project structure:

```bash
├─ 📂 node_modules/ # Dependencies
│ ├─ 📁 @webgpu # WebGPU types for TS
│ └─ 📁 ... # Other dependencies (TypeScript, Vite, etc.)
├─ 📂 src/ # @orillusion/core source
│ ├─ 📄 index.ts # The entry root, export all modules from /src
│ └─ 📁 ... # The core source files in sub category
├─ 📂 packages/ # @orillusion/xxx extensions
│ ├─ 📁 ammo # Archive for Ammo.js
│ ├─ 📁 debug # Internal debug lib based on dat.gui
│ ├─ 📁 draco # Archive for draco_decoder.js
│ ├─ 📁 media-extention # Media components for Orillusion
│ ├─ 📁 physics # physics component for Orillusion, powerd by Ammo.js
│ └─ 📁 stats # A simple performance stats component
│ └─ 📁 ... # Others
├─ 📂 samples/ # Live samples
│ ├─ 📄 index.ts # A entry mune to hold all samples in /samples
│ └─ 📁 ... # Samples to test each sub category
├─ 📂 test/ # Unit tests
│ ├─ 📄 index.ts # Entry mune to hold all tests in /test
│ ├─ 📄 util.ts # test libs
│ ├─ 📁 ci # main entry for electron
│ └─ 📁 ... # Unit tests in each sub category
├─ 📄 .gitignore # Ignore certain files in git repo
├─ 📄 index.html # Dev index page
├─ 📄 LICENSE # MIT
├─ 📄 package.json # Node package file
├─ 📄 tsconfig.json # TS configuration file
├─ 📄 vite.config.js # vite configuration file
└─ 📄 README.md # Read Me!
```

Welcome to submit PRs to extend `@orillusion` packages
3 changes: 3 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -108,6 +108,9 @@ Please read the [Docs](https://www.orillusion.com/guide/) to Learn More.
- [Documentation](https://www.orillusion.com/guide/)
- [Forum](https://forum.orillusion.com/)

## Dev and Contribution
Please make sure to read the [Contributing Guide](.github/contributing.md) before developing or making a pull request.

## License

Orillusion engine is released under the [MIT](https://opensource.org/licenses/MIT) license.
Loading

0 comments on commit 5d4991f

Please sign in to comment.