seaman: переводы
OGRE Manual / Руководство 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.
−1 Визуализация.
Окончательно получение изображения на экране - это касается низко-уровневого конца процесса визуализации, специфических API систем визуализации объектов таких как буферы, состояние визуализатора и подобных и ввода всего в процесс. Классы в подсистеме Менеджера сцены используют его ждя отображения их высоко-уровневой информации на экране.
Окончательно получение изображения на экране - это касается низко-уровневого конца процесса визуализации, специфических API систем визуализации объектов таких как буферы, состояние визуализатора и подобных и ввода всего в процесс. Классы в подсистеме Менеджера сцены используют его ждя отображения их высоко-уровневой информации на экране.
→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.
−1 Менеджер сцены.
Создержимое Вашей сцены - как она структурироавна, как выглядит из камеры и т.д. Объекты в этой области ответственны за предоставление Вам естественного декларативного интерфейса к миру, который Вы строите, т.е. Вы не говорите Ogre "установите это состояние визуализатора и затем визуализируй три полигона", Вы говорите "я хочу визуализировать объект тут, тут и тут с этим материалом на нем, визуализировать с этой точки" и позволяете ему сделать это.
Создержимое Вашей сцены - как она структурироавна, как выглядит из камеры и т.д. Объекты в этой области ответственны за предоставление Вам естественного декларативного интерфейса к миру, который Вы строите, т.е. Вы не говорите Ogre "установите это состояние визуализатора и затем визуализируй три полигона", Вы говорите "я хочу визуализировать объект тут, тут и тут с этим материалом на нем, визуализировать с этой точки" и позволяете ему сделать это.
→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 Менеджер ресурсов.
Все ресурсы необходимые для визуализации - геометрия, текстуры, шрифты, все остальное. Важно руководить загрузкой, повторным использованием и выгрузкой этих вещей осторожно, и это делает этот класс.
Все ресурсы необходимые для визуализации - геометрия, текстуры, шрифты, все остальное. Важно руководить загрузкой, повторным использованием и выгрузкой этих вещей осторожно, и это делает этот класс.
→The majority of rest of OGRE's classes fall into one of 3 roles:
0 Большинство из остальных классов 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.
−1 На самом верху диаграммы объект Root. Это точка входа в систему Ogre, и где Вы должны стремиться создать объекты верхнего уровня нужные Вам, такие как менеджер сцены, система визуализации и окно визуализации, загрузка плагинов, все фундаментальные вещи. Если Вы не знаете где начать, Root подоцдет почти для всего, хотя чаще он просто предоставляет Вам другие объекты, которые на самом деле делают всю работу, т.к. Root сам является более организатором и посредником.
→Shown below is a diagram of some of the core objects and where they 'sit' in the grand sceme of things. This is not all the classes by a long shot, just a few examples of the more more significant ones to give you an idea of how it slots together.
images/uml-overview
images/uml-overview
0 Ниже показана диаграмма некоторых объектов ядра и их расположение на общей схеме. Это вовсе не все классы, просто несколько примеров наиболее значащих, чтобы дать Вам идею их взаимодействия.
(картинка)
(картинка)
→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. ;)
−1 Ogre использует особенность C++ , называемую "Пространство имен". Это позволяет Вам размещать структуры, перечисления (enums), вообще все в определенные рамки, что является легким путем предотвращения конфликта имен, т.е. ситуации, когда имеются две вещи, названные одним именем. Т.к. Ogre был разработан для использования внутри других приложений, я хотел быть уверен что конфликт имен не будет проблемой. Некоторые люди предваряют их классы/типы коротоким кодом, т.к. некоторые компиляторы не поддерживают пространство имен, но я выбрал использование его, т.к. это "правильный" путь. Сожалею, если Вы не имеете нужного компилятора, но C++ стандарт был определен много лет назад, так что авторы компиляторов не имеют оправданий. Если Ваш компилятор не поддерживает пространство имен, то он возможно де**мо - возьмите лучший :)
→A Word About Namespaces
0 Слово о Пространстве имен.
→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 и описание для чего они используются.
→Finally, if you run OGRE in continuous rendering mode, i.e. you want to always refresh all the rendering targets as fast as possible (the norm for games and demos, but not for windowed utilities), the root object has a method called startRendering, which when called will enter a continuous rendering loop which will only end when all rendering windows are closed, or any FrameListener objects indicate that they want to stop the cycle (see below for details of FrameListener objects).
0 Окончательно, если Вы запустите Ogre в непрерывном режиме визуализации, к примеру, Вы хотите постоянно регенерировать все целевые визуализации как можно быстрее (стандарт для игр и демок, но не для оконных утилит), объект root имеет метод startRendering, который входит в непрерывный цикл визуализации при запуске, и этот цикл завершится только после закрытия всех окон визуализации, или когда любой из объектов FrameListener укажет, что он хочет остановить цикл (см. далее об объектах FrameListener).
→The root object is also your method for obtaining pointers to other objects in the system, such as the SceneManager, RenderSystem and various other resource managers. See below for details.
0 Так же объект root - это Ваш метод для получения указателей к другим объектам системы, таким как SceneManager (Диспетчер сцены), RenderSystem (Система визуализации) и различным другим диспетчеры ресурсов. Подробнее см. далее.
→The root object lets you configure the system, for example through the showConfigDialog() method which is an extremely handy method which performs all render system options detection and shows a dialog for the user to customise resolution, colour depth, full screen options etc. It also sets the options the user selects so that you can initialise the system directly afterwards.
0 Корневой объект позволяет Вам конфигурировать систему, например, через метод showConfigDialog(), являющийся очень удобным. Он позволяет задать определение всех опций системы визуализации и отображает диалог пользователя для настройки разрешения, глубины цвета, опции полноэкранного режима и т.д. Он также устанавливает набор опций пользователя, так что Вы можете инициализировать впоследствии систему напрямую.
→The 'Root' object is the entry point to the OGRE system. This object MUST be the first one to be created, and the last one to be destroyed. In the example applications I chose to make an instance of Root a member of my application object which ensured that it was created as soon as my application object was, and deleted when the application object was deleted.
0 Объект Root (Корень) является начальной точкой для системы Ogre. Этот объект должен создаваться первым и уничтожаться последним. В примерах я выбрал способ создания экземпляра класса Root как члена моего объекта приложения, что гарантирует что он будет создан при создании объекта приложения и удален при удалении объекта приложения.
Резюме
- Пол:
- мужчина
- Родной язык:
- русский
- С нами:
-
с 9 июля 2008 г.
(6675 дней)
Не является членом клуба. - Деятельность:
-
13 версий перевода
с общим рейтингом −6
Карма: 1 (оценок: 1)