Crossings

Idea

First workshop: Roehampton University 21/02.05
- preparations
-stills
- contactsheets
- visualisation ideas
- graphical seaweeds
-seaweed animation
- mesh designs

- new visualisation
- mesh coding logic

Second workshop: The Place
April 05
- stills

Fabrica submission

 

 

Crossings: mesh designs

Aim is to find ways of emulating the drawing:

Meeting with Chiron: 26/05/05

To develop three stages of mesh deform

1)     to put the agents in bands (separate bands so that we can have splits

2)     to make the triangulated bands move each their way with leftwards and rightwards agents

3)     that the agents generate paths of squares  so that we can have crystalisation
here the idea was also to

Mette's idea is that we should create the mesh as an if loop reacting on distance over time:

Vertices {a,b,c,d,e,f,g}

If distance (a2 -a1) is small then

            a1 is aPAST1, aPAST2, aPAST3 etc                        // this means that the old point is kept as a memory

draw triangles between a, aPAST1, aPAST2, aPAST3 and b - e.g. to get the webbing:

if distance is too small  - then nothing                     // i.e. don't draw point on top of each other

when distance is big again then kill aPAST over time // e.g. keep the crystals there for a while

Yaxis:

The yaxis can also result from this small loop

 

 

Playing with the surface

The surface moves per timeframe:

 

This can be set / slow is 2000 (20 secs)

It is one array of triangles:

 

I think it could be more like the original setup with 3 rows of triangles (responding to the 4 rows of departure points) this would give it a more surface like quality

The mesh moves smoothly with the agents - then there is a flicker between each state when the agents are re-sorted

  

I think the mesh needs to have its own trajectory, meaning it needs to move from state to state - rather than with the agents - this would eradicate the jumping and let the timeframe issue (times of interaction) be more clear.

The sorting at present makes the surface zigzag

  

Obviously just something we need to play with

Rendering

  

For now we could do it in wireframe - then find a renderer

 

Making it more like the drawing

In the drawing there are 2 surfaces

They are both with normals facing up and down creating a breaking up of the surface

  

 Could the vertices moving left be differentiated from the vertices moving right creating two meshes interacting?

The drawing is done on a grid of movement

 

I don't know if this is important but we could use a multiplication of integers to make the mesh move more grid like.

(e.g. take agent pos - turn it in to an integer and then threshold to give less resolution to movement).

The drawing is not regularily broken up into triangle - e.g. there are also square if even that they are triangulated

  

This is because the Ôagents' are imagine to be on top of each other - which they will never be

Perhaps we can make the

The drawing is more broken up

  

Is there a way to let the surface have breaks in it?

a)      could this be generated by the Yaxis? - e.g. if the yAxis is drawing the vertices down? - not v likely

b)     could we use the normals to make the mesh break up - wonder how regular this would be? I know that the mesh must be predefined (e.g. vertexlist)

c)     could we let there be double of the vertices to agents - and when distance/time is small then they can pop out

d)     could this work when we are doing the yaxis - e.g. could the extra points be moving downwards?

The drawing has many (!) agents - the particles that C is drawing doesn't

  

This is just to look out for

At present there is no differentiation between the between the directions of the agents

  

We could do this - it would double up the surface which might help solve bits above

This is with full surface - e.g. not cut up / but still triangulated - this looks better than the triangulated one  - but not when it is rendered?

Moving two ways