Menu
▾
▴
binrevengine-news — List to communicate the developing progress informations
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
(1) |
Aug
(3) |
Sep
(1) |
Oct
(5) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christian H. <Hel...@bi...> - 2008-10-18 14:45:35
|
With revision 198 we have finished the refactoring of the BinRev system configuration and their adapter classes. Up from this point the system configuration is split in logical groups to separate the config data values based on their technical classification i.e. screen and libraries. We also fix an issue in Revision 201 on regarding the modification path on configuration file access. Now the modification sources first checked for the configuration file before a fall back to the system root configuration occurs. |
|
From: Christian H. <Hel...@bi...> - 2008-10-04 15:44:32
|
With revision 170 we have finished the refactoring of the BinRev Vector classes for 2,3 and 4 dimensional vectors. Up from this point for each vector a single class exists located in the src/math folder, which could included explicitly if required. With this refactoring we have removed the obsolete Vector.h class. |
|
From: Christian H. <Hel...@bi...> - 2008-10-03 16:31:26
|
We are proud to announce that we have start up the integration of osgWidgets as GUI definition library for the BinRev engine. With revision 165 it's possible to use the first Widgets (Label and Panel as Widget container) as GUI elements in the BinRev engine. At a later point we will also support config files to define complex GUI elements. While the integration is in an early stage, we actually only support a low level definition of the widgets. Check out the game.rb ruby script to get a first impression of the usage of the new GUI interface. The source files of the GUI interface classes are archived by following structure: gfx/gui - The C++ BinRev interfaces for GUI elements gfx/gui/osgWidget - The C++ osgWidget adapter classes scripting/api - The Scripting API adapters for the C++ classes |
|
From: Christian H. <Hel...@bi...> - 2008-10-03 16:09:05
|
With Revision 167 a bug fix for the viewer has performed, which solves the issue in regarding the screen resolution settings from the system setting configuration file on initialization of the view. |
|
From: Christian H. <Hel...@bi...> - 2008-09-26 16:33:32
|
With the last revision 161 we finally refactored the API Scripts for the engine. Up from this point the Game class doesn't exists anymore and the initialization of the engine is controlled completely by ruby scripts. The refactored (and splitted) API script classes are placed under the src/scripting/api folder. Each class of this API uses the binrev::scripting namespace and encapsulates the access to the BinRev engine c++ classes from the scripting interface. The game.rb main script where the application is actually initialized is placed under scripts/ruby. If you want to add objects to the application or manipulate the application flow, you have to extend these scripts. Actually we only support minimalistic application controll, but this will be extend in future. |
|
From: Christian H. <Hel...@bi...> - 2008-08-25 13:27:24
|
With the last revision 134 we have refactored the mechanism of effect initialization. Up from now effects are initialized for execution when the run method of the viewer is called first time. At this point we call the new effect initialization method of the active scene from the view to force the initialization of the effects for all scene objects and the scene itself. Please take note that we have now three steps of effect registering and initialization: 1. Load configuration Load all effects from the effect configuration file on engine startup and validate each effect against the supported hardware. 2. Register effect on object/scene creation The Scene builder regards the defined effects from the configuration file of the object/scene on creation and register the already loaded effect if supported at the object/scene. 3. Initialize effects on first render call On the first call of the run method of the viewer, for the rendered view all registered effects are initialized once. This mechanism ensures that we invoke the render technology depended objects only when required and also regards all possible user value changes at the effects before rendering. |
|
From: Christian H. <Hel...@bi...> - 2008-08-09 15:52:16
|
An upgrade of OSG to version 2.6.0 has been accomplished. Additionally an update of osgPPU the newest osgPPU version has been accomplished too. We also performed some refactoring. With revision 125 we will no longer support the BinRev model container structures for object creation. Up from this point, all Objects are directly created based on the model XSD Kolpackov config adapter containers. Please take note that this libraries updates are required up from revision 126 to get the BinRev engine working. |
|
From: Christian H. <Hel...@bi...> - 2008-08-07 17:17:27
|
With the last revision 120 we've refactored the shader handling of the
engine.
Up from this point each shader is initalized and activated in a
multi-stage
process, which is visualized in the sequence diagram of the attachement.
The following steps try to explain how this process is performed:
1. An actor requests a shader from the AbstractShaderFactory based on the
BinRev IShaderConfig adapter.
2. The Factory creates an instance of the concrete type (OSGGLSLShader)
using the technology dependend concrete factory.
3. The initialization of the concrete shader object is performed in three
steps:
3.1 Load shader loads the shader source from file.
3.2 Initalize const shader params. In this step the const shader
params
of the shader config file are convey to the equivalent
osg::Uniform
objects.
3.3 Initialize the application params. In this step the equivalent
osg::Uniform
objects for the application params of the shader config file
are created.
Please take note, that this step only initalize the uniforms,
the values
are not set, while they depends on application context
references, which
are not known at this point.
After perfoming the initialization of step 3 the shader and all
corresponding
osg::Uniform objects are initalized but not executable, while the
bindings for
the application parameters are missing.
This status allowes us to execute the next step if it is defined in
the effect
config file:
4. If const parameter values have been redefined in the shader TAG of
the effect
config file, the corresponding initialized osg::Uniform values of the
shader are
overwritten by the new redefined values.
This mechanism makes it possible to use the same shader in different
effects,
with different const paramter values, i.e. you can use the gausian
blur shader
in the motionbur and dof effect with different bluring values.
Please take note that only const parameter values could be redefined,
while
application paramter values depends allways on specific application
reference
values.
5. Finaly the shader is make runnable by calling the attach method.
This method
call requires different parameters to bind the application references
for the
application parameters.
6. In the last step the performInitalizationLog is executed to log all
shader
parameters with their initalized values after make the shader
runnable. (This
log includes all redefined shader values).
|
|
From: Christian H. <Hel...@bi...> - 2008-07-12 15:51:16
|
We are proud to announce that with revision 102 the osgPPU post processing libary is supported by the engine. With this libary, developed by Art Tevs, you can define post processing shading effects like Motion Blur or Depth of Field for your scene. For details of handling of the osgPPU effects please see the inline source documentation and examples of the osgPPU at: http://projects.tevs.eu/osgppu In the engine you can define new osgPPU effects without changing or writing any line of code. The osgPPU effects are completely configurable by the following XML configurations: 1. configs/effects.xml ====================== Here you define the osgPPU effect, following the osgPPU.xsd Schemata definitions. The declarations of the osgPPU.xsd Schemata follows the composition of the osgPPU libary. Relationships between units are defined as unit graph. This example shows the definition of the simple osgPPU motion blur effect: <effect name="MotionBlur" forced="false" prefered="autochoice" type="ppu"> <description>MotionBlur post processing scene shading</description> <osgppu> <unit name="bypass" xsi:type="br:UnitBypass"> <unit name="blur" xsi:type="br:UnitInOut"> <unit name="show" xsi:type="br:UnitInOut" last="true"> <childunit name="blur"/> <technique version="PS20"> <shader file="src/shaders/glsl/show.frag"/> </technique> </unit> <technique version="PS30"> <shader file="src/shaders/glsl/motion.frag"/> </technique> </unit> </unit> </osgppu> </effect> In the example above the shaders, which are used by the show and blur units, are defined as references to a specific shader definiton in the shader.xml config file. In this config file the path to the shader is used as unique identifier for the shader. So you have only add the name (path) of the shader under the technique TAG of the version you will support to define a reference to the shader definition. You can define different technique tags for each unit to support different pixel shader versions in your unit. While the BinRev Engine encapsulates the binding of the units to the osgPPU processor, which could only exists once per view, you have to declare which of your units is the last of the effect,by setting the last attribute to true. Otherwise an exception will thrown on osgPPU initialization by the engine. 2. configs/shader.xml ===================== Here you have to define the shader which is used by the osgPPU effect. Shader variables, which depends on dynamically application values, like the camera view, has to be defined as parameter values. Constant shader values have to defined with the const-TAG, where you set the value directly in the configuration. This values could be defined also directly in the shader, but it's recommended to swap this out to the configuration file. <shader type="FRAGMENT" profile="GLSL" file="src/shaders/glsl/motion.frag"> <param type="TEXTURE" name="Next" id="TEXTURE0"/> <param type="TEXTURE" name="Prev" id="TEXTURE1"/> <const type="FLOAT" name="fMotionBlurFactor"> <value> <float>0.97548</float> </value> </const> </shader> Please take note that you have to ensure that the variables name of the configuration are equals to the variable names defined in the GLSL shader. You can check all your shader variable settings on engine startup, if you set the startup argument to --notify=PRIO_INFO_SHADER. 3. configs/default-scene.xml ============================ In the scene configuration you have to define the osgPPU effect reference to use the effect in the scene. Only if the enabled attribute of the effect tag is true, the effect is executed. <effect id="DOF" enabled="true"/> If any failure occurs on initialization of the osgPPU effect, the exception is caught and logged. Additionally the effect is disabled and ignored by the engine, so that the startup of the engine is not aborted. If you need more details of the failure, you have only set the notify startup argument to PRIO_DEBUG. Important info: =============== Please take note that the engine actually only supports the activation of one osgPPU effect for the scene. We are still working on a mechanism to combine several osgPPU effects in a scene. |
|
From: Christian H. <Hel...@bi...> - 2008-06-28 16:50:08
|
With revision 85 a new skybox configuration has been added to the
engine. Up from this point it's possible to define a skybox in the
scene configuration xml file like this:
<skybox name="nebulae" type="TYPE_FIXED_FUNCTION" enabled="true">
<image file="gfx/tga/nebular_posx.tga" face="FACE_POSITIVE_X"/>
<image file="gfx/tga/nebular_posy.tga" face="FACE_POSITIVE_Y"/>
<image file="gfx/tga/nebular_posz.tga" face="FACE_POSITIVE_Z"/>
<image file="gfx/tga/nebular_negx.tga" face="FACE_NEGATIVE_X"/>
<image file="gfx/tga/nebular_negy.tga" face="FACE_NEGATIVE_Y"/>
<image file="gfx/tga/nebular_negz.tga" face="FACE_NEGATIVE_Z"/>
</skybox>
If this TAG is defined, a skybox is created dynamically on scene
startup of the engine.
You could disable the creation easy by setting the attribute enabled
to false. It's required to define a texture with the image-TAG for
each face of the box, otherwise an exception is thrown on XML
validation or skybox initialization.
Please take note that the skybox refactoring is still in progress. By
this reason, actually only skyboxes of the type FIXED_FUNCTION are
supported!
|
|
From: Christian H. <Hel...@bi...> - 2008-06-07 17:56:09
|
With revision 65 we extends the scene configuration by regarding the new alignment-TAG definitions in the scene configuration XML file. Up from now it's possible to define object, camera and light alignments in a separated alignment-TAG. All alignment definitions following the OpenGL coordinate system coordinate definition! The alignment-TAG include the following single TAG definitions: TAG Functionality === ============= <pos> Define object position <pitch> Single rotation on X-Axis <yaw> Single rotation on Y-Axis <roll> Single rotation on Z-Axis <pyr> Cumulative pitch,yaw,roll Details for PYR see: http://en.wikipedia.org/wiki/Flight_dynamics Please take note that the single PYR settings are cumulative and must be follow exactly their sequence! If you use the pyr-TAG you overwrite all single pyr settings! Actually the light and camera alignments only supports position alignments! |
|
From: Christian H. <Hel...@we...> - 2008-06-03 16:10:43
|
Add new IAlignment3D interface and concrete OSGAlignment3D implementation for object alignments in 3D space. This interface allow access to object alignment mechanism on an abstract level in a standardized manner. This interface has to been inherit by each abstract object, which have to set in 3D space. The concrete OSG object implementation of these abstract 3D objects have to inherit the concrete OSGAlignment3D implementation of this interface. For implementation details see IObject3D structure. |
|
From: Christian H. <Hel...@bi...> - 2008-05-19 18:17:58
|
With revision 50 a new logger priority flag PRIO_INFO_SHADER has been added to the engine. If the log notify level is set to this value, the new OSGGLSLShader class do perform logging of the shader parameter binding values. I.e.: INFO : [OSGGLSLShader]::bindParameter :src/shaders/glsl/dot3.vert Set osg::Uniform::FLOAT_VEC3: CAMERA_POSITION with osg value (0, 0, 0). Set osg::Uniform::FLOAT_VEC4: LIGHT_POSITION with osg value (0, -110, 0, 1). Set osg::Drawable::ATTRIBUTE_7: binormal Set osg::Drawable::ATTRIBUTE_6: tangent This priority could be activated as new console parameter --notify. Please take note that the logging level is set to the lowest priority PRIO_NORMAL as default. |
|
From: Christian H. <Hel...@bi...> - 2008-05-19 17:59:16
|
An upgrade of OSG to version 2.4 has been accomplished. Additionally an update of osgPPU to version 0.2 has been accomplished too. Please take note that this libraries updates are required up from revision 40 to get the BinRev engine working. |
|
From: Christian H. <Hel...@bi...> - 2008-04-26 11:38:05
|
An upgrade of Kolpackov XSD to version 3.1.0-1 has been accomplished. With this update we have fixed many naming conflicts in the BinRev Kolpackov adapters, depending to new Kolpackov namings. So it's required to use Kolpackov 3.1.x and higher up from revision 24 of the engine. |
|
From: Christian H. <Hel...@bi...> - 2008-04-20 17:05:05
|
A full modification source support has been added to the engine. To archive this support we implemented the uils::FileHandler singleton. This singleton offers a getStatusInfo method to check if a file or directory exists, regarding possible modificiation settings. The method returns a special FileStatusInfo container, containing the origin path and a possible extended path. If a file or directory couldn't be found by this check on an active modification, a fallback check to the default BinRev root structure is done. However if this fallback fails a FileNotFound exception is thrown. Each class which have to load up resources have to use the FileHanlder first to check the path and regarding the possible modification. Then the possible extended path have to used for the loading process. To get an implementation example of this mechanism check the OSGSceneBuilder.cpp or ImageManager.cpp file. Up from now you could add your own modification sources under a free nameable folder in the mods directory of the engine. i.e. mods\starwars If you add your own modification sources to this folder, you have to follow the structure of the BinRev Engine. I.e. If you want to use your own default-scene settings, place the new default-scene.xml config under this structure: mods\starwars\configs\default-scene.xml Otherwise the default scene configuration of the BinRev Engine is used to create the scene. Please take note, that your modification files could have absolute references to files located under the BinRev root directory. So you have to fix this manually (like the xsd schema locations). To activate your modification you have to add the name of the modification as program argument --mod on startup: i.e. ./binrevframework --mod starwars Please take note that this mechanism doesn't support a source code modifications! Actually only configs, models and textures could be changed by this mechanism. |