Low Poly Modelling for PV3D
One of the key areas of our new site is the featured work slot on the home page. To showcase our most recent project for Virgin Media we decided to produce an interactive 3D phone, using PaperVision3D, a short video of the application, and a phone model produced in Cinema 4D.
And so began a long period of experimentation. Having not used PV3D with models before (previous projects had been produced through crafty combinations of the inbuilt primitives rather than importing models), we were unsure where to pitch the level of model complexity vs Flash responsiveness in order to get the best user experience. Very soon it became clear that the simpler the model and the more responsive the Flash the better, even if the model suffered slightly because of it. We also learnt that with a smart combination of pre-baked lighting on the more complex parts of the model, and dynamic lighting in PV3D on simpler parts, you can create a very immersive experience with as little processor drain as possible.
Proof Of Concept Model – 503 Polys
Before we got stuck in and started modelling, we needed to make sure that what we wanted to do was feasible and responded well enough to give a decent user experience. Our first proof of concept model doesn’t really resemble a phone too much, but it was good enough to get a feel for performance. We decided to bite the bullet and go straight for a fully PV3D shaded test, to see if we could get away with real-time lighting.
You might be able to make out in the top left hand corner of the Flash screenshot that we’re pulling about 15 FPS using this model. Bearing in mind that this is fully lit in PV3D with gouraud shading, that’s not half bad.
First Model – 10594 Polys
Having become slightly gung-ho about the whole thing following the successful proof of concept, we threw everything we had at it and went for an ultra-detailed model, to discover where the performance/detail split was. 10594 polys is a lot for a PV3D model. We discovered this very quickly:
This test was coming in at 4 FPS. This definitely wasn’t going to be much fun for anyone to play around with. You can also see that PaperVision3D is having a really hard time z sorting all of those polygons, and there are some serious z fighting issues. Out of interest, we tried disabling the shading to see what element of the processing was going on shading vs simply drawing the model:
Only a 2 FPS increase, so it’s back to the drawing modelling board.
Second Model – 5460 Polys
If we halve the number of polys, will we double the performance? Nearly:
Taking the poly count down to roughly half increased the FPS from 4 to 7. Not a massive leap, but definitely encouraging. After reviewing our model, it became clear that we were using a lot of unnecessary polys to draw flat planes for the screen, and we had also detailed the back of the phone, when in practice, the user would only ever see the front. Here you can see we’re using 800 polygons to draw the flat screen area:
So it was clear we had a lot of room for optimisation, and we still needed to sort out those z fighting issues. On to the next model…
Third Model – 2228 Polys
With this model, we started thinking a little differently. By removing the flat front plane from the 3D model and drawing it as a primitive in Actionscript, we could reduce the number of polys and also render the primitive plane and 3D model surround on separate Viewport Layers, which should sort out our z fighting. We also removed all of the parts of the model which the user wouldn’t see, which reduced our model to a thin slice of the front of the phone:
With the FPS now back up to 10, we’re starting to make some progress. It was clear that we needed to be quite brutal with our modelling in order to get decent performance, and a quick test with a colour material rather than gouraud shading showed that we could save some more processor cycles by being smarter with our shading:
Fourth Model – 1298 Polys
We recreated the model from scratch and rethought the lighting. By baking the lights in Cinema 4D into the texture and using it as a Bitmap Material in PV3D, we could get some nice looking lighting without wasting processor cycles. In order to keep the feeling of dynamic lighting however, we kept the flat primitive plane on the front of the phone lit real-time with gouraud shading. This gave us a happy medium – performant code and a decent looking model:
We were really happy with this result, the model looks great and we’re up to 17 FPS, which is quicker than our original proof of concept. The moral of the story? Keep the poly count as low as possible. The difference between modelling for real-time 3D in Flash and prerendered 3D for video is huge, and takes a bit of getting used to. However, with the right approach, you can get something which looks performs well and looks even better.