From Concept Prototyping to Production in a Creative Studio
Innovative thinking in prototyping
Before any line of code is written, we have to sit down and brainstorm ideas. To us this is the most essential phase, as refreshing our minds and mapping out prototype concepts can be extremely challenging. Especially so, as we always strive to be as original and innovative as possible. Thinking outside the box is difficult, sometimes daunting. But once we’ve collectivized our train of thoughts and thought of the most unique concept, that’s when the magic can begin.
TL;DR: Check out our live demo and the concept video here!
Live WebGL demo: https://surface-floater.lusion.co
Concept prototype Video: https://vimeo.com/239449648
In this industry, it seems to many a mystery how we get things done. We often encounter clients asking us to create real-time animations in order to visualize their product, but are completely unfamiliar with how this process works. This can be a problem if a client wants absolute assurance on a project’s success, yet feel as though they are placing too much trust in our hands.
—
So we made this article to show how we get things done at Lusion.
Step by Step how it’s done:
- Mood Board and Visual References
- Concept Prototyping
- Production
1. Mood Board and Visual References
To transpire our work process into client understanding. First of all, we begin by visualizing the basic concepts of the product. We do this by producing a mood board consisting of the product’s patterns/colors/history etc. In order to define what visual style we are working towards.
Once we’ve created our mood board, we make a list of visual references that serve as our inspiration for the project. These references include images and video links of other artist’s work, which helps to get a clearer idea of what the product will look like.
In our Surface Floater, we sketched out the type of image we planned to work with. Our mood board consisted of the bear model itself, it’s color/shading and the basic geometric shapes we planned to apply. Before we could begin prototyping, a little inspiration from fellow artists was also needed.
2. Concept Prototyping
Once we have mapped out and visualized product ideas, the prototyping can commence. Here we essentially lay out the foundations of what we will be creating for our client.
This involves sketching out a visual prototype of the product. We do this by using rapid prototyping tools, for example, through Houdini FX and Cinema 4D. These tools enable us to quickly lock down the dynamic and visual properties of the product, based on the client’s data and content they provide us.
After we have a clear visual of the prototype, the technical input to the product is brought into the prototype. In this phase, we test whether the application works efficiently and attempt to locate any technical errors that are in need of adjustment. If everything goes as planned, we then move onto the actual production phase of the product.
In our Surface Floater, we visualized our basic prototype in Houdini FX. Here we were quickly able to nail down an initial visual, as you can see below:
3. Production
In the production phase, we reproduce the visual prototype in real-time based on the required platforms such as Unity, Unreal, vvvv and WebGL. In this process we will try to optimize the codes in order to make it work in real-time.
Once we are satisfied with the project’s visual, we invite our clients to view their product in real-time animation. We do this as we believe that it is important to provide transparency in our work, as it is our aim to provide the client with the most accurate portrayal of their product as requested.
If we get the ALL OK from our client, then we can pass the product over.
As was the case with the production of the Surface Floater, we had to reproduce our completed visual prototype in real-time on WebGL. Once we were 100% satisfied with the project, we shared it at a production level for the world to see.
—
Technical Bits
The following involves some technical terms and codes that we used in Surface Floater. Skip it if you are not into it.
SDF Physics
In the concept prototype, we used SDF VDB in Houdini for the physics. We will need to apply the same treatment in WebGL in order to constraint the floating blocks not leaving the surface of the bear.
In our case, we sliced the volume into a 128³ voxels and stored the SDF data into a PNG image. We used the RGB channels for the SDF gradient a.k.a the normal from the shortest distance to the surface and used the alpha channel to store the signed distance.
With this SDF information, in the WebGL, we can simply apply the inbound/outbound force to push the blocks toward the surface of the bear.
Position Based Collusion
Even with SDF Physics, it is not enough. It is because the multiple blocks will eventually go to the same positions after applying the position based Curl Noise and the SDF physics.
The obvious solution here is to apply the collusion detection on the blocks to ensure the blocks will not be overlapping after applying the Curl Noise and the SDF Physics. In Houdini, there are so many built-in collusion detection nodes for the task. However, our end goal is to make it work in real-time and those built-in nodes are either not optimized for real-time animation or they are not compatible with what we are building.
The easiest way to resolve it is to create a simple collusion detection on our own. We decided to use the same algorithm in Houdini to test it before we do any premature optimization in WebGL. In the Houdini solver, we added a Point Wrangle node and did something like this:
int closePts[] = pcfind_radius(0, "P", "pscale", 0.2, v@P, @pscale + 0.02, 2);float restitution = 0.5;if (len(closePts) > 1) {
int closePt = closePts[1];
vector closePos = point(0, "P", closePt);
float closePScale = point(0, "pscale", closePt);
float closeMass = point(0, "mass", closePt);
vector closeVel = point(0, "v", closePt);
// https://stackoverflow.com/questions/345838/ball-to-ball-collision-detection-and-handling
// get the mtd
vector delta = @P - closePos;
float d = length(delta);
// minimum translation distance to push balls apart after intersecting
vector mtd = delta * (((@pscale + closePScale)-d)/d);// resolve intersection --
// inverse mass quantities
float im1 = 1 / @mass;
float im2 = 1 / closeMass;// push-pull them apart based off their mass
@P += mtd * (im1 / (im1 + im2));
closePos = closePos - (mtd * (im2 / (im1 + im2)));
setpointattrib (0, "P", closePt, closePos);// impact speed
vector v = @v - closeVel;
float vn = dot(v, normalize(mtd));// sphere intersecting but moving away from each other already
if (vn > 0.0f) return;// collision impulse
float i = (-(1.0 + restitution) * vn) / (im1 + im2);
vector impulse = mtd * i;// change in momentum
@v += impulse * im1 * 0.5;
setpointattrib (0, "v", closePt, closeVel - impulse * im2 * 0.5);
}
It is not a physically correct collusion but it got the work done - No more overlapped blocks!!
So, we needed to move this part into WebGL. This is really challenging because the complexity of this CPU based solution is O(n²) and there is no way to pull this off using this kind of brute force calculation for 16k blocks in real-time.
Luckily, we found this data structure idea from GPU Gems 3 and we can do the collusion detection in GPU. We basically stored the indices of blocks into a 3D sliced 2D texture. In our case, we used a 64³ voxel volume for the collusion, we rendered the blocks as points and stored the 4 indices into each voxel based on the their position. In our case, we only did the collusion detection based on the same voxel rather than comparing the values with all 27 neighbor voxels to reduce the sampling count. Obviously, it is not ideal but like what we said, we are not trying to create something physically correct and the visual outcome looks somewhat acceptable so we left it here.
—
Tips
Use planning time effectively
All technical directors and digital producers should think carefully about planning prototype concepts. Whether we are dealing with a client project or an internal R&D design, we always allocate a portion of our time to brief ourselves over planning operations. As we spend most of our time in the production phase, it is essential for us to utilize this time by absorbing as many original concepts as we can.
When we were sketching up our initial concepts for the Surface Floater, we set ourselves a time to brief and discuss how we were going to visualize our prototype concept.
Learn to Give Up
It is hard to accept when something’s not working. This is especially the case when you have devoted so much time and energy into your prototype design. But more often than not, persistently working at something can be unpractical. In fact, it can sometimes even be detrimental to a project’s success.
It is then crucial to identify errors and if unfix-able, scrap it and try another approach. More often than not, we have ideas in the creative period that we wish to execute in the final production. But not all of them can be brought into the final production due to technical issues. A good technical director should be able to identify these kind of issues and be willing to make changes, before moving forward into the production phase.
In our Surface Floater, we had a number of technical problems faced in the early stages of development. For example, we had some nice melting effect on the blocks in our Houdini prototype:
We had to give up this effect in our production due to the complexity and performance issues we were facing. So, determination is great, but sacrificing initial concepts for workable changes is even greater in successful creative development.
—
About us
We are a creative production studio based in Bristol (UK), specializing in real-time motion graphics for the Web, digital installations and VR/AR applications. Founded by Edan Kwan in September 2017, Lusion are a small team of advanced digital workers working with and contributing to leading edge technology in the online creative industry.
Get in touch!
Email: hello@lusion.co
Website: https://lusion.co
Twitter: @lusionltd
