Add files for first release (#1)

.gitattributes

@@ -0,0 +1,10 @@
+*.png filter=lfs diff=lfs merge=lfs -text
+*.jpg filter=lfs diff=lfs merge=lfs -text
+*.max filter=lfs diff=lfs merge=lfs -text
+*.gltf filter=lfs diff=lfs merge=lfs -text
+*.glb filter=lfs diff=lfs merge=lfs -text
+*.obj filter=lfs diff=lfs merge=lfs -text
+*.fbx filter=lfs diff=lfs merge=lfs -text
+*.mtl filter=lfs diff=lfs merge=lfs -text
+*.zip filter=lfs diff=lfs merge=lfs -text
+*.bin filter=lfs diff=lfs merge=lfs -text

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/ISSUE_TEMPLATE/problem-with-a-3d-model-or-pdf.md

@@ -0,0 +1,39 @@
+---
+name: Problem with a 3d model or pdf
+about: Create a report to help us improve
+title: 3D model issue
+labels: 3d model fix
+assignees: ''
+
+---
+
+**Describe the problem**
+A clear and concise description of what the error is. Remember to always attach a screenshot where you show the issue by marking it in the image.
+
+**Describe the exact steps which reproduce the problem in as many details as possible.**
+A step by step explanation of the steps you took so we can recreate this in our side
+
+**Provide specific examples to demonstrate the steps.(if applicable)** 
+Include links to files or GitHub projects, or text snippets, which you use in those examples.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem. Always mark the issue inside the image by drawing an arrow or outline around the issue you are refering to.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Software or Browser [e.g. chrome, safari, blender, 3dsmax, unreal, unity]
+ - Version [e.g. 22]
+
+**What fileformat are you using**
+ - 3d format: [e.g glTF, glb, obj]
+ - assembly instruction [pdf]
+
+**if the issue is material related**
+always attach a screenshot and in what render engine you are running when you get the problem.
+
+**What units are you working in**
+- Metric: [mm, cm, meter]
+gltf are by definition always defined in Meters and we do not use imperial units anywhere inside the models for IKEA.
+
+**Additional context**
+Add any other context about the problem here.

CODE_OF_CONDUCT.md

@@ -0,0 +1,133 @@
+
+# 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, caste, color, 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
+opensource-coc@inter.ikea.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.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

COMMUNICATION.md

@@ -0,0 +1,24 @@
+# General
+
+Go to our [Readme](README.md) page to learn more about the project and the [Maintainers](MAINTAINERS.md) page learn who our repo maintainers currently are.
+
+## Rules for communication
+
+- Any form of communication in this repository should abide by the [Participation Guidelines (Code of Conduct)](CODE_OF_CONDUCT.md).
+- We use GitHub aliases and issues for communication.
+- We want all communication to be public.
+
+## Versioning
+
+We communicate with each release what has been changed in the repository compared to the previous release. Read the section about [version](https://github.com/IKEA/IKEA3DAssemblyDataset/#version) on our readme page for information on our versioning strategy.
+
+## Releases
+
+Version 1.0.0 was released 15th of Nov 2021. No planned update or future release known at that time.
+
+## Guiding principles
+
+- Communication open to the public is better than private only communication.
+- Issues will remain available.
+- You can expect a response from a maintainer within 14 days. If you haven’t heard anything by then, feel free to ping the thread.
+

CONTRIBUTING.md

@@ -0,0 +1,124 @@
+# Contributing
+
+## What should I know before I get started?
+
+Please read about the project on the [main page of this repository](https://github.com/IKEA/IKEA3DAssemblyDataset/).
+
+## How to contribute to this project
+
+We would love to know if you find errors to this project.
+If you do, create an issue.
+
+## Creating an issue
+
+Creating an issue for errors is an important way you can contribute to the IKEA3DAssemblyDataset.
+This section guides you through submitting an issue report regarding the IKEA3DAssemblyDataset. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports. When creating an issue, you will be asked to select and follow one of the repository issues templates, depending on the matter of the issue you want to report.
+
+Before creating an issue, please check that an issue reporting the same problem does not already exist. If there is such an open issue, you may add your information as a comment.
+
+When creating an issue, please include
+
+1. The name of the file that contains the error.
+2. Description of the error/fix.
+3. Screenshot where you have marked the area that needs to be fixed.
+This is especially important when you found an error on a 3D or 2D file.
+
+When you are creating an issue, please include as many details as possible.
+Issues are tracked as [GitHub issues](https://guides.github.com/features/issues/).
+
+## Pull requests
+
+We are not accepting pull requests for changed 3D models. The reason is that IKEA need to update the source 3D files at IKEA and generate a new version which is exported either to .glTF or .obj format to add to the repo. Pull requests to change or add 3D models to the repo will only be accepted for review if they are created by the [repository maintainers](https://github.com/IKEA/IKEA3DAssemblyDataset/blob/main/MAINTAINERS.md).
+
+## Participation Guidelines (Code of Conduct)
+
+IKEA have for this repository adopted the [Contributor Covenant](https://www.contributor-covenant.org/) and project participants are expected to adhere to it. Please read the [Participation Guidelines (Code of Conduct)](CODE_OF_CONDUCT.md) to understand what actions will and will not be tolerated. Read more about our [rules for communication](COMMUNICATION.md) here.
+
+## Creating new 3D models *[this is information is for IKEA maintainers]*
+
+### For the .glTF/.glB models
+
+1. Create new 3D models using 3ds Max 2021
+2. Make sure you always are using mm as a system unit inside 3ds Max
+3. Export the .glTF/.glB models using babylonJs exporter in 3ds Max
+4. Remember to add copyright information to the files
+
+### For the .obj models
+
+1. Create new 3D models using 3ds Max 2021
+2. Make sure you always are using mm as a system unit inside 3ds Max
+3. Export the .obj models using standard 3ds Max
+4. Doublecheck that you exported the model with the correct units
+5. Remember to add copyright information inside the header of the files
+
+<!--
+### DO NOT EDIT
+This section describes the process to be followed by IKEA maintainers when a new release or a fix needs to be applied to the dataset.
+## Making a pull request
+*   Always follow the seven rules of a [great Git commit message](#git-commit-messages)
+*   Follow the normal [pull request flow](https://help.github.com/articles/creating-a-pull-request/).
+*   Feel free to make as many commits as you want; we will squash them all into a single commit before merging your change.
+*   Check the diffs, write a useful description (including something like `Fixes #123` if it's fixing a bug) and send the PR out. Please start the title of your pull request with the name of the affected package, followed
+    by a colon, followed by a short summary of the change, like "blob/gcsblob:add more tests".
+* There is no need to assign a reviewer to the PR, the project team will assign someone for review during the standard triaging process. OR Choose a reviewer from the maintainers guide.
+
+#### Git Commit Messages
+A well-crafted Git commit message is the best way to communicate context about a change to fellow developers (and indeed to their future selves).
+Follow the seven rules of a great Git commit message:
+* Separate subject from body with a blank line. 
+* Limit the subject line to 50 characters.
+* Capitalize the subject line.
+* Do not end the subject line with a period.
+* Use the imperative mood in the subject line. eg."Add feature" not "Added feature"
+* Wrap the body at 72 characters.
+* Use the body to explain what and why vs. how.
+
+## Code review
+All submissions, including submissions by project members, require review. It is almost never the case that a pull request is accepted without some changes requested, so please do not be offended!
+
+When you have finished making requested changes to your pull request, please make a comment containing "PTAL" (Please Take Another Look) on your pull request. GitHub notifications can be noisy, and it is unfortunately easy for things to be lost in the shuffle.
+
+Once your PR is approved (hooray!), the reviewer will squash your commits into a single commit and then merge the commit onto the main branch. Thank you!
+
+## Github code review workflow conventions
+(For project members and frequent contributors.)
+
+As a contributor:
+
+-   Try hard to make each Pull Request as small and focused as possible. In
+    particular, this means that if a reviewer asks you to do something that is
+    beyond the scope of the Pull Request, the best practice is to file another
+    issue and reference it from the Pull Request rather than just adding more
+    commits to the existing PR.
+-   Adding someone as a Reviewer means "please feel free to look and comment". Choose as many Reviewers as you'd like referring the Maintainers.
+-   Adding someone as an Assignee means that the Pull Request should not be
+    submitted until they approve. If you choose multiple Assignees, wait until
+    all of them approve. It is fine to ask someone if they are OK with being
+    removed as an Assignee.
+-   Make as many commits as you want locally, but try not to push them to Github until you've addressed comments; this allows the email notification about the push to be a signal to reviewers that the PR is ready to be looked at again.
+-   When there may be confusion about what should happen next for a PR, be
+    explicit; add a "PTAL" comment if it is ready for review again, or a "Please hold off on reviewing for now" if you are still working on addressing comments.
+-   "Resolve" comments that you are sure you've addressed; let your reviewers
+    resolve ones that you're not sure about.
+-   Do not use `git push --force`; this can cause comments from your reviewers
+    that are associated with a specific commit to be lost. This implies that
+    once you've sent a Pull Request, you should use `git merge` instead of `git rebase` to incorporate commits from the master branch.
+
+As a reviewer:
+
+-   Be timely in your review process, especially if you are an Assignee.
+-   Try to use `Start a Review` instead of single comments, to reduce email
+    spam.
+-   "Resolve" your own comments if they have been addressed.
+-   If you want your review to be blocking, and are not currently an Assignee,
+    add yourself as an Assignee.
+
+When squashing-and-merging:
+
+-   Ensure that **all** of the Assignees have approved.
+-   Do a final review of the one-line PR summary, ensuring that it meets the
+    guidelines (e.g., "blob: add more blobbing") and accurately describes the
+    change.
+-   Delete the automatically added commit lines; these are generally not
+    interesting and make commit history harder to read.
+-->