(Call for Papers PDF, TXT)

Your paper should be prepared according to this year's template. There is no strict page limit, but make your paper longer than 10 pages only if this is strongly justified. In order to be considered for reviewing, at least an abstract must be submitted by April 4, and the full paper by April 8 (23:59 UTC/GMT). All submissions should be uploaded to the SRMv2 website

https://srmv2.eg.org/COMFy/Conference/SGP_2016

Software Award

To encourage the distribution of high quality software in geometry processing, since 2011 an annual award has been given for freely available software related to or useful for geometry processing. Please send nominations and applications for the software award to chairs-sgp2016 (at) eg.org.

SGP Dataset Award

The main goal of this award is to highlight the importance of high-quality datasets and benchmarks to the advancement of the Geometry Processing community and to recognize the suppliers of such datasets. Similar to the software award, the data award will provide recognition of the effort and time put into preparing an important tool and stimulus for research.

We encourage submissions that initiate novel research directions by asking difficult questions, either in a form of a benchmark, or possibly by highlighting challenges previously ignored by the community. This way, researchers in Geometry Processing will hopefully become aware of both problems that are not addressed by existing algorithms and new applications in other domains. At the same time, we hope to acknowledge the impact of existing and established datasets that have helped to advance the field of Geometry Processing.

Eligibility. The dataset must be freely available (i.e., must come at no cost), and must be covered by a license allowing free academic use to be eligible for the award. We will also allow datasets that might have been obtained by collecting from different sources, rather than created from scratch (such as the Princeton Shape Benchmark), especially in the case where such datasets come with a novel challenge or problem for Geometry Processing. However, we will give preference to original datasets that have been created directly by their providers. Of course, the nominees should be relevant to the Geometry Processing community, and therefore the datasets must have some “geometric” flavor. However, another goal behind this award is to expand our understanding of what geometric datasets might entail, and therefore, we will also consider datasets that have not traditionally been used in the SGP community (for example, volumetric data, point cloud samplings of unusual objects, etc.)

Procedure. All members of the Geometry Processing community can nominate their favorite dataset (including possibly their own) for the data award by writing an email to the SGP conference chairs with a few words describing the dataset and why it is worthy of the award. The nominations will be accepted until one week following the deadline for the SGP conference. The chairs will collect the nominations and will decide on the winner following the guidelines described above.

Award format. The winners of the data award will be announced at the same time as the winners of the software award at the end of the SGP conference. The winners will be given an opportunity to describe the dataset briefly by giving a 10 minute talk following the award ceremony. During this talk, the winners will be encouraged to describe the process of preparing the dataset, and also the particular challenges and problems that are associated with this dataset. The winners will also be listed on the SGP conference website.

SGP Reproducibility Stamp

All papers accepted at SGP 2016 will be subject to a rigorous review process where at least 5 experts in the field will evaluate the technical correctness and reproducibility of the scientific results in the paper. The *reproducibility stamp* is an additional recognition that goes to the authors who are willing to go one step further, and in addition to publishing the paper, provide a complete open-source implementation of their algorithm. Note that the reproducibility stamp is not meant to be a measure of scientific quality of the paper or of the usefulness of presented algorithms. Rather, it is meant to be an endorsement of the reproducibility of the results presented in the paper and the recognition of the service provided to the community by releasing the code. Thus, the reproducibility stamp does not affect the reviewing process or the requirements for your submission to be accepted. Submissions for the stamp will be considered only *after* the paper has been accepted at SGP and any accepted SGP submission can apply for the reproducibility stamp, including course notes for the graduate school and posters.

All submissions that successfully pass the stamp reviewing process will receive additional exposure by being listed on a special webpage on the EG website together with a link to their source code. It will also be possible to use the special "stamp" both in the pdf, in the conference program and in the slides to highlight the commitment to push the state of the art by helping the community easily build on top of their research work. The papers with a reproducibility stamp will also have an extra 5 to 10 minutes in their presentation to give a live demo, in addition to getting an additional recognition in the closing ceremony.

The purpose of this award is to promote reproducibility of research results and to allow scientists and practitioners to immediately benefit from state-of-the-art research results, without spending months reimplementing the proposed algorithms and trying to find the right parameter values. We also hope that it will indirectly foster scientific progress, since it will allow researchers to reliably compare with and to build upon existing techniques, knowing that they are using exactly the same implementation.

The application process is very lightweight: a link to a github repository with the source code and instructions on how to compile it and reproduce the results has to be sent to the Reproducibility Stamp chair (panozzo (at) nyu.edu). The code should compile on a vanilla installation of any one of the major operating systems (Linux, MacOSX, Windows), have a license that allows free academic usage, and only depend on libraries that allow free academic usage. The code quality will not be evaluated, the purpose of the stamp is only to simplify reproducibility of the results: In its simplest form, the code should reproduce the data used to generate every result figure shown in the paper, using a fresh installation of one of the OS above.

Detailed guidelines

To ensure a fair and efficient review of the code submissions, the following guidelines must be followed when you prepare your submission. If there are technical reasons which do not allow your software to run under these conditions, please write an email to the chair (panozzo (at) nyu.edu) as soon as possible to describe the issue.

1. Distribution

The software must compile and run on *at least one* of the following operating systems, using exactly one of the versions listed below:

Note that you can pick whichever operating system you developed your code on. Your code does not need to compile on all of them to obtain the stamp.

The code should compile and run on a vanilla installation, without any software installed. If you need specific software to be installed, you should provide a script that automatically downloads and installs all the required dependencies. In the case of Windows, a text file with precise installation instructions will also be accepted.

The software should be written in any programming language, as long as the compiler/interpreter is free to use for academic purposes. One exception is Matlab, which will be accepted (version 2015b or newer) since it is very popular in our community: you can use any standard or custom toolbox and you can have mex functions, as long as they satisfy the license requirements described below.

Detailed instructions to install the compilers/interpreter and the dependencies should be in the readme.

2. Reproducing results

An independent script should be provided for every figure or table of the paper which contains a result generated with the algorithm. The script should be runnable without parameters and generate the data that is shown in the figure or listed in the table. If the produced data is not in a standard format, please describe the format in a text file attached to the submission. The script does not need to produce an image, it is sufficient to generate the data that has been used to create the image in the paper.

The review process will only ensure that the code runs and it is able to reproduce the material for the figures. The quality, robustness and running time of the code will not be evaluated and they will have no impact on the review process.

3. License

The code itself and all its dependencies should have a license that allows free academic use. Note that this does not preclude charging your users for a fee for commercial usage, see the CGAL project for a successful example of this code distribution model.

For example, you can use mosek or gurobi, since they are free for academic purposes, while knitro cannot be used since their academic license is not free. The only exception to this rule is the usage of Matlab, due to its popularity in our community. In case your project cannot satisfy this rule, please contact the chair to discuss the special case.

4. Interactive application

If your application is interactive and it is not possible to script it to reproduce the results in the paper, you must provide one short movie clip capturing the screen while you use your software to reproduce the figure. The reviewers will then follow step by step the video to reproduce the same results. If you want to use this option, you will have to provide a short description of the reason why it is not possible to script the generation of the results.

5. Hardware requirements

We encourage the authors to provide code that runs without requiring a specific GPU (or other hardware), to favor portability and simplify the reproduction of the results. However, for projects where this is not possible, we will accept submissions that run on specific hardware as long as this is justified in the submission. In this case, the review of the code will be done in a skype/hangout conference call if the reviewer does not have a compatible hardware setup.

6. Exceptions

The previous rules are general guidelines: If your software cannot satisfy one of the previous requirements, please write as soon as possible to the chair to explain the reasons. In many cases, it will be possible to lift any of the previous requirements if there is a good reason for doing it. In particular, there might be cases where the data used in a paper cannot be publicly released: in these cases, the stamp can still be awarded, but the data must be separately sent to the reviewers for the evaluation process.

7. Timeline and format of the submission

The submission for the stamp is submitted only after the paper is accepted and it is not blind. A single reviewer will be assigned to each submission and the reviewer will work together with the authors to ensure that the submission is improved until it satisfies all the guidelines.

The deadline for the submission is: June 6th 2016 23:59 CET

The submission for the reproducibility stamp will not use srm: The authors will have to create a github repository, commit all the material there and then send an email with a link to the github repository to panozzo (at) nyu.edu. A confirmation email will be sent within 24 hours, if you do not receive it please contact the chair.

The repository should contain:

a. A txt file containing the title of the paper, the authors, and the operating system required
b. A script that automatically downloads all required dependencies and compiles the code. If this is not possible (for example if matlab needs to be installed), then a text file with precise instructions should be provided. The instructions need to be precise and describe all the software dependencies that need to be installed, together with detailed compilation instructions. Please always specify entire paths: for example, do not write "change the cmake variable sx to point to the directory where solver x is installed" but instead tell the user to install the solver x in "c:/solverx" and always use absolute paths assuming a vanilla installation of the operating system.
c. The source code
d. A script for every result figure created with the proposed algorithm (in case of a comparison figure, the script should reproduce only the part created with the proposed algorithm), that launches the provided implementation and generates the data used to create the figure. The script does not necessarily need to create a figure: if the figure shows a triangle mesh, it is sufficient to export the triangle mesh to a text file.

Reproducibility Stamp Chair: Daniele Panozzo (panozzo (at) nyu.edu)