jfox: переводы
OGRE Manual / Руководство OGRE
→At the very top of the diagram is the Root object. This is your 'way in' to the OGRE system, and it's where you tend to create the top-level objects that you need to deal with, like scene managers, rendering systems and render windows, loading plugins, all the fundamental stuff. If you don't know where to start, Root is it for almost everything, although often it will just give you another object which will actually do the detail work, since Root itself is more of an organiser and facilitator object.
0 На самом верху диаграммы расположен объект root (корень). Это Ваш вход в систему, и это здесь Вам следует стремиться создавать объекты верхнего уровня, которые Вам понадобятся, такие как менеджеры сцен, системы и окна визуализации, загрузка плагинов, все фундаментальное. Если не знаете, где начать, root подойдет почти для всего, хотя обычно это всего лишь даст Вам новый объект, который и будет выполнять указанную работу, а root в большей степени организатор и посредник.
→You'll notice that scattered around the edge are a number of plugins. OGRE is designed to be extended, and plugins are the usual way to go about it. Many of the classes in OGRE can be subclassed and extended, whether it's changing the scene organisation through a custom SceneManager, adding a new render system implementation (e.g. Direct3D or OpenGL), or providing a way to load resources from another source (say from a web location or a database). Again this is just a small smattering of the kinds of things plugins can do, but as you can see they can plug in to almost any aspect of the system. This way, OGRE isn't just a solution for one narrowly defined problem, it can extend to pretty much anything you need it to do.
0 Вы заметите, что тут разбросана уйма плагинов. OGRE разработан расширяемым, а плагины - обычный путь расширяемости. Многие классы OGRE могут быть дополнены подклассами и расширены, как то организация сцены с использованием специального менеджера сцен, добавление новой реализации системы визуализации (например, Direct3D или OpenGL), или предоставление возможности загрузки ресурсов из другого источника (скажем, из Интернета или базы данных)/ Опять же это лишь малая часть того, что могут дать плагины, но как Вы видите, они могут быть подключены почти к любому аспекту системы. Таким образом, OGRE не является решением какой-то одной четко поставленной задачи, его можно расширить и приспособить к любым Вашим нуждам.
→Rendering
Finally, there's getting the visuals on the screen - this is about the lower-level end of the rendering pipeline, the specific rendering system API objects like buffers, render states and the like and pushing it all down the pipeline. Classes in the Scene Management subsystem use this to get their higher-level scene information onto the screen.
Finally, there's getting the visuals on the screen - this is about the lower-level end of the rendering pipeline, the specific rendering system API objects like buffers, render states and the like and pushing it all down the pipeline. Classes in the Scene Management subsystem use this to get their higher-level scene information onto the screen.
0 Визуализация
Ну и наконец, здесь мы получаем картинку на экране. Тут содержатся нижний уровень конвейера визуализации, характерные объекты API системы визуализации, такие как буферы, состояния визуализации и модуль, направляющий все это на конвейер. Классы подсистемы управлениями сценами используют функции этого модуля для доставки их высокоуровневой информации о сцене на экран.
Ну и наконец, здесь мы получаем картинку на экране. Тут содержатся нижний уровень конвейера визуализации, характерные объекты API системы визуализации, такие как буферы, состояния визуализации и модуль, направляющий все это на конвейер. Классы подсистемы управлениями сценами используют функции этого модуля для доставки их высокоуровневой информации о сцене на экран.
→Resource Management
All rendering needs resources, whether it's geometry, textures, fonts, whatever. It's important to manage the loading, re-use and unloading of these things carefully, so that's what classes in this area do.
All rendering needs resources, whether it's geometry, textures, fonts, whatever. It's important to manage the loading, re-use and unloading of these things carefully, so that's what classes in this area do.
1 Управление ресурсами
Любой визуализации нужны ресурсы, будь то геометрия, текстуры, шрифты или что-то иное. Важно управлять загрузкой, повторным использованием и выгрузкой всех этих объектов с должным вниманием, чем и занимаются классы в этой области.
Любой визуализации нужны ресурсы, будь то геометрия, текстуры, шрифты или что-то иное. Важно управлять загрузкой, повторным использованием и выгрузкой всех этих объектов с должным вниманием, чем и занимаются классы в этой области.
→Scene Management
This is about the contents of your scene, how it's structured, how it's viewed from cameras, etc. Objects in this area are responsible for giving you a natural declarative interface to the world you're building; ie you don't tell OGRE "set these render states and then render 3 polygons", you tell it "I want an object here, here and here, with these materials on them, rendered from this view", and let it get on with it.
This is about the contents of your scene, how it's structured, how it's viewed from cameras, etc. Objects in this area are responsible for giving you a natural declarative interface to the world you're building; ie you don't tell OGRE "set these render states and then render 3 polygons", you tell it "I want an object here, here and here, with these materials on them, rendered from this view", and let it get on with it.
0 Управление сценой
Описание содержимого Вашей сцены, её структуры, отображение через камеры и т.д. Объекты этой области призваны предоставить Вам естественный интерфейс объявлений для создаваемого Вами мира. Только Вы говорите OGRE не: "Выставь вот такие состояния визуализации и отобрази три полигона.", а говорите: "Хочу объект тут, там и вот здесь, с такими-то текстурами, отобразить вот с этого места." и даете команду на выполнение.
Описание содержимого Вашей сцены, её структуры, отображение через камеры и т.д. Объекты этой области призваны предоставить Вам естественный интерфейс объявлений для создаваемого Вами мира. Только Вы говорите OGRE не: "Выставь вот такие состояния визуализации и отобрази три полигона.", а говорите: "Хочу объект тут, там и вот здесь, с такими-то текстурами, отобразить вот с этого места." и даете команду на выполнение.
→OGRE uses a C++ feature called namespaces. This lets you put classes, enums, structures, anything really within a 'namespace' scope which is an easy way to prevent name clashes, i.e. situations where you have 2 things called the same thing. Since OGRE is designed to be used inside other applications, I wanted to be sure that name clashes would not be a problem. Some people prefix their classes/types with a short code because some compilers don't support namespaces, but I chose to use them because they are the 'right' way to do it. Sorry if you have a non-compliant compiler, but hey, the C++ standard has been defined for years, so compiler writers really have no excuse anymore. If your compiler doesn't support namespaces then it's probably because it's sh*t - get a better one. ;)
0 OGRE использует характерную черту с++, называемую пространством имен. Оно позволяет разместить классы, перечисления, структуры, все что в принципе вписывается в область пространства имен. А это кратчайший путь к предотвращению конфликта имен, т.е. ситуации, когда два объекта называются одинаково. Учитавая, что OGRE был разработан для использования внутри других приложений, я хотел быть уверен, что проблемы конфликта имен не возникнет. Некоторые используют префиксы в именах своих классов потому, что есть компиляторы, не поддерживающие пространство имен, но я решил его применить, так как это правильнее. Сожалею, если у Вас такой непослушнай компилятор, но ребята... Стандарт языка был определен в течении многих лет, так что создателям компиляторов нечем оправдаться. Если Ваш компилятор не поддерживает пространство имен, то скорее всего он дерьмовый. Возьмите какой-нибудь по-лучше. :wink:
→Overview from 10,000 feet
−1 Взгляд через 3000 метров
→OGRE's object-oriented nature makes all this possible. Currently OGRE runs on Windows, Linux and Mac OSX using plugins to drive the underlying rendering API (currently Direct3D or OpenGL). Applications use OGRE at the abstract level, thus ensuring that they automatically operate on all platforms and rendering subsystems that OGRE provides without any need for platform or API specific code.
1 Объектно-ориентированная основа OGRE делает все это возможным. На данный момент OGRE работает под Windows, Linux и Mac OS X (с плагинами, позволяющими использовать API визуализации, Direct3D или OpenGL). Приложения используют OGRE на абстрактном уровне, таким образом гарантируя, что они автоматически работают на всех платформах и подсистемах, которые поддерживают OGRE, без использования какого-либо специфичного кода для конкретной API или платформы.
→Similarly the 'SceneManager' class looks after the arrangement of objects in the scene and their rendering sequence. Applications only have to use this interface, but there is a 'BspSceneManager' class which optimises the scene management for indoor levels, meaning you get both performance and an easy to learn interface. All applications have to do is hint about the kind of scene they will be creating and let OGRE choose the most appropriate implementation - this is covered in a later tutorial.
0 Подобным образом класс SceneManager заботится о согласовании объектов сцены и последовательности их реализации. Приложению следует использовать только этот интерфейс, но существует класс BspSceneManager, который оптимизирует управление сценой внутренних уровней, это значит, Вы получаете два производительных и простых интерфейса. Все преложения должны использовать эту особенность в зависимости от типа сцены и позволять OGRE более предпочтительную реализацию. Эту темы мы развернем в последующих главах.
→A Word About Namespaces
2 Немного о пространстве имен
→This tutorial gives you a quick summary of the core objects that you will use in OGRE and what they are used for.
1 Это пособие дает Вам краткий обзор объектов ядра OGRE и их назначение.
→Therefore all the 'visible' parts of OGRE are completely independent of platform, 3D API and scene type. There are no dependencies on Windows types, no assumptions about the type of scene you are creating, and the principles of the 3D aspects are based on core maths texts rather than one particular API implementation.
0 Следовательно, все "видимые" части OGRE никак не зависят от платформы, трехмерного API и типа сцены. Нет никаких зависимостей ни от версии Windows, ни типа сцены, которую Вы создаете, и принципы трехмерных аспектов основаны на едином математическом ядре, а не на специфическом выполнении API.
→This means every class, type etc should be prefixed with 'Ogre::', e.g. 'Ogre::Camera', 'Ogre::Vector3' etc which means if elsewhere in your application you have used a Vector3 type you won't get name clashes. To avoid lots of extra typing you can add a 'using namespace Ogre;' statement to your code which means you don't have to type the 'Ogre::' prefix unless there is ambiguity (in the situation where you have another definition with the same name).
0 Каждый класс или тип должен содержать префикс Orge::, например, Orge::Camera, Orge::Vector3 и так далее, это значит, что если где-то в вашем приложении вам потребуется тип Vector3, конфликт имён не возникнет. Чтобы не печатать лишнего кода, можете добавить объявление use namespace Ogre::, тогда Вам будет не нужно набирать прификс, за исключением двусмысленных ситуаций, когда имеется другое описание с таким же именем.
→For example, there is a 'Win32Window' class which handles all the details about rendering windows on a Win32 platform - however the application designer only has to manipulate it via the superclass interface 'RenderWindow', which will be the same across all platforms.
0 Вот например, класс Win32Window, объединяющий все детали отображения окон на платформе Win32. Однако, же разработчик приложения может манипулирувать окнами только через интерфейс базового класса RenderWindow, который будет единым во всех платформах.
→Now of course somewhere OGRE has to get down to the nitty-gritty of the specifics of the platform, API and scene, but it does this in subclasses specially designed for the environment in question, but which still expose the same interface as the abstract versions.
0 Где-то, конечно, OGRE опустился до будничных особенностей платформ, API и сцен, но эти подклассы разработаны для решения определенных задач, при этом демонстрируют однотипный интерфейс и абстракцию.
→I wanted to do more than create a 3D engine that ran on one 3D API, on one platform, with one type of scene (indoor levels are most popular). I wanted OGRE to be able to extend to any kind of scene (but yet still implement scene-specific optimisations under the surface), any platform and any 3D API.
1 Я хотел большего, чем просто создать трехмерный движок, работающий на одном 3D API и одной платформе с однотипными сценами (внутренние уровни наиболее популярны). Мне хотелось, чтобы OGRE позволял реализовать любую сцену (но и позволял реализовать скрытую оптимизацию, специфичную для каждой сцены) и работал под любой платформой и трехмерным API.
→Material scripts are loaded when resource groups are initialised: OGRE looks in all resource locations associated with the group (see Root::addResourceLocation) for files with the '.material' extension and parses them. If you want to parse files manually, use MaterialSerializer::parseScript.
0 Скрипты материалов загружаются после инициализации ресурсных групп. OGRE ищет файлы с расширением .material во всех местах ресурсов, ассоциированных с группой, а потом анализирует их. Если нужно проанализировать файлы вручную, используйте MaterialSerializer::parseScript
→Material scripts offer you the ability to define complex materials in a script which can be reused easily. Whilst you could set up all materials for a scene in code using the methods of the Material and TextureLayer classes, in practice it's a bit unwieldy. Instead you can store material definitions in text files which can then be loaded whenever required.
0 Скрипты материалов дают возможность задавать множество материалов, которые просто использовать в дальнейшем. В принципе, вы можете настроить все материалы сцены в коде, используя методы классов Material и TextureLayer. На практике, это слишком громоздко. Вместо этого вы можете хранить определения материалов в текстовых файлах, подгружая их при необходимости.
→NOTE: ':' is the delimiter for specifying material copy in the script so it can't be used as part of the material name.
0 Замечание. Двоеточие является разделителем при описании копии материала, поэтому его нельзя использовать при именовании материалов.
→Every material in the script must be given a name, which is the line 'material <blah>' before the first opening '{'. This name must be globally unique. It can include path characters (as in the example) to logically divide up your materials, and also to avoid duplicate names, but the engine does not treat the name as hierarchical, just as a string.
0 Каждому материалу в скрипте должно быть дано имя в строке "material <такой-то>" до открытия первой фигурной скобки. Это имя должно быть глобально уникальным, оно может включать символы пути (как в примере) для логического разделения материалов, а так же для избежания повторения имен. При этом движок не рассматривает их как иерархию, только как строку
Резюме
- Пол:
- мужчина
- Родной язык:
- русский
- С нами:
-
с 7 июля 2008 г.
(6677 дней)
Не является членом клуба. - Деятельность:
-
54 версии перевода
с общим рейтингом 9
14 комментариев
Карма: 1 (оценок: 1)