Field offers a wide variety of ways of writing and running code. One new way is that code can be packaged up and sent to a connected web-browser for execution there instead. This trick allows us to ‘write code’ live on devices where writing code might otherwise be impossible or, at best, painful — for example: cell phones. This, in turn, allows us to ‘live code’ AR experiences, device in hand.
To put this hack together we need to connect web-browsers to Field. First we’ll grab a pre-made template and insert it into our Field document:
(bring up that menu by pressing
The template you want is either called
ar.android (note the special instructions for android here). Like all boxes this box contains code, but you don’t need to pay much attention to it. What you do need to pay attention to is the label below it:
That label is an invitation to connect a web-browser, either running in our AR extended iOS app, or on a desktop webbrowser. That URL is Field’s best guess at to the IP address of your machine:
Bringing that URL up in a web-browser yields a change of label:
This label tells you the number of browsers that Field is connected to and where they are coming from (here we’ve opened a browser on the same machine, so it’s IP address is identical).
As far as Field is concerned there’s now a bridge to executing code inside those remote processes. To tell Field that we want a particular box’s code to run else where we need to connect them our bridge:
Hold down the ‘g’, click and drag from the bridge to the box you want to connect (not the other way). You’ll see and arrow pointing from the bridge to the box. Congratulations, code that you write here is actually being executed in a web-browser, which might be on a different machine (or, of course, a cell phone!).
(you might experience this if your cellphone disconnects from the WiFi or swaps IP address over LTE). You can try wiring your phone into your computer.
the web-browser doesn’t bother to execute your code. This happens, for example, on desktop’s where the browser’s window is minimized or completely obscured. Make sure there’s at least a bit of the window visible or everything you run will ‘queue up’ until you can see the window again. In this case error messages effectively don’t appear until you look away.
you encounter something that is documented for Field as working inside Field, but doesn’t work inside a web-browser. Currently there’s quite a bit of Field that hasn’t been moved over to the web-browser / Three.js way of drawing things — if it isn’t on this page, there’s a good chance that it doesn’t work yet. We’ll be rapidly rolling out large pieces of infrastructure in the next week to bring the browser / Three.js up to parity. The order is definitely up for grabs. Ask.
you use two bridge boxes. Each box will try to open it’s own connection and everything will fall apart. Delete both of them and start again!
you use the wrong bridge box for your device. Desktops, iOS and Android need their own special support. The adventurous can just edit the code in the box to switch it over (remember to execute the code after you’ve changed it)
None of the above. In this case the best information that you can provide comes out of the ‘developer console’ or the ‘developer tools’ inside the web-browser. On the desktop you can get to from the application menu of the browser (for example, in Chrome ‘three-dots menu’ -> ‘more tools’ -> ‘developer tools’). You can also connect phones to desktops and open a remote developer tools session. We’ve tried very hard to move all error messages from the browser back to Field. Alas, much error information is considered a security risk, so sometimes browsers might decide to not ‘leak’ the information that your code is broken.
Tears, frustration. Above all, you should try to balance paying really close attention to your code and what you are writing, while still calling for help earlier than your pride normally allows. Looking at a piece of code and seeing the mistake isn’t an innate talent, it’s just something you need to practice. Computers are frustratingly cryptic, easily confused and require super-human levels of precision. Expect to lose an afternoon to a misplaced semi-colon at least once.
Two pieces of code for you to study, understand, manipulate and intervene in.
The first, is how to draw a shape — anything — inside the browser drawing surface:
When executed together that yields:
Let’s take it line by line:
This makes a new object called an
FLine that’s a container for dynamically drawn geometry. We’ll assign it to a new
f. Study this for a moment to make sure you understand which parts of this are arbitrary and which aren’t — where do the ‘names’ come from, and what are the ‘verbs’ in this statement.
fis arbitrary — it’s just a name we come up with here on the spot. It could be
var myGreatLine = new FLine(), or
var FRED = new FLine(), or (not advised)
()says that there aren’t any additional options that you want to supply for the construction of this
FLine; again, it’s part of the syntax of the language we are writing in.
Other programming languages would have different things for
() and even
=; things might go in a different order. But all languages have an idea of naming, invocation, and creating new things. Learn that once and you’ll have a head start on all other programming languages.
Next we do two things to
We’ve added some contents to this. Think of
FLine as a pen: it moves (without drawing) to position
[0,0,0] and it draws a line to
[1,1,1]. At this point, if you execute just these three lines you see nothing. We haven’t told Field to actually draw the line — we’ve built up a structure, a recipe for drawing something, but we haven’t deployed it.
This actually adds this line to the
stage (as in “all the world is a…”) to be drawn. We give it the name
myGreatLine — again, just an arbitrary name, but we’ll see that shows up in the Editor window. Naming things as we add them is a useful trick — if we run this code again then anything that was previously on the stage called
myGreatLine gets replaced. This is exactly what we want: we want to be able to run the code over and over again (while making mistakes).
If we tweak and tweak that piece of code we can slowly, incrementally, turn it into some other kind of beast:
_rvariable to define a function that will be called for every frame of animation — this allows us to start and stop an animation independently of other boxes. Start the animation by option-clicking the box and swiping down. Stop by option-clicking and swiping up.
_t()which is a function that yields a ‘time’. This time goes from 0 to 1 depending on where the ‘red line’ strikes the left or the right of the box. This lets you build ‘scores’ of animations inside Field. It might be, for example, how you fade something in or out in time.
The code above displays an animation that runs and runs. We can move it around inside the editor, and we can start and stop it inside Field, but other than that we can’t interact with it. To draw something we need to interact. Specifically, we need to run code in response to the environment (the finger). Here’s the code for a primitive copy of ‘Just a Line’ by Google:
Let’s annotate it from top to bottom:
This adds to the list of things to do with the ‘mouse’ (or finger) is pressed down. Here
mouseDown is part of Field and
drawme is just some arbitrary name. But, again, like lines, this gives us code that we can execute over and over — subsequent declarations of
drawme overwrite previous ones — without accumulating bits of code that all end up running when we mouse around. The
event is an arbitrary name give for a variable that will store some information about where the mouse / finger is. We ignore it here, because we don’t care where the mouse starts.
Let’s finish this code that gets run, automatically (that is: as if we had selected it and hit alt/option-return), when we press down with our mouse-finger:
Now we have an invisible line that’s made and added every time we press down. Let’s add some drawing instructions to it when we move our finger:
Finally, a note to record when the ‘mouse’ is released, just in case we are actually using a mouse. Fingers don’t call
mouseMove when they aren’t touching.
You can also try
event.hit to get the position of the
event on the nearest AR detected plane in space. Now you can draw in space!
Your task, for sketch one, is to provide a new ‘drawer’ — by modifying this code (or any other strategy).