Creating 4edge

I am Morgan Rogers. This blog records my attempt to contribute a vision of mathematics to the world, in the form of a tool for building and exploring 3D networks. "Visualisation is a powerful stride towards understanding."

[4edge]

I would at some point like to be able to adjust the scale on my Edge UI; this would certainly resolve any problem of compatibility between devices. Alternatively, if the idea of extending my software to 2 categories looks appealing, I will want to replace this UI with an iteration of the broader network design!

Ultimately, this train of thought is taking me off track. Once I have a basic product which is shipable, I can come back and add features like this, or indeed branch into different versions of the software depending on application. Ideal features like avoiding edge overlaps are similarly distracting, but will be more important to fix once the framework is in place.

[4edge]

I made the basic ‘target’ overlay for the interface. The idea is that the middle circles give a sense of scale: the central one represents the radius of one of the nodes in the network, the second is twice the radius. The outer circle which actually receives the input expands with the screen size; this could cause problems between platforms/resolutions, but those problems can be left until later in development.

[4edge]

It turns out that trying to do anything graphical without Photoshop is an absolute pain, even in 2D. To act as the markers of my edges, I wanted a handful of geometric shapes; to produce these I had to draw them in MS Paint (RIP) and then move across to PowerPoint to remove the backgrounds. But I’m not putting any money into this project until I absolutely have to, so since there is no free 2D shapes package that I could find in the asset store, this will have to do.

[4edge]

I’m not sure throwing code at you is good exposition, dear reader, but I do so to show you that the time has come to work out how the edge configuration interface will work. Although when I first mentioned this I had intended it as a feature to be implemented later, it is integral enough to the program structure that I need to know now how the information will be acquired.

I have found a handy tutorial for clicking and dragging (applied to an inventory system, but easily modified) which will help me get to grips with the available event triggers, and another on designing modal windows in Unity, which should help me produce a simple interface for doing this.

[matan-matika]

An important example in Graph Theory is the Petersen Graph. It is very symmetric. Because it is so symmetric, some proofs with it are easier to see in a different configuration. The two shown here highlight its 3-fold symmetry and 5-fold symmetry.

[4edge]

or perhaps in a 3D configuration, since it’s non-planar?

[backward-indication]

I have finally succeeded in making a (pretty?) picture of my thesis… featuring the Johnson graph J(7,3), and a partition of its vertices such that the induced subgraph at each part is a cycle

[4edge]

This looks like an instance of something that it would be useful to be able to model in 3D? Especially to be able to animate following cyclic subgraphs. Maybe 4edge will eventually be useful for producing nice visualisations like this!

[4edge]

The outcome of my last post is that I now have a convenient level structure to my programs: at the bottom is the storage level, where data about networks will be stored persistently. On top of that is the data-handling level, where the information about the contents of information in the network is processed as efficiently as possible (through a choice of implementation of the ICmpnt interface). Then there’s the visualisation level, handled by the Cmpnt script, where game objects are manipulated to match the data. Finally, the sum of the parts is tracked by the ComponentLoad script, which will mainly track where components are relative to one another.

Wrapped around this structure is the influence of the GameControl script, which gets everything going in the first place. If only I had access to some network visualisation software to model this workflow...

[4edge]

My friend Jamie convinced me that now would be a good time to implement the info about interfaces that he mentioned a while ago:

Until this code is actually running, I have no way to know what the most efficient way to code the data behind my networks will be. Even a priori, I could choose between storing the basic data of ‘how many edges are there between each pair of nodes’ as an adjacency matrix or as a (decorated) adjacency list, and that’s even before deciding how those matrices or lists will be stored in the C# framework. I have asked for advice on StackExchange, but in the mean time I have created an interface (code pictured above) and will be producing one implementation of it to work with for the time being.

I hope that eventually the implementation chosen will vary with the network (as edge density changes beyond certain thresholds, say), and having an interface will allow me to do this with minimal changes to the code and without losing earlier solutions to the problems I encounter.

[4edge]

I think weekly plans have blown up in my face, despite being useful. Over the next few weeks I’ll be more concise in my reviews and objectives.

The system as it stands consists of six main scripts, all of which have major parts waiting to be coded.

The GameControl script has two purposes. First, it carries data between ‘scenes’. For example, when the tool is initiated, a main menu will appear, from which a save file may be selected. Doing so will open the interactive interface, which in Unity terms consists of a separate scene; GameControl carries the information from the main menu into this new scene. Second, GameControl contains the saving and loading functionality for the tool, in particular reading and writing persistent files to the disk.

The CmpntLoad script will be attached to an empty game object in the interactive interface. Its main purpose is to be the parent of all of the visible objects in the scene, and to initiate the loading of these objects into the scene.

The nodes are controlled by the NodeSelectable script.

Similarly, edges are controlled by the EdgeSelectable script. I coded some parts of these much earlier in the project.

The Cmpnt script encodes all of the processes required for basic manipulation of the network. The network will be manipulated componentwise. That is, nodes and edges are children of a parent ‘component’ object, to which the Cmpnt script is attached. I have designed the functions for adding and removing edges and nodes so that if a component becomes disconnected, a new Cmpnt object is created for the detached nodes and edges. CmpntLoad contains an array of the components and their relative transforms. This will allow greater flexibility for moving things around later!

The basic data for each component is stored in an instance of the CmpntData class stored in a script of the same name. This is the data which is serialized by GameControl in order to save the network to a file. All of the data is store numerically to save file space (via large, but hopefully sparse, matrices/arrays).

Similarly, most of the routines aim to use the numerical information about the parts of the network in order to save processing more complex game objects. To this end, it will be important that the code I apply to the visible network is carefully reflected in the changes made to numerical data and vice versa.

The next stage in the coding is to work out how these codes can generate visible objects in the scene with the correct components to make the tool function!

[4edge]

Week 4 Review

So this fourth week has ended up lasting... four weeks. Not that anyone’s paying attention! I have occasionally found moments to work on this project in that time, though, and the outcome is that I’ve designed a system capable of storing the positional data of a network to a persistent file and then extracting it into the virtual meat space. Most of the aspects of this design are not yet coded to functionality, but I at least have a good enough understanding of how scripts in Unity interact to have come this far!

[4edge]

A template, just like the one for my button. Useless until I can work out how to extract what’s typed!

[4edge]

A quiet week on this blog (back home, driving theory test next week, hosting people for my birthday this weekend). Mid way into learning about data persistence, I realised that for this to be even minimally functional, I would want to be able to name save files from within the game. Which requires text input. Hence my exploration of a text-based adventure tutorial! All I need from it is player input but there might be some useful info about ‘scriptable objects’ too.

[4edge]

Week 4 Plan

There are two pieces of the puzzle I want to understand better this week: First, the Data Persistence introduced in the Adventure Game tutorial. The ability to save networks once drawn is obviously one I want; while including it as a feature at this stage may seem premature, it will make 4edge usable as a resource long before it's viable for distribution. Moreover there is a more basic tutorial that I can use to fill the gaps, while nonetheless implementing the editor produced in the Adventure Game tutorial. Second, I would like to understand the Animator better, since this may be the key to controlling the (appearance) states of  nodes. Since the point of this project is visualisation, appearance will ultimately be one of the most important things to control; I'd rather get on top of it now. Since the plan in Week 2 (and hence Week 3) was overly ambitious, this is all I'm going to set myself for this week.

[4edge]

Week 3 Review

It turns out that trying to repurpose pieces of a code base for a different project isn't straightforward, especially when you're not entirely up to speed with the underlying principles... I spent much time this week trying to understand enough about materials, renderers and shaders to produce a simple colour-change reaction upon clicking the components of my network, but to no avail: there is an entire graphical system that one should learn in order to properly understand how to manipulate these components, and I was trying to wade in at the deep end! The (not great) organisation of Unity's documentation has not helped me thus far. Nonetheless, I have acquired some select pieces of the graphics process which will be useful when I eventually want to improve the aesthetics of my product. Otherwise, I have had time to further scour the details of my ported material, and have implemented some additional aspects of it, in particular the 'Persistent Scene', which is a background space into which networks are loaded from save files. I have concluded that I should focus on making more of this material functional before continuing with the so far unsuccessful click-and-react mechanism. Overall, I haven't at all met my targets even for Week 2. I must cut my losses now and go back to basics next week.

[4edge]

A worm’s nest of collision issues today, which I will outline for you now:

Currently, clicking on the screen ‘casts a ray’; that is, it shoots a line into the virtual 3D space, and looks for the first place that that line collides with anything (at least, I think it’s the first place, for now...) It does this by checking the coordinates of colliders present in the scene, which are components (scripts/objects) attached to game objects. The function that performs this calculation then returns some information about the collision.

The issue is that the returned information is relatively limited. I can access the contents and location of the collider mentioned above, but I can’t access the game object that the collider is attached to directly; in particular, if I click on a node, I can’t work with scripts attached to that node.

There are ways around this; it seems some of the effort I put into researching raycasting way have not been well used, since there is a better-integrated event system which includes convenient triggers such as OnPointerClick which I will likely resort to.

There was also a future problem to work with: for collisions to work effectively, unity specifies that one should attach a rigidbody (physics) component to any moving entities involved in collisions. Since the amount of motion involved in my project, I may ultimately ignore this, but having physics so integral to collisions may get annoying in the future...

[4edge]

Getting there (not much done today).

[4edge]

My Scripts folder is significantly heftier now than when I started..! In theory I have only replicated the scripts from the Adventure Game project that I think I need, but since I skipped the Inventory talk (and since the speakers occasionally referenced things I hadn’t seen them discuss) I have some debugging to do to patch anything I’ve omitted. In theory it’s now mostly a matter of implementation..!