The world of 3D graphics has recently witnessed a number of really remarkable events, namely, the first graphics chips with the integrated geometric accelerators were announced and the final version of API Direct3D 7.0 was released. In this respect we made up our mind to ask the leading Russian game developers several questions (including some really tricky ones ;-) We were lucky to catch a few representatives from the companies listed below:

• TS Group Entertainment (http://www.tsgroup-inc.com)
• Snowball Interactive (http://www.snowball.ru)
• Nival Interactive (http://www.nival.com)
• SoftLab-Nsk (http://www.softlab-nsk.com)
• Buka Entertainment (http://www.buka.ru)
• Maddox Games Development Group (http://www.maddox.aha.ru)
• K-D Lab (http://www.kdlab.com)

Q: Hello, thank you for your time and attention. Could you, please, briefly introduce yourself first and tell us about your responsibilities in the company?

TS Group: My name is Serguey Titov. I am Chief Executive Officer of TS Group Entertainment.
We have been dealing with gaming technologies since 1994 and directly with games development since 1996. Now we are working on a tactical war simulator "Private Wars" (www.privatewars.com). And my responsibilities in this company include not only administrative stuff, but also the duties of a project producer.

Snowball: Vitaly Klimov, Leading Programmer of Moscow Snowball Interactive. To my responsibilities in Snowball belongs everything connected with technology (engine & tools, some parts of concrete projects). Now our team is finishing a two-year-old "Warlord Vseslav", which found its way in the evolutionary developing technology and in terms of engine flexibility represents another step towards more professional approach to long-term gaming engine development.

Nival: Hi, my name is Yury Blazhevich. I work in Nival Interactive as Leading Programmer of "Allods 3. Redemption".

SoftLab-Nsk: I am Yury Nekrasov. I work in the position of a program-maker in SoftLab-Nsk company. Here I am responsible for proper reflection of the virtual world in our games and other systems as well.

Buka: Grigory Krasnozhenov and Evgeny Kolombet. The leaders of "Overdrive" project software part.

Maddox: Well, my name is Yury Kryachko. I am 3D programmer in Maddox Games Development Group. Our company has been developing games for over 5 years already. Among the last products we released were such 3D shooters as: "ZAR", "Madspace". At present we are working on an airsimulator "IL2-Sturmovik". The action takes place during the Second World War. This game will be developed with the latest achievements in sound, graphics, network gaming, AI and physics.

K-D Lab: Let me introduce myself. My name is Vladimir Golidnichuk, programmer at K-D Lab. I am working on the graphics engine lower level for our new project called "Mechosoma" (http://www.mechosoma.com).

Q: Not so long ago Microsoft launched its new Direct 7.0 version. What does it mean for you? Are you going to use DX7? What advantages and drawbacks could you find in DX7? Will the use of DX7 influence the gaming speeds?

TS Group: To tell the truth we believe that a more powerful and convenient geometric engine of DX7 (if compared to DX6) is the most important thing for us. From purely theoretical point of view, it may help us to increase the world detailization (the number of triangles used) in case we use it together with an on-board hardware T&L engine. However, in practice it hardly means anything at all: a lot of game developing companies have already spent so much time and effort on their own optimized T&L algorithms. That's why I really doubt if it can somehow influence the shift to DX7 before the cards with hardware T&L win at least 40% of the market.
You are asking if we are going to apply it? Well, we have been working with DX7 for a few months already. But in fact we don't make full use of all the features it provides, mainly because of the low support by the graphics cards manufacturers. The same situation happened to DX6: if you remember environment bump mapping is supported only by G400, which is quite a poor argument for it.

Snowball: At present I cannot forecast any changes because we are quite satisfied with the features provided by the current (6.1) DirectX version. In the future we will of course try those new features, which will help us to put all our ideas into life more efficiently (first of all - hardware T&L, if this thing gets widely spread in the next generation 3D accelerators).
As far as the gaming speeds are concerned, DirectX 7 will actually reward us with a performance gain only in case we utilize all its specific features, otherwise the performance will be able to get higher (or lower :-)) only due to the changes made directly to DirectX core and will tend to be quite insignificant. Among the other innovations that seem worth mentioning, I would like to point out VisualBasic support, though we can still argue whether it is an advantage or not.

Nival: First, DX7 can boast a really nicely improved D3D interface. There appeared a very good option in VertexBuffer: it is now possible to send not all the data from the buffer for rendering, but just a certain range. The absence of this option in DX6 restricted its application field. Besides, the work with lighting sources and materials as well as texture management have also been significantly improved. All this means that D3D7 is now much more convenient to work with than all its predecessors.
Speaking about the gaming speed, I would like to point out three factors, which may exert certain influence:

• VertexBuffer (after improvement it is now possible to use it in a lot of different cases);
• Automatic texture management (it is really cooler now compared to DX6);
• HW T&L support (just take a look at GeForce256 at work and you won't have any more questiuons here :-).

SoftLab-Nsk: We are going to apply DX7. I consider all the innovations not useless, to say the least of it. However, the most displeasing thing is the process of moving to a new version, because despite all the continuity, each shift still causes some unpleasant problems. Of course, the gaming performance will rise (will produce more triangles for the system to process, to be more precise) as soon as the geometric processors are widely used in graphics accelerators.

Buka: We always use the latest DX versions. As is known, DX has always provided not very fast interfaces (at least used to before). However, hardware development will one day totally eliminate this disadvantage. And compatibility will remain.
We think that compatibility is the main requirement for any contemporary software. Judging by the previous experience, we can state without a slightest doubt that the future belongs to compatible achievements. ;-)

Maddox: We have moved our graphics engine to DX7 even before its final version was released. However, we didn't and we don't have any 3D accelerator supporting all the DX7 newly introduced features, and any driver working properly without grave bugs. At present there are two most popular graphics API: D3D and OpenGL (Glide has one foot in the grave already :-)
At first we intended our game for OpenGL, which is a simpler and math1ematically more strict API working at the whole lot of different platforms. OpenGL applications debugging much rarer leads to system crashing. Hardware lighting acceleration is long supported on API level and by professional OpenGL accelerators (such as FireGL from Diamond graphics cards family). The efficiency of rendering through any API greatly depends on a number of subjective reasons: drivers quality and the necessity to optimize the engine for every graphics card. By the way, OGL drivers are the last thing to be done (Microsoft's intrigues :-)) And are optimized only for 2-3 particular games (ala Quake). If the functions are not working you cannot claim them from the driver. Direct3D provides higher performance and allows making more use of each graphics accelerator's specifics compared to OpenGL. In our IL2 project we use our own high level RenderAPI with either OpenGL or D3D.

K-D Lab: Although DX6.1 currently meets all our requirements, we will of course use DX7. The main thing is that working on this API version Microsoft almost completely rewrote their graphics pipeline having isolated it into a separate module. They also changed the drivers interface. With the older DX6 interfaces we not just lose the opportunity to use such new features as hardware T&L, but also use the old "legacy" in Direct3D run-time as well as in new DX7-compatible drivers. As a result, if the user installs DX7 and an improved DX7-compatible driver, he will not only see no performance gain, but on the contrary, will get an absolutely reversed effect. However, if you are using DX7, you can increase the performance "for free" by an ordinary driver upgrade. It is also possible to get a considerable performance increase after you upgrade your CPU to AMD K6-2 or PIII, because Direct3D will automatically enable 3DNow! and SSE T&L instructions support. The same thing refers to hardware T&L. I suppose these are pretty weighty reasons to shift to DX7, especially since this change won't bring any serious problems to our current project. We are planning to use the new features to the full extent in the near future.
As for the cons and pros, I feel like listing only positive things now:

• Hardware T&L support (higher detailization);
• Texture coordinates generation (allows effectuating a lot of interesting effects);
• Vertex Blending (provides "scanning" - for example, flexible and naturally bending arms and legs, and "morphing" - slowly and gradually changing shape of the object);
• Graphics pipeline optimized for different processors (3DNow! and SSE). Microsoft said that the specialists from Intel and AMD carried out the optimization themselves;
• Enhanced texture manager now can hand over texture operation to the driver, which theoretically is supposed to increase the gaming performance due to the use of special hardware texture operating devices;
• Much simpler API;
• Windows NT 5 support (yeah, finally! :-)

DirectX7 will undoubtedly speed up new games written especially for it. The older games using Direct3D transformations may also start performing somewhat faster due to the SIMD optimized software T&L module. However, I do not exclude that the reverse effect is also possible for some games and graphics cards, because the driver developers may sacrifice the old DX6-branches of their drivers for the sake of the new DX7 code.

Q: Very soon the market will welcome new graphics adapters with geometric coprocessors on-board, i.e. supporting hardware Transformation & Lighting (T&L). What does it mean for you? Will you take advantage of the new graphics accelerators' features?

TS Group: Of course, we will! Let me repeat once again: if the fillrate is enough to draw all the triangles T&L processor can process, everything will be just perfect. If not (as we see in case with GeForce256), then the possible profit derived from the use of T&L will be twice as low as it could actually be.

Snowball: It is still hard to say something definite. Probably we will, but the final decision will be made only in half a year, when the attitude of the industry towards this innovation becomes clear. Of course, our gaming engine will be developed so as if the changes required for hardware T&L support were minimal.

Nival: What does it mean for us? Well, just another piece of extra unscheduled work :-( However, we will use this feature: it's really attractive.

SoftLab-Nsk: It means that we can increase the amount of triangles used for the scene. Of course we can't miss this chance!

Buka: No doubt we will use T&L and all the other new graphics accelerators features if they win public acknowledgement and find wide application. It is not worth using a feature if its hardware realization is carried out only on a few graphics cards, because the number of those, who enjoy the outcome won't make up for the time and effort spend on it. That is why everything depends on the future situation in the market: whether this operation will be spread in graphics cards or not.

Maddox: It will save us 25% of all Rendering Calculations (we use our own software lighting). As a result, the number of scene polygons will grow up and the lighting will become more realistic. Besides, the general image quality will also improve due to the possibility to simultaneously use lighting and Bump.

K-D Lab: We will work with hardware T&L. In fact, the question deals not with its support realization (which is very easy to do at least in terms of "T" - transformation), but with the development of highly detailed models. Since we will still have to support graphics accelerators without T&L for quite a while, we will need a certain way of changing the detailization depending on hardware T&L support and some other factors such as processor power and SIMD-instructions (AMD 3DNow! and Intel SSE).

Q: Is it hard to add hardware T&L support into the already existing D3D games? Will you integrate this support into your own games?

TS Group: Hardware T&L support will obviously be very hard or just impossible to integrate into the already released games. Although very much depends on the engine used. If T&L model is made in a separate DLL, then it may be done with a new DX7 module and a patch.
Theoretically, it may be a way-out just to release a patch with the whole code but we really doubt if anyone will agree to it taking into account the marketing inexpediency of this move.
Our Engine is developed according to the module principle. In other words, it means that we can easily make our games support T&L or some other feature directly connected with rendering or geometric transformation.

Snowball: It entirely depends on the game, on the aims of the engine developers. That's why we can't give any univocal answer to this question. And as for the support in the previously released games, I have already answered this question above.

Nival: Speaking about the difficulties, I shall say that it has to do with the initial orientation of the game's T&L pipeline: if everything is carried out through D3D, then integrating support will require the changes of 2-20 code lines. However, if it was a separate T&L pipeline then you'll have to sweat over it for quite a while, actually.

SoftLab-Nsk: It's not a problem for our games. Yes, we will.

Buka: For those people who developed their own engines it is not hard. However, if it is pretty easy to clear everything up with Transformation, then as it comes to using someone else's lighting you may feel slightly puzzled. You can't be sure that you'll manage to make hardware realization of all the cool things you are going to do about lighting. And our plans about integrating T&L into the project we are currently working on again depend on the situation with this feature by the time it is released.

Maddox: If the game utilizes the model of vertex lighting calculations and OpenGL, then it is easy. For Direct3D we should first change to DX7 (from the older versions) and only after that we can introduce light sources into API. The lighting is calculated with the vertex normals or primitive plane. That is why some games, where the objects were not lit before, will need models modification to introduce vertex normals (can also be approximately calculated in real time).

K-D Lab: If the game uses integrated Direct3D for T&L, then you have to add just a few code lines to enable hardware T&L support. Otherwise everything depends on the engine architecture. In our project "Mechosoma" we will for sure use the hardware T&L.

Q: What do you consider the most important for today's graphics accelerators: fillrate or T&L (in terms of polygons processing)? When do you expect hardware T&L to become a must for modern mass market graphics accelerators?

TS Group: Now it is probably fillrate: almost all present games, and to be more precise, their performance, are limited exactly by this fillrate. In other words, the processor can process and transfer to the graphics card much more polygons than it is able to handle.
And mass use of T&L will probably start by the end of next year, I think.

Snowball: In my opinion, it is mostly fillrate. The new possibility to calculate T&L yourself allows creating interesting effects, which cannot be achieved with the current hardware T&L. And since the processor performance is also constantly improving and multiprocessor configurations gain more and more popularity, then I think there is no sense in making T&L dependent from the power of the integrated graphics card processor. If we assume that computer industry successfully accepts hardware T&L, then it may become a necessary requirement only in 2001, not earlier.

Nival: Maybe you mean the fillrate or triangle setup? I believe that fillrate will remain a bottleneck for a considerably long time because of a large overdraw. And if the triangle setup completely processes all the triangles coming to it from HW T&L without any delays, then what else should we need? I think that HW T&L support in games will become highly needed in half a year or in a year, whent he average amount of polygons per frame comes closer to 50,000.

SoftLab-Nsk: At present especially with the existing fillrate hardware T&L is already actual.
And for about a year or so graphics adapters without hardware T&L will still remain suitable (the matter of price).

Buka: Of course, fillrate appears more important. It is exactly the thing, any graphics accelerator should deal with and is initially designed for. It is not a secret that in serious engines the time spent on vertex lighting and transformation can hardly be compared to all other calculations (take for instance, portal technology), although we can't deny we wish we could make the hardware responsible for at least a part of calculations.

Maddox: By the spring of the year 2000 :-(((

K-D Lab: T&L. Hardware T&L allow radically improving 3D scene quality, because it appears possible to increase the number of planes used. To my mind, the available fillrate is quite enough for such today's graphics accelerators as TNT2 and Voodoo3. Besides, the fillrate utilization may be reduced by cutting down the overdraw or by setting the resolution to lower one.
I think hardware T&L will grow into a compulsory attribute of every worthy accelerator by the summer of 2000. By that time there will be launched at least 4 graphics cards with T&L on board: GeForce256, Napalm (Voodoo4?) [if 3dfx manages to remain in the market], Savage2000 and a new chip from NVIDIA. I can't imagine that any other manufacturer will dare offer a card without T&L support.

Q: What is your attitude to different bump mapping techniques? Which one will appeal to you or already does and why? Which of them will be the technique of the future?

TS Group: Before I answer your question let me make a small comment. There is a "real" bump mapping, such as the one we see in G400 (EMBM), and there is also a "fake" one based on multitexturing. So, if we are talking about the future, it will definitely belong to real bump mapping. Now its support is mostly declarative and serves marketing purposes, i.e. there are no games (except Expendable), which resort to Bump mapping to really noticeably improve the image quality.

Snowball: There is still no universal bump mapping standard. If it is worked out one day, then the game developers will breather freely. Now we consider environmental mapped bump mapping to be the most interesting for us (as in Matrox G400), especially since this technology is supported by hardware manufacturers.

Nival: As far as I understand, you mean embossing, EMBM and DOTPRODUCT3, don't you?
I exclude embossing from the very beginning for it is too heavy (it requires three complete separate passes). Let's now consider EMBM and DOTPRODUCT3. I think EMBM can boast a couple of really attractive details: it allows bending the image (to create water waves, to imitate a look through a lens, etc.), controlling specular reflection (bump + luminance texture format). But on the other hand, DOTPRODUCT3 is easier to understand and to predict and it needs no environment maps. As for the future, it will belong to the method supported by the most popular graphics accelerators in the market!

SoftLab-Nsk: The modification of texture coordinates (G400) and intensities caused by the height differences (for example, embossing) do not compete with each other, because they serve to create different effects. Embossing can be replaced with some other techniques as soon as the corresponding hardware becomes available.

Buka: No preferences. Generally, because none of the graphics cards we have at hand right now can boast hardware realization of any techniques, unfortunately. We have neither G400 nor GeForce256 :-(

Maddox: The most widely spread ones are: Embossing, NormalMaps (Dot Product), EMBM. Each of them requires some particular data and algorithms :-((( We will do our best to support them all.
Embossing is a two-pass technique (single-pass with multitexturing) with errors in case of small light angles and at edges (for example in Savage2000).
EMBM is the most beautiful of all.
DotProduct is OK as a standard solution for T&L... (GF256)
API OpenGL and D3D use vertex normals to calculate polygons lighting. Dot Product Bump Mapping is carried out with Normal Maps (textures) together with the vertex normals. IMHO is the right approach, which allows T&L module to obtain the Bump of numerous lighting sources simultaneously with only one single Normal Map.
Together with Bump we are planning to add environment Maps to our Engine as well (we already have Cube Environment for the background) to create realistic high light on various objects and water surface. Here EMBM (G400) fits best of all.

K-D Lab: We haven't yet worked with bump mapping because we had no corresponding hardware for that. I think that different techniques will coexist for quite a long time, because different tasks require different methods.

Q: What are the prospects of vertex lighting hardware calculation? Are you planning to use it or do software methods provide greater flexibility here?

TS Group: Probably they are very weak or even zero :-) the main reason that makes me say so is the fact that as a rule every company suggests its own particular way of operating lighting when developing its own engine. And I really doubt that someone may feel inclined to change the whole ideology for the sake of a few percent performance increase (take note that the processor development is also in constant progress).
The second reason is the following. Very often the developers use static lighting based on lightmaps. For example, the brick wall is in a special way covered by a second texture (usually several times smaller), which is none other than a lightmap.
Of course, this method appears either absolutely unsuitable for dynamic lighting or greatly reduces the number of dynamic light sources.
For instance, we use a combination of several methods: radiosity net, gouraud (strongly modified), and lighting maps calculated in advance basing on radiosity. Even if the graphics card lets you modify its vertex lighting algorithm we will still have another two "non-accelerated" methods left.

Snowball: The prospects? Well, probably to keep developing until it dies off as unneeded :-) or on the contrary: until it wins stable position "under the sun". Currently, hardware T&L are of course something unusual and exotic. We'll see within the next 6-8 months if they remain exotic or spread further.

Nival: HW T&L are a really good choice for many cases, but we wouldn't like to totally give up the possibility to light something "with our own hands" if necessary. We would choose HW + SW T&L. To tell the truth it seems very similar to the situation with texturing. If you need standard lighting then you'd better use HW, but for some particular special effects it would be cleverer to rely on your own hands, i.e. on the CPU.

SoftLab-Nsk: We will use hardware lighting.

Buka: We will take a look at the way this feature will be arranged. Maybe we will combine the standard hardware lighting with software special effects. At present hardware manufacturers should pay more attention to direct texture access mechanism, we think, since bump mapping, dynamic lightmaps and etc. appears inaccessible because of enormous time spent on LOCK/UNLOCK (~500,000 time steps per operation).

Maddox: In a number of games with static geometry and light sources (Quake) the lighting looks highly realistic due to lightmaps composed after a long-lasting ray (quanta) tracing. In our case it is not worth doing so, because for a landscape a gaming world is over 100x100sq.km! And for sure the same thing refers to objects with dynamic lighting! However, I think that the dynamically lit bump in our airsimulator will look much better than we could manage with a static lightmap. We also have really good vertex lighting (calculated according to OpenGL spec formulas). And the number of light sources can exceed 8 per polygon! Our model covers Ambient, Shiness, Diffuse, Specular components. Parallel and point light sources. T&L will let us shift off some calculations to the accelerator, but nothing will change visually.

K-D Lab: I suppose the prospects are rather promising. With the increased detailization (possible with the hardware T&L) we will be able to achieve higher results following our standard lighting algorithm. Especially concerning dynamic lighting. Of course, unusual effects require unusual algorithms, so I'm sure that software techniques will remain safe and sound for a long time.

Q: What do you consider most important for image quality improvement: full-scene anti-aliasing of larger amount of polygons used to create objects?

TS Group: Anti-aliasing only. And also correct focusing. In general, believe me: 3dfx knew what they did when they designed their T-Buffer.

Snowball: I think that if we correctly use a large amount of polygons the resulting effect may be more tangible than that achieved due to full scene anti-aliasing.

Nival: The latter is more important if there is HW T&L and the other option - if there isn't.

SoftLab-Nsk: It seems more logical to compare anti-aliasing not with the polygons amount increase, but with the screen resolution, i.e. in fact with the fillrate, because both of them diminish the "steps". Today's high-speed growth of the fillrate gives us to understand that pretty soon anti-aliasing will lose its significance. In the games at least with a relatively high fillrate the amount of polygons used turns out more important.

Buka: Full-scene anti-aliasing is a cool feature! In our project we have large territories full of small objects. Actually, this feature is just irreplaceable for those who deal with "long-distance views". Besides, it is really nice for borders smoothing, which act especially irritating in places of objects connection or in case some lighting errors occur. But you will anyway need to show something really close (sure, you may try to use a flying camera, though it is not always a way-out). Then it is only the amount of polygons used that matters. Moreover, as we have already said the direct task of any graphics accelerator is to draw triangles. The more it draws (the faster it draws), the better is the card. No other way.

Maddox: These are absolutely different things. But I think that the autumn graphics cards have a sufficient fillrate for 800x600x32. The amount of polygons is much more important for higher-quality surrounding objects (I get so mad about "cut" monsters and multi-polygon surfaces!).
NVIDIA is now actively promoting the use of larger amounts of polygons and as the best solution it recommends curvilinear surfaces with software tesselation. They will be tesselated by T&L module.

K-D Lab: It looks very much like a question of what is cooler: GeForce256 or Napalm. :-)... In my opinion, it is larger amount of polygons. Although in fact both of them are equally important. Aliasing grows together with the increase of the planes involved, especially in perspective. To combat it you can either use full-scene anti-aliasing or increase the resolution (utilizing fillrate). By the way, NVIDIA announced that GeForce256 supports full-scene anti-aliasing, but it won't be introduced in the first driver version.

Q: Is it possible to develop a game, so that it could adjust to different graphics accelerators, for example to improve the image quality by means of increase in polygons amount on powerful multi-pipelined ones (including those with hardware geometric pipeline support)? Or maybe something of the kind?

TS Group: Of course, it is possible. But it is not a purely hardware programming: this work mainly deals with arranging data.

Snowball: Everything is possible :-) Today there are a few technologies designed to allow something of the kind, for instance, realtime tesselation or the use of various meshes depending on the hardware. The first method requires more graphic work but is more advantageous in terms of it developing and accompanying. While the second method requires more free memory and individual handling of each mesh version.

Nival: Yes, it is. There is the whole lot of methods, such as subdivision surfaces, for instance, for polygons amount increase and LOD for its reduction. In fact, a lot of various technologies can be supported, but the expenses and time required for their realization can be too high. Finally, people buy games because they want to have fun and to play and not because they want to study the peculiarities of this or that technology.

SoftLab-Nsk: Sure, any professionally designed game simply must get adjusted to both: polygonal performance and texturing features (texture memory size and special effects).

Buka: No problem. There is a special setting in out project responsible for detailization. A lot of people know it very well and work with it. All the models are created with the maximal number of polygons, and then undergo certain software operations so that to receive copies composed of fewer polygons in the end. Manipulating with the algorithms of different coolness we may achieve almost invisible transitions between the detailization levels. (As you can see in our works, for instance). However, you can still easily distinguish between less polygonal and full models… :-)
As for the multi-pipelining, it appears possible to use not only for lightmap lighting, but also for high lights, reflections and other special effects.

Maddox: Most games, and our one as well, will have a lot of "quality <-> performance" settings. The user will be able to select those most suitable for his own accelerator (all the parameters get automatically detected as default). The options will include the parameters, which may influence geometry detailing (the number of polygons), lighting model, number of passes, etc.

K-D Lab: No doubt, it is possible. The "right" approach implies that the user gets the opportunity to decide what is prior for him: image quality or high performance by simply changing the corresponding settings. It may refer not only to object detailization (which can be done with a few different methods) but also to texture resolution, enabling/disabling various effects, etc. We are planning to use some of these features in our "Mechosoma".

Q: What do the modern graphics processors lack? What innovations can we expect within the coming half a year, one year?

TS Group: Frankly speaking, it will be what it should be: T&L, anti-aliasing.
Besides, we also wish the graphics card could boast motion blur and other custom effects hardware support. It could help the graphics to conquer another height.
Ideally, each developer wishes he had a graphics card, which required just a full scene description with all light sources, etc. to carry our lighting and transformation calculations, rendering and all other things absolutely independently. In other words, he wishes it could replace the part of gaming engine responsible for visualization and hardware effects support, so that he could focus only on gaming logic, etc.
However, this is very unlikely to happen next year :-)

Snowball: I think it is higher fillrate, because everything else can be done in software (see the example about T-Buffer), if you are not too lazy of course. As for me, it is not a very good idea to invent another algorithm, to stuff it into hardware and then to try winning the competition with its help.

Nival: I think that the following items are missing:
In 2D:

• Blit with alpha channel.

In 3D:

• Bezier surfaces and subdivision surfaces;
• Hardware shadow calculation (at least one light source) can be carried out through shadow buffer (scene z-buffer from the point of view of light source with further recalculation for each pixel: pretty heavy but absolutely universal).

SoftLab-Nsk: It could be not bad actually, if the automatic texturing in DX7 were somewhat broader. The integrated spline triangulation is already not enough. It could be just perfect in hardware. Ground-fog could also appear very helpful. Particle system is already possible: it's high time it was supported. Next half a year - next year they will introduce mostly the features declared in DX7, such as hardware T&L, bump and multitexturing.

Buka: The performance is insufficient. They could have drawn the polygons a bit faster, actually. Besides, the textures are also processed too slowly. 24-bit Z-buffer is absent even in fresh new graphics accelerators. (Savage4, though they added it in the last driver version). And the scenes with a lot of triangles can't be sorted because their amount grows not linearly. We are looking forward to GeForce256.
Come what may! We don't know ;-)

Maddox: In our engine Lighting module is also responsible for shadows calculation. There are only two types of shadows right now we use: Projective and ShadowVolume. The latter doesn't work on TNT in terms of polygon amount and fillrate (this is one of the most honest versions, which includes the shadows of each object over itself and over other ones and requires the double redrawing of the scene: lit and in shadow). Unfortunately, T&L doesn't speed up the drawing at all :-((( But even if this support appears it is still unclear if the accelerator will draw washed out shadows generated by several light sources simultaneously without any performance drops. So, the polygon lighting model still has room for further development.
The increased geometric processing capacities while the bus bandwidth remains low (vertexes and textures data is submitted through AGP) will result into primitives with non-planar geometry. In the nearest future we expect curvilinear surfaces. Complex objects will require less data, which will significantly reduce the bus utilization. Curvilinear surfaces will be tesselated and dynamically lit by a new T&L version depending on the required detailization level. So, the final amount of polygons will get tens of times higher (for example, Playstation 2). Now the manufacturers are trying to use one of the types of curvilinear surfaces - NURBS. They are most likely to be accelerated.
Then in 2-3 years we may receive height maps support: textures will contain also the value showing the distance (height) between the point and the primitive plane. This can be regarded as a further Bump mapping development though with real bump geometry (bump is absolutely flat). Besides, the growth of the on-board memory of the graphics accelerator may call out voxels of the objects defined with voxels in a 3D parallelepiped. They can help to model complicated natural things: fire, clouds, trees with tiny leaves, grass, waterfall drops. They can be also correctly destroyed (broken). A voxel brick wall will contain separate bricks, a voxel monster or robot will contain life-support systems. And Quake5 will be the best anatomy manual. :-)
Initially, the rendering of complex primitives will be carried out with a stupid division into simple triangles. Later on they will be drawn directly. To decrease the fillrate and to improve realism we will need to resort to hardware light ray (quanta) tracing.
In the happy future :-) such API as Sound, Graphics and Physics may merge together into one single thing. And the modeler will have to define sound and physical parameters of the materials and objects. The graphics part will be in charge of rendering (ray tracing with reflection, refraction and consumption). The sound part will trace the sound wave fronts according to the created geometry. The physical part will work on the interactions between the object and the environment basing on the same initial data.
Can't wait to see all this :-)

K-D Lab: There are such beautiful cards as V2x00 from Rendition, which include a programmable RISC-processor. The developer can load the microcode directly into the graphics accelerator and run it as any other subprogram. The chance to program the graphics card on the microcode level provides absolutely unprecedented opportunities. Realtime Particle systems, voxel output, procedure textures, - these are just several examples. To our great disappointment Rendition cards were not a commercial success that is why the development of some particular effects directly for this graphics card is not justified. The graphics accelerator of my dreams is something like GeForce256 with the integrated RISC-processor, where via special software you could flexibly operate the internal graphics pipeline, generate textures on the fly, superpose post-processes over the created images in the frame buffer, etc.
On the other hand, we need standardization and stability, reliable and universal API. DirectX is still pretty far from it because this industrial branch develops too fast. However, the latest DirectX version proves that Microsoft has chosen the right direction.

Q: Well, did we miss anything out? We are ready to accept your questions and answers to them as well :-)

SoftLab-Nsk: A possible question: what is your attitude to geometric blending?
Answer: In case of hardware T&L it is very promising, otherwise, it may be much cheaper to do with our own means.

Q: Thank you very much once again for such detailed and reasonable answers!

We are planning to update this interview later when we receive answers from a few other Russian companies.
We hope that the developers won't mind us bothering them with questions later. That is why feel free to send us your questions: you will probably get the response.