Stage 4

This environment is completely new and is set in mid-air using floating platforms and islands. The following are the new features added in this stage:

• High amounts of animation and overlap events.
• Environmental biomes that was inspired by research into stress and how certain environments can bring relief to people. We used a forest > snow > beach biome (designed by Jason) for this stage.
• Using more particle systems that related to nature e.g. waterfall, fire, snow. This shows how UE4 can be utilized to create different immersive environments.
• New interactable objects and triggers.
• Dynamic material instances.

Once the user places the cube inside the box, the box starts blinking/glowing green and a waterfall starts.

This slider allows the user to slow down the wind and start a fire particle system.

Once the user goes through all the biomes, they enter a similar structure to that of Stage 3. Each arc starts turning white and the camera starts fading to white and the user is teleported back to stage 1.

Video of VR Experience

The VR Experience: Stage 4&5 was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the past few weeks the fabrication group has continued on exploring the use of latex and different ways it could be implemented into the design of the pavilion.

If we recount all the way back to the start May, the fabrication folks put together a jig that allowed us to repeatedly pull a material in a bi-axial vectors, pulling whatever sheet of material we wanted in vectors perpendicular to each other. With the help of workshop staff, the design of the device and how it works is similar to how an umbrella operates. So with the help of a threaded rod, we are able to push these four wooden arms up and outward to pull the material four different ways.

This process held us pull material in a uniform repeated problems but also faced its own problems. By twisting a nut to move these arms up, it was a really tedious and lengthy task. The twisting of the nut also lead to a breakage with the hinges we used for the arms since they were just hinges that were sourced from spares around the workshop and even cut to size. These hinges were replaced with new ones and new wooden arms. The fabrication group had some success with the new parts but still went through the slowed process of using the threaded rod and nut to move the arms to pull the fabric. This process was actually helpful when there was high tension in the material we were pulling since it would stretch in smaller, manageable increments. Ultimately, this slight improvement also ended up falling apart as well

The amount of energy built up in the latex ended up ripping the screw holding one of the hinges that was attached to the arm and the slider plate. A way this could have been avoided was by using longer screws since we used short pan head screws that allowed it to rip through the wood grain. We did put the arm back together after this but we noticed that the jig would not operate the same. The plate on one side of the jig did not move as freely as the other plates and required a tug for displacement to occur. We soon realised that one of the other new hinges have also broken. Regardless of breakages and the setback they have brought on the fabrication team, the show must go on.

The Jig ended up being operated in a more manual method but was still useful. We started cutting patterns out with the laser cutter using a number of different sheet materials (plywood, acrylic, polypropylene) that were more rigid than latex.

these panels were attached on to the latex. We tried different adhesives to apply the pattern but the group found that super glue provided the strongest bond between the latex and rigid, plastic sheet pattern.

when the tension is slowly released, the panels gets bent into shape from the relieved elongation of the latex. the difference in lengths of the two materials causes the non-stretchy material to warp.

We repeated this method over and over again as the design of the pavilion changed, one of the challenges we faced throughout the testing of different material, patterns and force applied, was getting really consistent, and identical results. Even though we repeated these tests, we still weren’t getting the perfect results we were after, there was still some form of unpredictability and inconsistency with the results. Some factors that may have caused this could be through human error. Since the jig slowly fell apart, piece by piece, we had to take testing into our own hands, with the use of what wasn't broken with the jig (+ shaped track and sliding plates). We did measure the distance we pulled from each side but little things such as the release of tension on the material was down by hand, the way the material was attached to the jig caused a few tears. Another reason for the inconsistent results was due to material composition, especially with ply wood. We noticed that the grain of the plywood affected the bending of the panel.

Another aspect our group explored was the way in which we cut the latex. What originally seemed like a good option was to use the Zünd cutter, a CNC modular cutting machine which was equip-able with different tool bits such as a milling bit or even a razor blade. This machine would have worked well with other sheet materials but would not be compatible with cutting latex, the elasticity, stretch and stickiness wouldn’t allow for the razor to simply cut through it. we had to use a manual method of hand and scissors.

As the group soldier on with pattern testing and the overall design of the pavilion was going through changes, one of the elements of the design that remained the same throughout the changes were the ribbing structure elements of the pavilion. this was originally designed with finger joints holding the different pieces together. I reviewed this design and discussed it with workshop staff Ed and tutor Alessandra. A few changes were made to this design such as:

• Use of dovetail joinery instead of finger joinery to prevent pieces sliding outward
• placement of joinery/where the sheet is to be cut, avoiding the centre of the arc where there is a higher chance of displacement and instability occurring
• Including an extra structural element design to increase the rigidity and prevent the rib from bending at the joints and to also prevent the joint from sliding out.

I had also prepared the lines for cnc milling of these wooden ribs. It would use up 2 x 1.2m by 2.4m plwood sheets 15mm wide.

A recap… was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

• The beginning of the stage uses a moving light to show the path of the hallway as it is very dark.
• A particle system is also animated to also act as a guide and add more intrigue into the design.
• Rotating arcs surrounding a pathway along with dynamic lights which displays the possibilities of dynamic elements in VR.

The above script uses very simple logic:

• Once trigger box is overlapped>play animation>play audio

This is the basis for all interactions used in the experience:

• EVENT > INTERACTION > RESULT

This leads into Stage 4 of the experience.

The VR Experience: Stage 3 was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

The start of the experience begins in the pavilion, putting the user in a familiar space and introducing them to the virtual space. This is where the on-boarding happens, teaching the user to teleport, pick up objects (torch), and turn it on. In addition, there is atmospheric audio which includes people walking around, a cafe, birds and general chatter. This is essential in creating an immersive experience as it fills out the space and causes the user to forget they’re in VR.

Stage 2

After a certain amount of time (30s–90s) everything fades to black and the user is teleported to stage 2 — a night time version of the pavilion with a mystery themed soundtrack playing in the background. Dynamic lights and an interactive button are introduced in this stage. The purpose of this stage is to engage and intrigue the user to advance through the encompassing environment that surrounds them.

Once they press the button, all lights start turning off and the screen fades to black, leading into Stage 3.

The VR Experience: Stage 1&2 was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Iteration 1

The first iteration was a very simple array of lofted gills that were positioned to have a gradient in distance of separation so that the entrance would seem more natural.

I began by extracting half of a circular curve and dividing that into even distances. Using a cull by pattern node I used the patter true, false, true, false, false, true, false, false false, true …etc until I reached enough falses and trues to take up the entire curve.

Although this way is quite manual, it was the only solution I could think of at this time that would replace the graph mapper.

I repeated this step with an internal circle and then created arcs between each point using arch SED

This was repeated with a smaller external curve and a larger internal curve. This would create the lowest point of the gills.

They were then lofted to create the gills. Since this was only half the curve, all the geometry was then mirrored to complete the pavilion form.

Iteration 2

Iteration 2 was very similar to iteration one, however some of the panels were removed to allow more light to enter the space. This would also make it easier for the fabrication team to create and would be beneficial in terms of cost and fabrication time.

Iteration 3 (Finger joints)

Dom was able to take what I had done and create more organic looking gills.

This is something the group preferred as it seemed more organic and and resembled a fungi more so than the original more simple gill design. I took these gills and started to look at how it could be constructed. Something that I knew how to script as I had previously scripted it for another project, was finger joints. I took one of the gills and played with how finger joints could be scripted with this form.

In this script I have exploded the gill brep, found the edge of a face and laid it flat. I then exploded the four curves of this edge curve and found a point along both of the longer curves to dictate where the finger joints would be positioned.

I took the curve created using the two points, exploded and shattered it and then used dispatch to extract every second shattered curve. I then offset the remaining shattered curves to create what you see above. I then used weave and connect curves to create the final finger joints.

Iteration 4

Dom and I then put a bit of both our scripts together to come up with the final form. Using Dom’s organic gills with my separation panel scripts we were able to come up with a good balance of simplicity and a unique form. Dom also added in a bench in the centre which everyone agreed felt fitting for the pavilion and its theme.

I then took this model in to 3DS Max and did a simple render using Vray and Photoshop to create a hero image. It was realised that none of the previous pavilions had had any renders or visualisations that showed what it could actually look like and I felt by taking this extra step it would “sell” the pavilion better.

Week 11–12 (Part2): Lamella was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

We started brainstorming about stress relief and what can decrease stress levels. We know from earlier studies looked at, that nature is a highly effective way to reduce stress and so we wanted to take inspiration from an organism within nature for the pavilion. After brain storming with the class we decided upon a mushroom or fungi form. This was due to the fact that fungi already shelter the ground beneath them, their form naturally would allow for people to walk around underneath the “cap”. The gills which form underneath the cap also are slightly translucent which would create a soft ambient light inside.

We wanted to look at one particular species of fungi so that we could narrow down what to take inspiration from. During a workshop with the fab team I came across the Lactarius Fungi. This species of fungi is stunningly beautiful in its simplicity. The gills are thing and elegant and they create depth and dimension to the form from underneath. The gills of this type of fungi are also always parallel to gravity which is something I thought we could incorporate into our design.

Another interesting biological characteristic of this type of fungi is that it excretes milk or latex when it is cut or bruised. This linked perfectly to the material we were using.

Week 11–12 (Part1): Fungi was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kinetic Biomimicry and the Internet of Things

WHERE WE LEFT OFF

As previously shown in the journal “The Kinetic Façade: A Hyper-Sensitive Solution”, we constructed two prototype frameworks, wherein kinetic façade elements will oscillate. The intention was to mimic a natural “breathing” motion and portray differences in human stress levels seen in the heart and lungs when under duress. However, both solutions failed to generate the desired motion, mainly due to the size of the frame and the translation of force vectors.

In addition to the kinetic façade, as expressed in the journal “Communication: Hardware Hurdles and Forwarding Firmware”,we have conducted explorations into utilising microcontrollers, to actuate motors in the kinetic façade and an array of LED strips for visualisation purposes. However, due to the time restrictions and scope of the studio, we have shelved inquiries into the LED strips, for want of providing one well-reasoned solution, as opposed to two half-arsed solutions.

Documented below are the final hurdles in approaching Group 7’s Kinetic Façade.

TWO STEPS FORWARD (IN A CIRCLE)

After the second prototype experienced materialistic failures, we took a step back and reflected upon what worked, but more importantly, what didn’t.

Firstly, over time, the repetitive movement would cause the force (strings) to find the most efficient path to the object (fabric), meaning that the fabric would rotate off center on the square frame. The method we decided to combat this issue was to create a frame with an even distance from the motor and the connections to the fabric. Furthermore, a potential reason why the motor was having difficulty pulling the fabric was the frictional forces between the fabric and the wooden framework. The larger the surface area of contact between the two materials, the larger the friction is, thus the more difficult it would be for the motor to pull the fabric. Our solution was to reduce the total surface area of the framework’s upward faces (the faces that touch the fabric). And finally, almost in conjunction with the previous point, the purpose of using wood for the first prototypes was the availability of the material, however, is detrimental with the goal of optimising movement by minimising friction.

Our solution: a plastic bucket…

AN ALTERNATE ACTUATOR

As mentioned, one of the reasons behind the failures of the first two prototypes was the poorly designed translation of force vectors. In other words, we were using a motor to provide a pulling force, perpendicular to the desired motion, and around a corner that further lowered the effective pulling strength (not to mention the coefficient of friction of the two materials in contact). As such, the power that the motor provided was not nearly enough to overcome these inefficiencies.

We saw two possible solutions. We either create a more efficient system in an attempt to minimise the loss, or we simply purchase a more powerful motor to brute force the issue. Like most do, we threw money at our problems (though, as stated later on in this journal, we eventually resorted to the former solution because apparently, not enough money was thrown).

A secondary issue, that furthered the need to purchase a new motor, was the imprecision of the previous motor. The crux of the matter was that its rotation was determined by a speed variable. Under load, imprecisions transpire because the input speed does not take into account external resisting forces. A stepper motor, for example, does not have this issue, as it’s rotation is determined by mechanical “steps” in the motor’s architecture. Precision is vitally important in oscillation, because without it, the repetition will shift, thus causing the elements of the façade to eventually jam.

After purchasing the NEMA-17 Bipolar Stepper motor from Little Bird Electronics, we popped into the local Jaycar for some advice on wiring it up to a Particle Photon, our desired microcontroller. The lifeless, sunken-eyed, shell of a human-being who attended us indicated that a stepper motor controller module was needed for proper control (we later learned that this was not true at all). Another problem, another purchase.

Several insignificant technical complications later, we established methods of control over the stepper motor within the Particle IDE.

A MORE HUMAN MACHINE

A fair warning: this whole section gets rather technical. If you, the reader, would rather understand the overall work that was completed, know that this section simply discussed the restrictions of stepper motors on a Particle Photon, and that a variation of rotational speed was not received well by the microcontroller; so, feel free to skip this section. However, it was documented and included in the final journal, as I am of the opinion that the complications that we experienced were rather curious and I would like some professional feedback. Discussion leads to comprehension.

To begin, our goal for the kinetic facade was to mimic the motion of organs that experience pulse position modulation due to stress. Our solution was to control a motor that would pull on a piece of fabric, raising its position on the framework, and then release the tension to allow for gravity to lower it. This up-and-down motion will represent the in-and-out repetition seen in breathing. Thus, our Particle code for controlling a stepper motor included these lines:

int stepsPerRev = 200;

void loop() {
  myStepper.step(stepsPerRev);
  delay(500);
  myStepper.step(-stepsPerRev);
  delay(2000);
}

Put simply, the stepper motor would rotate clockwise for one full revolution, pause for half a second, rotate counter-clockwise for another full revolution, and then pause for two seconds, only to loop back to the start and repeat these steps indefinitely. However, there is an important line that was intentionally left out:

void setup() {
  myStepper.setSpeed(60);

Most entities that oscillate do not move at a constant speed. Dr. Karamjit Singh states that “nature follows periodicity. The day and night, life and death, everything is repetitive. Periodic motion is the motion that repeats itself after a fixed interval of time. There are many types of periodic motion and the most common of them is simple harmonic motion. In SHM, displacement, velocity and acceleration all are sinusoidal.”

With the goal of affecting the speed of the stepper motor to make “a more human machine,” we first needed to have the speed continuously update as the script runs. In order to do that, we can simply move the function that changes the speed, from something that only runs at the start of the script, to something that continuously loops, like so:

void loop() {
  myStepper.setSpeed(60); 

After that, we need to give the speed function a sinusoidal variable. Below is a simple mathematical statement that maps a sine wave to an amplitude range from 0 to 60 with a wavelength of 2 seconds (at time = 0s, speed = 0; at time = 1s, speed = 60; at time = 2s, speed = 0):

void loop() {
  myStepper.setSpeed(30*cos(PI+2*PI*(millis()%2000)/2000)+30);

From here, we scripted some movement that matches the frequency of this wave. We can eliminate the need to dictate the quantity of steps, if we use an “if” statement based off of the properties of the independent variable of the above wave, that is, time:

void loop() {
  myStepper.setSpeed(30*cos(PI+2*PI*(millis()%2000)/2000)+30);
  if (millis()%2000 < 1000) {
    myStepper.step(1);
  } else {
    myStepper.step(-1);
  }
}

It’s at this point where the Particle Photon says “SOS!” Literally. The Particle Photon has a RGB LED that blinked red in the pattern of the Morse Code’s SOS. This means that the firmware has crashed. With the reason still unknown to us, the microcontroller doesn’t do well when we use time to alter the speed variable. We attempted to use different methods to create a variable that uniformly ascends, by either constructing integer variables that increase per repeat of the loop function, or by using the Photon’s internet connectivity to send a HTTP request to a universal clock and extract the seconds value, but nothing worked. So, we we’re in need to find an alternate solution to mimic a natural sinusoidal wave, or scrap the idea completely.

After some frustration, we attempted to implement a solution that avoided the problem all together. Instead of changing a variable that cannot be changed, we found another variable that had the potential to simulate a wave. We experimented with using ‘for loops” to alter the variable in the delay instead of the speed, however was side tracked with what will be described in the next section.

LEARNING FROM MISTAKES

Having finished construction of our third prototype, we put it to the test.

Above are two variations of the third prototype, one requiring human intervention and one without. As it stands, the model is not able to function as intended without something (or someone) pushing the fabric down as the motor loosens the tension in the strings. In the video without the helping hand, weights were used to provide the downwards force, to maintain tension in the strings as it loosened, but there is a fine balance. If the weights are too heavy, the motor will not have enough power to overcome the frictional forces and inefficiencies of the system. If the weights are too light, the force they provide will not be able to keep the string in tension.

Our previous intention to brute force the problems of the system by purchasing a more powerful motor was done in vain. So, back to the two solutions; either brute force it or develop a more efficient system. We resorted to the latter.

Reflecting upon the prototype, we found that the points in the system where the string had to translate its force in a perpendicular fashion, seemed to be the location the string had the most trouble moving through. In an attempt to aid this transition, we change the string to a nylon based material (to reduce the potential friction caused by the coarse material of previous string) and added small pulleys. This was the fourth and final prototype:

COMMUNICATION v2.0

The idea behind using a motor to actuate the kinetic façade was for more than just automation, it was for control. We wanted to be able to change the speed of the oscillation based off data, collated from the environment. For example, we wanted interactions from the Hololens, ultrasonic sensors placed around the pavilion, and maybe even live data from the web, to ultimately play a part in how the façade moves. This is our embodiment of the Internet of Things.

The microcontroller that we are using is called the Particle Photon. The Photon is a brilliant little device, as it has onboard capabilities to connect to local wifi networks (discussed more in the journal, “Communication: Hardware Hurdles and Forwarding Firmware”). Furthermore, Particle offers a functionality called “Tinker”. Tinker allows the user to control and read the voltage of the pins on the Photon, from an application on your phone. We decided to show the powerful, live connectivity of these devices by controlling the kinetic façade’s oscillation speed from this application.

Below are the main components in adding the Tinker functionality to our code:

int tinkerDigitalRead(String pin);
int tinkerDigitalWrite(String command);

int pinIn0 = A0;
int pinIn1 = A1;
int on0;
int on1;

void setup() {
  Particle.function("digitalread", tinkerDigitalRead);
  Particle.function("digitalwrite", tinkerDigitalWrite);

  pinMode(pinIn0, INPUT);
  pinMode(pinIn1, INPUT);
}

void loop() {
  on0 = digitalRead(pinIn0);
  on1 = digitalRead(pinIn1);

  if (on0 == LOW && on1 == LOW) {
    // State 0 - Off
  } else if (on0 == HIGH && on1 == LOW) {
    // State 1
  } else if (on0 == HIGH && on1 == HIGH) {
    // State 2
  } else if (on0 == LOW && on1 == HIGH) {
    // State 3
  } else {
    // Nothing
  }
}

int tinkerDigitalRead(String pin) {
  int pinNumber = pin.charAt(1) - '0';
  if (pinNumber< 0 || pinNumber >7) return -1;
  if(pin.startsWith("D")) {
    pinMode(pinNumber, INPUT_PULLDOWN);
    return digitalRead(pinNumber);
  } else if (pin.startsWith("A")) {
    pinMode(pinNumber+10, INPUT_PULLDOWN);
    return digitalRead(pinNumber+10);
  }
  return -2;
}

int tinkerDigitalWrite(String command) {
  bool value = 0;
  int pinNumber = command.charAt(1) - '0';
  if (pinNumber< 0 || pinNumber >7) return -1;
  if(command.substring(3,7) == "HIGH") value = 1;
  else if(command.substring(3,6) == "LOW") value = 0;
  else return -2;
  if(command.startsWith("D")) {
    pinMode(pinNumber, OUTPUT);
    digitalWrite(pinNumber, value);
    return 1;
  } else if(command.startsWith("A")) {
    pinMode(pinNumber+10, OUTPUT);
    digitalWrite(pinNumber+10, value);
    return 1;
  }
  else return -3;
}

By connecting pins D0 to A0, and D1 to A1, we can use the Tinker app to send either an “on” or “off” signal to the digital pins. From there, the analogue pins pick up this signal, and a combination of the two will indicate one of four possible states. Once we’ve connected it up to the phone (ie. the web), we can easily wire up ultrasonic sensors, or use HTTP requests to collect data from the Hololens, or even live data sets. From there, all that’s needed is to remap the values onto a range that the motor can comprehend, and we have generated a data driven kinetic façade.

This control over the kinetic façade is representative of the capabilities of the Internet of Things.

A More Human Machine was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Create a new project, for this example i’ll be choosing “Architectural Template” and click “save as” to give it a name.

2. Click “Collaborate” tab > under “Manage Collaboration” panel > select “Collaborate using A360” and click “OK”

3. Give it a name under “Current Revit Model” > select the location of where you like the file to be stored > click “Initiate” (this is where we upload the central file on to the cloud).

4. Image below is where the local file you just created will be stored, this is where other team members can download the Central file and create a new local copy from.

5. Once you finished downloading the central file, make sure to copy and NOT cut the file.

6. Give it a new name under a new folder, to open the local file, make sure to DOUBLE CLICK THE FILE, DO NOT OPEN IT IN REVIT!!!

7. To synchronize back to the central file, click on “Collaboration Tab” > under “Synchronize with central”> click “Synchronize and Modify Settings” > click “OK”

Collaboration in A360 through Revit was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Because the pavilion has been made in Rhino and grasshopper, i would need to bring all the geometry to Revit in order to assign parameters on it.

linking rhino geometry to Revit by layer.

next is to categories element though DirectShape.ByGeometry which enables the rhino element to be a revit element such as Generic models.

next is to assign parameters to elements by Element.SetParameterByName and using the String.Insert to insert the assembly code name to the value.

As a result i was able to assign parameters and assembly code successfully.

Next is to test and see will these parameters can be shared and stored in the cloud based such as Autodesk A360

As a result it was able to be read directly in the cloud.

Assigning Parameters and Assembly Code was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.

From our research, the five most popular ways of managing stress in Australia are:

85% of people use technological entertainment (television, movies)

81% of people focus on positives

81% of people spend time with family and friends

80% listen to music

75% Read

Australian Psychology Society. (2015). APS Stress and Wellbeing in Australia Survey 2015. Retrieved from http://www.psychology.org.au/psychologyweek/survey/results-stress-and-wellbeing/

The internet of things is the embodiment of widespread connectivity. And through the use of IoT, we intend to bring people together, to engage with responsive technological installations. Our aim is to provide a platform to bring people together, through the inter-connectivity of computer devices and the internet, to help alleviate the burdens of stress.

Kinetic Facade

The onset of stress causes the lungs to provide the blood with more oxygen, affecting breathing patterns. We propose a way to encourage user interaction and demonstrate how people can have a direct influence on other people’s stress. This will take the form of a kinetic facade.

Sensors will detect the presence of people around the installation and will send a digital signal to the actuator; a stepper motor. This motor will respond by rotating to tighten or loosen a cable which will stretch or loosen a fabric facade in the centre of the pavilion. The purpose of this is to simulate a breathing pattern. When there are no people near the sensors, the facade will respond to an external data source, providing live updates on stress levels.

LED Visualisation

An Augmented Reality experience will be created to reduce stress and will be included with the pavilion. The purpose of this will be to create an immersive (being deeply engaged or involved) AR relaxation experience to reduce stress. This experience will make use of colour theory, responsive technology and create a shared experience.

The experience will continue the ideals of using the Internet of Things by collecting data from multiple sources. Similar to the aforementioned example, this experience will control and manipulate the data within a micro-controller. However, in this case, the actuator will be a series of LED strips.

Implementation

The kinetic facade will be located inside the centre of the pavilion. It will be isolated from users to ensure safety and durability of the facade. It will be visible between the structural elements of the pavilion and located above head height.

The LED visualisation will be placed around the edges of the ribs, with the light being projected up the walls of the pavilion. All electrical equipment will be hidden from view.

IoT Narrative was originally published in code3100 on Medium, where people are continuing the conversation by highlighting and responding to this story.