EXP 2: Week 4: Research Continued...

Entity Rotation of 360 Degree’s:

As part of my mastery demonstration video’s I intend on presenting the Entity: AttachChild flow graph node through a simplified version of my porosity lens which requires the core attachment entity to rotate 360 degrees. However to perform such a task in Crysis is more difficult than one would think due to that after 180 degrees is set, it immediately assumes 360 -‘x’ degrees within the opposite direction. However I have managed to come up with a flow graph to overcome this issue which simply runs two 180 degree rotations with a time delay, as presented below.

It is a rather confusing process, but simply it uses a key input to obtain the current rotation of the defined entity before adding 180 degrees upon a set axis to the current rotational value, before ordering the action to happen with a set time, i.e. 3 seconds. Meanwhile upon that initial key press a time delay of also 3 seconds has begun to perform the same task. Thus immediately when the initial rotation ends, the position is obtained and yet another 180 degrees is added, rotating the entity through a “Movement: RotateEntityTo”.

Entity Attachment and Detachment – Experimentation Three:

After experimenting further with the initial idea of using a very simple attachment flow graph system last week I discovered that it wouldn’t in fact work correctly as the attachment of each cube would need to be set for every option. Thus I began researching again other options for a way in which I could identify the cubes surrounding the central rotation point. I remembered within a lecture of Russell Lowe’s he demonstrated the notion of ‘Ray casting’ and after a discussion with a friend I began to realise it may be a possible solution. However upon planning out the way in which this could work I discovered that it was going to be extremely difficult and not very precise or accurate. Due to the manner in which a fired beam determines an output through collusion, I first realised it may be difficult for the beam to reach the corner cubes due to the edge cubes being in the way. Secondly I realised due to the variable shaped entities which will make up the surrounding cube, it will be difficult to ensure the beam makes contact with the correct entity. I have therefore decided to not pursue this option any further, as I begin to consider the use of physics triggers.

Entity Rotation – Local Player Tracking:

One of the main components of my porosity lens documentary exists within the main interactive component which uses the local player or an AI to control the rotation of each surface. Thus I needed to therefore come up with a way in which I could convert the protagonist’s position into a relative rotation to a selected entity. After some research and some help from Vinh, we worked out a way to achieve this notion. Such simply subtracts the values of the entity and the protagonist to present a vector which we discovered needs to flipped before the result is then multiplied and presented to the rotational node. However there remain some issues at the moment including the way in which the entity snaps to the current rotational position of the protagonist, and the lack of control due the use of both the x and y axis. However it still achieves the basic principles of interaction I am looking to achieve. I have included the flow graph beneath.