Home > Buzz 3D software Technical data > New Lighting Engine

Below is an overview of the visual quality that our new lighting engine now makes possible, albeit using far more detailed 3D models.

The actual amount of detail on the sports car shown below is actually quite low, as evidenced by the lack of smooth curves around the headlights, but you can imagine how a high quality 3D model of a vehicle or other simulated 3D object will appear, which in a real-time engine would previously have been unthinkable to accomplish.

An image of a vehicle is used purely as visual clarification of what is possible,
and would apply to any 3D model

Buzz 3D is adding the following into its portfolio of capabilities:

Lighting Engine
1. Multi-texture Rendering
This allows multiple textures to be processed by the graphics card in a single frame, which delivers a performance boost and enables many advanced visuals without any drop in frame rate.  We have a target frame rate in all cases of 30 - 60fps.

2. Pixel Shader Support
Pixel shaders use the advanced capabilities of the GPU (Graphics Processing Unit) on the 3D hardware to perform mathematical manipulation of the image on the screen without involving the PC's processor.  This opens the door to the following:

a) Bump-mapping.  A flat surface consisting of only 2 polygons may be given a special image called a bump-map, which affects the way light is cast from the object, making it appear to be 'bumpy'.  Depending on the pattern of the bump-map, or whether or not the bump-map itself is animated, this can create many interesting effects, such as the surface of fabric, leather, or even just a raised emboss / deboss within a decal on the dashboard, all without actually modelling the three dimensional shape exactly.  This allows us to have smaller model files with less 'real' detail, and the graphics card puts the remaining realism in for us during runtime.

b) Normal-mapping.  This is a more advanced version of bump-mapping, which allows the surface of a simplified object to be totally warped and remodelled as seen on screen, but without this warped shape (which would otherwise have consisted of a lot of polygons) needing to be programmed.  An example of the use of this technique is in the detail of the hood / bonnet as shown on page 1 and in the higher resolution attached image.  As you can see, the vertical divider line shows the difference a normal-map makes, with the original (flat) geometry shown on the left hand side, and on the right the distortion that the normal map has achieved, not just to make a dent in the same surface, but to truly warp the surface into the desired shape.  This technique saves a LOT of model detail, allowing smaller files to be used, and improving overall performance.  For closer inspection, however, it can easily be replaced by 'real' geometry that may be viewed for close range only if the need arises.
The same difference can be seen in the floor on which the car is standing, where on the left hand side it's revealed to be flat, whereas with the normal mapping activated, a lot of detail is shown in the surface, along with reflection effects that distort in the manner one would expect.  This would also be an extremely useful and system saving feature for external environments.

c) Light Mapping / Photon Mapping.  This technique allows us to set up a form of lighting where the lighting effects can be applied to many objects, without those individual objects needing to be independently lit - a single lightmap can be applied to large areas of a scene, giving it the requisite texture of light and shade, irrespective of the amount of detail in the textures it is illuminating. There are 2 types of lightmaps - static and dynamic. Static lightmaps are typically used where there is a large amount of unchanging illumination in the scene, whereas dynamic maps are used should the scene need to be adjusted based on the position, say, of the sun if it should pass along its trajectory and ultimately illuminate a whole section of a room that was previously in shadow.  The lightmap would be dynamically altered to permit this new level of illumination to be displayed.
We will be initially focusing on static lightmapping, and developing dynamic lightmaps to follow.
One other benefit of lightmaps is that they reduce the amount of texture maps needed for the scene as a whole.  Instead of having to render large swatches of a floor area or a long wall at high resolution to preserve its detail, only the lightmap is rendered at high resolution, and the objects that the lightmap touches can utilise repeating (tiled) textures to create fine detail.
Lightmapping will be utilising 'triangle clusters' in order to determine the optimum number of lightmaps to use in a scene.

d) Real-time shadows.  Objects which move in relation to their light source require real-time shadows to be generated.  This would also be a requirement if the car headlights were turned on - the objects in front of the car as it rotated on its plinth would cast a shadow on their far side.  Shadowing will be produced in 2 stages :  Hard and Soft.  A hard shadow has a crisp, well-defined 'edge', as if cast by direct sunlight.  A soft shadow, however, has a diffuse, blurred edge and tends to look more realistic to the human eye when in a 3D world.
We will initially produce hard-edged shadows, and then further develop this system to deliver soft shadows as required by individual clients.

e) Glossiness and specularity.  This controls the amount of 'sheen' on a particular surface, allowing us to simulate surfaces such as leather, fabric, rubber, matte and gloss metals, etc.

3. Real-time lighting.  We will be introducing support for lighting so that, hand in hand with shadow generation, the lights can become animated aspects of the overall environment, making it possible to bring up or down levels of illumination, go from day to night and back again, or simulate the passage of the sun (with dynamic lightmaps if required).

4. Lens Flare.  In the same way that point-light sources can create lens-flare in the lens of a camera, this too can be simulated, lending the environment a far more cinematic feel.

5. 3D Studio Max Exporter
The Buzz 3D engine has compatibility with 3D Studio MAX scenes, since MAX is our own primary tool for model-building and animation.  Provided the artists who use MAX conform to some very simple rules, then the transition into Buzz 3D real-time display (with animation support) is a straightforward.

However, the way a dedicated rendering platform such as MAX calculates lighting is very different from the needs of a real-time renderer like Buzz.  To this end, we have written our own Buzz 3D exporter for MAX, which permits the use of our own lighting components within the MAX scene, and setting of various custom-flags which tell our lightmapper and lighting engine how to illuminate the surfaces that are exported to it.  We also have compatibility with a range of MAX material types (including nested multi-subobject materials).  Our roadmap over the coming weeks will include updates to the exporter on an as-needed basis, to permit greater compatibility with the 3DS MAX way of 'doing things' (including the use of materials blending, opacity maps, glossiness, specularity, and masks).

While the raw 3D side of things is handled by the graphics card's onboard GPU (under normal circumstances), our multi-threaded approach reveals itself whenever we do any CPU-intensive operations.  These manifest typically when displaying multimedia in 3D.  Each media 'channel' (composed of video, audio, web page data, or other independent interfaces which run on their own thread) has to be independently scaled, copied to graphics memory, posted to a 3D surface, managed for throughput and rendered on a lower priority than the user-thread so the overall frame rate of the 3D experience doesn't suffer.  Scalability is built into the system, so that if the power is there, it's used automatically.

Animation support for rigid geometry is currently in place (including camera animation), with support for skeletal (ie. parented / linked) objects and Vertex-morphing to follow once we encounter a project that requires it.

6. External Toolkit and Lightmap Generator.  This toolkit will offer a preview of the 3D world, and allow individual tweaking of lighting settings with very rapid feedback (10 - 20 seconds).  Once the entire scene is illuminated the way we wish, we can then generate export high-resolution lightmaps.

______________________________________

However, in addition to being able to simulate the photorealistic visuals applicable to the right-hand-side of the attached image, we will also have the capability of being able to render complete video sequences in ‘better than’ real-time.  These sequences could then be exported to external pre-rendered configurators, such as the type used by Flash.  This will permit a VERY large amount of video to be created in an exceptionally short timescale, suitable for use in these external configurators.

What this would make possible for Automotive or other Manufacturers requiring a single graphical resource, with all the cost savings that entails, capable of supporting both an alternative 3D presentation in addition to the Car-Configurators on their 2D web site.

Apart from the convenience and speed of effecting changes in Buzz 3D, the maths for generating the ‘movies’ works like this.

a) To use a rendering package, such as 3D Studio MAX, to generate a 3D video file ready for converting to Flash typically would take anywhere from 10 seconds to 10 minutes per frame, depending on how accurate the vehicle render needs to be.  Being conservative, let's say it takes 10 seconds per frame.  In Flash, videos typically run at 15fps, so for 1 second of video time, 15 frames must be rendered, at 10 seconds each (150 seconds = 2.5 minutes).  The videos will usually run from anywhere between 5 seconds and 20 seconds, but again being conservative let's say 5 seconds : 2.5 x 5 = 12.5 minutes to render 1 flash video.

b) In a Flash-based car configurator, there are often dozens if not hundreds of such videos, all of which are linked together in a variety of ways, and any minor change to any one aspect of a vehicle often requires an entirely new chain of videos be created to support that change.

c) Buzz typically renders 3D content at 1/60th of a second per frame.  That same Flash video running for 5 seconds would require 75 frames.  Instead of being rendered by the 3D renderer at 12.5 minutes, Buzz would be able to render that entire video in a little over 1 second.

d) As mentioned these numbers have been deliberately chosen to be conservative, but since even at these levels Buzz will offer a gain in performance in production of pre-rendered videos of 75,000%.

Therefore, since the 3D models will already be present within Buzz, AND renderable at visually acceptable quality, Buzz can be used as an engine to deliver all the Flash-based video content you would ever require, in a fraction of the time and cost of other solutions dependent upon pre-rendered video from a non-real-time system.