| Q&A |
 Leadwerks
Engine ,
Josh Klint, CEO
Leadwerks Corporation
June 2008 |
| |
 |
"
We have a really nice shadow mapping system, which gives
us dynamic soft shadowing with directional, point, and
spotlights. We also have a kind of real-time global
illumination effect called screen space ambient occlusion.
In version 2.1 of the engine we will have a cool effect
called "volumetric light scattering" better
known as "god rays" that can look really amazing.
"
<Leadwerks
2.0 in action |
|
| |
|
| Q1 |
Please
give a biref description of Leadwerks engine. |
| A1 |
I
think "real-time" is the best way to describe it.
When I saw Crytek's presentation of their editor at the Game
Developer's Conference, I knew I wanted to do an engine where
everything just worked on-the-fly. Lighting, physics, and culling
are all instantaneous, and no pre-compiled data of any kind
is used. By offloading as much as possible onto the GPU, we
greatly simplified both the engine source code, and the experience
for our end users. I think my experience with older BSP-based
engines was good training, but it is so much easier to work
with our new technology. Our main engine source code is less
than 400 kilobytes! |
| |
|
| Q2 |
Leadwerks
engine seems to support advanced visual effects and can support
terrains with up 33 million triangles. How can it be possible? |
| A2 |
 33
million triangles sounds like a lot, but it isn't that hard.
To render terrain, our engine just draws the same 128x128 patch
over and over again. Each section of terrain has its own unique
height array which gets passed to the terrain shader as a vertex
attribute. This means that a 4096x4096 terrain only uses about
33 megabytes of memory. This is a little bit different from
older approaches, and we lose the ability to do edge turning,
since the same patch is used for each section of terrain. However,
we can have a much higher polygon density now, so it isn't so
important that every edge be oriented a certain way. I've actually
gone as high as 130 million
triangles in a terrain and it rendered fine, but I can't imagine
an artist having time to design a scene of that magnitude. |
| |
|
| Q3 |
What
are the features of Leadwerks engine in terms of lighting and
shadowing? |
| A3 |
 Our
lighting system is what I am most proud of. We have a really
nice shadow mapping system, which gives us dynamic soft shadowing
with directional, point, and spotlights. We also have a kind
of real-time global illumination effect called screen space
ambient occlusion. In version 2.1 of the engine we will have
a cool effect called "volumetric light scattering"
better known as "god rays" that can look really amazing. |
| |
|
| Q4 |
How
can we import in Leadwerks characters animated in 3ds max, Maya
or XSI ? |
| A4 |
For
simple meshes, our engine loads .obj and .md3 files directly.
You can specify textures and shaders explicitly in a material
file, but if no material file is found the engine does a pretty
good job of guessing what textures and shaders to apply. For
animated meshes, you export a .b3d (Blitz3D) file and use our
converter to save a .gmf (Game Model Format) file, which supports
skinning, animation, and hierarchies. I spent a lot of time
looking for a suitable animated file format that would load
quickly to use for the engine, and I can tell you that none
exist. I was really interested in Collada for a while, but it
turned out not to be suitable for our needs. Finally, I decided
to design a file format based on how I think things should be
done, and I called it the "Game Model Format".
As a former artist turned programmer myself, I think a good
art pipeline is crucial. I am talking to Brad Bolthouse about
writing an Unwrap3D plugin for .gmf models. Unwrap3D is a little
secret of the industry that is extremely good at converting
3D models. It is primarily a UV mapping program, but features
import and export capabilities much better than Deep Exploration
or anything else, and it is very inexpensive. So if we add an
export plugin for that, then Collada, FBX, and every other file
format under the sun is supported. The next step will be specific
exporters for 3ds max, XSI, etc. |
| |
|
| Q5 |
Can
Leadwerks be used by "begining devloppers" or 3D artists? |
| A5 |
It's
one thing to implement a cool effect or design a good renderer,
but the real challenge is in building it into a system that
makes sense and is easy to use. OpenGL paradigms are messy.
My job is to make it simple without the end user losing control.
I spend a lot of time agonizing over the command set until I
find a solution I am happy with. I can say with confidence you
will not find another engine with comparable features that is
anywhere near as easy to program as ours. It's a goal I take
very personally, since I am going to be using it too.
Since there isn't much left to implement on the programming
side of things, I will soon be turning my attention to the art
pipeline. I want to add more editors and tools so that our art
pipeline is as easy to work with as the programming is. Artists
make the engine look good, so I want to keep them happy. Our
upcoming Sandbox editor is one major part of that. |
| |
|
| Q6 |
What
is the role of 3D World Studio? Can it be used with other engines
such as Ogre3D, Torque, C8. What are the feature of 3D World
Studio for terrain editing : see, trees, terrain? Is it possiblie
to get results as good as what artist can achieved with 3ds
max or Maya? |
| A6 |
 3D
World Studio is mainly a CSG editor along the lines of Hammer
or Radiant. It's designed for making buildings, not people or
cars or guns. It is very good for producing a BSP scene, and
the production time will be a lot shorter than if you were using
3ds max or something. 3D World Studio is used by many people
in conjunction with Torque, 3D Game Studio, Dark Basic, etc.
However, for Leadwerks Engine 2 I have something new "in
the werks".
Leadwerks Sandbox uses a completely new approach, kind of a
cross between Crytek's Sandbox 2 and Garry's Mod for Half-Life
2. It's a real-time editor that lets you create terrain and
place models in the scene. What's neat about this editor is
the physics editing is completely real-time. You can create
a table or something in mid-air, and it will fall to the floor
as soon as it materializes. There's an early video of the editor
here (although the interface has gotten a lot better since this
video was made):
<youtube.com>
Of course since all the lighting is real-time, you can draw
a hill on the terrain and the shadow will move as the hill grows.
It's quite strange to create a tree and see the branches waving
in the wind and self-shadowing as you move it around in the
editor. I am very excited about what this approach allows our
artists. |
| |
|
| Q7 |
What
is deferred lighting? What can it change for realtime 3D contents? |
| A7 |
Deferred
lighting is basically a way of rendering lights and shadows
in a post-processing step. Its strength is that it only processes
lighting for the final screen pixels. Therefore it will run
at the exact same speed whether there is one or one million
polygons onscreen.
Last summer we were experimenting with a deferred lighting system
using dual parabolic shadow maps for point lights, and a kind
of perspective skewing for directional lights. It was a disaster.
These techniques suffered from fundamental flaws that made it
impossible to use them in a real game. Back around February
I started playing with shadow maps again, and I got good results
using cascaded shadow maps and cube shadow maps in a forward
renderer. We released Leadwerks Engine 2.0 with the forward
renderer, but it had a few limitations. We could only have 8
lights onscreen at any given time, both due to hardware and
performance limitations. Another problem I
did not anticipate had to do with shaders. The engine would
generate a different version of each shader for the number of
lights onscreen,
resulting in tens of thousands of potential combinations that
got compiled as they were needed. It didn't turn out to be the
subtle background process I thought it would be.
These issues got me thinking again about deferred lighting,
so I devoted a week to it after the release of version 2.0.
I got it working pretty
quickly, and was amazed with the results. Not only did this
get rid of all the aforementioned problems, we gained about
a 50% performance improvement for each light onscreen. I know
Crysis uses forward lighting, and a lot of forum debates on
the subject favor forward rendering, but after trying both approaches
I won't ever use anything but deferred lighting again. The deferred
renderer will debut in version 2.1 of the engine. I thought
our results were interesting enough that I wrote a paper describing
our experience here: <PDF> |
| |
|
| Q8 |
There
have been a lot of announces the past few months about 3D acceleration
: Intel's Larabee want to bring realtime Raytracing trought
CPU, and nVidia promise to accelerate Mental Ray with the GPU.
As a 3D professionnal, what do you think about the future of
3D ? |
| A8 |
The
year 2007 was the first time we saw real-time computer graphics
that didn't suck. I mean, we can render lighting now! I know
there were some techniques like a blurry colored texture applied
to the scene (lightmaps) and ridiculous looking hard-edged shadows,
but once you start playing with a system like ours you realize
everything until now has been terrible. We used to use lightmaps,
then we used stencil shadows, now we use shadow maps. I don't
think there is a next step we will move to from here. The implementations
and some minor things will get better, but the CG film industry
uses shadow maps, so that should tell you something. When you
see
real-time graphics converging with film, that's when you know
a final optimal approach has been arrived at.
I don't think Intel is going to be able to do what they are
proposing with the Larabee chip. Some cool stuff will come out
of it, but I don't think they will produce a raytrace renderer
comparable to rasterizers. The only way to make an optimal raytrace
renderer is to use complicated scene processing tricks like
BSP trees. Now that GPU occlusion queries and deferred lighting
finally allow us to program a completely dynamic engine, with
no pre-processing or scene compilation, there's no way I will
ever go back to the days of static pre-compiled scenes. John
Carmack has talked about such a system, and it might be optimal
if you are only looking at what
takes place in parallel in the renderer, but I think you have
to consider the usability and art pipeline of an engine. No
one wants to "compile" a scene anymore. I also don't
see it as a matter of we just need so much processing horsepower,
and then we can switch to raytracing. Rasterizers will always
be exponentially faster than raytracers, so if the Larabee chip
was able to provide that much power, why not use it to make
a rasterizer that can render ten times as much geometry? That
might very well be the outcome of this. I would love to program
my own software rasterizer running on a 16-core CPU.
The GPU is becoming more and more programmable, which is a very
interesting development. I have been talking to Julio Jerez
of Newton Game Dynamics about adding GPU-accelerated physics,
in addition to the multicore-optimized processing Newton Archimedes
already allows. There are still some problems to work out because
parallelizing physics is not quite as simple as graphics
rendering. I am glad NVidia is taking responsibility to implement
PhysX on the GPU, because this will allow them to find those
barriers and solve them so we can all benefit.
There's still lots of room for improvement using shadow maps
and rasterizers. We can't render ten million triangles onscreen
at a very good framerate. We can render miles of terrain, but
we can only draw grass in the immediate area around the player.
Why should there be a limitation like that? If I had ten times
as much GPU horsepower right now, I wouldn't use different techniques,
I would just draw more stuff onscreen. So I think the current
technology is pretty stable, and very good for compatibility
with future hardware. We'll just see limitations like the number
of characters onscreen drop away, and finally be able to render
scenes that are as detailed and interesting as real life. |
| |
|
| |
|
 |
|
|
