New Features and improvements of ogre 1.7.0 RC1

Address: http://blog.csdn.net/miaolinvip/archive/2010/01/08/5158979.aspx

[Translation] ogre 1.7.0 RC1 [deflator -- ktug] has been released!

We said we 'd try to get this out before the end of the year, and with only hours to spare we just about made it! Ogre 1.7 has been under development for over a year now, and the time has come to draw a line under it and get it shipped as a brand new stable version. unlike the maintenance releases we 've been issuing regularly for 1.6, this release already des a huge number of new features and enhancements, of which the headliners are listed after the jump.Edit:I forgot to mention that this release makes official our transition to the MIT license-we 've been using it in subversion for a while so it slipped my mind that this is the first 'official' release under that license. so that's news!

As usual, plenty of people have been testing it direct from subversion for a while now, but even so we're re issuing it as a release candidate to begin. due to time constraints, we're also only issuing this as a source release for the moment-prebuilt sdks will follow in a second release candidate or the final.

For those of you using subversion, the new path for ogre 1.7 is now https://svn.ogre3d.org/svnroot/ogre/branches/v1-7. Otherwise, you can find the new release on the source Downloads page.

Happy New Year!

Here are some of the main new features and enhancements you'll find in ogre 1.7:

We once said that we would try to release this version before the end of the year. We just finished it in the last few hours! Now Ogre 1.7 has been developed for a year and is a stable version of a brand new baseline. Unlike the 1.6 maintenance version we have released on a regular basis, this release contains a large number of new features and improvements that have been listed after these titles. Edit: I forgot to mention that this official release has transformed us into using the MIT license agreement-we have been using it on SVN for a while, because I forgot it at the time, it was the first time "officially" to be published using this protocol. So it's news ..!

Generally, many people have been testing it directly from SVN for a while, but even so, we should first release it to the candidate. Due to time constraints, we can only release one source code version at the moment. The SDK will be released immediately after the second candidate or the final release.

If you are using SVN, the new path of ogre1.7 is.

Happy New Year!

Here are some of the major new features and improvements you will find in ogre 1.7:

Due to time constraints (now available ~~~), The subsequent content will be repeated later.

//////////////////////////////////////// /// // 2010.1.9 ////////////// //////////////////////////////////////// ////////

License changes

• Ogre 1.7 is now released under the MIT license

License changes:

Ogre 1.7 is now published in accordance with the terms of the MIT license.

Compositor changes

• Allow 'pooled 'compositor surfaces.
  • Separate compositor instances using the same size & format surfaces can share them, saving memory
  • System detects the compositor instance chaining to avoid problems with interdependence
  • 'Pooled 'has to be explicitly enabled on Texture definitions, it is not the default because once enabled you cannot necessarily rely on being able to see all the intermediate texture results (because they can be Ping-ponging loss SS shared textures ); people may be relying on this

Synthesizer changes:

· Allows the "Pooles" synthesizer surface.

Different synthesizer instances can share the same size and format, thus saving memory.

The system detects this synthesizer instance chain to avoid mutual dependency issues.

The "Pooles" attribute must be explicitly activated when the texture is defined. It is not activated by default, because once it is activated, you cannot expect to see all the intermediate texture results. (Because they can be cross-shared textures); some may depend on this.

• Manual switching between supported compositor techniques is now possible on the fly
  • Compositor extends can now have 'scheme 'names, You can manually switch between supported ususing the scheme name to drop to different approaches for reasons other than hardware compatibility (performance, alternative tweaks etc)
  • You can keep & share the textures used by previusly active techniques so switching back & forth is faster (must use 'poold' option for this ).

· Now we can manually switch two synthesizer technologies at runtime.

The synthesizer technology now has a composite name of 'scheme '. You can manually switch two supported technologies and use this scheme name to save a variety of methods, unless you want to make a choice for hardware compatibility (performance, it is very difficult ).

You can save and share the used texture through the previously activated technology, so restoring or moving forward will be faster than before. (For this feature, you must use the "pooled" option)

• Compositors can-now specify if they don't want to inherit the fsaa setting from the main target for texture definitions ('no _ fsaa ')

If they do not want to inherit this fsaa setting from the main target, the synthesizer can now explicitly specify the texture as 'no _ fsaa '.

• Compositors can now turn on sRGB gamma conversion per texture definition instead of just inheriting from the main surface ('Gamma ')

  The synthesizer can now enable the "texture-by-texture sRGB gamma conversion (gamma)" function to replace methods inherited only from the main surface.

• Cross-compositor communication (from soc2009 compositor)
  • Define a texture as accessible from other locations by the chain_scope or global_scope Directive in the texture Definition
  • Reference a texture from a different compositor in the chain (or in general) using the texture_ref Directive

Cross-communication between synthesizer (from the 2009 Summer code contest)
Define a texture that is easily obtained from other locations. You can use this formal texture to define chain_scope or global_scope.
You can use the texture_ref command to reference a texture from a different synthesizer in the same chain (or in general purpose.

• Compositor <-> code connection improvements (from soc2009 compositor)
  • It is now possible to define a custom composition pass (instead of just quad/scene/clear) in code and trigger it using the render_custom composition pass type.
  • You can now link between a compositor and related code (for example, a compositor listener) automatically using compositorlogics.

Improvement of the connection between synthesizer and code (from the 2009 Summer code competition)

It can now define a custom synthesizer pass (not just quad/scene/clear) in the Code and trigger. It uses the render_custom pass type.
Now you can connect a synthesizer with the relevant code. It can automatically use the synthesizer logic (for example, a compositor listener ).

 

 

Scenemanager changes(From soc2009 compositor)

• It is now possible to pause a frame's rendering mid-way (for example, during a callback called in the middle of the process) to trigger a side render and then resume rendering. see scenemanager ::_ pauseframe and scenemanager ::_ resumeframe.
• Added an option to manually trigger the updating of shadow textures for specific lights. See scenemanager: prepareshadowtextures. The combination of the two new additions allow reusing a single texture for multiple shadowmaps.

Scenario manager change (from 2009 Summer code contest)

It can now pause the rendering of a frame in the middle (for example, the callback period in the middle of a process) to trigger a side rendering and then start rendering again. For details, see scenemanager ::_ pauseframe and scenemanager ::_ resumeframe.

Add an additional option to manually trigger the update of this shadow post image to the specified illumination. For details, see scenemanager: prepareshadowtextures. The combination of the two new features allows you to reuse a texture for Multiple shadows.

New sample Browser(From soc2009_samples)

• Instead of eclipseparate demos, we now have one integrated Sample Browser
• Samples are pluggable libraries that can be reloaded at runtime without restarting the browser
• A simple 'array' system is used to make sample GUI controls easy to create

Example browser of the new addition (from the 2009 Summer code contest)
Instead of many different demos, we now have a complete example Browser
Examples are pluggable libraries that can be reloaded at runtime without restarting the browser.
A simple turntable system is a simple interface control used to create an example.

Antialising changes

• Support for coverage sampled AA (csaa)-DX9 & dx10 only for now
• Uniied & Simplified AA settings
  • On Root's config options the setting is now called 'fsaa 'in all cases, and consist of samples and a hint string (separated by spaces)
  • On the miscparams to createrenderwindow you can supply 'fsaa 'and 'fsaahint'. The former is the number of samples, the latter any hinting (e.g. 'quality ')

Anti-aliasing changes
Csaa is supported. Currently, it can only be used in DX9 or dx10.
Standard or simplified anti-tooth setting
In all cases, the root configuration option is currently called 'fsaa 'and consists of a sampling method and a prompt string (separated by spaces)
On the miscparams parameter of createrenderwindow, you can provide the "fsaa" and "fsaahint" parameters. The former is a multiple of the sampling, and the latter is a number of prompts (quality)

Light changes

• Near/far plane settings for shadow cameras can now be manually configured per light if required
• You can now mask lights out per object by calling movableobject :: setlightmask-A renderable object's mask is bitwise AND 'ed with the Light's mask and the light is excluded if the result is 0.

Illumination change
You can now manually configure the face setting of the Shadow camera for each light, if needed.
Now you can call movableobject: setlightmask to cover the light. The mask of a rendered object is a bit-by-bit relationship with the mask of the light. If the result is 0, this light is excluded.

SlS changes(From soc2008_fine)

• No longer has to use distance as a metric for changing
• Lodstrategy can now be set on both material and mesh, to either distance or pixelcount (new strategies can also be added)

STL container changes

• All STL containers now use custom memory allocators

Changes to the level of detail
The distance in meters is no longer used to change the level of the level.
Currently, you can set the texture and grid based on the DLE policy. pixel counting is not based on distance. (New policies can also be added)

STL container
All STL containers now use a custom memory distributor.

Optimisations

• Fixed-function light state is now handled more intelligently, leading to better performance with large numbers of Objects
• Shader parameters are now updated more selectively, unnecessary updates

Optimization
The illumination state of a fixed pipeline is now processed smarter, resulting in better performance when the number of objects is large.
Updating the color filter parameters is now more selective, reducing unnecessary updates.

Gpuprogramparameters changes

• Support added for shared parameter sets which allow you to define/update shader variables for your programs and materials in one place. See gpuprogrammanager: createsharedparamerers
• Use shared_params, shared_param_named and shared_params_ref in scripts to define and reference shared parameter sets.
• Parameters are now automatically migrated when the program they are based on is changed and reloaded; any parameters which still apply are merged into the new parameters

Changes in GPU program parameters (this translation may be incorrect)
Added support for the shared parameter set, allowing you to define/update the shader variable for the sake of many programs and materials that come together. For more information, see

Gpuprogrammanager: createsharedparamerers.
Use shared_params, shared_param_named, and shared_params_ref to define and reference the shared parameter set in the script.
Parameters are automatically migrated. When the program is changed and reloaded, some parameters are merged into the new parameters.

 

Archive changes

• Archive Now supports create and remove of files (filesystem only implemented for now)

File changes
Files now support creating and removing folders (only effective in filesystem)

Datastream changes

• Writeable data streams are now supported (filesystem only implemented for now)

Changes in data streams
Writable data streams are currently supported. (It takes effect only in filesystem)

File Handling changes

• New Class streamserialiser is the new way to read & write binary chunk-based formats

Changes in File Processing
A newly added streamserialiser class is a new method for reading and writing basic binary data formats.

Build changes

• Cmake is now used to generate project files, separate explicitly maintained build systems are being removed. See Building with cmake

Build changes
Cmake is now used to generate project files. Separate explicitly maintained build systems is removed. For details, see building with cmake.

Renderwindow changes

• Miscparams now supports 'vsyncinterval 'option, allowing you to sync to a multiple of the refresh rate if you want (and the hardware supports it)

Renderwindow change
The miscparams parameter now supports the "vsyncinterval" option, allowing you to synchronize the update rate by a multiple, If you want (and hardware also needs to support it)

Viewport changes

• Added clear method to manually clear any combination of color/depth/stencel to a specified value without specify Ming an update.

Changes in the view
A clear method is added to manually clear the combination of any color, depth, or template. The specified value is not updated.

Image changes

• Added loadtwoimagesasrgba and combinetwoimagesasrgba to make it easier to construct combined normal/height and diffuse/specular images etc

Image changes
The loadtwoimagesasrgba and combinetwoimagesasrgba methods are added. using these methods, you can easily construct a combination of a normal, height, and diffuse/highlight map.

New paging component

• Scenemanager-independent, separate optional component (ogre_home/components/paging)
• Pluggable strategy components to control paging strategy for a section of the scene
• Pluggable content components to control paging of content
• Plugggable collection components so that paged elements can be composed or selected between in different ways (e.g. Paging using lods levels within a page)

New paging component
It is independent from the scenario manager and becomes several optional components.
Pluggable policy components to control paging policies for part of this scenario.
Pluggable content components to control paging content
Pluggable collection components so that paging elements can be combined or selected between two different methods (for example, many of the pages in a page range with a single level of granularity)

New Terrain component

• Scenemanager-independent, separate optional component (ogre_home/components/terrain)
• Inherently editable
• Hierarchical geometry batching; batch counts reduce at lower lods as well as vertex count. At the lowest level of detail, the entire terrain page is a single batch.
• Details about how to create a custom image using a custom image.
• Skirts are used instead of stitching to avoid cracks in geometry; this means fewer indexing arrangements & lower overall index buffer usage
• Saving & loading of terrain built in, including loading/processing in a background thread
• In-built support for splatting layers, retriable sampler inputs and pluggable material generators
• Support for generating global normal maps and light maps, in a background thread

New Terrain component

Isolated from the scenario manager and separated into selectable Components
Built-in editable Functions

Batch rendering of geometric structures in batches. The number of batch rendering decreases with the lower levels of the level of the slice. At the lowest level of detail, the whole terrain page is a separate batch.

Now you can configure the level of view in the real-time camera settings (The View Size is different from the level of view offset), so you can use the same terrain to increase the view efficiency.

Edges use stitching to avoid cracks in the ry; this means less arrangement of indexes and a lower usage of integrated index buffering.
Terrain storage and loading are built-in, including background thread loading and processing.
Built-in support for post layer, configurable input samplerger and pluggable material generation.

Allows you to generate a global normal post image and a light post image in a background thread.