Online Geometry Viewer Project Proposal[edit]

Personal Information[edit]

Name: Gauravjeet Singh

Email Address: gaurav.ishwerdas@gmail.com

IRC Username: gjeet

Brief Background Info[edit]

I study in 3rd year B.Tech (Computer Science and Engineering) at Guru Nanak Dev Engineering College, Ludhiana (India). I was welcomed in this community in late 2012 via Google Code In (GCI). I was a GCI 2012 student and then acted as a GCI mentor of BRL-CAD for next two consecutive years (2013 & 2014).

I have been interested in 3D graphics from a long time. In early 2013, after finishing up with GCI as a student, I started looking for opportunities to work with BRL-CAD. And I ended up taking a very small part of BRL-CAD functionality on the web, using a simple shell script and CGI. Here's the Github repo of that app: https://github.com/GreatDevelopers/wBRLCAD/tree/master/general/tableModel

Later that same year(2013), I came to know about a GSoC project called Online Geometry Viewer. I have been an active listener about OGV discussions since then.

Also, I have been contributing to various Meteor projects in the past few months. These include

Lord Byron: A real-time text editor that checks for grammar using Natural Language Processing.
Blocks: Application for making presentations and static websites

My experience in meteor and interest in 3D graphics makes OGV a perfect project for me.

Project Information[edit]

Brief Summary[edit]

OGV has the ambition to become something of an Instagram for 3D models. It includes features like profiles, likes, comments, followers. But the code is a lot buggy and unstable.

What has been done As previously stated Online Geometry Viewer started as a GSoC project in 2013 by a student named Harmanpreet Singh to show BRL-CAD modeling capabilities on the web. It was initially a vanilla PHP + three-js project. This project was continued by Inderpreet Singh in 2014 and was converted to Meteor from vanilla PHP in order to get a robust backend. Next year in 2015 two Students Deepak Sharma and Shubham Chauhan continued the meteor project.

What I will do One of the major motives of my GSoC would be to improve the existing code. To complete the things that are almost complete. Also, the new features I am adding aren't completely new, they are an extension of some existing feature of OGV. By the end of GSoC, I want OGV to be production ready and available to use for a wider majority of people.

I am mostly concentrating on the efficiency and control over the model viewer. For now, we can only view the complete model. We have no control over what parts of a model to show/hide. This includes giving different color/material separately to different parts of a model instead of the complete model. There are much more such things that I would accomplish during my GSoC tenure. Things I will do in GSoC are listed as following:

Things that I'll improve:

Search (for models, users and even parts inside model)
Database schema (Adding schema to the collections)
Increasing speed and efficiency in handling Obj files (merging multiple Obj files and removing duplicates)
Overall User Experience and User Interface
Removing redundancy and unused code

Things that I'll add:

Show/hide parts of model (also color them separately)
Adding push notifications for like, comment, share
Easy Deployment procedure
Adding view restrictions on uploaded models
Enabling users to create Groups/lists of followers

Detailed Project Description[edit]

Code Cleanup[edit]

Github branches and PR's: There are a lot of branches and PR's pending, my task would be to merge all the code and get the desired stable code in the master branch.

Current Code: Changes in the code includes adapting to more appropriate variable names, removing redundant code.

For example, there exists redundant code in file OGV/client/views/model_viewer.js at line no 220. The package ishwerdas:ogv-threejs is not updated since it is created by Inderpreet Singh in 2014. There are many such instances in the code that needs to be fixed.

Robust and secure database by using Schema[edit]

We are using MongoDB in OGV. It is a schema-less database. But however, it is generally a good practice to define a schema that validates the content of the collection. If we don't use schema, there comes a high chance of adding wrong values in the database. That's the reason meteor officially supports and recommends using schema. http://guide.meteor.com/collections.html#schemas To add schema to meteor collections, we may use package

   aldeed:simple-schema

For instance, we have a collection in OGV called "Ogvsettings".

   settings.schema = new simpleSchema({ 
gobjPath: {type: string} });

If we apply the above schema to collection Ogvsettings, it will make sure we get a string value in the "gobjPath" field of the collection. Thus, making our application more robust and secure.

Efficiency in handling Obj files[edit]

OGV is a bit slow for now. It can't handle big models, one of the main reasons is the number of HTTP requests for each obj file. Thus, OGV can be boosted by doing following things:

Removing duplicates: When a .g file is converted into obj, each converted obj is copied to another location. Thus, there exists a duplicate file for each obj file. Thus occupying unnecessary storage to the server. Obj files are created at OGV/.meteor/local/cfs/files/modelFiles during conversion, which aren't required while viewing the model. Thus, they occupy extra space. I will write the code that removes these files after a certain amount of time automatically so that there is no wastage of server space.
Merging all OBJ files into one: On model rendering page, multiple requests are made(~300 for complex objects) thus slowing down OGV. Therefore merging obj files will reduce HTTP requests by a big number.