This week was insane. The workload was heavy, but thankfully flexbox came to the rescue. When making the basic html and css I went with laying out the website using flex box. Which turned out to be a savior and very helpful, in making the website responsive. Since the flexbox, elements are already responsive, I did not have to do much with coding regarding the media queries. So yeah, media queires were used in order to set the size of the non flex box elements at a mobile size. (around 500px width)
Geoff and I were blessed with flexbox, as it made our lives easier
Thursday, 16 February 2017
NICK SPRINT 4
Nick
Hickey Sprint 4 Blog
This week was quieter than normal. I spent the week
researching and purchasing the necessities for the production of our display
device.
Our original design was a semi cubic display with harsh 90
degree angles. After giving our Alpha presentation and taking James Acres
advice, we decided to switch up our design (As seen in Tristan’s Blog). We have
opened up the display to have a wider angle exceeding 90 degrees. This will
allow me to projection map the object easier and make it easier for the users
to see the display. I also decided that doing this will help the production and
development of the actual applications now the device is a little bit easier to
projection map properly.
I have purchased projection material online, and the plywood
to construct the object. Next using the diagram provided by Tristan I will
produce the object accurately and firmly. I want to eliminate the possibility of
the display having any issues, so we do not go to show a potential customer and
the display is tacky and falling apart. I have purchased wood glue and filler
as well, this is so I can fill all the screw holes, and sand it so the
projection material will be seamless, without bumps and creases. Overall, as
mentioned this week was slower than normal, however I now have everything in
place to complete my production with all the required material being purchased
and all essential research has been conducted. The goal is to create something
that is visually stunning, sturdy, and moveable.
The angles are wider and easier to see compared to our original 90 degree idea.
Similar honeycomb effect will be used to create ours.
Similar to our original idea you can see how much harder this is to see compared to the first two images. I want this to be visually simple to see and using a similar design to the top two will allow for this.
SEE YOU NEXT SPRINT!
NICK
Landing Page Responsivity
This was a quiet week that MIA scheduled to include less tasks than usual. We set this up deliberately to deal with an increased external workload that the team was subject to.
I worked with Laith this week making our web pages responsive. This will allow users to access and use the Kubus design application from mobile devices as well as laptops.
I worked with Laith this week making our web pages responsive. This will allow users to access and use the Kubus design application from mobile devices as well as laptops.
Friday, 10 February 2017
Feb 10th
For this sprint, my responsibilities were fairly light. All I had to do was create the call function for the submit button in order to incorporate the NODE.JS and three.js application. I also worked on improving some of the mark up. I could have done the responsiveness, but that was due for the next sprint and there were other classes
Thursday, 9 February 2017
User Generated Content Serialization
My focus this week was on formatting JavaScript objects properly and properly converting them to JSON strings to eventually be sent from client to server.
First, I had to deal with the fact that in addition to using existing three.js objects (such as Mesh), we will need to have custom data associated with each user generated design element. For example, a 3D cube shape will (in the backend) need to be comprised of a three.js Mesh object and rotation data. In the following code block, we can see how I've set up this example object to be created on user request.

Another example would be a particle system. Each particle could be a three.js Mesh object. In addition to a member Mesh variable, each particle would also need position and velocity data. The particle system itself will need its own custom attributes - and everything must be compatible with the three.js object types.
It's easy to convert JavaScript objects to JSON text, but a specific function is necessary to first prepare three.js objects for JSON conversion.


In MIA_3/Project Drop/JSON_encoding_and_parsing, index.html will run a version of the Kubus engine with functional JSON conversion and parsing.
Instructions:
'a' - add a cube object to be converted
's' - serialize all data
'p' - parse all data
'm' - toggle object motion
To test the functionality:
Looking at the JavaScript console, we can see the JSON conversion processes happening:

Due to the way that current scene data is handled with the draw_list array and the three.js scene variable, after you've added, serialized, parsed and motion toggled a(some) objects, any additional objects added to the scene will not move correctly. Of course, JSON conversion and parsing isn't meant to be used within a single instance of the web application, so this scene drawing bug is not related to the topic at hand.
To test by adding multiple cube objects, reload a new instance of the program and hit 'a' multiple times before serializing the data.

The next step concerning the development of this web application is sending JSON strings through Node.js from client to server.
First, I had to deal with the fact that in addition to using existing three.js objects (such as Mesh), we will need to have custom data associated with each user generated design element. For example, a 3D cube shape will (in the backend) need to be comprised of a three.js Mesh object and rotation data. In the following code block, we can see how I've set up this example object to be created on user request.
JavaScript object creation
Another example would be a particle system. Each particle could be a three.js Mesh object. In addition to a member Mesh variable, each particle would also need position and velocity data. The particle system itself will need its own custom attributes - and everything must be compatible with the three.js object types.
It's easy to convert JavaScript objects to JSON text, but a specific function is necessary to first prepare three.js objects for JSON conversion.
This function serializes the complex object defined above.
As can be seen in this function, the Mesh.toJSON() function must be used to prepare a three.js object (such as a Mesh) for JSON string conversion. The following code does the reverse process - it parses incoming JSON text and converts it into an object usable by the Kubus rendering engine.
This function converts JSON text back into a usable JavaScript object
In MIA_3/Project Drop/JSON_encoding_and_parsing, index.html will run a version of the Kubus engine with functional JSON conversion and parsing.
Instructions:
'a' - add a cube object to be converted
's' - serialize all data
'p' - parse all data
'm' - toggle object motion
To test the functionality:
- hit 'a'
- hit 's'
- hit 'p'
- hit 'm' (optional)
Looking at the JavaScript console, we can see the JSON conversion processes happening:

The JavaScript console prints out the results of the JSON conversions
Due to the way that current scene data is handled with the draw_list array and the three.js scene variable, after you've added, serialized, parsed and motion toggled a(some) objects, any additional objects added to the scene will not move correctly. Of course, JSON conversion and parsing isn't meant to be used within a single instance of the web application, so this scene drawing bug is not related to the topic at hand.
To test by adding multiple cube objects, reload a new instance of the program and hit 'a' multiple times before serializing the data.
5 cube meshes being converted to JSON, and parsed back into JavaScript objects
The next step concerning the development of this web application is sending JSON strings through Node.js from client to server.
Nick Hickey Sprint 3
Nick Hickey – Blog Post 3
Sprint 3 was a lot of exploring new methods and trying to implement them into our various developed applications. I spent the majority of my time exploring express' POST and GET methods to be used to interact with Geoffrey's application.
The goal of this is to create an experience that is instant for the user. When they post or submit their design it will instantly be accessed and displayed on the interactive display. Based on the users inputted physics, and design characteristics their design will be turned into a JSON file to be displayed.
The next step I have concluded is to set up a database using Digital Ocean. Right now we still do not have a compute instance. Digital Ocean will allow me to store the data and access it to be displayed on the projection mapped surface. Using the current code I programmed we will be able to post the designs to Digital Ocean then access them again from another source.
I have the goal of getting a fair amount of the physical production done for the next sprint but for the following sprint my goal is to set up the database and also use openFrameworks to projection map.
Thursday, 2 February 2017
Graphics Engine Development
three.js Graphics Engine
This week, I spent the majority of my time developing a basic graphics engine using three.js.
Kubus graphics engine running standalone
I set up a three.js application in a modularized way that can be easily inserted into a larger HTML structure. Currently, the entire application runs from one JavaScript file which is executed from within the canvas wrapper HTML element.
Kubus graphics engine running inside the first iteration of our web application page
I've placed my basic engine in the first iteration of our web application front end page. Next steps include creating interactions between the UI elements and the canvas itself.
three.js setup
This code sets up the three.js framework (the scene, camera and renderer objects) and performs several other setup tasks. I had to write a function to take care of canvas sizing in case the browser window was resized (responsivity). This function (updateCanvasSize()) as well as others are defined below.Containers for design elements
These variables will contain a library of defined resources that users will use to construct their designs. This format makes it easy to add new resources as well as determine which array elements each belong to (for use with user triggered events later in development).
Helper functions
These helper functions (like updateCanvasSize() as mentioned earlier) support the application's functionality and are largely used within the render() function.Render function
render() is three.js' update/draw loop and is called at the very end of the script. Any code in this function will be updated every frame of the application (by default, 60 fps). So far, I simply have example functionality written into the engine to prove that it works.Instructions:
- press a to add a new slender cube to the scene
- press m to toggle object movement
Graphics Engine Design
The engine is designed to deal with graphical elements in the following way:- on receiving user input, append a new code object into the draw_list (persistent list of scene data)
- call updateDrawList() which constructs the three.js Scene object
- update the data of any existing items in the draw_list
- render the scene with the camera
In retrospect, a better name for updateDrawList() is reconstructScene(), since it's actually preparing the scene data that three.js will render (as opposed to performing any action on the draw_list variable).
Something that I don't completely understand is how (if the renderable scene object is only reconstructed every time a new object is added) does changes to draw_list elements (rotation in this my example) actually effect the objects that were previously added to the scene. I figure this is because data is by default passed and assigned as references in JavaScript, but I need to research this a bit more to understand fully how this is actually working.
MarkUp for the landing and canvas page
While making this, my goal was to create all the mark ups in an easy way to understand and modify as this project will be built on over the days and might undergo changes.
The main goal was to implement flex box as it provides some sort of responsiveness.
for the landing/loading page, it was a simple mark up and styling that I did. I tried to use 3.js in order to create a funky background for the landing page, but it was going to take more time, and it was not needed so i just went with a static background.
The main/canvas page was a bit tricky. Using flex box was really foreign to me. Even thought its fairly straight forward, Id get weird situations where boxes would disappere, so i ended up using half half. I used the flexbox, to set up the layout, which I used the "holy grail layout"
Nick Hickey – Blog Post 2
Sprint two is coming to an end. Team
MIA worked hard once again to ensure progress is being made in the development
of their KUBUS interactive experience. Nick spent time researching the
requirements for the web server. The found data was
Researched Requirements:
- Load our application (node server.js) onto a computer or laptop that has an IP address, then make sure the application is listening to the correct port (most servers is on 80). Use express to do this.
- Load our application (node server.js) onto a computer or laptop that has an IP address, then make sure the application is listening to the correct port (most servers is on 80). Use express to do this.
-Using GoDaddy we will get the
DNS (domain name server) settings and change the IP address, goal is to have
our domain name point to our IP address and render our node.js application.
Nick also researched the capabilities of Express, and the
programming applications of it. If the application is listening to the correct
port using Express. It can be as simple as implementing the following code
As a team we want the experience to be quick and immersive, if the time taken for a users design to display to the screen is long then the user will lose interest and we wont achieve our goal. Now if the experience is quick and once the user hits submit their design is displayed very quickly, then the user will feel instantly immersed in the experience.
Next, Nick worked with another team member
(Tristan) to work on a Node.js based system to let users draw designs and
download them. The two members got a basic application that allowed a user to
draw on an internet localhost and the data be saved to user’s downloads. The
next step is to save the data to a database so it can be accessed by the main
installation.
Server.js Code
Script.js Code
CODE DEMONSTRATION
Together we want to achieve a visually stunning application, however the experience is very responsive and efficient. As mentioned earlier if the experience of submitting a design to viewing it is slow, we will lose valuable time for the user to interact with the display, their design, and other designs. Overall, we are looking forward to using the mentioned methods to achieve our goals and limit the overall transfer time.
Subscribe to:
Posts (Atom)