Onieroi has a maintained page at efuller.net/onieroi.
According to Greek mythology, the Oneiroi were gods that created dreams. The Oneiroi were sons of Hypos, God of Sleep. Morpheus created humans, Phobetor shaped animal forms, and Phantasos shaped abstract and inanimate dreams.
The Oneiroi Project seeks to bring a collective shape to dreams through visualizing a network of dreams submitted to the Oneiroi project. Dreams are linked by content, date, location, and dreamer, creating a network of associations tracing a series of dreams by any of these subjects.
Onieroi involved two distinct stages:
My first step was to develop a dream submission site. Here, I designed a form for people submit dreams to my database. Along with the actual dream, people were asked for their name, date of the dream, frequency of the dream, physical location during the dream, location in the dream, and emotion evoked during the dream.
This process involved more than a simple HTML form. Since the physical locations specification was presented as a drop down menu of countries, I created the menu in a separate .inc file which was loaded by a PHP script, keeping the site cleaner and easier to manage. Similarly, I wanted the emotions section to be flexible. Thus, there is both a drop down menu and a text field. People are encouraged to use the drop down menu, since it requires less creative effort on their part and makes grouping dreams easier on my part. But, should a dream evoke an emotion that I did not have the presence of mind to include, I wanted to give users the option of adding that emotion so that they can be accurate and others can use it in future. Anything entered in the text field will be added to the drop down menu by adding it to the text file from which a PHP script pulls the different emotions.
Along with the visible fields, the dream form has some fields that the php script automatically fills out. The dream form submits the IP address of the connection for each dream. This is in case I choose to later implement a further level of dream location organization for those dream submissions that the user omits a location for dream. While this is obviously not 100% accurate—the writer could be using a proxy and there is no guarentee that the location that the person is writing the dream is where they had it—it gives an approximation to work with. Similarly, I wrote a script to submit the date that the form was sent as a backup reference for submitted dreams where the dreamer omitted the date of the dream. I chose to presume that, when unspecified, the dream in question occurred the night before.
Also, given my experiences with user interface and some questionable characters, I included a second page where users review and confirm their submission. In terms of usability, I set this up to ensure that people didn’t write up a dream and then change their mind and make a second submission of what they intended to write the first time. In terms of security, the php on this page sanitized all the submissions to prevent any MySQL injection attacks on my database. I’m sure that no one would intentionally harm my database, but you never know when little Bobby Tables is going to have a bad dream to share:
Exploits of a Mom, brought to you by XKCD.
OK, I admit it, I do have little faith in some personages exploiting the security holes of my site for the lulz.
Finally, I set up my first experiment with pulling data from the database as a record page that showed the 30 most recent posts.
I would have not felt guilty at all to leave my project like this. The amount of time I invested in developing this PHP/MySQL site and database was significantly more time than I intended to devote my project in light of my ambitious life dress. Still, I would not have been satisfied with just this.
The second stage of my dream project was the Processing visualization application and the Onieroi site. This application pulls dreams from the database and visualizes each as an orb that travels around the screen. Users can click on the orb to read the individual dream. They can also navigate the dream submissions through associated links. Each dream offers the option of viewing more dreams, organized by dreamer, subject, emotion, date, and location. By clicking the orb or link, Processing runs a PHP script reminiscent to what I developed for the dream site’s Record page and displays either the selected dream or the next dream in the series of related dreams.
PHP and MySQL
The majority of my time on this project was spent working with PHP and MySQL. While I had had some experience with it before, it was fairly limited. Thus, this project took a lot of trial and error. The learning process was particularly difficult since I didn’t have any Eclipse-like interface to easily pinpoint and diagnose errors. Still, I thought this was the ideal opportunity for me to explore these languages rather than taking dynamic web development next semester.
In order to create the Processing application, I relied heavily on several libraries to simplify certain basic tasks. At one point or other, I employed OpenGL, ControlP5, and Traer Physics. While each library simplified some process, since I didn’t write them, I wasn’t totally aware of their functionality. Thus, when I came across library related bugs, I was at a loss as to how to solve them.
OpenGL had its pluses and minses. When I started this project, my main desire was to explore creating a 3D environment. Thus, I wanted to create 3D objects and allow the user to view the environment from different angles. Unfortunately, this became rapidly infeasible due to the number of dreams to be visualized and the amount of time it would take to draw them all.
The final, killing blow, however, was when I attempted to upload my application to be used online. For some reason, the application would not load. At first I wondered if the application was too heavy to run online, but when it didn’t load for minutes and I observed no activity on the command line, I realized there muse be some problem with the program’s contents. After deconstructing the program piece by piece, I discovered that the error was caused by some bug associated with OpenGL. Given the collective nature of this project, it would be an egregious failure on my part for me not to have this environment online. Submitters should have the benefit of viewing their work within the greater context of this project. Thus, OpenGL had to go.
ControlP5 is a handy interface library that enables me to easily create text areas, buttons, and text fields. Processing is not an application written for much text manipulation. In an earlier project, I had to set up an application that read each keystroke and then drew it on the screen. It is a lot more effort that I would consider it to be worth. Thus, I was quick to search out a library that would do this work for me.
Unfortunately, there are a few bugs that I haven’t been able to completely identify. In the example code, when the text in a text area exceeds the scope of the dimensions of the text area, a scroll bar automatically appears. Strangely enough, this has not been the case in my dream code, which means that long dreams are currently being cut off. This is obviously something that I do not want, however, I have yet to identify what it is that is suppressing this method.
Another error that is part of ControlP5 is the lack on an auto return in text fields. It is rather intuitive that a user wants to see what they are typing. In text fields by ControlP5, however, type does not auto return or scroll. When the text is longer than the frame any additional keystrokes are not visible, though they are taken in. This is a problem on so many levels and yet another one that I haven’t solved. I think I will have to manually tweak the code to solve this problem.
To access information in my database, I have to use the loadStrings() method which retrieves the page contents of the given URL. By calling a page with PHP, I can call have that page query the database and echo back the information that I want. This is then read into Processing as an array of strings. Dealing with arrays of dreams and arrays of strings lead to LOTS of Null Pointer Exceptions and Arrays Out of Bounds. Most of them I’ve dealt with. But there are some seemingly inconsistent cases where they do still crop up.
Subject Assignment and Sorting
I have yet to organize submissions by subject. This is, of course, a difficult thing to automate, but it needs to be automated since I have no intention of assigning subject manually and the manual process limits the the potential breadth of the project by what my isolated self considers relevant. There is an excellent library, RiTA, which has many fine ways of sorting and finding associations for words. I’m just trying to find the most efficient and accurate method of sorting through all these dreams that will not only generate properly descriptive identifiers but also repetitive subject identifiers so there are multiple dreams with the same subject. After all, what is the point of having the option of reading more dreams with this subject if there are none?
Currently, the dream orbs travel in a meaningless trajectory. I want to have the dreams placement on the screne reenforce the theme of dream relatedness. Thus, I want dreams to be closer to eachother when they share more common attributes. Dreams that share the same dreamer, date, and location should be closer to eachother than dreams that only share the same date.
Not only do I want spacial linkage, I also want visible links between dreams so that users can see how there are certain large clusters of dreams and other free floating dreams with relatively no associations.
Currently, the dreams are simply circles on a white background. While this was a simple way to visualize the dreams with little effort so that I could focus on more practical concerns, the overall effect is similar to Harris and Kamvar’s We Feel Fine. While I think their piece is beautiful, I would like to distinguish my project from theirs. Of foremost interest is designing new representations of the dreams. I’m still in the rough stages, but I would like to design something less visually distinct that shifts internally as well as travel across the screen.
A major limitation, of course, is run time. Each individual part that I add to distinguish the dreams means an additional feature that has to be drawn for around a hundred dreams (with potential to increase) for every frame. This makes it easy for a more ornate dream design to significantly bog down the run time of the application. I don’t want the dreams to be so complex that they noticeably disrupt the smoothness of the animation. This is particularly a concern for the web version which already runs slower that the locally run application.
As I earlier noted, my original vision was to develop a 3D environment. I still want to do this. I believe that allowing the viewer to navigate through the environment rather than click on the environment will make the overall experience far richer and more immersive than it is now. While I have had problems with OpenGL, I am ready to look at it in greater detail to determine what the problem is.
- Morpheus Onieroi has a maintained page at efuller.net/onieroi. It came to...
- Morpheus: Dream Environment Progress After being moved to the back seat while...
- Morpheus: Information Collection Onieroi has a maintained page at efuller.net/onieroi. It’s not just...
- Life Dress: Final Presentation Video The Life Dress has a maintained page at efuller.net/life-dress-f2. Click...
- Life Dress: Final Presentation The Life Dress has a maintained page at efuller.net/life-dress-f2. The...