Instead of hosting research materials on our own servers (as I did in the old days for both ongoing projects and published outcomes), it is more flexible to share on GitHub/Bitbucket public/private repos that need revision control, and store the compiled files in other services, such as papers on research gate or semantic scholar, videos via YouTube/Vimeo, etc.

With this setup, the co-authors can edit the research page together, and have less to worry about server management.

We should share only information ready for the public domain, e.g., paper title only after the submission is formally approved for acceptance, and code/algorithm after filing the relevant patent(s).

I cannot believe I have not (really) noticed this earlier, but the current git/svn revision controls are based on simple line differences, without taking into account the actual editing operations which we actually did in SIGGRAPH 2011 for image editing.

As a very simple example, say a file contains an original line like this:

I love you. Do you love me?

User 1 breaks the line into two:

I love you.
Do you love me?

User 2 adds one word the line:

I love you. Do you love me too?

A revision control tool that considers editing operations can automatically merge the two edits:

I love you.
Do you love me too?

While the current svn/git tools, based on line differences, will simply give up and ask users for manual intervention.

Among the 3 options for your glorious SIGGRAPH (or other ACM) paper, I usually choose the new licensing agreement (option 2) because it does not require shelling out a few grands for retaining all rights (option 3) and allows the authors to retain the theoretical copyright unlike the traditional copyright transfer (option 1).

By theoretical, I meant that options 1 and 2 probably make little to no practical differences for authors, since the license transfer is perpetual and exclusive for ACM, and authors can share their preprints anyway.

Co-authors and I submitted a paper with two main parts to X, a top venue in our field.
The reviews said the first part is good contribution but the second part is basically nothing, and rejected our paper.

We then revised the paper and submitted to Y, another top venue in our field.
The reviews said the exact opposite from X, but accepted our paper conditional upon the removal the first part.

So we split the paper, with the second part to Y and the first part to (the next round of) X.

😀

Hmm do people start to submit so early for the next SIGGRAPH?
😀

Server is unavailable

Please try back later…

The SIGGRAPH server is experiencing very heavy traffic right now, and cannot service your request. Please contact sis_support@siggraph.org if you need immediate assistance. Otherwise, please try your request again shortly. Thank you.

[Later] And this:
http://dl.acm.org/errorpgs/503.html

I wish people invite me to attend parties as much as they invite me to review papers.
=D

— Li-Yi Wei (@liyiwei) July 28, 2017

https://www.facebook.com/groups/leagueparty/

SIGGRAPH Taipei
9 to 11 pm, Sunday July 30 2017
L.A. Live Courtyard & Residence Inn, LA 2 & 3

NVIDIA
6:30 – 9:30 pm, Monday July 31 2017
(Invitation only)

Snap
6 to 8 pm, Monday July 31 2017

Disney (?)
Dreamworks (?)
light.co (?)
GVU (?)

Adobe
5:30 to 7:30 pm, Wed August 2 2017
4th floor (outside) Bonaventure Brewing Co. 404 S. Figueroa St

Canadian night
9 pm to midnight, Wed Aug 2 2017
Shoo Shoo, Baby, 717 West 7th Street, Los Angeles, CA 90017

Looking at the paper titles for HPG 2017, I wonder if it can be renamed to HPRT (similar to how CVPR can be renamed to CVML).

When we have real-time ray tracing on mobile devices (the day will come), all the legacy graphics algorithms (i.e. tricks) will become obsolete.
I believe real-time RT, instead of machine learning, will be the end of traditional rendering tricks.

Well I guess this is long overdue; knock yourself out here.
🙂

Open source facilitates collaboration and code reuse, and propels our progress forward. I shall participate more in the future.