source: OGRE/trunk/ogrenew/Docs/src/vbo-update.texi @ 692

Revision 692, 5.4 KB checked in by mattausch, 19 years ago (diff)

adding ogre 1.2 and dependencies

Line 
1\input texinfo   @c -*-texinfo-*-
2@c %**start of header
3@setfilename vbo-update.info
4@settitle Hardware Buffers In OGRE
5@c %**end of header
6   
7@titlepage
8@title Geometry Changes In OGRE 0.12
9@author Steve Streeting
10@page
11@vskip 0pt plus 1filll
12Copyright @copyright{} The OGRE Team@*
13
14Permission is granted to make and distribute verbatim
15copies of this manual provided the copyright notice and
16this permission notice are preserved on all copies.
17
18Permission is granted to copy and distribute modified
19versions of this manual under the conditions for verbatim
20copying, provided that the entire resulting derived work is
21distributed under the terms of a permission notice
22identical to this one.
23@end titlepage
24
25@node Top
26@top Geometry Changes In OGRE 0.12
27This manual covers the changes which have been made in the core geometry
28and rendering operation classes in OGRE v0.12.
29
30@ifinfo
31@menu
32* Introduction::                What's all this about anyway?
33* Hardware Buffers::                            All about hardware buffers
34* Hardware Vertex Buffers::     The stuff that vertices are made of
35* Hardware Index Buffers::      Indirect rendering through indexes
36
37@detailmenu
38@end detailmenu
39@end menu
40@end ifinfo
41
42
43@node Introduction
44@chapter Introduction
45
46Geometry handling, for obvious reasons, is at the centre of any 3D engine. OGRE inherited much of its core geometry structures from a previous engine I
47designed for DirectX 6 / OpenGL, and it has worked quite well. It was based around the historical premise that applications wanted to construct a lot
48of geometry in main memory, manipulate it on the CPU, and upload it in small chunks for the hardware to process every frame. This was fine because the card
49couldn't handle enormous amounts of polys anyway, so it was up to the application to pick the most appropriate subset to upload.
50@*@*
51Times changed, however, with graphics processors beginning to have more and more of their own memory, and being able to process the transformation and lighting on the card itself, or in AGP memory, rather than main memory. This made it feasible to upload static geometry to the card and keep it there, avoiding the bandwidth requirements of the per-frame upload. The advent of vertex shaders has allowed programs to process the vertices in custom ways without having to shuffle them between main memory and the card. We'll call these GPU and AGP-based buffers 'Hardware Buffers'. We often refer to them as 'VBOs' (Vertex Buffer Objects) for speed, although the term is not exactly accurate since they can hold both vertex and index data. The use of hardware buffers can significantly improve the rendering speed of a scene, especially one with a large amount of repeating geometry or one which uses lots of multipass effects.
52
53@*@*
54So why did we wait until now? After all, the APIs have supported hardware buffers in some shape or form for some time. Well, there were a few reasons. Firstly, it's a large and disruptive change (to do it properly and use it to it's full) so we had to find time in our schedule. We worked on a separate CVS branch to avoid disturbing regular developers for some time. Secondly, it's actually only in the past 6-12 months that both APIs have exposed these functions in such a way that makes them practical to implement in a generic engine like OGRE. Whilst DirectX has had VBOs since D3D7, version 7 was so simplistic as to be almost useless, and version 8 has a serious design flaw which tied a buffer to a single vertex format, a restriction which would have crippled our design. D3D9 is the first version to have a genuinely useful VBO design. As for OpenGL, nVidia and ATI has their own, very separate extensions to the GL API to manage VBOs - these have only recently been standardised (Feb 2003) into the ARB_vertex_buffer_object extension. So we saw this as the best possible time to bring this new feature into OGRE.
55
56@section More than just hardware buffers
57Besides allowing buffers to be held on the GPU / AGP memory, we also took the opportunity to completely overhaul the way we represent geometry formats in the engine. Previously, the GeometryData and RenderOperation classes held explicit pointers to elements of the vertex, e.g. a pointer to the positions, a pointer to the normals etc. The type and format of the vertex elements was fixed (positions always had to be 3 floats for example), because that's how cards used too work. The latest generation of cards allow a lot more flexibility around what data you feed into them - for example if you like you can omit positions and generate them in the vertex shader, or use a 4D normal vector, among many other things.
58@*@*
59In addition, since hardware buffers can be very large, there is more incentive to try to reuse and share buffers between meshes, perhaps using subsets of the same buffer for different purposes, perhaps even changing vertex format half way through the buffer - this sharing can be beneficial to performance because changing the source of the 'streams' of vertex data coming into the card can be comparatively expensive.
60@*@*
61Finally, we also wanted to make it easier to switch the vertex sources used by a given piece of geometry, without changing the information held about the format of the vertex. Therefore we have the concept of buffer bindings - vertex elements (a position for example) are bound to a 'source index' which is not a pointer to a buffer, it's just an identifier. You then 'bind' this index to a real vertex buffer, and you can rebind it to another buffer if you wish later.
62@*
63
64@include vbos.inc
65
66
67@bye
Note: See TracBrowser for help on using the repository browser.