[Opensg-users] Changing a field name

[Johannes Brunen]

Hello Carsten,


I was forced to change the name of a field in a FieldContainer. Do you know if 
it is possible to hook into the loading procedure to load the content of the 
former field into the new field of the container?


Background: I have stupiditly named the light type multi field of the 
MultiLighChunk just 'Type'. But that breaks in some template code with the 
getType() function of the type system. The compiler can't resolve the corretly 
to be used function and spills errors therefore. I think it is best to rename 
the field and solve the loading issue introduced by that change.


Hope you know what I can do here.


Best,

Johannes


P.S. Beside, you have convinced me with the deepClone problem.


___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Method deepClone possibly not correct

[Johannes Brunen]

Hello Carsten,

IMHO we are in the realm of modulo bug :-)

Below, I have copied the two relevant functions with their comments.

My scenario:

MaterialGroup* mgrp = ...;
vector shareTypes;
shareTypes.push_back(::getClassType());
cloned_mgrp = deepClone(mgrp, shareTypes, ...);


Method deepClone calls dstField->shareValues(srcField) if

TypePredicates::typeDerivedFrom(
shareTypes.begin(),
shareTypes.end  (), *rcType))

results true. 'rcType' is the MaterialGroup's 'material' field:

const ReflexiveContainerType *rcType =
dynamic_cast(
>getContentType());

Now, the predicate 'typeDerivedFrom' results in true if any of the
sequence's elements is a base class of the third parameter 'type',
i.e. rcType, i.e. "Material". That is the way 'typeDerivedFrom'
is implemented.

Hope I could clarify my point ;-)

Best,
Johannes


/*! Tests if type is derived from any of the types in the sequence
specified by [begin, end). The sequence must consist of pointers
to TypeBase objects (or a derived class).

\param[in] begin Start of sequence.
\param[in] end End of sequence.
\param[in] type Type that is tested.
\return true, if type is derived from any of the types in
[begin, end), false otherwise.
 */
template  inline
bool TypePredicates::typeDerivedFrom(  InIteratorTypeT  begin,
   InIteratorTypeT  end,
 const OSG::TypeBase )
{
return (std::find_if(begin, end,
 TypePredicates::IsBaseOf(type)) != end);
}

/*! Creates a deep copy ...

\param[in] src FieldContainer to clone.
\param[in] shareTypes Types that should be shared instead of cloned.
\param[in] ignoreTypes Types that should be ignored.
\param[in] shareGroupIds Type groups that should be shared instead
of cloned.
\param[in] ignoreGroupIds Type groups that should be ignored.
...
 */
FieldContainerTransitPtr deepClone(
  OSG::FieldContainer const*src,
const std::vector ,
const std::vector ,
const std::vector ,
const std::vector )
{
if(src == NULL)
return FieldContainerTransitPtr(NULL);

const FieldContainerType   = src->getType();
FieldContainerTransitPtr  fcClone = fcType.createContainer();

UInt32 fCount = osgMin(fcType.getNumFieldDescs(),
   fcClone->getType().getNumFieldDescs() );

for(UInt32 i = 1; i <= fCount; ++i)
{
const FieldDescriptionBase *fDesc = fcType.getFieldDesc(i);

if(fDesc->isInternal())
continue;

GetFieldHandlePtr  srcField = src->getField (i);
EditFieldHandlePtr dstField = fcClone->editField(i);

if(dstField == NULL || dstField->isValid() == false ||
   srcField == NULL || srcField->isValid() == false)
{
continue;
}

if(srcField->isPointerField() == false)
{
dstField->copyValues(srcField);
}
else
{
// get type info for values stored in field
const DataType  = srcField->getType().getContentType();

// check if it's a "pointer to FC" type (needed, because
// AttachmentMap also passes the above isPointerType() check)
const PointerType *pointerType =
dynamic_cast();

// punt, share if it is something that is not "pointer to FC"
if(pointerType == NULL)
{
dstField->shareValues(srcField);
continue;
}

// get type info for pointed-to FC type
const ReflexiveContainerType *rcType =
dynamic_cast(
>getContentType());

// punt, share if it is something that is not derived from RC
if(rcType == NULL)
{
dstField->shareValues(srcField);
continue;
}

// check if type should be ignored
if(!TypePredicates::typeInGroupIds(
ignoreGroupIds.begin(),
ignoreGroupIds.end  (), *rcType) &&
   !TypePredicates::typeDerivedFrom(
ignoreTypes.begin(),
ignoreTypes.end  (), *rcType)  )
{
// check if type should by shared
if(TypePredicates::typeInGroupIds(
shareGroupIds.begin(),
shareGroupIds.end  (), *rcType) ||
   TypePredicates::typeDerivedFrom(
shareTypes.begin(),
shareTypes.end  (), *rcType)  )
{
dstField->shareValues(srcFiel

[Opensg-users] Method deepClone possibly not correct

[Johannes Brunen]

Hello again,


I think that the method deepClone implemented in OSGFieldContainer.cpp does not 
what I'm expecting it to do.


Say I have a container with a material field (MaterialGroup) in it and I want 
that my special material (MyMaterial) must not to be deep cloned but shared. So 
I provide myMaterial to the shareTypes parameter of the deepClone method.


deepClone checks for each of the fields of the given 'src' container the 
following in order to decide if the field is to be cloned or shared:


// check if type should by shared

if(TypePredicates::typeInGroupIds(
shareGroupIds.begin(),
shareGroupIds.end  (), *rcType) ||
   TypePredicates::typeDerivedFrom(
shareTypes.begin(),
shareTypes.end  (), *rcType)  )
{
dstField->shareValues(srcField);
}
else
{
dstField->cloneValues(srcField,
  shareTypes,
  ignoreTypes,
  shareGroupIds,
  ignoreGroupIds);
}


Now the function TypePredicates::typeDerivedFrom states


/*! Tests if \a type is derived from any of the types in the sequence
specified by [\a begin, \a end). The sequence must consist of pointers
to TypeBase objects (or a derived class), e.g.
std::vector\.

\param[in] begin Start of sequence.
\param[in] end End of sequence.
\param[in] type Type that is tested.
\return true, if \a type is derived from any of the types in
[\a begin, \a end), false otherwise.
 */
template  inline
bool TypePredicates::typeDerivedFrom(  InIteratorTypeT  begin,
   InIteratorTypeT  end,
 const OSG::TypeBase )


In my case MyMaterial is derived from Material but the test gives only true if 
Material would be derived from MyMaterial what is not the case.


Is this intentionally or is deepClone not correctly implemented and should use


/*! Tests if \a type is a base type any of the types in the sequence
specified by [\a begin, \a end). The sequence must consist of pointers
to TypeBase objects (or a derived class), e.g.
std::vector\.

\param[in] begin Start of sequence.
\param[in] end End of sequence.
\param[in] type Type that is tested.
\return true, if \a type is a base type any of the types in
[\a begin, \a end), false otherwise.
 */
template  inline
bool TypePredicates::typeBaseOf(  InIteratorTypeT  begin,
  InIteratorTypeT  end,
const OSG::TypeBase )


instead?


Any help is appreciated.

All the best,
Johannes

___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OSG file format and UInt64 fields

[Johannes Brunen]

Hello,


I have some field containers in use that contain UInt64 fields und multi 
fields. With the native OSB file format I don't see any problem but I jsut 
discoverd that the OSG file format does not support UInt64. Is there anything 
that can be done for extending the OSG file loader? I looked into the 
OSGScanParseSkel code but that is an alien world for me. I can't solve that by 
myself. Any help is appreciated.


Best,

Johannes

___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Building Git codebase on Windows

[Johannes]

Hi again,

with respect to the dependencies. You can find all of them on the net 
and you can build most (if not all as of today) of them with cmake.
But you do not need all dependencies in the first place. Most of the 
dependencies can be installed with vcpk from Microsoft. However, I did 
not tried that variant.


Best,
Johannes



___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Building Git codebase on Windows

[Johannes]

/Install64/lib/freeglut.lib
-D GLUT_glut_LIBRARY_DEBUG=D:/_xxx/Install64/lib/freeglutD.lib
-D LIBMINI_INCLUDE_DIR=D:/_xxx/Install64/include/libmini
-D LIBMINI_LIBRARY_RELEASE=D:/_xxx/Install64/lib/libmini.lib
-D LIBMINI_LIBRARY_DEBUG=D:/_xxx/Install64/lib/libminiD.lib
-D OPENNURBS_INCLUDE_DIR=D:/_xxx/Install64/include
-D OPENNURBS_LIBRARY_RELEASE=D:/_xxx/Install64/lib/opennurbs.lib
-D OPENNURBS_LIBRARY_DEBUG=D:/_xxx/Install64/lib/opennurbsD.lib
-D QHULL_INCLUDE_DIR=D:/_xxx/Install64/include/QHull
-D QHULL_LIBRARY_QHULLCPP_RELEASE=D:/_xxx/Install64/lib/qhullcpp.lib
-D QHULL_LIBRARY_QHULLCPP_DEBUG=D:/_xxx/Install64/lib/qhullcppD.lib
-D 
QHULL_LIBRARY_QHULLCPP_DEBUGOPT=D:/_xxx/Install64/lib/qhullcppDO.lib
-D 
QHULL_LIBRARY_QHULLCPP_RELEASENOOPT=D:/_xxx/Install64/lib/qhullcppRN.lib
-D 
QHULL_LIBRARY_QHULLSTATIC_R_RELEASE=D:/_xxx/Install64/lib/qhullstatic_r.lib
-D 
QHULL_LIBRARY_QHULLSTATIC_R_DEBUG=D:/_xxx/Install64/lib/qhullstatic_rD.lib
-D 
QHULL_LIBRARY_QHULLSTATIC_R_DEBUGOPT=D:/_xxx/Install64/lib/qhullstatic_rDO.lib 

-D 
QHULL_LIBRARY_QHULLSTATIC_R_RELEASENOOPT=D:/_xxx/Install64/lib/qhullstatic_rRN.lib 


-D ASSIMP_INCLUDE_DIR=D:/_xxx/Install64/include
-D ASSIMP_LIBRARY_RELEASE=D:/_xxx/Install64/lib/assimp-vc120-mt.lib
-D ASSIMP_LIBRARY_DEBUG=D:/_xxx/Install64/lib/assimp-vc120-mtD.lib
-D 
ANTTWEAKBAR_INCLUDE_DIR=D:/_xxx/Comp/prebuild/extern/AntTweakBar/include
-D 
ANTTWEAKBAR_LIBRARY_RELEASE=D:/_xxx/Comp/prebuild/extern/AntTweakBar/lib/AntTweakBar64.lib 

-D 
ANTTWEAKBAR_LIBRARY_DEBUG=D:/_xxx/Comp/prebuild/extern/AntTweakBar/lib/AntTweakBar64.lib 


-D GLM_INCLUDE_DIR=D:/_xxx/Comp/prebuild/extern/glm
-D GLI_INCLUDE_DIR=D:/_xxx/Comp/prebuild/extern/gli
-D VMATH_INCLUDE_DIR=D:/_xxx/Comp/prebuild/extern/vmath
-D DOXYGEN_EXECUTABLE=D:/_xxx/Utils/doxygen/bin/doxygen.exe
-D DOXYGEN_DOT_EXECUTABLE=D:/_xxx/Utils/Graphviz/bin/dot.exe
-D OSGBUILD_TESTS:BOOL=ON
-D OSGBUILD_UNITTESTS:BOOL=OFF
-D OSGBUILD_EXAMPLES_SIMPLE:BOOL=ON
-D OSGBUILD_EXAMPLES_TUTORIAL:BOOL=ON
-D OSGBUILD_EXAMPLES_ADVANCED:BOOL=ON
-D OSGEXCLUDE_TESTS_FROM_ALL:BOOL=ON
-D OSGEXCLUDE_UNITTESTS_FROM_ALL:BOOL=ON
-D OSGEXCLUDE_EXAMPLES_SIMPLE_FROM_ALL:BOOL=ON
-D OSGEXCLUDE_EXAMPLES_ADVANCED_FROM_ALL:BOOL=ON
-D OSGBUILD_PYTHON_BINDINGS:BOOL=OFF
-D OSGBUILD_PYTHON_DUMP_DECLS=FALSE
-D BOOST_ROOT=D:/_xxx/Comp/prebuild/extern/boost
-G"Visual Studio 12 2013 Win64"
D:/_xxx/Comp/builder/support/opensg

On my platform OpenSG 2.0 builds fine.
Hope that this helps a little :-)

Best,
Johannes



___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Crash in SplitGeoPump setup

[Johannes Brunen]

Hi Gerrit,

Are you still around? I have a program crash in the setup of the GeoPump data 
and I would like to hear your opinion. I have the following scenario: I have a 
Geometry core that is filled with usual data (length, types, props, ...) and 
this renders fine. Now, during a dynamic operation on the geometry, the mesh 
degrades and the length and types becomes empty. That leads to a program crash 
in the following code place:

In file OSGGeoSplitVertexArrayPumpGroup.cpp line 133

namespace
{
// collect info for property in 'slot'
bool pumpGLSetup(PumpData , UInt16 slot)
{
...
if(info.attribPtr[slot]  != NULL  &&
   info.attribPtr[slot]->getIgnore() == false   )
{
info.attribData  [slot] = info.attribPtr[slot]->getData();
...
...
}
}

The crash happens in the getData access function, which assumes that the 
property has at least one element, i.e. it accesses vector index 0.

I have added the following additional code into this function and the related 
functions of the other PumpGroups:

// collect info for property in 'slot'
bool pumpGLSetup(PumpData , UInt16 slot)
{
bool retVal = false;

if(slot < info.prop->size())
   info.attribPtr[slot] = (*info.prop)[slot];

if(slot < info.propIdx->size())
info.attribIndex[slot] = (*info.propIdx)[slot];

if (info.attribPtr[slot] != NULL &&  // 
NEW
info.attribPtr[slot]->size() == 0  )
// NEW
info.attribPtr[slot] = NULL;
// NEW

if(info.attribPtr[slot]  != NULL  &&
   info.attribPtr[slot]->getIgnore() == false   )
{
info.attribData  [slot] = info.attribPtr[slot]->getData();
info.attribStride[slot] = info.attribPtr[slot]->getStride();

if(info.attribStride[slot] == 0)
{
info.attribStride[slot] =
info.attribPtr[slot]->getFormatSize() *
info.attribPtr[slot]->getDimension();
}

retVal = true;
}

return retVal;
}

This way the info.attribPtr[slot] stays zero and the calling code of the 
function filters the empty props case:

bool GeoSplitVertexArrayPumpGroup::masterClassicGeoSetupPump(...)
{
...
// Setup: get all the data
PumpData   pumpData;

pumpData.lengths = lengths;
pumpData.types   = types;
pumpData.prop= prop;
pumpData.propIdx = propIdx;

UInt16 nattrib = prop->size32();

for(UInt16 i = 0; i < nattrib; ++i)
{
if(pumpGLSetup(pumpData, i) == false)
continue;
}

// we need positions
if(pumpData.attribPtr[0]  == NULL ||// catches the situation
   pumpData.attribPtr[0]->getUseVBO() == false)
{
...
}
...
}

Now my question is whether this is a good solution to circumvent the program 
crash?
Do I have overseen some crucial point?
Do you have a better solution in mind?

In my opinion the situation, that the geometry carries empty properties should 
be valid.
What is your opinion?

I hope you still read the mailing list and have some time to give me an answer 
to my problem.

Best,
Johannes


___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] FBOViewport, DeferredShading and PassiveWindow

[Johannes]

Hi Victor,

I'm curious, did you solve your problem?

Best,
Johannes



___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] FBOViewport, DeferredShading and PassiveWindow

[Johannes]

On 20.12.2018 15:31, Victor Haefner wrote:

Hello Victor,

I have spend some time in your example and actually found two errors.

At first, the fboDTexImg should be setup (imho) in the following way:

fboDTexImg->set(GL_DEPTH_COMPONENT, fboWidth, fboHeight, 1, 1, 1, 0.0, 
0, GL_UNSIGNED_INT, false);


Secondly, the commented

//fbo->setColorAttachment(texDBuf, 1);

is definitely wrong. The statement you have actually used is the one to go:

fbo->setDepthAttachment(texDBuf);

But, thirdly, the

fbo->editMFDrawBuffers()->push_back(GL_DEPTH_ATTACHMENT_EXT);

is not correct. You only can provide color attachements here.


The problem is, with these corrections the OpenSG log is better, but I 
still get the following fbo binding error on the second and third 
renderOnce call:


WARNING: 
(D:\_xxx\Comp\builder\support\opensg\Source\System\Window\FrameBufferObjects\OSGFrameBufferObject.cpp,654): 
FrameBufferObject::activate::bind failed: Der Vorgang ist ungültig. (0x502)


This unfortunatly leads to the very same result as in your case. The 
first texture image is ok and the others are completely black. In my 
case (windows) I see the same problem whether I render into a glut 
window or if I use a passive window. In both cases the binding fails. 
That all images are correct in the glut window case seems to me an 
artifact. I do not think that they are actually rendered.


Unfortunately, I run out of time. Hopefully, I could help you a little 
nevertheless.


Marry Christmas and all the best

Johannes


#include 
#include 
#include 
//#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#define GLSL(shader) #shader

using namespace std;
using namespace OSG;

string DSAmbient_vp_glsl =
"#version 120\n"
GLSL(
void main(void) {
gl_Position = ftransform();
}
);

string DSAmbient_fp_glsl =
"#version 120\n"
"#extension GL_ARB_texture_rectangle : require\n"
"#extension GL_ARB_texture_rectangle : enable\n"
GLSL(
uniform sampler2DRect  texBufNorm;
uniform vec2   vpOffset;
void main(void) {
vec2 lookup = gl_FragCoord.xy - vpOffset;
vec3 norm   = texture2DRect(texBufNorm, lookup).xyz;
if(dot(norm, norm) < 0.95) discard;
else gl_FragColor = vec4(0.02, 0.02, 0.02, 1.);
}
);

string DSGBuffer_vp_glsl =
"#version 120\n"
GLSL(
varying vec4 vertPos;
varying vec3 vertNorm;
void main(void) {
vertPos= gl_ModelViewMatrix * gl_Vertex;
vertNorm   = gl_NormalMatrix* gl_Normal;
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_FrontColor  = gl_Color;
gl_Position= ftransform();
}
);

string DSGBuffer_fp_glsl =
"#version 120\n"
GLSL(
varying vec4  vertPos;
varying vec3  vertNorm;
uniform sampler2D tex0;
float luminance(vec4 color) {
return dot(color, vec4(0.3, 0.59, 0.11, 0.0));
}
void main(void) {
vec3 pos = vertPos.xyz / vertPos.w;
float ambVal  = luminance(gl_Color);
vec3  diffCol = gl_FrontMaterial.diffuse.rgb;
gl_FragData[0] = vec4(pos, ambVal);
gl_FragData[1] = vec4(normalize(vertNorm), 0);
gl_FragData[2] = vec4(diffCol, 0);
}
);

string DSDirLight_vp_glsl =
"#version 120\n"
GLSL(
void main(void) {
gl_Position = ftransform();
}
);

string DSDirLight_fp_glsl =
"#version 120\n"
"#extension GL_ARB_texture_rectangle : require\n"
"#extension GL_ARB_texture_rectangle : enable\n"
GLSL(
// compute directional light INDEX for fragment at POS with normal NORM
// and diffuse material color MDIFF
vec4 computeDirLight(int index, vec3 pos, vec3 norm, vec4 mDiff) {
vec4  color= vec4(0., 0., 0., 0.);
vec3  lightDir = gl_LightSource[index].position.xyz;
float NdotL= max(dot(norm, lightDir), 0.);
if(NdotL > 0.) color = NdotL * mDiff * gl_LightSource[index].diffuse;
return color;
}

// DS input buffers
uniform sampler2DRect texBufPos;
uniform sampler2DRect texBufNorm;
uniform sampler2DRect texBufDiff;
uniform vec2  vpOffset;

// DS pass
void main(void) {
vec2 lookup = gl_FragCoord.xy - vpOffset;
vec3 norm   = texture2DRect(texBufNorm, lookup).xyz;
if(dot(norm, norm) < 0.95) discard;
else {
vec4  posAmb = texture2DRect(texBufPos,  lookup);
vec3  pos= posAmb.xyz;
float amb= posAmb.w;
vec4  mDiff  = texture2DRect(texBufDiff, lookup);
gl_FragColor = computeDirLight(0, pos, norm, mDiff);
}
}
);

struct OsgTestScene2
{
TransformUnrecPtr camBeacon;
NodeUnrecPtr camBeaconNode;
PerspectiveCameraUnrecPtr cam;
SolidBackgroundUnrecPtr background;
NodeUnrecPtr lightNode;
DirectionalLightUnrecPtr light;

NodeUnrecPtr dsStageN;
DeferredShadingStageUnrecPtr dsStage;
ShaderProgramUnrecPtr li

Re: [Opensg-users] (Issue with the ShaderMapCache)

[Johannes]

Hello Victor,

for the record, I'm also working with OSG_SHC_MODE_5, but havent't had 
any issues so far. Can you make an example showing this problem?


Best,

Johannes


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Custom SField and MField types

[Johannes]

Hello Carsten,

On 2018-05-15 16:33, Carsten wrote:
On 15.05.2018 16:10, Johannes wrote:
>> The FieldContainerMap does work great in the app session but does not
>> work with persistence. I stored my class in an OSB file and load that
>> file in separate session. The FieldContainerMap does contains the
>> respective entries but the mapped FieldContainer do not correspond to
>> the containers which I used for storing in the first place.

> I think for maps you'll have to add support to the OSB loader/writer.
> IIRC it can not figure out on its own that there are pointers to
> objects that need serialization.
> I think that was also be the reason some places use a string to
> int map and a MField of FC Ptr to achieve map like behavior.

I feared that. I will not touch the OSG loader/writer at the moment 
because I'm not comfortable with the implementation details of this kind 
of stuff.


However, yesterday I have taken a different route and build a poor man's 
version of a map, i.e. I have created a FieldContainer (KeyValue) 
holding a string and a FieldContainerPtr and created another 
FieldContainer (StringToFieldContainerMap) containing a sorted multi 
field of KeyValue elements. This way access is O(log N), insert and 
erase is O(N). Also the overhead due to the KeyValue container is 
considerable, but I am fine with that.


Best,
Johannes


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Documentation

[Johannes Brunen]

Hi,

I would like to build fresh HTML documentation of my OpenSG working tree. I am 
able to generate docs for the core system but cannot get documentation for the 
Contrib libraries. Because I have started to create a new Contrib - library 
this is hurting me much.

Does anyone know how to generate docs that contain the Contrib classes etc.?

Best,
Johannes


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Custom SField and MField types

[Johannes]

Hi,

I have spend some time to experiment with the StringToUInt32Map and 
FieldContainerMap, i.e. I added to test fields to my class.









The FieldContainerMap does work great in the app session but does not 
work with persistence. I stored my class in an OSB file and load that
file in separate session. The FieldContainerMap does contains the 
respective entries but the mapped FieldContainer do not correspond to 
the containers which I used for storing in the first place.


The implementation of the alternative AttachmentMap does not allow the
integration in my fcd file. Additionally, I can't get my head around the 
implementation of this beast.


What I need is just a persistent map from string to FieldContainer that
I can use in my FCD file and that does store the mapped FieldContainer 
in OSB files and later reload them as an mfFieldContainer would do.


I really need help here.

Does anyone knows how such a map can be implemented?

Best,
Johannes



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Custom SField and MField types

[Johannes Brunen]

Hi,

I am in need for a map of string to FieldContainer in some context. OpenSG does 
not provide such a mapping, but I have found some examples that tells me 
roughly how to proceed:

OSGFieldContainerMap*:
typedef std::map<Int32, FieldContainerRecPtr>  
FieldContainerMap;

OSGAttachmentMap*:
typedef std::map<UInt32, Attachment *>  AttachmentMap;

OSGStringToUInt32Map*:
typedef std::map<std::string, UInt32> StringToUInt32Map;

What I do not understand/know is the difference/consequences between the 
following two approaches:
typedef std::map<std::string, FieldContainerRecPtr>  
MyFieldContainerMap;
typedef std::map<std::string, FieldContainer*>  
MyFieldContainerMap;

The first implementation based on OSGFieldContainerMap* seems much simpler, but 
the types are not used in OpenSG at all.

I would like to store some ShaderProgram objects in the map and have them 
readily available after loading a field container from file that contains such 
a map.
Which of the two approaches are recommended for a general mapper of string to 
Fieldcontainer? What are the pros and cons?

Any help is appreciated.

Best,
Johannes

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: vs2017 Optimization error

[Johannes]

Hello Michael,

On 30.11.2017 11:36, Michael Raab wrote:

I must revise my comments ;-)
The problem was not the compiler..
Before updating vs2017 we pulled the recent opensg source from git. 
There's a commit from 21.08.2016 which breaks the suspicious function.

Line 318 was commented out, but indexBegin needs to be reset to 0;


It is much better to find an error in the code than that the compiler is 
faulty :)


Best,
Johannes


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: vs2017 Optimization error

[Johannes]

Hello Michael,

> Do you have any ideas how to fix this without deactivating
optimizations?
First I would try to refactor the code a little. Maybe that is enough to 
get the compiler back in line. You could for instance move the 
declaration of index up out of the loop. If that does not solve the 
problem, consider taking the last compiler update. Can you reproduce the 
error in a simpler test program? Maybe you can switch of optimization 
locally for that function?


> Do you have experienced other similar problems?
Not really. We have had problems with faulty optimizations in the past 
and always worked around somehow. Most of the time it was in the 
floating point regime.


Sorry, that I can't come up with a good trick :(

It gives bad feelings if you can't rely on the compiler to do its work 
properly.


Best,
Johannes


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Stages and material overriding

[Johannes Brunen]

Hi Carsten,

I need a little help with understanding the material overriding process.

My scene graph looks like the following sketch:

root
 |
  MyStage
 |
MaterialChunk-
OverrideGroup
 |
   Scene
 |
  Material
 |
Geometry

At first, if the MyStage node is not present in the scene the idea of the 
MaterialChunkOverride group is to provide a ShaderProgramChunk that is used for 
all the geometry found below of the scene. Now, the stage MyStage should render 
its child tree with a special shader (or without any shader) into some FBOs. 
For instance shadows. Then, the shader of the MaterialChunkOverrideGroup should 
take credit from the information provided by the stage.

Now, I have the impression, that I always have the MaterialChunkOverrideGroup 
shader in the way when rendering into the FBOs. I.e. I am unable to force the 
usage of my special stage material alone.

How, should I setup things correctly?

My stage goes as follows:

MyStage::renderEnter
{
...
//ract->disableDefaultPartition();

this->beginPartitionGroup(ract);
{
this->pushPartition(ract, RenderPartition::CopyAll);
{
this->pushPartition(ract);
{
RenderPartition* pPart = ract->getActivePartition();
pPart->setRenderTarget(data.pFBO);
...

// _lightPassMaterial is MaterialChunk with or without shader 
chunk
pPart->overrideMaterial(_lightPassMaterial, 
ract->getActNode());// (*)

recurseFromThis(a);
ract->useNodeList(false);

pPart->overrideMaterial(NULL, ract->getActNode());
}
this->popPartition(a);


ract->pushState();

ract->addOverride(_myTexObj->getClassId() + iUnit, _myTexObj);
ract->addOverride(ShaderProgramChunk::getStaticClassId(), 
_injectProgChunk);

this->recurseFromThis(ract); // (**)
ract->useNodeList(false);

ract->popState();
}
this->popPartition(ract);

}
this->endPartitionGroup(ract);

return Action::Skip;
}

Is this a sensible approach for what I have in mind?
Is my handling of the partition groups correct?
I still have not fully grasped, when I have to use the disableDefaultPartition 
call and what is its intention.
Are all useNodeList(false) calls are necessary?
The code line (*) should completely setup my material for the special stage 
rendering. How to force that?
Is the chunk overriding process generally problematic in the context of stages 
and shaders?
Can I replace the material incl. shaders at line (*)   somehow?
Is it correct for rendering the final scene to use the recurseFromThis call at 
(**) or is it appropriate to leave the renderEnter function with a return 
Continue?

Can you help me a little with this? Actually, I have come a long way and hope 
to get around this to get my stage running.

Best,
Johannes



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Question about Stages, Shader and Textures

[Johannes Brunen]

Hi Carsten,

Nice to hear from you again.

>> I have written a Stage that is ...
> hmm, typically the children of a stage are considered to contribute to 
> whatever the stage produces. That "product" is then used elsewhere in the 
> scene.

Yes

>> Can you require new enough OpenGL so that you have access to layout(location 
>> = N) specifiers in your GLSL - in that case you would not need a uniform.

Yes, I could and thought about it, but I want to be as general as I can. Apart 
from that, I want to use the same style as in other places. If I am going to 
get it working the way I intended, I will be more comfortable with the Stage 
concept. Therefore, it is also subject of learning.

>> - Do I have access to the active Shader, i.e. the ShaderProgramChunk?
> I think that depends, where do you want access to it. 
> The stage typically does not have access to shaders of its children, 
> because they can use widely different materials if they want to.

Yes, that is an important observation. Actually, I have a subset of geometry 
that should take the Stage result texture as input. Other materials should just 
ignore it.

> To me this sounds largely like the task of rendering some (sub)-scene into a 
> texture 
> and then using that on an object. 
> I'm pretty sure we have an example for that and you've probably seen it ;) 
> Perhaps I'm missing something why your case is fundamentally different?

I will investigate...

>> - Can I assemble program fragments in the Stage render function, i.e. 
>> can I inject shader code from the Stage class render function?

> I *believe* OpenSG mimics OpenGL behavior here, i.e. you can have multiple 
> fragment 
> shader objects linked into a program object so long you ensure that there is 
> exactly one 
> main() function in the combined fragment shader objects.

That would be great for assembling shader programs. I will have to read the 
OpenGL specs to get comfortable with that too.

Best,
Johannes
 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Cluster shading example

[Johannes]

ping...

On 30.05.2017 14:27, Johannes wrote:

Hello Carsten,

I have finished the 'ClusterShadingStage' as promised. I have written an 
example 'multirangelightclustershadingstage.cpp' which is basically
identical to the 'multirangelightclustershading.cpp' example but uses 
the new Stage core instead of setting up the technique by hand.


Since the 'ClusterShadingStage' depends on the 'Contrib/ComputeBase' 
library and because I think that this 'Stage' does not belong into this 
box, I have introduced a new 'Contrib' library named 'Techniques' for 
high level components that depends on 'Contrib/ComputeBase'.


I have attached a zipped patch file 'cluster_stage_opensg.azip' and I 
will send it also directly to you so that is get not lost.


Because of the 200k limit of the mailing list, I have to store the patch 
somewhere else. I have uploaded it to File-Upload.net and you

can download it from

https://www.file-upload.net/download-12525698/cluster_stage_opensg.azip.html 



All missing parts are included in this patch aside from the 
'props_opensg.patch'. For the 'props_opensg.patch' I did have had some 
questions and asked for help. Unfortunately I got no answer.


The current patch file also contains some additions to the 
infrastructure, i.e. extension to 'MatrixUtility', correction to 
'AlgorithmComputeElement', extension of 'Image', a new 'SimpleCurve', a 
new 'SimpleLightGeometry'. All needed for the stage and the example but 
nothing fancy about these.


Additionally, the patch also contains the pending 
'MultiPropertyUBOChunk' and 'MultiPropertySSBOChunk' changes that were 
missing in the [c9024f] commit.


Last but not least it contains an enhancement to the 'MultiLightChunk' 
with respect to usability and a new twist parameter for the cinema light 
source.


The usage of the 'ClusterShadingStage' core is quite simple. It belongs 
into a parent node of the scene that would like to take credit from its 
offerings. A 'MultiLight' chunk must be created and provided to the
'ClusterShadingStage' core. The scene is expected to use shader 
programs. The fragment shader code must be expanded by the shader code 
provided by a call to function 'getFragmentProgramSnippet()' of the 
stage (*). This fills all the necessary parts into the fragment shader 
code. In the fragment shader the normal light shading calculation takes 
place. The only difference is that the light is determined from the 
global list of lights with the help of the light grid and light index 
list provided by the 'ClusterShadingStage'. buffer and texture binding 
points and all buffer block names can be adapted by the stage API if 
necessary.


So basically the c++ code and fragment shader code would look like this:

cluster_shading_stage = OSG::ClusterShadingStage::create();
cluster_shading_stage->setMultiLightChunk(multi_light_chunk);
cluster_shading_node->setCore(cluster_shading_stage);
cluster_shading_stage->setLightBindingPnt(1);
... binding points for all of the buffers and textures used

stringstream ost;
ost
<< "#version 440 compatibility"
<< "..."
<< cluster_shading_stage->getFragmentProgramSnippet()
<< "..."
<< "vec3 directionalLight(uint light_index, ...) {..."
<< "vec3 pointLight(uint light_index, ...) {..."
<< "vec3 spotLight(uint light_index, ...) {..."
<< "vec3 cinemaLight(uint light_index, ...) {..."
<< "..."
<< "void main()"
<< "{"
<< "..."
<< "vec3 color = vec3(0,0,0);"
<< ""
<< "uint list_idx= 0;"
<< "uint light_count = 0;"
<< ""
<< "if (clusteringData.enabled)"
<< "{"
<< "uvec2 grid_data = getGridData("
<< "  gl_FragCoord.xy"
<< "  vPositionES.z);"
<< ""
<< "list_idx= grid_data.x;"
<< "light_count = grid_data.y;"
<< "}"
<< "else"
<< "{"
<< "light_count = affectedLightIndexList.idx.length();"
<< "}"
<< ""
<< "for (uint i = 0; i < light_count; ++i)"
<< "{"
<< "uint light_idx = (clusteringData.enabled)"
<< "   ? lightIndexList.idx[list_idx+i]"
<< "   : affectedLightIndexList.idx[i];"
<< ""
<< "switch (lights.light[light_idx].type)"
<< "{"
<< "case   POINT_LIGHT:"
<< "color +=   pointLight(light_idx, ...);"
<< "

Re: [Opensg-users] OpenSG2: Cluster shading example

[Johannes]

 case DIRECTIONAL_LIGHT:"
<< "color += directionalLight(light_idx, ...);"
<< "break;"
<< "caseSPOT_LIGHT:"
<< "color +=spotLight(light_idx, ...);"
<< "break;"
<< "case  CINEMA_LIGHT:"
<< "color +=  cinemaLight(light_idx, ...);"
<< "break;"
<< "}"
<< "}"
<< "vFragColor = vec4(color, ...);"
<< "}"

I hope that this stage and the additional changes make it into OpenSG. 
It would be nice if you could also take a look if I had made some 
terrible design flaws. This was really a lot of work and I hope to build 
on it in the near future.


Best,
Johannes


(*) I have also tried to add an override for the shader code itself 
beside from the overrides to the buffer chunks. But that did not work 
well and I have limit the stage by providing the necessary shader source 
code. I did have problems with the shader #version and #extensions 
primitives that must be in the first line of the shader code.




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Compute Shader...

[Johannes]

ping...


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Compute Shader...

[Johannes]

Hello Carsten,

>
> sorry, I did not explain this in enough detail. I meant to use GL_NONE
> as a special value that guards the call to glMemoryBarrier, i.e.
>
> if(_sfMemoryBarrier.getValue() != GL_NONE)
> glMemoryBarrier(_sfMemoryBarrier.getValue());
>
> Please see the attached patch for details.
Yes, your are right, I did not pay enough attention. I'm fine with your 
suggestion. We should do it that way.

Thank you.

Best
Johannes



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Cluster shading example

[Johannes Brunen]

Hello,

As promised, today I send you my finished and polished ClusterShading example. 
It is based on:

Ola Olsson et.al
http://www.cse.chalmers.se/~uffe/clustered_shading_preprint.pdf
High Performance Graphics (2012), pp. 1-10
C. Dachsbacher, J. Munkberg, and J. Pantaleoni (Editors)

This invention describes the clustering the view frustum and population of 
these clusters by lights contributing to the shading of the cluster's 
fragments. Light lists are generated for each cluster and evaluated in the 
fragment shader.

Additionally I have used the

SIGGRAPH 2015 course "Real-Time Many-Light Management and Shadows with 
Clustered Shading"
https://newq.net/publications/more/s2015-many-lights-course

I have implemented the example in a classic forward rendering setup and hope 
that it makes its way into OpenSG and that is useful for anyone.

Additionally, the patch contains small enhancements to the MultiLightChunk and 
corrections to the examples basing on this chunk.

@Carsten: The patch does also contain the MultiPropertyUBOChunk and 
MultiPropertySSBOChunk classes which I have forgotten to add to my recent patch 
' ssbo_ubo_opensg.patch'.  There, I did introduced common base classes for the 
various UBO and SSBO classes, and I adapted these two missing guys also.

Best,
Johannes




cluster_opensg.azip
Description: cluster_opensg.azip
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Compute Shader...

[Johannes]

Hi Carsten and Gerrit,


Ok I will give it a try.


Attached you can find a first version of the changes. I have added a 
osgGLId field to the ref property classes. I still use the inherited 
GLId field, but I have added an getOglGLId/setOglGLId API. I have still 
an issue with the implementation since in the former cpp-files you can 
find a few statements with getGLId() != 0 and I'm unsure how to handle 
these correctly. I have replace these calls by (getOsgGLId() != 0 || 
getOglGLId() != 0). Can I safely use this->getOpenGLId(pEnv) != 0 instead.
Especially, in the integral ref property implementation of the 
changeFrom function, their is a call to a GeoIntegralProperty::getGLId() 
(line 165) that can not be replaced with my schema since 
getOsgGLId()/getOglGLId() are unknown here.


Do you have an idea how I should implement this reasonably?

Best,
Johannes

P.S.: I also have the ShaderStorageBufferObjRef finished. This does not 
have any unclear issues. But since I was recently forced to introduce a 
common base class for the ShaderStorageBufferObj chunk classes and one 
for the UniformBufferObj chunk classes, I will send them separately. 
This ssbo/ubo patch exceeds the 200kB limit of the mailing list and 
therefore I allow me to send this patch directly to Carsten. Hope that 
this is fine for you.




diff -rupN 
d:/_opensg_clone/Comp/builder/support/opensg/Source/System/NodeCores/Drawables/Geometry/Properties/OSGGeoIntegralBufferRefProperty.cpp
 
d:/_opensg_merge/Comp/builder/support/opensg/Source/System/NodeCores/Drawables/Geometry/Properties/OSGGeoIntegralBufferRefProperty.cpp
--- 
d:/_opensg_clone/Comp/builder/support/opensg/Source/System/NodeCores/Drawables/Geometry/Properties/OSGGeoIntegralBufferRefProperty.cpp
  2017-05-11 11:33:54.387564100 +0200
+++ 
d:/_opensg_merge/Comp/builder/support/opensg/Source/System/NodeCores/Drawables/Geometry/Properties/OSGGeoIntegralBufferRefProperty.cpp
  2017-05-11 11:11:59.379763500 +0200
@@ -117,22 +117,47 @@ void GeoIntegralBufferRefProperty::dump(
 SLOG << "Dump GeoIntegralBufferRefProperty NI" << std::endl;

 }

 

+/*-- tools --*/

+

+void GeoIntegralBufferRefProperty::validate(DrawEnv *pEnv)

+{

+if(this->getOsgGLId() != 0)

+{

+pEnv->getWindow()->validateGLObject(this->getOsgGLId(),

+pEnv  );

+}

+}

+

+Int32 GeoIntegralBufferRefProperty::getOpenGLId(DrawEnv *pEnv)

+{

+if(this->getOsgGLId() != 0)

+{

+return pEnv->getWindow()->getGLObjectId(this->getOsgGLId());

+}

+else

+{

+return this->getOglGLId();

+}

+}

+

 void GeoIntegralBufferRefProperty::activate(DrawEnv *pEnv, UInt32 slot)

 {

-Window *win = pEnv->getWindow();

-

-if(!win->hasExtOrVersion(_extVertexBufferObject, 0x0105, 0x0200))

+Window *pWin = pEnv->getWindow();

+

+if(!pWin->hasExtOrVersion(_extVertexBufferObject, 0x0105, 0x0200))

 return;

 

-if(getGLId() != 0 && getUseVBO()) // Do we have a VBO?

+if((getOsgGLId() != 0 || getOglGLId() != 0) && getUseVBO()) // Do we have 
a VBO?

 {

+validate(pEnv);

+GLuint id = this->getOpenGLId(pEnv);

+

 OSGGETGLFUNCBYID_GL3_ES( glBindBuffer, 

  osgGlBindBuffer,

 _funcBindBuffer, 

- win);

+ pWin);

 

-osgGlBindBuffer(GL_ELEMENT_ARRAY_BUFFER_ARB, 

-getGLId());

+osgGlBindBuffer(GL_ELEMENT_ARRAY_BUFFER_ARB, id);

 }

 }

 

@@ -145,22 +170,24 @@ void GeoIntegralBufferRefProperty::chang
 if(old == this)

 return;

 

-Window *win = pEnv->getWindow();

+Window *pWin = pEnv->getWindow();

 

 GeoIntegralProperty *o = dynamic_cast<GeoIntegralProperty*>(old);

 

-if(!win->hasExtOrVersion(_extVertexBufferObject, 0x0105, 0x0200))

+if(!pWin->hasExtOrVersion(_extVertexBufferObject, 0x0105, 0x0200))

 return;

 

 OSGGETGLFUNCBYID_GL3_ES( glBindBuffer, 

  osgGlBindBuffer,

 _funcBindBuffer, 

- win);

+ pWin);

 

-if(getGLId() != 0 && getUseVBO()) // Do we have a VBO?

+if((getOsgGLId() != 0 || getOglGLId() != 0) && getUseVBO()) // Do we have 
a VBO?

 {

-osgGlBindBuffer(GL_ELEMENT_ARRAY_BUFFER_ARB, 

-getGLId());

+validate(pEnv);

+GLuint id = this->getOpenGLId(pEnv);

+

+osgGlBindBuffer(GL_ELEMENT_ARRAY_BUFFER_ARB, id);

 }

 else if(o != NULL && o->getGLId() != 0 && o->getUseVBO())

 {

@@ -172,10 +199,13 @@ void *GeoIntegralB

Re: [Opensg-users] OpenSG2: Compute Shader...

[Johannes]

Hi Gerrit,

>> This sounds promising. But I we would transfer that into the geo
>> property ref classes we would still break backward compatibility because
>> of API naming.
>
> I'm actually ok with this as it won't compile (which is a pretty
> obvious hint that something changed ;)). The original commit
> unfortunately silently broke stuff as only the inner workings changed.
>
Ok I will give it a try.

I have one additional remark wrspt. to the ComputeShader stuff. 
Currently it is housed in the Contrib\ComputeBase library. Since many 
techniques are going to work with compute shaders nowadays, they are all 
doomed to live outside of the core libraries probably in their own 
techniques library that would be dependent on the Contrib\ComputeBase 
library. I was thinking along the line that it might be preferable to 
have to compute shader stuff as first class citizens like the other 
shader code. What do you think?

Best,
Johannes





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Compute Shader...

[Johannes]

Hello Carsten and Gerrit,

I'm really happy to hear from you again :-)

Allow  me to answer all the questions and remarks in this answer.

 > - For OSGComputeShaderAlgorithm is it possible to combine the
 >   useMemoryBarrier and memoryBarrier fields, i.e. if memoryBarrier
 >   is GL_NONE that means no memory barrier? That would allow
 >   controlling the barrier with a single field instead of requiring
 >   the setting of two.
Hmm, I don't think so. GL_NONE is not a valid (better listed of allowed) 
parameters to the glMemoryBarrier API. I wouldn't try this.

 > - Can you imagine a situation where a barrier is needed/useful
 >   before the compute shader? If so, should we have
 >   preMemoryBarrier/postMemoryBarrier fields instead?
I can't come up with a good scenario. Maybe if you would like to do some 
post processing of the buffer/image written by the fragment shader. I 
would wait until someone has a real need for that.

 > - In OSGGeo{Integral/Vector}BufferRefProperty you add getOpenGLId
 >   helper functions, but then they appear to not be used. Did I
 >   miss something?
Let me explain how I came up with this modification first.

I was writing example 'computeshader5.cpp' and have had the need to 
transport data from the compute shader to the fragment shader. In the 
compute shader I can modify either a shader storage buffer object or a 
texture image.
In this particular example, however, I have the need to use the written 
data from the compute shader in form of an array buffer in order to use 
them as input data into the vertex/fragment pipeline. I did see two 
possibilities for that scenario. Either setup a geo property and tell 
the compute shader that this buffer is basically a shader storage buffer 
object or the other way around, that is, to setup a shader storage 
buffer object and to tell the pipeline shaders that it is basically an 
array buffer.
Firstly, I did go with the second approach and I was positively 
surprised to find the GeoVectorBufferRefProperty that seemed to be 
invented for my scenario. That is, setup the shader storage buffer 
object and to provide the GL id to the GeoVectorBufferRefProperty 
object. Then I discovered that the Id provided to the property interface 
is taken directly instead of going the route over the 
pWin->getGLObjectId(getGLId()). At this point I thought that this is 
probably an implementation error or that it is simply not finished yet. 
So I changed it and went on with the example. It worked well this way.
Then I thought about the first approach, that is to setup the geo 
property in the first place and to reference that buffer as a shader 
storage buffer object. So I wrote the ShaderStorageBufferObjRefChunk and 
adapted the example accordingly. That also worked well and I leaved it 
in this final state.

 > small comment, the *Ref* classes are meant to refer to/reference
 > OpenSG external OpenGL objects, so validating them through OpenSG
 > and translating them to an OpenSG managed OpenGL Id is not the
 > intended behavior.
So I misinterpreted the idea of these guys. My scenario is referencing 
within OpenSG.

 > I'll revert that part right away. If Johannes has a
 > scenario where the previous behavior is not doing the right thing
 > we can figure out a correct change with more calm.
As the example currently works not with the GeoVectorBufferRefProperty 
but with the ShaderStorageBufferObjRefChunk the revert is not hurting. 
But I think that the scenario that I describe above is a valid and 
important one. So we should support it. Additionally, now we have a 
semantically interface break between the 'Ref' classes. We should find a 
solution that supports both scenarios equally.

 > There is one example actually using 2 ids, OSGTextureObjRefChunk.
I do not know this one and have to look it up.

 > This one has a oglGlId and an osgGlId if the OSG id is set the
 > normal OSG validation/mapping is done. If the oglGlId is set
 > only the GL calls are made. If both are set, the OpenSG id wins
 >
 > If there is a need to reference OpenSG internal properties this
 > might be the way to go.
This sounds promising. But I we would transfer that into the geo 
property ref classes we would still break backward compatibility because 
of API naming.

It is good that you have still interest in OpenSG. I have worked a lot 
recently on OpenSG. The last thing that I have finished is to write an 
ClusterShading example in the line of:

Ola Olsson, Markus Billeter, and Ulf Assarsson
High Performance Graphics (2012),  pp. 1–10
C. Dachsbacher, J. Munkberg, and J. Pantaleoni (Editors)
http://efficientshading.com/wp-content/uploads/clustered_shading_preprint.pdf
http://efficientshading.com/2013/08/01/practical-clustered-deferred-and-forward-shading/

This example works quite well and I will send it to the list in the near 
future. I have to do some polishing to get it upload ready. The 

Re: [Opensg-users] OpenSG2: Compute Shader...

[Johannes]

Hello Carsten,

is this still in the pipeline?

Best,
Johannes



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Compute Shader...

[Johannes]

Hi,

I have a small addition. I have added the necessary extensions to the 
OSGGLExt.h and OSGGLFuncProtos.h headers. The 
GL_ARB_image_shader_load_store was already present, so I have only added 
the GL_ARB_compute_variable_group_size extension.


Best,
Johannes





OpenSG2.azip
Description: Binary data
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Compute Shader...

[Johannes Brunen]

Hello Carsten and Gerrit,

I have some need for a compute shader and therefore I have learned its usage in 
OpenSG land. As a result I have some examples that I would like to see in 
OpenSG and some patches to the code base.

Let me first give you some information about the patches:

1. Main CMakeLists.txt file:
I have added a statement that allows you to bring boilerplate examples into the 
Examples/Advanced folder. I have added five examples into this folder because 
IMHO these are not simple anymore.

2. Source/Base/Base/OSGPolygon.cpp
Removed a compiler warning.

3. Source/Contrib/ComputeBase/ComputeShader/OSGComputeShaderAlgorithm.fcd
3.0. Added some documentation
3.1. Added a ChunkMaterial attribute that allows the use of 
ShaderStorageBufferObjs and UniformBufferObjs in conjunction to the 
TextureImageChunk. This allows you to bring multiple of these chunks into the 
compute shader.
3.2. Added the possible use of a glMemoryBarrier at the end of the computation.
3.3. Added the possible use of a variable work group size.

For 3.2 and 3.3 the following ARB must be available: 
GL_ARB_shader_image_load_store and GL_ARB_compute_variable_group_size
These provide the glMemoryBarrier and the glDispatchComputeGroupSizeARB APIs 
that are used.

ATTENTION: I have not added these to the OSGGLEXT.h and OSGGLFuncProtos.h 
files, because I do not work with them. I hope that this is Ok, and not too 
much of a burden to you.

4. 
Source/System/NodeCores/Drawables/Geometry/Properties/OSGGeoIntegralBufferRefProperty.cpp
 and

Source/System/NodeCores/Drawables/Geometry/Properties/OSGGeoVectorBufferRefProperty.cpp
At first, I was going to use these but decided otherwise. However, I think that 
their implementation is not correct with respect to the GL id.

5. Source/System/State/Base/OSGShaderStorageBufferObjChunk.cpp
Source/System/State/Base/OSGShaderStorageBufferObjStdLayoutChunk.cpp
Source/System/State/Shader/Variables/OSGShaderVariables.inl
I have changed the usage of calls like
hasExtOrVersion(_extUniformBufferObject, 0x0310);
getExtIdGPUShader4(), 0x0330, 0x0200))

to

hasExtOrVersion(_extUniformBufferObject, 0x0301);
getExtIdGPUShader4(), 0x0303, 0x0200))

That is the form found elsewhere in the code base. Could you confirm that this 
is the correct usage pattern?

6. Source/System/State/Base/OSGShaderStorageBufferObjRefChunk.fcd
This one is new and it allows you to bind a shader storage buffer object from 
an ordinary array buffer provided by the geo properties. This works fine if the 
array layout is compatible to the std430 layout format. That is the case for 
Pnt4f, Vec4f and Vec1f vector properties.

The compute shader examples I have written are numbers 1 to 5 and are of 
growing complexity. The first three build on the CSM compute shader example. 
Especially the first one is just a plain translation into C++ world. The second 
one is slight variation and uses a ShaderProgram instead of providing the 
source code directly to the ComputeShaderChunk. The third uses a 
ShaderStorageBufferObjChunk to provide some coloring into the compute shader. 
The fourth is a variation of the well known cylinder/torus example, but uses a 
compute shader to modify the material database which is a 
ShaderStorageBufferObjChunk. The fifth example uses the new 
ShaderStorageBufferObjRelChunk. It is a simple particle simulation, that does 
allows me to run as much as 6.000.000 particles in the simulation.

This contribution builds up on the last one I have send to the list (cc. to 
Carsten; mail still pending on the list, awaits moderation), e.g. it uses the 
MultiPropertySSBOChunk. However, the diff is against my last clone of the 
OpenSG master.

Best regards,
Johannes



OpenSG1.azip
Description: OpenSG1.azip
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] WG: OpenSG2: DepthPeeling example

[Johannes]

Hello Carsten,

sorry for the late answer but I was quite busy with the finishing of the 
MultiLightChunk that I have just send to the list.

On 09.03.2017 17:37, Carsten Neumann wrote:
>   Hello Johannes,
>
> On 2017-03-09 00:13, Johannes wrote:
>
>> Next, I know that you haven't written the DepthPeelingStage. What I
>> hoped to learn, is the 'correct' way of writing any Stage with respect
>> to transparency. If have debugged a little in the stage and see that in
>> a mixed transparency/opaque scene the rooted stage's renderEnter(Action*
>> action) method is called exactly once. That mean (correct my if I'm
>> wrong) that the stage is responsible for discriminating the transparent
>> from the opaque pass. For instance in the case of shadowing, the
>> transparent geometry should not be part of the shadow map generating
>> objects at all, because they do not cast any shadows. So part of a
>> shadow stage must be able to constrain on opaque geometries. Or in the
>> depth peeling case the opaque geometry must be rendered with other
>> materials and possibly other shader configuration. So there must be a
>> way to detect the render state in the shader.
>
> Hmm, I'm not sure if there is a general way. I believe some stages play
> tricks with the traversal mask - which isn't ideal as those bits should
> be available to the application.
>
> The separation of opaque and transparent objects happens at the DrawTree
> level. Those are constructed by the RenderPartition to decide the order
> objects are really being drawn in - allowing to sort by materials (for
> opaque objects, to reduce state changes) or depth (for transparent ones).
>
>> I'm looking for explanation of how these things are to be set up
>> correctly in any Stage implementation. I think that this is a central
>> point and I would like to learn these details in order to do my thinks
>> correctly.
>
> Those are valid questions; the thing is that I suspect that there may
> not be a straightforward answer to them. Especially with the more
> complex stages that essentially implement entire "rendering algorithms"
> compositing their results is in general not a problem with a totally
> obvious solution.
> Some of these methods were not even invented (or widely used at least)
> when the Stage abstraction was initially implemented and its initial use
> was to have a way to render to texture. If you have an algorithm that
> requires finer grained control over the rendering you may have to go
> into the bowels of the Render{Action,Partition} and extend what they expose.
>
>> On 08.03.2017 17:02, Carsten Neumann wrote:
>>>
>>>> Is it even possible to mix opaque and transparent geometry with the
>>>> DepthPeelingStage core or is the stage incomplete with respect to that 
>>>> task?
>>>
>>> I guess that is a possibility.
>>>
>> In that case it needs correction to be usable in the common case.
>
> True, but see above: compositing arbitrary rendering algorithms in all
> combinations automatically seems to me like it could turn into tricky
> problem.
>
>>> Transparent objects are rendered after opaque ones in back to front
>>> order (IIRC using the bounding box center).
>>>
>> Yes, but that is not enough in my understanding. There has to be a
>> pattern of how to write Stages with respect to transparency in the case
>> that different rendering setups are necessary for transparent and opaque
>> geometries.
>>
>>>> Could you please take a look into the example and give me some hint what
>>>> I'm doing wrong here?
>>>
>>> Not specifically, sorry. In general I would suspect it has something to
>>> do with the FBOs/Attachments the stages are rendering into and how they
>>> perform clearing.
>> I will have a look into the details.
>>
>> I really need more explanations for the RenderAction, RenderPartition,
>> Stage, transparency mix. I have searched the mailing list but did not
>> get enough information for sorting the issues in my head.
>
> The RenderAction (RA) traverses the scene tree visiting the NodeCores
> along the way. Drawable objects are collected into the active
> RenderPartition (RP, there is a default one that renders to the window
> backbuffer), which stores them into its DrawTree. The DrawTree is
> responsible for organizing objects in the "optimal" drawing order, by
> default separating opaque and transparent objects and ordering them
> differently (see above). IIRC the DrawTree is processed (i.e. drawing
> happens) when its owner RP is finalized.
> Stages use API on the RA to create 

Re: [Opensg-users] OpenSG2: dependency problem

[Johannes]

Hello Carsten,

thank you for your answer.

On 15.03.2017 19:55, Carsten Neumann wrote:
>   Hello Johannes,
>
> On 2017-03-15 05:45, Johannes Brunen wrote:
>> I'm in the process of writing a Chunk based class that depends on core
>> Transform. Nearly all chunks are sorted into System/State.  Transform is
>> in System/Group that is dependent on State. Should I sort my chunk class
>> into library Group though is belongs definitely into State?
>>
>> The problem is that my chunk is holding a beacon and does need to get
>> informed when the beacons transform changes. Therefore I add a changed
>> function entry into the Transform and beacon objects that allows me to
>> take proper action in any cases.
>
> can the beacon type be something derived from Transform instead? In that
> case perhaps split the functionality so that the Chunk only represents
> the state and the Transform derived type populates the Chunk with
> values. I think that would move the setup closer to how other parts of
> the system use Chunks, i.e. there is a user facing type that internally
> manages a chunk in order to communicate OpenGL state to the system.
>
I will remember that for the future, but in this case I have found a way 
around and I'm quite happy with the result. I have send the outcome of 
this work in a top level mail (and send a cc to you) and requested 
adoption in the framework.

Best,
Johannes



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: dependency problem

[Johannes Brunen]

Hello,

I have a dependency problem for that I'm looking for a proper solution.

I'm in the process of writing a Chunk based class that depends on core 
Transform. Nearly all chunks are sorted into System/State.  Transform is in 
System/Group that is dependent on State. Should I sort my chunk class into 
library Group though is belongs definitely into State?

The problem is that my chunk is holding a beacon and does need to get informed 
when the beacons transform changes. Therefore I add a changed function entry 
into the Transform and beacon objects that allows me to take proper action in 
any cases.

Best,
Johannes

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] WG: OpenSG2: DepthPeeling example

[Johannes]

Hi Carsten,

first off, my understanding is that the TransparencyForceTransparent, 
... give you the possibility to govern the process of transparency 
detection of a material. If you have a standard material this can be 
done automatically and therefore the default for the attribute is 
TransparencyAutoDetection. However, if you have a fancy material as in 
my case that does not have any known transparency characteristic you 
need to have a way to tell the system that your material is either 
transparent or opaque. At least that is my interpetration :-)

See the ChunkMaterial::isTransparent() implementation:

bool ChunkMaterial::isTransparent(void) const
{
 Int32 tm = getTransparencyMode();

 if(tm != Material::TransparencyAutoDetection)
 {
 return (tm == Material::TransparencyForceTransparent);
 }

 bool returnValue = false;

 MFChunksType::const_iterator chunksIt  = _mfChunks.begin();
 MFChunksType::const_iterator chunksEnd = _mfChunks.end  ();

 for(; chunksIt != chunksEnd && returnValue == false; ++chunksIt)
 {
 returnValue = (*chunksIt)->isTransparent();
 }

 return returnValue;
}

Next, I know that you haven't written the DepthPeelingStage. What I 
hoped to learn, is the 'correct' way of writing any Stage with respect 
to transparency. If have debugged a little in the stage and see that in 
a mixed transparency/opaque scene the rooted stage's renderEnter(Action* 
action) method is called exactly once. That mean (correct my if I'm 
wrong) that the stage is responsible for discriminating the transparent 
from the opaque pass. For instance in the case of shadowing, the 
transparent geometry should not be part of the shadow map generating 
objects at all, because they do not cast any shadows. So part of a 
shadow stage must be able to constrain on opaque geometries. Or in the 
depth peeling case the opaque geometry must be rendered with other 
materials and possibly other shader configuration. So there must be a 
way to detect the render state in the shader.

I'm looking for explanation of how these things are to be set up 
correctly in any Stage implementation. I think that this is a central 
point and I would like to learn these details in order to do my thinks 
correctly.

On 08.03.2017 17:02, Carsten Neumann wrote:
>
>> Is it even possible to mix opaque and transparent geometry with the
>> DepthPeelingStage core or is the stage incomplete with respect to that task?
>
> I guess that is a possibility.
>
In that case it needs correction to be usable in the common case.

>
> Transparent objects are rendered after opaque ones in back to front
> order (IIRC using the bounding box center).
>
Yes, but that is not enough in my understanding. There has to be a 
pattern of how to write Stages with respect to transparency in the case 
that different rendering setups are necessary for transparent and opaque 
geometries.

>> Could you please take a look into the example and give me some hint what
>> I'm doing wrong here?

>
> Not specifically, sorry. In general I would suspect it has something to
> do with the FBOs/Attachments the stages are rendering into and how they
> perform clearing.
I will have a look into the details.

I really need more explanations for the RenderAction, RenderPartition, 
Stage, transparency mix. I have searched the mailing list but did not 
get enough information for sorting the issues in my head.

Be patient with me :-)

Best,
Johannes






--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] WG: OpenSG2: DepthPeeling example

[Johannes Brunen]

Hello Carsten,

I'm playing around with the DepthPeelingStage and have written a simple 
example. For that I have taken the testDepthPeeling.cpp and merged it with the 
shaderstoragebufferobject_std430.cpp example. I have done this because I would 
like to have an example that uses transparent and opaque geometry and that uses 
the more elaborate shader code. The example is working somehow, but what I do 
not get right so far, is that the transparent geometry is correctly blended 
with the opaque geometry.

In extension to the attached example I also added the following code lines into 
the example:

geom1_state->setTransparencyMode(OSG::Material::TransparencyForceTransparent);
...
geom6_state->setTransparencyMode(OSG::Material::TransparencyForceTransparent);

This, however does also not bring the desired correct rendering.

Is it even possible to mix opaque and transparent geometry with the 
DepthPeelingStage core or is the stage incomplete with respect to that task?
How do I have to handle the task of differing actions with respect to 
transparency in a stage implementation at all?
How is blending of transparent and opaque rendering performed in the common 
case?

Could you please take a look into the example and give me some hint what I'm 
doing wrong here?

Additionally, I have tried to setup the HDR2 stage above of the DepthPeeling 
stage in another example. With that I do not get any rendering.  If I replace 
the HDR2 stage or the DepthPeeling stage by a simple Group core I got the 
expected rendering for the particular stage. Do you have any idea what is 
missing in that scenario where both stages are active?

Best,
Johannes

P.S. I have send you a Cc because I expect the mailing list to have trouble 
with the example attachment, sorry for that.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Clarification wrpt. to changed notification...

[Johannes Brunen]

Hello,

I'm currently writing a chunk class and I'm a little puzzled about the 
'whichField' and its usage that is provided to the 'changed' procedure.

I have found the following code in a number of classes:

void TextureChunk::changed(ConstFieldMaskArg whichField,...)
{
// Only filter changed? Mipmaps need reinit.
if((whichField & ~(MinFilterFieldMask | MagFilterFieldMask)) == 0)
{...

void TextureObjChunk::changed(ConstFieldMaskArg whichField,...)
{ ...
// Only filter changed? Mipmaps need reinit.
if((whichField & ~(MinFilterFieldMask | MagFilterFieldMask)) == 0)
{...

void GeoProperty::changed(ConstFieldMaskArg whichField, ...)
{
Inherited::changed(whichField, origin, details);

if(0x != (whichField & ~UsageFieldMask))
{...

void UniformBufferObjStd140Chunk::changed(ConstFieldMaskArg whichField,...)
{...
if((whichField & ~(UsageFieldMask | BufferFieldMask)) == 0)
{
Window::reinitializeGLObject(id);
...

and some more. The last one is created by myself :-(

After thinking about it, I come to the conclusion that this usage pattern is 
not correct. If I understand correctly the whichField contains a bit pattern 
that has a 1 for each field that has changed. Then if I would like to test if 
that bit is set, I have to do a bit wise & operation to that bit. So for 
instance the TextureObjChunk code should read:

void TextureObjChunk::changed(ConstFieldMaskArg whichField,...)
{ ...
// Only filter changed? Mipmaps need reinit.
if((whichField & (MinFilterFieldMask | MagFilterFieldMask)) != 0)
{...

Could someone check that please or give me some lecturing so that I understand 
correctly and do it right in the first place next time.

In the context of the my new chunk class I do have an additional  questions:

My chunk is derived from another chunk class that manages some OpenGL state. 
What is the correct way so that the parent chunk works correctly. What I mean 
is how can I force that the parent's 'activate', 'handleGL', etc. functions are 
properly called?
Is this allowed at all?

Best,
Johannes

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Fwd: Re: OpenSG2: Accumulated changes... part 6: LiPSM

[Johannes]

Hi Carsten,

small correction :-)>
> So Carsten, let me end this long mail with my appreciation to take the
> work of managing the library.

what I tried to say: ... with my appreciation that you take the work of ...

Best,
Johannes



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Accumulated changes... part 6: LiPSM

[Johannes]

Hello Carsten,

On 13.02.2017 23:32, Carsten Neumann wrote:
>
> I just spotted this in the new Plane::intersect(const LineSegment&,
> Real32&, Real32) function:
>
> if (t < -tolerance || tolerance > 1.f + tolerance)
> {
>  t = 0.f;
>  return false;
> }
>
> Shouldn't the condition be ... || t > 1.f + tolerance. IIUC this is
> meant to check if the parametric value t is in [0, 1] +/- epsilon.
>
Yes, of course. This is a typing error, sorry.

Best,
Johannes




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Problem with multi fields...

[Johannes Brunen]

Hello,

I have implemented a class that contains a multi field of category 
'weakpointer' (see extract of fcd file below) representing the beacons of the 
lights managed  by this class. Now I would like to add a function 
setBeacon(const UInt32 idx, Node* beacon) to my class. But I could not succeed 
in implementing that function . I always get compile errors. What I expected to 
be the right implementation is the following

void MultiRangeLightChunk::setBeacon(const UInt32 idx, Node* const beacon)
{
OSG_ASSERT(idx < _mfBeacon.size());
editMField(BeaconFieldMask, _mfBeacon);
_mfBeacon.replace(idx, beacon);
}

but that is not going to work. I get the following error for that code:

OSGPointerMField.inl(1173): error C2664:

typedef 
OSG::PointerMFieldCommon<OSG::PointerAccessHandler,0>  
 PointerMFieldCommon_t
typedef OSG::PointerMField   
PointerMField_t

'void 
PointerMFieldCommon_t::ptrStoreReplace(PointerMFieldCommon_t::PtrStoreItType,PointerMFieldCommon_t::const_value)'

: cannot convert argument 2 from
'OSG::Node *const ' to
'PointerMFieldCommon_t::const_value'

  Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast

  OSGPointerMField.inl(1172) : while compiling class template member 
function 'void PointerMField_t::replace(OSG::UInt32,OSG::Node *const )'
  OSGMultiRangeLightChunk.cpp(151) : see reference to function template 
instantiation 'void PointerMField_t::replace(OSG::UInt32,OSG::Node *const )' 
being compiled
  OSGMultiRangeLightChunkBase.h(222) : see reference to class template 
instantiation 'PointerMField_t' being compiled

I have tried a lot but do get not my head around this error. Does anyone know 
how to write correct setBeacon function in that scenario?

Help is really appreciated here.

Best,
Johannes






   
...





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Accumulated changes... part 2: link flags

[Johannes]

Hi,

finally I have finished the link flag undertaking :-)

Attached you can find the final diff file.

What I have done:

1. Added cmake variable OSG_WINDOWS_LINK_OPTIMIZE which defaults to OFF.
If the variable is ON the /OPT:REF /OPT:ICF are added to the
CMAKE_SHARED_LINKER_FLAGS_DEBUGOPT, CMAKE_SHARED_LINKER_FLAGS_RELEASE, 
CMAKE_EXE_LINKER_FLAGS_DEBUGOPT, and CMAKE_EXE_LINKER_FLAGS_RELEASE 
variables.


2. I removed the cmake code that tried to handle the INCREMENTAL linking 
in the DEBUG case. I have done that for two reasons:


  At first, I realized that the code is not working at all.
On my platform MSVC 2013 VC12 the CMAKE_SHARED_LINKER_FLAGS_DEBUG 
variable contains the following content at the beginning:

"/debug /INCREMENTAL".

The string replacement code in OSGSetupCompiler.cmake tries to replace 
string "INCREMENTAL:YES" with "INCREMENTAL:NO":


STRING(REPLACE "INCREMENTAL:YES" "INCREMENTAL:NO" replacementFlags 
${CMAKE_SHARED_LINKER_FLAGS_DEBUG})


That does not work, since the search string is not contained in the 
variable.


After that follows the code line:

SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG "/INCREMENTAL:NO 
${replacementFlags}" ).


That also won't work, since the "/INCREMENTAL" contained in the variable 
replacementFlags is appended to the CMAKE_SHARED_LINKER_FLAGS_DEBUG 
variable what finally leads to the following content of variable 
CMAKE_SHARED_LINKER_FLAGS_DEBUG:


"/INCREMENTAL:NO /debug /INCREMENTAL msvcprtd.lib msvcrtd.lib".

Thus the incremental linking is still active.

  Secondly, it is not desirable to do not incremental linking on the 
debug variant which is used at development times and thus requires short 
turn around times. I do not know for what reason that code was added to 
the OSGCompiler.cmake file but I strongly recommend to relinquish that part.


I hope that this patch pleases all parties.

Best,
Johannes


diff -rupN opensg_org/CMake/OSGSetupCompiler.cmake 
opensg_opt/CMake/OSGSetupCompiler.cmake
--- opensg_org/CMake/OSGSetupCompiler.cmake 2017-01-16 11:34:52.635334200 
+0100
+++ opensg_opt/CMake/OSGSetupCompiler.cmake 2017-02-01 15:31:25.547160100 
+0100
@@ -166,22 +166,26 @@ IF(MSVC)
 
 
 
-# Shared Linker Flags
 IF(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER "19")
SET(OSG_ADD_MSVC_STD_LIBS_DEBUG   "vcruntimed.lib ucrtd.lib")
SET(OSG_ADD_MSVC_STD_LIBS_RELEASE "vcruntime.lib ucrt.lib")
 ENDIF()
 
+IF(OSG_WINDOWS_LINK_OPTIMIZE)
+SET(windows_link_optimization "/OPT:REF /OPT:ICF")
+ENDIF()
+
+# Shared Linker Flags
 SET(CMAKE_SHARED_LINKER_FLAGS_RELEASENOOPT 
 "${CMAKE_SHARED_LINKER_FLAGS_DEBUG} msvcprt.lib msvcrt.lib 
${OSG_ADD_MSVC_STD_LIBS_RELEASE}"
 CACHE STRING "OpenSG defaults" FORCE )
 
 SET(CMAKE_SHARED_LINKER_FLAGS_DEBUGOPT 
-"${CMAKE_SHARED_LINKER_FLAGS_RELEASE} /debug msvcprtd.lib msvcrtd.lib 
${OSG_ADD_MSVC_STD_LIBS_DEBUG}"
+"${CMAKE_SHARED_LINKER_FLAGS_RELEASE} /debug 
${windows_link_optimization} msvcprtd.lib msvcrtd.lib 
${OSG_ADD_MSVC_STD_LIBS_DEBUG}"
 CACHE STRING "OpenSG defaults" FORCE )
 
 SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE 
-"${CMAKE_SHARED_LINKER_FLAGS_RELEASE} /debug msvcprt.lib msvcrt.lib 
${OSG_ADD_MSVC_STD_LIBS_RELEASE}"
+"${CMAKE_SHARED_LINKER_FLAGS_RELEASE} /debug 
${windows_link_optimization} msvcprt.lib msvcrt.lib 
${OSG_ADD_MSVC_STD_LIBS_RELEASE}"
 CACHE STRING "OpenSG defaults" FORCE )
 
 SET(CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL 
@@ -192,32 +196,23 @@ IF(MSVC)
 "${CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO} msvcprt.lib msvcrt.lib 
${OSG_ADD_MSVC_STD_LIBS_RELEASE}"
 CACHE INTERNAL "OpenSG defaults" FORCE )
 
-STRING(REPLACE "INCREMENTAL:YES" "INCREMENTAL:NO" replacementFlags 
${CMAKE_SHARED_LINKER_FLAGS_DEBUG})
-SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG "/INCREMENTAL:NO ${replacementFlags}" )
-
 SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG 
 "${CMAKE_SHARED_LINKER_FLAGS_DEBUG} msvcprtd.lib msvcrtd.lib 
${OSG_ADD_MSVC_STD_LIBS_DEBUG}"
 CACHE STRING "OpenSG defaults" FORCE )
 
-
-
+# Exe Linker Flags
 SET(CMAKE_EXE_LINKER_FLAGS_RELEASENOOPT 
 "${CMAKE_EXE_LINKER_FLAGS_DEBUG} msvcprt.lib msvcrt.lib 
${OSG_ADD_MSVC_STD_LIBS_RELEASE}"
 CACHE STRING "OpenSG defaults" FORCE )
 
-SET(CMAKE_EXE_LINKER_FLAGS_DEBUG 
-"${CMAKE_EXE_LINKER_FLAGS_DEBUG} msvcprtd.lib msvcrtd.lib 
${OSG_ADD_MSVC_STD_LIBS_DEBUG}"
-CACHE STRING "OpenSG defaults" FORCE )
-
 SET(CMAKE_EXE_LINKER_FLAGS_DEBUGOPT 
-"${CMAKE_EXE_LINKER_FLAGS_RELEASE} /debug msvcprtd.lib msvcrtd.lib 
${OSG_ADD_MSVC_STD_LIBS_DEBUG}"
+"

Re: [Opensg-users] OpenSG2: Accumulated changes... part 2: link flags

[Johannes]

Hi,

attached you can find the size numbers for the release dlls and pdb 
files that I have extracted from the opensg master build with and 
without the patch of OSGSetupCompiler.cmake. So we would be gaining 
around 22.5% of size reduction for the dlls.


Best,
Johannes

Microsoft Visual Studio Professional 2013
Version 12.0.40629.00 Update 5
  OpenSG- OpenSG-patched
  masterOPT:REF + OPT:ICFdiff
-
OSGBase.dll  10558976 7609856   27.9%
OSGCluster.dll1469440 1104896   24.8%
OSGContribBackgroundLoader.dll 139776   96256   31.1%
OSGContribComputeBase.dll 1637888 1273344   22.3%
OSGContribCSM.dll 4941824 3862528   21.8%
OSGContribCSMSimplePlugin.dll   23040   17920   22.2%
OSGContribDataSolid.dll   2893312 2193408   24.2%
OSGContribGUI.dll  720384  565248   21.5%
OSGContribPLY.dll  119296   60928   48.9%
OSGContribRhino3D.dll  138240   98816   28.5%
OSGContribTrapezoidalShadowMaps.dll352768  279552   20.8%
OSGContribVTK.dll  719360  546816   24.0%
OSGContribWebInterface.dll  99840   75264   24.6%
OSGDrawable.dll  10978304 8403456   23.5%
OSGDynamics.dll   8501760 6726656   20.9%
OSGEffectGroups.dll   5417984 4353536   19.6%
OSGFileIO.dll 3940352 2896384   26.5%
OSGGroup.dll  8133120 6411776   21.2%
OSGImageFileIO.dll 401920  321536   20.0%
OSGState.dll  5288448 4211712   20.4%
OSGSystem.dll2570905620341248   20.9%
OSGText.dll318464  204800   35.7%
OSGUtil.dll   1854976 1363456   26.5%
OSGWindow.dll 6321664 4988928   21.1%
OSGWindowGLUT.dll  331776  263168   20.7%
OSGWindowWIN32.dll 528896  402432   23.9%
OSGBase.pdb  8598732852817920   38.6%
OSGCluster.pdb   1607680011841536   26.3%
OSGContribBackgroundLoader.pdb4567040 4042752   11.5%
OSGContribComputeBase.pdb1624883212365824   23.9%
OSGContribCSM.pdb3878502428561408   26.4%
OSGContribCSMSimplePlugin.pdb 2928640 28794881.7%
OSGContribDataSolid.pdb  2621030418903040   27.9%
OSGContribGUI.pdb 9080832 7548928   16.9%
OSGContribPLY.pdb 4583424 4067328   11.3%
OSGContribRhino3D.pdb 5910528 53616649.3%
OSGContribTrapezoidalShadowMaps.pdb   6877184 6025216   12.4%
OSGContribVTK.pdb 9662464 7696384   20.3%
OSGContribWebInterface.pdb3788800 3084288   18.6%
OSGDrawable.pdb  7599308851105792   32.7%
OSGDynamics.pdb  5910937642078208   28.8%
OSGEffectGroups.pdb  3830169627832320   27.3%
OSGFileIO.pdb4452761629356032   34.1%
OSGGroup.pdb 5770035241463808   28.1%
OSGImageFileIO.pdb6565888 5533696   15.7%
OSGState.pdb 3548364825890816   27.0%
OSGSystem.pdb   167505920   116101120   30.7%
OSGText.pdb   7852032 5820416   25.9%
OSGUtil.pdb  2322022416035840   30.9%
OSGWindow.pdb5198233637908480   27.1%
OSGWindowGLUT.pdb 5296128 4583424   13.5%
OSGWindowWIN32.pdb6467584 5132288   20.6%

diff -rupN opensg_org/CMake/OSGSetupCompiler.cmake 
opensg/CMake/OSGSetupCompiler.cmake
--- opensg_org/CMake/OSGSetupCompiler.cmake 2017-01-16 11:34:52.635334200 
+0100
+++ opensg/CMake/OSGSetupCompiler.cmake 2017-01-27 10:28:53.746851700 +0100
@@ -172,16 +172,24 @@ IF(MSVC)
SET(OSG_ADD_MSVC_STD_LIBS_RELEASE "vcruntime.lib ucrt.lib")

Re: [Opensg-users] OpenSG2: Accumulated changes... part 2: link flags

[Johannes]

Hello Marcus,

I will implement your suggestion and provide a new diff for that. But 
before I will take the time to build both versions so that I have 
numbers that I can provide. Please stay tuned, it will take one day or 
another.

Carsten, please wait before check in. I will give it another try.

Best,
Johannes




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Accumulated changes... part 2: link flags

[Johannes]

Hello Marcus and Carsten,

First of, we also do need debugging symbols in release builds.

Microsoft writes on
https://msdn.microsoft.com/en-us/library/windows/desktop/ee416349(v=vs.85).aspx

"You also need to take steps to maintain full compiler optimizations 
while generating symbols."

- set Debug Information Format to Program Database (/Zi).
- set Generate Debug Info to Yes (/DEBUG).
- set References to Eliminate Unreferenced Data (/OPT:REF).
- set Enable COMDAT Folding to Remove Redundant COMDATs (/OPT:ICF).

That reference initiated my initial change of the code generation of all 
of our libraries and executables since we have started to generate 
memory dumps on crash in release code.

The flags are detailed on
https://msdn.microsoft.com/en-us/library/bxwfs976(v=vs.120).aspx

/OPT:REF eliminates functions and data that are never referenced;
/OPT:ICF to perform identical COMDAT folding. Redundant COMDATs can be 
removed from the linker output.

Usage of /OPT:REF implicitly sets /OPT:ICF.
Usage of /Zi /DEBUG implicitly sets /OPT:NOREF

/OPT:ICF is controversial. Microsoft recommends to use OPT:NOICF to 
preserve identical functions in debugging builds.

"If /DEBUG is specified, the default for /OPT is NOREF, and all 
functions are preserved in the image. To override this default and 
optimize a debugging build, specify /OPT:REF. Because /OPT:REF implies 
/OPT:ICF, we recommend that you also specify /OPT:NOICF to preserve 
identical functions in debugging builds. This makes it easier to read 
stack traces and set breakpoints in functions that would otherwise be 
folded together. The /OPT:REF option disables incremental linking."

On 25.01.2017 11:05, Marcus Lindblom Sonestedt wrote:
> We need debugging symbols in release builds.
>
> If OPT:REF / OPT:ICF doesn't conflict with /Zi and pdb-generation, I
> have no objections.
>
I'm not quite sure on that. Probably the /OPT:REF /OPT:NOICF is the 
better combination.

Finally, I think that best we should create some cmake options for that, 
so that nobody is negatively affected. Then we can experiment a little 
with these settings and see what is best.

What do you think,

Best,
Johannes





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Accumulated changes... part 3: texture

[Johannes]

Hello Carsten,

On 21.01.2017 00:01, Carsten Neumann wrote:
> Can you adjust the changes to TextureBuffer/LayeredTextureBuffer
> to be in line with the above? Thanks!

here we go :-)

Best Johannes


diff -rupN ./opensg_org/Source/System/State/Base/OSGTextureObjChunk.cpp 
./opensg_texture/Source/System/State/Base/OSGTextureObjChunk.cpp
--- ./opensg_org/Source/System/State/Base/OSGTextureObjChunk.cpp
2017-01-16 11:34:55.022138400 +0100
+++ ./opensg_texture/Source/System/State/Base/OSGTextureObjChunk.cpp
2016-09-26 12:15:54.703999700 +0200
@@ -480,7 +480,8 @@ void TextureObjChunk::handleTexture(Wind
 }
 
 if((imgtarget == GL_TEXTURE_1D_ARRAY ||
-imgtarget == GL_TEXTURE_2D_ARRAY  )  &&
+imgtarget == GL_TEXTURE_2D_ARRAY ||
+imgtarget == GL_TEXTURE_CUBE_MAP_ARRAY)  &&
!win->hasExtOrVersion(_extTextureArray, 0x0300))
 {
 FWARNING(("texture arrays not supported on Window %p!\n",
@@ -596,18 +597,21 @@ void TextureObjChunk::handleTexture(Wind
 glTexParameteri(paramtarget, GL_TEXTURE_MAG_FILTER, 
getMagFilter());
 glTexParameteri(paramtarget, GL_TEXTURE_WRAP_S, getWrapS());
 
-if(paramtarget == GL_TEXTURE_2D   ||
-   paramtarget == GL_TEXTURE_2D_ARRAY ||
-   paramtarget == GL_TEXTURE_3D   ||
-   paramtarget == GL_TEXTURE_CUBE_MAP_ARB ||
-   paramtarget == GL_TEXTURE_RECTANGLE_ARB )
+if(paramtarget == GL_TEXTURE_2D ||
+   paramtarget == GL_TEXTURE_2D_ARRAY   ||
+   paramtarget == GL_TEXTURE_3D ||
+   paramtarget == GL_TEXTURE_CUBE_MAP_ARB   ||
+   paramtarget == GL_TEXTURE_CUBE_MAP_ARRAY ||
+   paramtarget == GL_TEXTURE_RECTANGLE_ARB   )
 {
 glTexParameteri(paramtarget, GL_TEXTURE_WRAP_T, getWrapT());
 }
 
-if(paramtarget == GL_TEXTURE_2D_ARRAY ||
-   paramtarget == GL_TEXTURE_3D   ||
-   paramtarget == GL_TEXTURE_CUBE_MAP_ARB  )
+if(paramtarget == GL_TEXTURE_2D_ARRAY   ||
+   paramtarget == GL_TEXTURE_3D ||
+   paramtarget == GL_TEXTURE_CUBE_MAP_ARB   ||
+   paramtarget == GL_TEXTURE_CUBE_MAP_ARRAY  )
+   
 {
 glTexParameteri(paramtarget, GL_TEXTURE_WRAP_R, getWrapR());
 }
@@ -748,6 +752,7 @@ void TextureObjChunk::handleTexture(Wind
 break;
 case GL_TEXTURE_3D:
 case GL_TEXTURE_2D_ARRAY:
+case GL_TEXTURE_CUBE_MAP_ARRAY:
 osgGlCompressedTexImage3D(
 imgtarget, 
 i - baseLevel, 
@@ -802,6 +807,7 @@ void TextureObjChunk::handleTexture(Wind
 break;
 case GL_TEXTURE_3D:
 case GL_TEXTURE_2D_ARRAY:
+case GL_TEXTURE_CUBE_MAP_ARRAY:
 osgGlTexImage3D(imgtarget, 
 i - baseLevel, 
 internalFormat,
@@ -1124,6 +1130,7 @@ void TextureObjChunk::handleTexture(Wind
break;
case GL_TEXTURE_3D:
case GL_TEXTURE_2D_ARRAY:
+   case GL_TEXTURE_CUBE_MAP_ARRAY:
osgGlCompressedTexImage3D(imgtarget, 0, 
  internalFormat,
  osgNextPower2(width),
@@ -1192,6 +1199,7 @@ void TextureObjChunk::handleTexture(Wind
break;
case GL_TEXTURE_3D:
case GL_TEXTURE_2D_ARRAY:
+   case GL_TEXTURE_CUBE_MAP_ARRAY:
osgGlTexImage3D(imgtarget, 
0, 
internalFormat,
@@ -1269,6 +1277,7 @@ void TextureObjChunk::handleTexture(Wind
 break;
 case GL_TEXTURE_3D:
 case GL_TEXTURE_2D_ARRAY:
+case GL_TEXTURE_CUBE_MAP_ARRAY:
 osgGlCompressedTexImage3D(imgtarget, 0, 
   internalFormat,
   width, height, depth, 
@@ -1315,6 +1324,7 @@ void TextureObjChunk::handleTexture(Wind
 break;
 case GL_TEXTUR

Re: [Opensg-users] OpenSG2: Accumulated changes... part 3: texture

[Johannes]

Hello Carsten,

first off, I'm not an expert with textures. First I will show you how I 
initialize my shadow maps in my plain OpenGL example. So that you 
understand what I want to map into OpenSG land.

Example: [1]

Next the sources I have studied:
https://www.khronos.org/opengl/wiki/Framebuffer_Object
https://www.khronos.org/opengl/wiki/Geometry_Shader#Layered_rendering

https://www.opengl.org/sdk/docs/man/html/glFramebufferTextureLayer.xhtml
https://www.opengl.org/sdk/docs/man/html/glFramebufferTexture.xhtml


I have reread these articles and I now tend to agree with you wrt to the 
LayeredTextureBuffer. However, the GL_TEXTURE_CUBE_MAP_ARRAY is missing 
nevertheless (?)

This stuff is not easy to grasp. Most important for me is that I have 
the OpenSG primitives at hand that I need to translate my plain OpenGL 
shadow implementation into OpenSG land.

Best,
Johannes


[1]
void OpenGLWindow::InitializeShadowFBO()
{
 if (_shadow_casters_point > 0)
 {
 glGenTextures(1, &_texture_shadow_array_point_id);
 glBindTexture(GL_TEXTURE_CUBE_MAP_ARRAY, 
_texture_shadow_array_point_id);

 glTexImage3D(
 GL_TEXTURE_CUBE_MAP_ARRAY,
 0,
 GL_DEPTH_COMPONENT,
 SHADOW_WIDTH,
 SHADOW_HEIGHT,
 6 * _shadow_casters_point,
 0,
 GL_DEPTH_COMPONENT,
 GL_FLOAT,
 nullptr);

 glTexParameteri (GL_TEXTURE_CUBE_MAP_ARRAY, 
GL_TEXTURE_MIN_FILTER,   GL_NEAREST);
 glTexParameteri (GL_TEXTURE_CUBE_MAP_ARRAY, 
GL_TEXTURE_MAG_FILTER,   GL_NEAREST);
 glTexParameteri (GL_TEXTURE_CUBE_MAP_ARRAY, GL_TEXTURE_WRAP_S, 
  GL_CLAMP_TO_EDGE);
 glTexParameteri (GL_TEXTURE_CUBE_MAP_ARRAY, GL_TEXTURE_WRAP_T, 
  GL_CLAMP_TO_EDGE);
 glTexParameteri (GL_TEXTURE_CUBE_MAP_ARRAY, GL_TEXTURE_WRAP_R, 
  GL_CLAMP_TO_EDGE);

 for (unsigned int i = 0; i < _shadow_casters_point * 6; i++)
 {
 GLuint fbo_id;
 glGenFramebuffers(1, _id);

 glBindFramebuffer(GL_FRAMEBUFFER, fbo_id);
 glFramebufferTextureLayer(GL_FRAMEBUFFER, 
GL_DEPTH_ATTACHMENT, _texture_shadow_array_point_id, 0, i);

 glDrawBuffer(GL_NONE);
 glReadBuffer(GL_NONE);

 glBindFramebuffer(GL_FRAMEBUFFER, 0);
 }

 glBindTexture(GL_TEXTURE_CUBE_MAP_ARRAY, 0);
 }

 if (_shadow_casters_dir > 0)
 {
 glGenTextures(1, &_texture_shadow_array_dir_id);
 glBindTexture(GL_TEXTURE_2D_ARRAY, _texture_shadow_array_dir_id);

 glTexImage3D(
 GL_TEXTURE_2D_ARRAY,
 0,
 GL_DEPTH_COMPONENT,
 SHADOW_WIDTH,
 SHADOW_HEIGHT,
 _shadow_casters_dir,
 0,
 GL_DEPTH_COMPONENT,
 GL_FLOAT,
 nullptr);

 glTexParameteri (GL_TEXTURE_2D_ARRAY, GL_TEXTURE_WRAP_S, 
GL_CLAMP_TO_BORDER);
 glTexParameteri (GL_TEXTURE_2D_ARRAY, GL_TEXTURE_WRAP_T, 
GL_CLAMP_TO_BORDER);

 GLfloat borderColor[] = { 1.0, 1.0, 1.0, 1.0 };
 glTexParameterfv(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_BORDER_COLOR, 
borderColor);
 glTexParameteri (GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MIN_FILTER, 
GL_NEAREST);
 glTexParameteri (GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAG_FILTER, 
GL_NEAREST);

 for (unsigned int i = 0; i < _shadow_casters_dir; i++)
 {
 GLuint fbo_id;
 glGenFramebuffers(1, _id);

 glBindFramebuffer(GL_FRAMEBUFFER, fbo_id);
 glFramebufferTextureLayer(GL_FRAMEBUFFER, 
GL_DEPTH_ATTACHMENT, _texture_shadow_array_dir_id, 0, i);

 glDrawBuffer(GL_NONE);
 glReadBuffer(GL_NONE);

 glBindFramebuffer(GL_FRAMEBUFFER, 0);
 }
 glBindTexture(GL_TEXTURE_2D_ARRAY, 0);
 }
  }



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Accumulated changes... part 3: texture

[Johannes Brunen]

Hi,

on request of Carsten I have split up my 'accumulated changes' into smaller 
chunks so that it easier to look at them.

Currently, I'm working on shadow techniques. For these I do need texture 
arrays, especially cube map arrays. I have added support to the TexureObjChunk 
and to LayeredTextureBuffer and TextureBuffer.
The last two did have an 'unused' field named 'zoffset'. According to the specs 
of GL the correct parameter name is 'layer' and I have modified the Interface 
accordingly. See the .fcd files for that.

Additionally the Buffers work with the 'glFramebufferTextureLayer' API of 
OpenGL now.

Best,
Johannes





opensg_texture_diff
Description: opensg_texture_diff
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Accumulated changes... part 2: link flags

[Johannes Brunen]

Hi,

on request of Carsten I have split up my 'accumulated changes' into smaller 
chunks so that it easier to look at them.

This change does only affect the MSVC windows build. OpenSG is traditionally 
build with the compiler flag /Zi on windows even in the optimized cases. That 
results in generation of the .pdb database files that can be used for debugging 
purposes. However, I think that it is recommended to use the following linker 
flags in that case: /OPT:REF /OPT:ICF in the optimized cases.

>From the docs: https://msdn.microsoft.com/en-us/library/bxwfs976.aspx

/OPT:REF eliminates functions and data that are never referenced;
/OPT:ICF to perform identical COMDAT folding. Redundant COMDATs can be removed 
from the linker output.

By default, /OPT:REF is enabled in non-debug builds.
When /OPT:REF is enabled either explicitly or by default, a limited form of 
/OPT:ICF is enabled that only folds identical functions.

If /DEBUG<https://msdn.microsoft.com/en-us/library/xe4t6fc1.aspx> is specified, 
the default for /OPT is NOREF, and all functions are preserved in the image. To 
override this default and optimize a debugging build, specify /OPT:REF. Because 
/OPT:REF implies /OPT:ICF, we recommend that you also specify /OPT:NOICF to 
preserve identical functions in debugging builds. This makes it easier to read 
stack traces and set breakpoints in functions that would otherwise be folded 
together. The /OPT:REF option disables incremental linking.

Best,
Johannes




opensg_link_flags_diff
Description: opensg_link_flags_diff
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Accumulated changes... part 4: math

[Johannes Brunen]

Hi,

on request of Carsten I have split up my 'accumulated changes' into smaller 
chunks so that it easier to look at them.

At first,  I have added a ' setValue' function to the Matrix class that takes 4 
vector parameters. I did miss that somewhere.

Secondly, I have extended MatrixUtility file. I have added some new convenience 
APIs for the creation of matrices commonly used.

Best,
Johannes



opensg_math_diff
Description: opensg_math_diff
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Commits 53e16c and 0177b7

[Johannes]

Hello Gerrit,

I still would like to get an answer from you. Let me rephrase my point:

 > Currently I'm working with recent stuff
 > of the GL specification and it is annoying to always add the missing
 > things piece by piece, forgetting this piece and that piece or doing  it
 > wrong somehow in the first place. That does always leads to a compile
 > link cycles which take their time. So I thought that it would be perfect
 > to have all symbols and prototypes of the most recent GL spec at hand.
 > What I did was merely to split the prototypes and renamed them to the
 > osgGL... convention. Now, that has worked perfect to me. IMHO, if you
 > need the gl... prototypes under different conditions, that could also 
 > be
 > mapped into my scheme.

and

 > I see, but isn't it the problem of the non spec conforming content of
 > the /usr/include/GL/glext.h file? If you compile against that file you
 > can't use any of the extensions that use GLuint64EXT types in its
 > signature or you would have compatibility issues. Actually, I'm puzzled
 > why /usr/include/GL/glext.h is included at all? Where is the #include
 > statement for that file?

and finally

 > It would be fine if we could found some common ground on that issue,
 > however.

So I don't see what could be wrong by working on complete and the most 
recent content of the gl specification.

Best,
Johannes



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: LightEngine and light information in shader

[Johannes Brunen]

Hello,

currently I'm working on a shader shadow engine example and have realized that 
the light information is not available in the shader as I expected. I did 
expected that the OSGLightNActive variables are defined and that the OpenGL 
light structure gl_LightSource is valid. The reason is, imho, that the 
Light::renderEnter method does not perform any action, but  delegates all the 
work to the engine's runOnEnter method. Obviously the ShaderShadowMapEngine:: 
runOnEnter does not care about that.

I have a couple of Questions for that:

1. Is my analysis correct?
2. Is it a bug or is it intentional?

I'm planning to use more lights than the 8 OpenGL standard lights. Additionally 
these lights may carry some extra information compared to the standard ones. In 
the end, I would like to have an uniform buffer object that does contain all 
the light information in an array of light structures.

3. How would you design such a scenario?

I have not yet understand what would be the correct place to setup the UBO of 
the lights. I would like to use light cores/chunks as usual in my scene graph, 
i.e. not  bypassing the system by directly defining the UBO myself. I could 
imagine that a core at the top the scene graph could be responsible for 
accumulation of the light information and setting up the UBO for shader based 
rendering.

Finally, I'm heading to use a shadow map engine that I'm planning to write that 
performs shadowing on these lights.

I would really appreciate some help on these two related topics.

To be clear, the problem with the OSGLightNActive and the gl_LightSource 
structure relates to the simple first example with the ShaderShadowMapEngine  
that I'm writing. I did have  tried to use an off- the-shelf light shader and 
it did not work, because of the missing information. But what I really would 
like to solve is the scenario with many shadowing lights in a forward rendering 
approach.

Best,
Johannes

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hello Carsten,

On 13.07.2016 12:30, Johannes wrote:
> Hello Carsten,
>
> On 01.07.2016 18:17, Carsten Neumann wrote:
>>
>> I suspect the problem is that the texture memory is not initialized,
>> because there is no data specified for the OSG::Image used with the
>> OSG::TextureObjChunk - which is mostly fine since these textures are
>> used as render targets before they are read for the first time - except
>> for the adaptive luminance texture from the previous frame (which has
>> undefined content on the very first frame).
>> For this texture we would need a way to initialize it when it is
>> created. I haven't thought through all the consequences, but one way to
>> do this is add a field SFVector4f "ClearValues" to TextureObjChunk and
>> if the Image has no data issue the glClearTexImage call when creating
>> the OpenGL texture object in TextureObjChunk::handleTexture.
>>
> I will take a look into this.
>
I have implemented that, but it does not solve this particular problem. :-(

I have no further ideas and will leave it in the current state.

Best,
Johannes



--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Commits 53e16c and 0177b7

[Johannes]

Hello Gerrit,

I'm really happy to hear from you.

On 28.09.2016 21:02, Gerrit Voß wrote:

> sorry for taking so long to answer, it's currently silly season ;)
I hope that things settle for you. :-)

> currently I pull on demand and split the defines and functions.
That was what I tried to avoid. Currently I'm working with recent stuff 
of the GL specification and it is annoying to always add the missing 
things piece by piece, forgetting this piece and that piece or doing it 
wrong somehow in the first place. That does always leads to a compile 
link cycles which take their time. So I thought that it would be perfect 
to have all symbols and prototypes of the most recent GL spec at hand. 
What I did was merely to split the prototypes and renamed them to the 
osgGL... convention. Now, that has worked perfect to me. IMHO, if you 
need the gl... prototypes under different conditions, that could also be 
mapped into my scheme.

> The reason behind that is that on Linux (where I spend most of my time) I
> can directly build against OpenGL 4.x libraries. OSGGLFuncProtos.h
> is build in a way that I can switch between the window based extension
> mechanism and direct linking.

>
> What I usually do if I need newer functionality which is not
> inside either OSGGLExt.h or OSGGLFuncProtos.h depends on the system
> I'm on. On Linux I just define GL_GLEXT_PROTOTYPES before anything else
> and am done with it.

> On Windows I use glew (set
> OSG_ENABLE_GL_INCLUDE_GLEW to TRUE and make sure glew is available).
> The only trick is that one has to intialize glew at the right time.
>
> Once I'm done testing I pull the required things over to OSGGLExt and
> OSGGLFuncProtos.


>
> The problem with just dumping things in there was the following:
>
> In file included
> from 
> /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLDefineMapper.h:47:0,
>
> from 
> /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLDefineMapper.cpp:45:
> /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLEXT.h:1523:18: 
> error: conflicting declaration ‘typedef uint64_t GLuint64EXT’
>  typedef uint64_t GLuint64EXT;
>   ^
> In file included from /usr/include/GL/gl.h:1630:0,
>
> from /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGL.h:71,
>
> from 
> /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGBaseTypeTraits.h:49,
>
> from 
> /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGBaseTypes.h:837,
>
> from 
> /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGSingletonHolder.h:45,
>
> from 
> /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLDefineMapper.h:46,
>
> from 
> /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLDefineMapper.cpp:45:
> /usr/include/GL/glext.h:3901:28: note: previous declaration as ‘typedef
> long long unsigned int GLuint64EXT’
>  typedef unsigned long long GLuint64EXT;
>  ...
I see, but isn't it the problem of the non spec conforming content of 
the /usr/include/GL/glext.h file? If you compile against that file you 
can't use any of the extensions that use GLuint64EXT types in its 
signature or you would have compatibility issues. Actually, I'm puzzled 
why /usr/include/GL/glext.h is included at all? Where is the #include 
statement for that file?

>
> that's how I bumped into it and that's why I like it a little bit more
> controlled, and also more nicely formatted ;)
Ok, I agree on that, but probably I define control slightly differently 
than you. ;-)

Formatting is another issue, that could be enhanced in my approach so.

It would be fine if we could found some common ground on that issue, 
however.

Best,
Johannes




--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Win/MSVC2010 - pull request added to vossg-repo on github

[Johannes]

Hello Marcus,

On 28.09.2016 15:41, Marcus Lindblom Sonestedt wrote:
> Hi Johannes!
>
> On the pull request, is there an offical github repo somewhere else?
I think that the official repo is at

https://sourceforge.net/p/opensg/code/ci/master/tree/

> Who picks up your patches from the mail-list?
Carsten did all the administration and merging tasks lately. I think he 
is rather busy with other stuff and does not use OpenSG that much in his 
daily work anymore (Carsten correct me if I'm wrong).

> (Also, these guys don't use cygwin, so I had to fix it for windows, even
> though it was only two classes...)
You are welcome :-)

>
> Currently I'm helping a company to move to OpenSG2 as their dataset
> requires 64-bit addressing, but I don't think they plan to do too much
> with OpenSG after that.
> This was the easiest way to get 64-bit without rewriting the entire app,
> but I don't see any needs for them to grow OpenSG outside what is there
> at the moment.
Yes I see. OpenSG 2 is working pretty fine on 64-bit Windows.

>
> The places I've been previously that've used OpenSG are looking for
> options, mainly because development is dropping (their/my fault too, not
> making any contribs) and OpenSG is a bit too big & complex for their
> needs and a scene-graph isn't really state-of-the-art in how one express
> a 3D scene anymore (most game engines, and Qt 3d 2.0, use an entity
> based approach instead, and an frame/render-graph for stages).
Could you elaborate a little so that I fully understand what that mean.

>
> Maybe one could revive OpenSG, but I've never used the
> aspect-over-network and I don't think many ppl will.
> Doing GL calls in a render-thread is enough, and that's doable via
> easier methods that full on aspect-copy.
Actually, we also do not use the network capabilities of OpenSG.

>
> Btw, I've gone from Lead Dev to a consultant so I've done most of my
> hacking in C# the last two years, on various projects in various places,
> and this task was something that fit well, as I've used OpenSG for ~10
> years. But I'm not employed here, just helping out with my previous
> C++/OpenSG2 experience.
It would be fine to have you on board for some time and hopefully you 
find proper projects in the future.

Best,
Johannes



--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Commits 53e16c and 0177b7

[Johannes]

Hello again,

I have just started to compile my code with the two extension files from 
the master and got compiler errors because 
osgGlFramebufferTextureLayerProc is missing from prototypes header.

Best,
Johannes



--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: Commits 53e16c and 0177b7

[Johannes Brunen]

Hello,

I have just discovered that one of my contributions (OSGGLEXT.h, 
OSGGLFuncProtos.h) which Carsten has pushed with commit 53e16c to the master 
tree has been 'reverted' by Gerrit with commit 0177b7. I did  made the changes 
in order to stay as close as possible to the official glext.h and wglext.h 
files. The commit of Gerrit has the following log message:

"changed: some clean-up, check if most of these files can be auto-generated"

Gerrit, did that mean, that you regularily update these files from the official 
header files with some code generation machinery? I would be fine with that if 
I could do the same on my local setup. Otherwise I think that it is easier the 
way I did choose.

What is your position?

I think that it should be at most easy to compare the current official 
extension files with the OpenSG files in order to update these if necessary.

Best,
Johannes


--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes Brunen]

Hello Carsten,

On 07/30/2016 15:09 AM, Carsten wrote:


>> 1. I added the Qhull library. Currently it is not used at all, but I'm

>> planning to use it in the OpenSG Base library in the near future.

>>

>> Link: http://www.qhull.org/

>>   https://github.com/qhull/qhull/wiki

>

> hmm, to me in general it is preferable to add dependencies when they are

> used...
>
I understand that, it was only that I just did the CMake build system stuff and 
I hoped that I could close this topic for now.


>> 2. I added the glm and vmath libraries. I do not intend to use them in

>> any OpenSG libraries nor in any example, but here and then I use them in

>> my examples for testing some code fragments. They are used a lot in the

>> OpenGL community and sometimes it is quite useful to have them at hand.

>> If the libraries are not present nothing awful will be happen. I would

>> really appreciate support for these. The changes are really minimal.

>

> Perhaps I'm misunderstanding something, but if the code is not going

> into OpenSG or examples why does the build system have to know about

> these libs in the first place? If it's just for something you are

> hacking on it seems easier to just hardcode the include path into the

> cmake file - especially given that these libraries seem to be header

> only. Anyway, if you feel strongly about this let me know and we can add

> them.


I'm used to make OpenSG examples for my stuff that are not of  interest to the 
public. For these examples I sometimes use vmath and glm. If I would have 
support for these libraries, I could always easily add my examples to my local 
OpenSG distribution copy and everythink is in place for productive working. 
What I do not like is to have many patches, that I have to apply to the 
official code base after I have taken it from the net, in order to get going. 
Adding some files to the OpenSG code base is fine for me but changing any 
official file by patching it is not ok. Additionally, in that case license 
issues would pop up. So these two libraries are a little bit special but since 
the changes are so minor I hope that you could do me this favor.

Best,
Johannes

P.S.: Since my thunderbird  news client that I use for list communication has 
problems to show up all send messages I could not answer directly to your 
message. Probably my answer will be llisted into the wrong place. Sorry for 
that.

--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hello Carsten,

On 01.07.2016 18:17, Carsten Neumann wrote:


I suspect the problem is that the texture memory is not initialized,
because there is no data specified for the OSG::Image used with the
OSG::TextureObjChunk - which is mostly fine since these textures are
used as render targets before they are read for the first time - except
for the adaptive luminance texture from the previous frame (which has
undefined content on the very first frame).
For this texture we would need a way to initialize it when it is
created. I haven't thought through all the consequences, but one way to
do this is add a field SFVector4f "ClearValues" to TextureObjChunk and
if the Image has no data issue the glClearTexImage call when creating
the OpenGL texture object in TextureObjChunk::handleTexture.


I will take a look into this.



On linux it is more about the default compiler dialect. GCC 6.1
(released 2016-04) is the first release that switched the default to
C++14 (previous C++98). So while it had full support for C++11 for a
long time it is not enabled by default.
That means system compiler for distributions that are widely used at
this point in time need an extra compiler switch to compile C++11 code.

I would not bother with that. C++11 and C++14 are such a huge leap that 
it would be a shame to stick to old C++03, at least for the long time. 
However, I will of course respect your decision :-)




The overload of std::vector::erase() that takes a const_iterator
overload is a C++11 addition, before erase() required a iterator
argument, see http://en.cppreference.com/w/cpp/container/vector/erase


I didn't know that.


Third, I'm still hoping for a CMake build system solution for the
AntTweakBar library, that allows me to easily integrate the library in
the generated example projects. Do you have an idea how to setup things
for that. If not, however, I will take some time to come up with a
solution, hopefully.


I haven't gotten around to that. If you want to take a stab at it that
would certainly be appreciated. It should be possible to model this
after the existing external dependencies (e.g. image format libs). So
add a OSG_CONFIGURE_ANTTWEAKBAR macro to
CMake/OSGConfigurePackages.cmake and call find_package() from there. For
more details I'll have to dive back into the build system myself, been a
while that I looked at it.


Attached you can find a patch file that contains the CMake build system 
adaptation for AntTweakBar.


Besides, it contains additional changes to CMake build system in order 
to support some other libraries.


1. I added the Qhull library. Currently it is not used at all, but I'm 
planning to use it in the OpenSG Base library in the near future.


Link:   http://www.qhull.org/
https://github.com/qhull/qhull/wiki

2. I added the glm and vmath libraries. I do not intend to use them in 
any OpenSG libraries nor in any example, but here and then I use them in 
my examples for testing some code fragments. They are used a lot in the 
OpenGL community and sometimes it is quite useful to have them at hand. 
If the libraries are not present nothing awful will be happen. I would 
really appreciate support for these. The changes are really minimal.


Remark 1: AntTweakBar, glm and vmath only show up in the Simple examples 
targets.


Remark 2: I'm not that proficient in the OpenSG CMake build system that 
I can testimony that the changes are correct for every platform. I only 
work on the Microsoft Windows platform and do not know the rules for 
Linux, OSX, etc. On my Windows platform everythink is working fine, so.


I hope that OpenSG can support these four libraries in the way I do need 
them.


Best,
Johannes

diff -rupN org/opensg/CMake/FindAntTweakBar_OpenSG.cmake 
new/opensg/CMake/FindAntTweakBar_OpenSG.cmake
--- org/opensg/CMake/FindAntTweakBar_OpenSG.cmake   1970-01-01 
01:00:00.0 +0100
+++ new/opensg/CMake/FindAntTweakBar_OpenSG.cmake   2016-07-12 
16:39:18.318756300 +0200
@@ -0,0 +1,49 @@
+# - Find AntTweakBar
+# Find the native AntTweakBar includes and library
+# This module defines
+#  ANTTWEAKBAR_INCLUDE_DIR, where to find AntTweakBar/include/AntTweakBar.h.
+#  ANTTWEAKBAR_LIBRARIES, the libraries needed to use AntTweakBar.
+#  ANTTWEAKBAR_FOUND, If false, do not try to use AntTweakBar.
+# also defined, but not for general use are
+#  ANTTWEAKBAR_LIBRARY, where to find the AntTweakBar library.
+
+FIND_PATH(ANTTWEAKBAR_INCLUDE_DIR AntTweakBar/include/AntTweakBar.h)
+
+SET(ANTTWEAKBAR_NAME AntTweakBar)
+IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
+SET(ANTTWEAKBAR_NAME AntTweakBar64)
+ENDIF()
+
+SET(ANTTWEAKBAR_NAMES_RELEASE ${ANTTWEAKBAR_NAMES_RELEASE} ${ANTTWEAKBAR_NAME})
+FIND_LIBRARY(ANTTWEAKBAR_LIBRARY_RELEASE NAMES ${ANTTWEAKBAR_NAMES_RELEASE} )
+
+SET(ANTTWEAKBAR_NAMES_DEBUG ${ANTTWEAKBAR_NAMES_DEBUG} ${ANTTWEAKBAR_NAME})
+FIND_LIBRARY(ANTTWEAKBAR_LIBRARY_DEBUG NAMES ${ANTTWEAKBAR_NAMES_DEBUG} )
+
+IF(ANTTWEAKBAR_LIBRARY_DEBUG)
+  SET(ANTTWEAKBAR_LIBRARIES_

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hello Carsten,

On 01.07.2016 18:17, Carsten Neumann wrote:
 >
 > I suspect the problem is that the texture memory is not initialized,
 > because there is no data specified for the OSG::Image used with the
 > OSG::TextureObjChunk - which is mostly fine since these textures are
 > used as render targets before they are read for the first time - except
 > for the adaptive luminance texture from the previous frame (which has
 > undefined content on the very first frame).
 > For this texture we would need a way to initialize it when it is
 > created. I haven't thought through all the consequences, but one way to
 > do this is add a field SFVector4f "ClearValues" to TextureObjChunk and
 > if the Image has no data issue the glClearTexImage call when creating
 > the OpenGL texture object in TextureObjChunk::handleTexture.
 >
I will take a look into this.

 >
 > On linux it is more about the default compiler dialect. GCC 6.1
 > (released 2016-04) is the first release that switched the default to
 > C++14 (previous C++98). So while it had full support for C++11 for a
 > long time it is not enabled by default.
 > That means system compiler for distributions that are widely used at
 > this point in time need an extra compiler switch to compile C++11 code.
 >
I would not bother with that. C++11 and C++14 are such a huge leap that 
it would be a shame to stick to old C++03, at least for the long time. 
However, I will of course respect your decision :-)

 >
 > The overload of std::vector::erase() that takes a const_iterator
 > overload is a C++11 addition, before erase() required a iterator
 > argument, see http://en.cppreference.com/w/cpp/container/vector/erase
 >
I didn't know that.

 >> Third, I'm still hoping for a CMake build system solution for the
 >> AntTweakBar library, that allows me to easily integrate the library in
 >> the generated example projects. Do you have an idea how to setup things
 >> for that. If not, however, I will take some time to come up with a
 >> solution, hopefully.
 >
 > I haven't gotten around to that. If you want to take a stab at it that
 > would certainly be appreciated. It should be possible to model this
 > after the existing external dependencies (e.g. image format libs). So
 > add a OSG_CONFIGURE_ANTTWEAKBAR macro to
 > CMake/OSGConfigurePackages.cmake and call find_package() from there. For
 > more details I'll have to dive back into the build system myself, been a
 > while that I looked at it.

You can find a patch file that contains the CMake build system 
adaptation for AntTweakBar on Wikisend:

http://wikisend.com/download/506872/org.patch

Besides, it contains additional changes to CMake build system in order 
to support some other libraries.

1. I added the Qhull library. Currently it is not used at all, but I'm 
planning to use it in the OpenSG Base library in the near future.

Link:   http://www.qhull.org/
https://github.com/qhull/qhull/wiki

2. I added the glm and vmath libraries. I do not intend to use them in 
any OpenSG libraries nor in any example, but here and then I use them in 
my examples for testing some code fragments. They are used a lot in the 
OpenGL community and sometimes it is quite useful to have them at hand. 
If the libraries are not present nothing awful will be happen. I would 
really appreciate support for these. The changes are really minimal.

Remark 1: AntTweakBar, glm and vmath only show up in the Simple examples 
targets.

Remark 2: I'm not that proficient in the OpenSG CMake build system that 
I can testimony that the changes are correct for every platform. I only 
work on the Microsoft Windows platform and do not know the rules for 
Linux, OSX, etc. On my Windows platform everythink is working fine, so.

I hope that OpenSG can support these four libraries in the way I do need 
them.

Best,
Johannes




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hello Carsten,

On 01.07.2016 01:14, Carsten Neumann wrote:

>> ...
>>
>> and the problem is gone for me. Could you check that in your setup please.
>
> hmm, it now is non-deterministic, i.e. sometimes it works sometimes it
> does not. I suspect that is because the texture contents are indeed
> undefined.
> Ideally we would have a way to issue a glClearTex{Sub,}Image call to
> initialize the texture content.
>
Could you elaborate a little at which place do you think that this api 
should be called.

>
> I went ahead and added it anyway, that should hopefully make it easier
> to iterate on it since it only requires sending patches instead of
> entire files.
Yes, that makes it easier.

I have some minor nitpicking questions:

First, why do you do not accept the nullptr instead of macro NULL? Do we 
really have to support such ancient compilers from the pre c++11 time?

Second, you did make a change in OSGStateOverride.cpp from a 
const_iterator to a mutable iterator. What was the reason for that change?

Third, I'm still hoping for a CMake build system solution for the 
AntTweakBar library, that allows me to easily integrate the library in 
the generated example projects. Do you have an idea how to setup things 
for that. If not, however, I will take some time to come up with a 
solution, hopefully.

Thanks again!

Best,
Johannes



--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hello Carsten,

On 24.06.2016 00:21, Carsten Neumann wrote:
>
> ok, using the HDR background image I can reproduce the problem on linux.

That is good to hear. I do not like errors that only show up under 
special circumstances :-)

> If I modify the tonemapping example to not create the scene on startup
> (i.e. remove the call to setupScene() from Example::initialize() and
> instead add the following to the switch in Example::keyboard():
>
> case '1':
>  {
>  std::cout << "Loading scene... " << std::flush;
>  setupScene();
>  std::cout << "done." << std::endl;
>  _mgr->showAll();
>  }
>  break;
>
> Pressing '1' at runtime creates the scene and then it looks as expected.
> Not sure what to make of this finding.

Ok, that did bring me to some new experiments:

I have changed the function setupAdaptLuminanceMaterial in line 1026 in 
the following way:

I replaced the following line of code (line 1041)

chunkMat->addChunk(pData->getLuminanceTexObjChunk(), 0);

with this one

chunkMat->addChunk(pData->getAdaptLuminanceTexObjChunk(!pData->getCurrentAdaptLuminanceIdx()),
 
0);

and the problem is gone for me. Could you check that in your setup please.

Actually, that is the line that is intended by theory. I did have used 
the initial line of code for the following reason. I have first 
programmed the complete example in a pure OpenGL setup without OpenSG. 
There, I couldn't initialize the last adapted luminance texture without 
actually rendering it first. Therefore, I fooled the setup insofar that 
I initialized the last adapted luminance texture for the first 'ping', 
with the luminance texture written by the luminance render target. I 
expected the same must hold in OpenSG land and mapped the code accordingly.

Ok, when this also works for you, I would like to ask you if the code 
can be added into the OpenSG2 code base?

Also, I would like to ask for a simple method to add the AntTweakBar 
library via CMake flags to the generated projects?

Hopefully you like the HDR2 stage and it meets the standards set by OpenSG.

I do also have some other things in the pipeline for which we have to 
talk a little in the near future. So I hope you are not tired for 
assisting me with my problems.

Again, Carsten, thank you for taking your time. I hope that I will gain 
some speed in the future to contribute good things to OpenSG.

Best,
Johannes





--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hello Carsten,

On 17.06.2016 20:28, Carsten Neumann wrote:

> sorry for the very long delay on this. I had a severe deadline that
> prevented me from looking at anything unrelated to ${DAYJOB}.
>
It is good to here from you :-) Hope that you could serve your task in time.

> On 05/24/2016 02:30 AM, Johannes wrote:
>> I'm still hoping for some help with my HDR stage problem. I have updated
>> all files again to wikisend:
>> http://wikisend.com/download/544744/OpenSG_files.zip
>
> hmm, unfortunately it has expired again. Do you perhaps have a google
> drive or dropbox account (or similar) that keeps the files around
> without expiration?
No not currently. But I will investigate in the future. For now, I have 
reloaded the last zip file to wikisend:

http://wikisend.com/download/870064/OpenSG_files.zip

> In any case I'm attaching two images from running the tonemapping
> example (on linux) before and after performing a resize - the background
> color in both cases is RGB (0, 0, 180).
> I've also built with AntTweakBar to look at the various debug
> visualizations and the ExposureMap always comes out as gray (not solid
> black) after waiting for a moment to let the auto-adjustment settle.
> I've also run the whole thing under apitrace to capture the OpenGL
> commands issued, but there are around ~1000 OpenGL calls per frame
> making it challenging to find the difference between what happens on
> initialization vs. on a resize. Nothing jumped out at me as an obvious
> problem (I was mainly looking at viewport and texture sizes in the trace).

Maybe it is a problem that only shows up on windows? However, I do have 
the problem on on different computer with differing windows versions as 
well as differing graphic platforms (NVIDIA and AMD). I think that it 
must somehow be related to the cube map that is used in the example. But 
this guesswork and not very profound.

> The next two weeks should be a bit calmer for me, so I can be more
> responsive ;)

I really appreciate that.

My intention is the following:

1. Resolve the issue so that the stage is working properly.

2. Correct the code so that it follows the rules and intentions of 
OpenSG. For instance, I'm a bit unsure about the HDR2Stage::changed(...) 
implementation, which currently basically is empty.

3. Optimize the stage as far as possible so that it can be used without 
hesitations.

For point 2 and 3 I really do need a reviewer with experience in OpenSG 
land. I have undoubtedly made mistakes, but currently I'm on the 
learning curve from flatland to space.


Thank you again for taking your time.

Best,
Johannes





--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hi,

I'm still hoping for some help with my HDR stage problem. I have updated 
all files again to wikisend:

http://wikisend.com/download/544744/OpenSG_files.zip

You can find two zip files in this zip: OpenSG_1.zip is the original 
code I send. And OpenSG_2.zip contains the requested pictures and some 
minor enhancements to the code.

I would really appreciate some help here :-)

Best,
Johannes



On 17.05.2016 11:25, Johannes wrote:
> Hello Carsten and Gerrit,
>
> I have reloaded the zip file to
>
> http://wikisend.com/download/702966/OpenSG.zip
>
> because the former link was expired.
>
>
> Do you have had time to take a look. I really hope that you can spot the
> origin of the problem. I would like to bring this stage into the
> official OpenSG repository. I have dedicated a lot of time into this
> piece of code and I would like to bring it to a successful end.
>
> Best,
> Johannes
>
>
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>



--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hello Carsten and Gerrit,

I have reloaded the zip file to

http://wikisend.com/download/702966/OpenSG.zip

because the former link was expired.


Do you have had time to take a look. I really hope that you can spot the 
origin of the problem. I would like to bring this stage into the 
official OpenSG repository. I have dedicated a lot of time into this 
piece of code and I would like to bring it to a successful end.

Best,
Johannes




--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: New HDR stage

[Johannes]

Hello Carsten,

thanks for taking your time!

On 09.05.2016 23:45, Carsten Neumann wrote:
>
> hmm, after fixing some small build issues (the gcc of Fedora 22 still
> defaults to C++98 and was barfing on some C++11'isms) it seems the
> example is working for me. At least I can see the colors adjust based on
> the brightness of the image content - I'm running without the
> AntTweakBar stuff, so only using initial settings for everything.
> Can you perhaps send a screenshot of the problem or describe what is
> going wrong?
>
Yes, I have uploaded images and small enhancements of the HDR2 stage and 
the example to Wikisend:

http://wikisend.com/download/451168/OpenSG.zip

The enhancements allows me to set the mipmap level from the example. I 
used that for images 6.png to 8.png.

Ok, what you can find in the zip files is:

1.png and 2.png:
I tried to not use the AntTweakBar library in order to rule it out as 
the cause of my problems. But the library has nothing to do with it.
In the 1.png you see the screenshot just after I have started the 
example. You can see that the colors are all much to bright. After 
resizing the image about a small amount with the mouse I took image 
2.png and now all rendering is as expected, i.e. correct.

3.png, 4.png and 5.png:
Know I have enabled the AntTweakBar library in order to tweak the 
example a little. 3.png shows the example just after start up. Again the 
colors are much to bright. Now I have changed the output texture to the 
Exposure Map and you can see in image 4.png that the screen is totally 
black. That means that the average luminance map is not correct. Image 
4.png is taken after resizing the window and you can see that the screen 
is pale gray, i.e. the  average luminance map is functioning.

6.png, 7.png and 8.png:
In this set of images I have used the new functionality that allows me 
to adjust the mipmap level used for lookup of the average luminance. See 
HDR2Stage::genFuncGetAvgLuminance() called by HDR2Stage::genSharedCode() 
which is called by HDR2Stage::genCompositeFragmentShader().
Image 6.png shows the example after startup and changing of the mipmap 
level to zero. The red arrow pointing to the mirror sphere shows 
artefacts that do stay at the original position after change of view 
point. This can be seen in image 7.png. Lastly, image 8.png shows that 
the artefacts vanish after resizing of the example window.

> What
> exactly do you mean by "... provide CMake support for AntTweakBar", i.e.
> what is missing to make it work or work better?
>
What I mean is that I would like to do the same as I do for e.g. the 
jpeg library. I.e. I call cmake with the following defines with respect 
to the jpeg library:

-D JPEG_INCLUDE_DIR=$CompInstallDir/Install${i}/include
-D JPEG_LIBRARY_RELEASE=$CompInstallDir/Install${i}/lib/jpeg.lib
-D JPEG_LIBRARY_DEBUG=$CompInstallDir/Install${i}/lib/jpegD.lib

That is cmake knows that the jpeg library is a dependency of the OpenSG 
project and ask for these entries in the cmake GUI.

Currently, I modify the MS VC project by hand, but I would like to 
generate them with the AntTweakBar set up already.


Hope that my explanations help :-)

Best,
Johannes






--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: New HDR stage

[Johannes Brunen]

Hello Carsten and Gerrit,

I have implemented a new HDR stage and I would like to ask for some  help with 
it. I have written a test and an example for this new stage. Essentially it is 
working but I get some strange behavior on startup of the examples. I.e. if I 
start the example/test the mipmap generated texture that I use in the stage is 
not working correctly. After resizing the window about some amount suddenly it 
starts working. The problem does not show up if I do not use the cube mapped 
sphere in the example/test. I have tried a lot but can't locate the problem. 
The problem shows up on my ATI and on my NVidia platform with recent drivers. 
So I could really use some help for this.

Additionally, I have written a special foreground in order to allow AntTweakBar 
integration. The example does make use of it. In the example is a flag that 
allows to enable or disable the GUI. However, in order to use AntTweakBar the 
OpenSG example (tonemapping.cpp) does have to include and link against the 
library. Currently, I do setup this by hand in my VC++ project. It would be 
nice if OpenSG would provide CMake support for AntTweakBar. For complex stuff 
like the tonemapping example it does really help for testing and experimenting.

The example and the new stage is not polished and optimized in any way. But I 
would really like to track down the above problem first.

I have uploaded to code to ' wikisend' and you can download it with the 
following link:

http://wikisend.com/download/628564/OpenSG.zip

I would really appreciate some help and stay tuned to hear from you.

Best,
Johannes

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: CMake build system

[Johannes]

Hi Carsten,

I think that this issue is not merged correctly into the git master.
The CMakeLists.Lib.OSGContribCSMSimplePlugin.txt file now contains the 
following line of code:

TARGET_LINK_LIBRARIES(simplePluginApp ${OSG_GLOBAL_LIB})

but it has to be

TARGET_LINK_LIBRARIES(simplePluginApp ${${OSG_GLOBAL_LIB}})

in order to work correctly.

Could you please change the file accordingly.

Sorry, that I do not have detected this earlier but I do not build this 
target regularly.

Best,
Johannes


On 11.11.2015 17:02, Carsten Neumann wrote:
>  Hello Johannes, Gerrit,
>
> On 2015-10-22 07:41, Johannes wrote:
>> I have one additional small problem with the build system. I got an
>> unresolved external symbol error from a missing memmanager library in
>> target simplePluginApp. That target is somehow special and does not add
>> the OSG_GLOBAL_LIB dependencies. I have temporarily added the following
>> line of cmake code
>
> hmm, why is that not a problem for the tests? I guess the difference is
> they link with at least one OpenSG library and pull in the memmanager
> symbols that way?
>
>> TARGET_LINK_LIBRARIES(simplePluginApp ${${OSG_GLOBAL_LIB}})
>> into
>> Contrib/CSMPlugin/SimpleTest/CMakeLists.Lib.OSGContribCSMSimplePlugin.txt
>>
>> which resolves this error. Probably there is a more elegant solution
>> that would be more in the line of the other executable targets?
>
> Given that this is indeed a special target that (intentionally) does not
> link with any OpenSG libs and also avoids the rest of the build
> machinery this is probably the simplest solution.
>
> Gerrit: I'll push the attached patch in a few days if there are no
> objections. Thanks!
>
>  Cheers,
>  Carsten
>
>
> --
>
>
>
> ___
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>



--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: HDR example

[Johannes]

Hello Carsten,

thanks for instant reply.

On 01.03.2016 18:22, Carsten Neumann wrote:
>
> On 2016-03-01 10:52, Johannes Brunen wrote:
>>
>> How do I get the floating point format render target if I use the HDRStage?
>   > Where does it come from?
>
> I suspect that is controlled by the bufferFormat field of HDRStage.
>
Sorry Carsten, but I did not formulate my question appropriate. What I 
currently did not understand correctly is at what point does the 
floating point render target, managed by the HDRStage, replaces the 
normal display render target. It boils down to an understanding problem 
of Stages, Partitions and grouping of the latter, I think. Could you 
explain these concept for me?

Say I have 3 Stages s1, s2 and s3 that I have placed on top of each 
other in the scene. Each stage does have its own render target defined. 
How happens the hand shake between them and with the display draw 
buffer? Which one is rendered first?

I would like to be able to write Stages myself and do need a thorough 
understanding of what are the underlying rules and ideas.

>> How can I setup my own tone mapping shader with the HDRStage?
>
> It does not look like that is a customization point at the moment.
> Either making HDRStage::generateHDRFragmentProgram virtual (assuming a
> new shader uses the same uniforms) or a new stage for your algorithm
> would be needed.
>
I will think about it.

>> Do I always have to pay for the shrinking  and blurring stuff?
>
> That is used for the bloom effect where bright light sources/surfaces
> "bleed" into adjacent fragments. I guess the HDRStage could be optimized
> to skip these steps if the settings that control them are at 0.
>
Oh, I lacked the fantasy that this could be an implementation of the 
bloom effect. Actually, I'm interested in this effect too :-)

>
>> How can I rescue the depth buffer from the original scene rendering into
>> the display depth buffer?
>
> Hmm, I don't recall how other stages handle that, does glBlitFramebuffer
> work for the depth attachment?
In principle it does. The recent FBOBackground and FBOForeground rely on 
this feature.

This is important to me, since we need to render into the display buffer 
after OpenSG render action has finished. For that the depth buffer must 
be valid.

Same question arises for other Stages as well, especially for the 
ShadowStage.

Best,
Johannes



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG 2: HDR example

[Johannes Brunen]

Hello,

I would like to build a HDR example. I have read the following chapter about 
HDR:

http://www.learnopengl.com/#!Advanced-Lighting/HDR

and now I try to get exactly that with OpenSG.

If I understand the article correct I do need to render into a floating point 
format color target. Here are some questions I have...

How do I get the floating point format render target if I use the HDRStage?
Where does it come from?
How can I setup my own tone mapping shader with the HDRStage?
Do I always have to pay for the shrinking  and blurring stuff?
What does the shrinking do at all?
How can I rescue the depth buffer from the original scene rendering into the 
display depth buffer?

Sorry for bothering,

best,
Johannes

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Separate Opaque from translucent objects

[Johannes]

Hello Michael and Carsten,

I'm also interested in this topic and would like to ask if you have 
found a solution to the problem.

Additionally, do you have any idea if it is possible to use the 
DepthPeelingStage in conjunction to the DefferedShadingStage?

Best,
Johannes


On 02.04.2015 16:40, Carsten Neumann wrote:
>  Hello Michael,
>
> On Thu, Apr 2, 2015 at 8:28 AM, Michael Raab <michael-r...@gmx.de> wrote:
>> for deferred shading purposes I would like to separate opaque from
>> translucent objects as I would like to render translucent objects in a
>> separate forward pass after the deferred shading phase for opaque objects.
>> If I investigated that correctly, after the call to recurseFromThis() in
>> DeferredShadingStage::scheduleGBufferPass() the active partition should hold
>> two filled lists of functors, an opaque and a translucent one.
>> I thought of the following sequence:
>> 1.) Copy the current partition (including the mentioned lists)
>> 2.) Clear translucent list from active partion
>> 3.) Clear opaque list in cloned partition
>> 4.) Schedule shading pass
>> 5.) Push cloned partition
>> 6.) Draw the 3 partitions in sequence
>>
>> The things that need to be implemented from my point of view should be:
>> - a clone function for partitions
>> - a push-method using partion pointers
>> - clear functions for opaque and translucent functor list
>>
>> Do you see any problems I'm not aware of? Did I miss something?
>
> hmm, IIRC RenderPartitions are allocated off of pools to avoid having
> to hit the system memory allocated too often and to allow for reuse of
> the storage allocated by their members (e.g. allow reuse of any
> std::vectors they contain) and in general requesting a new partition
> also sets it up to be rendered.
> The lists of opaque and translucent objects are subtrees of the
> DrawTree that the partitions build up when traversing the scene. The
> nodes of the DrawTree are also allocated from pools (usually quite a
> few DrawTreeNodes are needed each frame) and probably don't have
> existing API to duplicate them (especially duplicate them on a
> different pool).
> I guess it's possible to do what you are describing, there are some
> details (like the pool allocation) that may need some working around.
>
>  Cheers,
> Carsten
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: sRGB and Gamma correction

[Johannes]

Hello Carsten,

On 12.12.2015 01:02, Carsten Neumann wrote:
>   Hello Johannes,
>
> I've not forgotten about the FBO/scissor issue, ...
>
Sorry for badgering, but one month has passed by and I would like to ask 
if you have not forgotten about the FBO/scissor issue?

Best,
Johannes





--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: sRGB and Gamma correction

[Johannes Brunen]

Hello,

I would like to write my shader correctly with respect to Gamma correction. 
After spending some time I see two possible routes for that.

1. Explicitly write the conversions into the shader code, e.g. after texture 
fetch or before writing the fragment color.
2. Use the OpenGL extensions that provide support for the sRGB color space, 
i.e. EXT_texture_sRGB and ARB_framebuffer_sRGB.

I would like to apply the second case because it simplifies the shader code and 
is expected to provide more performance. Is this case supported by OpenSG and 
if not could we add the missing parts into the framework?

Does anyone know in detail what have be to be done in order to support these 
two extensions?

Best,
Johannes

--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: FBOBackground and FBOGrabForeground

[Johannes]

Hello Carsten,

I think I have found the origin of the problem. However, I'm not sure 
about the validity of the solution I have implemented and that you can 
find in the zip file attachment.


The problem stems from enabled scissor testing in the blit operations of 
the FBOGrabForeground and of the FBOBackground. I have disabled the test 
and then my code runs fine.


If this observation is correct then other parts of the OpenSG might also 
be affected. Generally, the framebuffer object blit operation takes part 
of the scissor testing.


Best,
Johannes




OpenSG.azip
Description: Binary data
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: FBOBackground and FBOGrabForeground

[Johannes]

Hello Carsten,

what is the state of affairs?
Are you waiting for me to proceed or on a response from Gerrit?

Hi Gerrit, are you listening?

I would like to finalize this topic :-)


Best,
Johannes



> On 20.11.2015 18:48, Carsten Neumann wrote:

>> I think the blit in FBOForeground should use the pEnv viewport
>> dimensions as source (pEnv->getPixelLeft(), ..., pEnv->getPixelRight()
>> +1, ...) and the entire FBO as destination (0,0, fbo->width, fbo->height).
>> I'm holding off adding the FBOForeground and example so we can come to
>> an agreement what values are best here.



--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: FBOBackground and FBOGrabForeground

[Johannes]

Hello Carsten,

On 20.11.2015 18:48, Carsten Neumann wrote:
> On 2015-11-19 09:50, Johannes Brunen wrote:

>> 2.) For experimentation I did put some clear buffer code into the
>> FBOBackground clear function. I have provided a modified FBOBackground
>> along with the new stuff in the attached zip file. In this source you
>> can activate the buffer clearing with define DEBUG_CLEAR_BACKGROUND.
>
> I assume that is meant purely for debugging purposes? I may well be
> missing something but outside of debugging I don't see a reason to clear
> the buffers we are about to overwrite with the blit?
>
yes, only for debugging.

> I'll check places where glBlitFramebuffer is used, since those seem the
> most likely to have a problem.
thank you.

>
> I think the blit in FBOForeground should use the pEnv viewport
> dimensions as source (pEnv->getPixelLeft(), ..., pEnv->getPixelRight()
> +1, ...) and the entire FBO as destination (0,0, fbo->width, fbo->height).
> I'm holding off adding the FBOForeground and example so we can come to
> an agreement what values are best here.
>
ok.

>> For instance, I'm still unsure about the
>> implications of an multsampling render GL context of the window.
>
> I'm not sure what you are asking. To the extend that I understand it
> glBlitFramebuffer is capable of blitting between multisampled and
> single-sampled buffers (at the very least in the direction of multi ->
> single).
You gave me just a new piece of information with you answer. My scenario 
is that I might have a multisampled render context window and a non 
multisampled framebuffer object. I was unsure whether I did have also to 
use a multsampling framebuffer object when I have such a render context.

> So my hope would be that things "just work" ...
That would be best :-)

Greetings,
Johannes




--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG 2: FBOBackground and FBOGrabForeground

[Johannes Brunen]

Hello Carsten and Gerrit,

after Gerrit was so kind to provide a FBOBackground on my request, I have taken 
the time to write a FBOGrabForeground and two examples showing these in action.

The first one, named dyndrawing1.cpp uses a FBO that is created from the scene 
with the help of a SimpleStage, a VisitSubTree and a PassiveViewport. This FBO 
is then used in the new FBOBackground.

The second one, named dyndrawing2.cpp is quite similar to the first one, but 
the FBO is filled with the help of my new FBOGrabForeground class that I would 
like to see in OpenSG.

Both examples work reasonably but nevertheless some things are not perfect or 
need some clarifications. May I ask for some help here?

Let me enumerate the points:

1.) In the class FBOBackground Gerrit has used the following BlitFramebuffer 
statement in function clear:

osgGlBlitFramebuffer(
 0,
 0,
_sfFrameBufferObject.getValue()->getWidth (),
_sfFrameBufferObject.getValue()->getHeight(),

pEnv->getPixelLeft  (),
pEnv->getPixelBottom(),
pEnv->getPixelRight (),
pEnv->getPixelTop   (),

(GL_COLOR_BUFFER_BIT  |
 GL_DEPTH_BUFFER_BIT  |
 GL_STENCIL_BUFFER_BIT),
GL_NEAREST);

Is it not better to state the source points also from the pEnv dimensions? I'm 
unsure here and would like to hear your opinion.

2.) For experimentation I did put some clear buffer code into the FBOBackground 
clear function. I have provided a modified FBOBackground along with the new 
stuff in the attached zip file. In this source you can activate the buffer 
clearing with define DEBUG_CLEAR_BACKGROUND. With that in place and usage of 
the pEnv dimensions for source as well as for destination of the blit operation 
I always get a one black pixel seam at the top and the right of the rendered 
window (in both examples). However, do I add one pixel to the top and right 
dimension, then the rendered window seems to be ok. That can be done by 
enabling define ADD_PLUS_ONE_TO_TOP_AND_RIGHT in both the FBOBackground (for 
example 1) and FBOGrabForeground (for example 1 and 2) sources.

I have inspected other places in OpenSG at where the pEnv->getPixelLeft  (),... 
calls are used and I found that at no place the additional pixels were added. 
So I'm confused. What is correct and how to explain the black edge in the 
window? If the additional pixel is correct, however, I have to ask about the 
correctness of the other code places :-(

3. Beside of these two points I would like to see the examples in OpenSG and I 
would like to ask for some polishing or review. This is the first foreground I 
have written and I'm still struggeling with the OpenGL framebuffer object. For 
instance, I'm still unsure about the implications of an multsampling render GL 
context of the window.

Anyway, I would really appreciate some help here.

Best,
Johannes



OpenSG.azip
Description: OpenSG.azip
--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: CMake build system

[Johannes]

On 22.10.2015 14:41, Johannes wrote:
> Hello Gerrit,
>
> I have one additional small problem with the build system. I got an
> unresolved external symbol error from a missing memmanager library in
> target simplePluginApp. That target is somehow special and does not add
> the OSG_GLOBAL_LIB dependencies. I have temporarily added the following
> line of cmake code
>
> TARGET_LINK_LIBRARIES(simplePluginApp ${${OSG_GLOBAL_LIB}})
>
> into
>
> Contrib/CSMPlugin/SimpleTest/CMakeLists.Lib.OSGContribCSMSimplePlugin.txt
>
> which resolves this error. Probably there is a more elegant solution
> that would be more in the line of the other executable targets?
>
> Could you adapt OSGContribCSMSimplePlugin.txt accordingly?
>
>
> Thanks,
> Johannes
>
>
>
> --
>
ping :-)



--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: ComplexSceneManager

[Johannes]

On 26.10.2015 15:36, Johannes Brunen wrote:
> Hello,
>
>
>
> I would like to play a little bit with the ComplexSceneManager.
> Therefore I have build the
>
> appCSM target on my Windows VC12/64 platform, but I'm unable to get it
> run properly.
>
>
>
> I used the following environment and command line:
>
>
>
> Working directory:
>
> cwd = d:\_xxx\Comp\builder\support\opensg\
>
>
>
> Arguments;
>
> $( cwd)/Source/Contrib/ComplexSceneManager/data/system-native.osg --data
> d:/_xxx/Data/tie.wrl --global $( cwd)
> /Source/Contrib/ComplexSceneManager/data/simple_mouse.osg
>
>
>
> I got the following console output but otherwise nothing happens
>
>
>
> OSGLog::setLogLevel: overridden by envvar OSG_LOG_LEVEL 'debug'.
>
> Log::setLogFile: overriden by envvar OSG_LOG_FILE 'd:/work/opensg.log'.
>
> ColorBuffer : 0x0001
>
> DepthBuffer : 0x0002
>
> GBuffer : 0x0004
>
> ShadowFactor: 0x0008
>
> start from arg
>
> loading osg file
> d:/_xxx/Comp/builder/support/opensg/Source/Contrib/ComplexSceneManager/d
> ata/system-native.osg ...
>
> loading data d:/_xxx/Data/tie.wrl ...
>
> FieldConnectorFactoryBase::terminate
>
>
>
> Any idea what I'm missing or what is going wrong?
>
>
>
> Best,
>
> Johannes
>
>
>
>
> --
>
ping :-)


--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: overriding of chunks

[Johannes]

On 02.11.2015 11:22, Johannes wrote:
> On 29.10.2015 01:12, Carsten Neumann wrote:
>>
>> I think for consistency with most of the rest of the
>> API (and symmetry with addOverride) it should be subOverride instead of
>> removeOverride.
> Yes, you are right.
>
>> Could you also please add a comment to the new bool removeOverride field
>> describing what it does.
> Yes.
>
>> I'm wondering if it would be better to have a separate collection of
>> chunks to "remove" instead of changing the semantics of the group based
>> on a bool flag? But given that this is driven by your needs I don't feel
>> strongly one way or the other :)
> Personally, I think that it would be a kind of code bloat to introduce
> new classes specifically for that matter.
>
> Below you can find the patch file and the modified source files.
>
> Thanks for taking your time to look at this issue.
>
> Best,
> Johannes
>
>
>
>
> --
>
>
>
> ___
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
ping :-)


--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: overriding of chunks

[Johannes]

Hello Gerrit and/or Carsten,

On 26.10.2015 13:57, Johannes Brunen wrote:
>
> Is it possible to a allow a subtractive
> MaterialChunkOverrideGroup core.
>
> Is that possible and can I get some support in realizing that?
>
I have made a first implementation of what I have in mind. Attached you
can find my solution. Could you take a look at it and give me some
feedback. I would like to see something like this in OpenSG 2 :-)

Best,
Johannes

P.S.: Files.azip is just a simple zip file. I uses this extension 
because the mail server filters *.zip files :-(


Files.azip
Description: Binary data
diff -rupN 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderAction.h
 
d:/_xxx/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderAction.h
--- 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderAction.h
 2015-10-09 14:25:58.0 +0200
+++ 
d:/_xxx/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderAction.h
 2015-10-27 10:49:50.750921100 +0100
@@ -157,6 +157,8 @@ class OSG_SYSTEM_DLLMAPPING RenderAction
 

   void   addOverride(UInt32  uiSlot, 

  StateChunk *pChunk);

+  void   removeOverride (UInt32  uiSlot, 

+ StateChunk *pChunk);

 

 const StateOverride *getCurrentOverrides(void  ) const;

 

diff -rupN 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderAction.inl
 
d:/_xxx/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderAction.inl
--- 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderAction.inl
   2015-10-09 14:25:58.0 +0200
+++ 
d:/_xxx/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderAction.inl
   2015-10-27 10:50:17.646459500 +0100
@@ -114,6 +114,12 @@ void RenderAction::addOverride(UInt32 ui
 }

 

 inline

+void RenderAction::removeOverride(UInt32 uiSlot, StateChunk *pChunk)

+{

+_pActivePartition->removeOverride(uiSlot, pChunk);

+}

+

+inline

 const StateOverride *RenderAction::getCurrentOverrides(void) const

 {

 return _pActivePartition->getCurrentOverrides();

diff -rupN 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderPartition.h
 
d:/_xxx/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderPartition.h
--- 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderPartition.h
  2015-10-09 14:25:58.0 +0200
+++ 
d:/_xxx/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderPartition.h
  2015-10-27 10:10:17.008150800 +0100
@@ -307,6 +307,9 @@ class OSG_SYSTEM_DLLMAPPING RenderPartit
   void   addOverride(UInt32  uiSlot, 

  StateChunk *pChunk);

 

+  void   removeOverride (UInt32  uiSlot, 

+ StateChunk *pChunk);

+

 const StateOverride *getCurrentOverrides(void  ) const;

 

 /*-- comparison -*/

diff -rupN 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderPartition.inl
 
d:/_xxx/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderPartition.inl
--- 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderPartition.inl
2015-10-09 14:25:58.0 +0200
+++ 
d:/_xxx/Comp/builder/support/opensg/Source/System/Action/RenderAction/OSGRenderPartition.inl
2015-10-27 10:10:45.370773000 +0100
@@ -386,6 +386,12 @@ void RenderPartition::addOverride(UInt32
 }

 

 inline

+void RenderPartition::removeOverride(UInt32 uiSlot, StateChunk *pChunk)

+{

+_sStateOverrides.top()->removeOverride(uiSlot, pChunk);

+}

+

+inline

 const StateOverride *RenderPartition::getCurrentOverrides(void) const

 {

 return _sStateOverrides.top();

diff -rupN 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/NodeCores/Groups/Base/OSGChunkOverrideGroup.cpp
 
d:/_xxx/Comp/builder/support/opensg/Source/System/NodeCores/Groups/Base/OSGChunkOverrideGroup.cpp
--- 
d:/cpp_xxx_/Comp/builder/support/opensg/Source/System/NodeCores/Groups/Base/OSGChunkOverrideGroup.cpp
   2015-10-09 14:26:00.0 +0200
+++ 
d:/_xxx/Comp/builder/support/opensg/Source/System/NodeCores/Groups/Base/OSGChunkOverrideGroup.cpp
   2015-10-27 10:50:54.831586300 +0100
@@ -224,7 +224,10 @@ Action::ResultE ChunkOverrideGroup::rend
 while(chIt != chEnd)

 {

 if(*chIt != NULL && (*chIt)->getIgnore() == false)

-pAction->addOverride(uiSlot, *chIt);

+if (getRemoveOverride())

+pAction->removeOve

[Opensg-users] OpenSG 2: ComplexSceneManager

[Johannes Brunen]

Hello,

 

I would like to play a little bit with the ComplexSceneManager.
Therefore I have build the 

appCSM target on my Windows VC12/64 platform, but I'm unable to get it
run properly.

 

I used the following environment and command line:

 

Working directory:

cwd = d:\_xxx\Comp\builder\support\opensg\

 

Arguments;

$( cwd)/Source/Contrib/ComplexSceneManager/data/system-native.osg --data
d:/_xxx/Data/tie.wrl --global $( cwd)
/Source/Contrib/ComplexSceneManager/data/simple_mouse.osg

 

I got the following console output but otherwise nothing happens

 

OSGLog::setLogLevel: overridden by envvar OSG_LOG_LEVEL 'debug'.

Log::setLogFile: overriden by envvar OSG_LOG_FILE 'd:/work/opensg.log'.

ColorBuffer : 0x0001

DepthBuffer : 0x0002

GBuffer : 0x0004

ShadowFactor: 0x0008

start from arg

loading osg file
d:/_xxx/Comp/builder/support/opensg/Source/Contrib/ComplexSceneManager/d
ata/system-native.osg ...

loading data d:/_xxx/Data/tie.wrl ...

FieldConnectorFactoryBase::terminate

 

Any idea what I'm missing or what is going wrong?

 

Best,

Johannes

 


--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG 2: overriding of chunks

[Johannes Brunen]

Hello,

 

I'm using a MaterialChunkOverrideGroup core in my render tree in order
to define some global state. For instance, I manage clip planes in that
way. Now, I have the rather obscure situation that I need to render a
part of my tree with a material state that does not need some of the
corresponding chunks. The overriding process is currently additively
defined. Is it possible to a allow a subtractive
MaterialChunkOverrideGroup core.

 

To be more clear what I mean. Suppose that I have the following render
tree:

 

  parent-tree

   |

 MaterialChunk-

 OverrideGroup 1

   |

  ...

   |

  ++-+

  |  |

MaterialChunk-   |

OverrideGroup 2  |

  |  |

MaterialGroup A MaterialGroup B

  |  |

  Geometry A Geometry B

 

What I wish to have is that the material chunks that are defined by
MaterialChunkOverrideGroup 2 should be removed from the state chunks
defined at this place, so actually negating some of the chunks that I
have defined by MaterialChunkOverrideGroup 1.

The special behavior of MaterialChunkOverrideGroup 2 could be either
activated by an additional boolean flag, or the MCOG could  take an
additional material that is subtracted when it is defined.

 

Is that possible and can I get some support in realizing that?

 

I think that beside of changing MaterialChunkOverrideGroup the parent
class ChunkOverrideGroup  would have to be adapted.

 

Is there something that I'm missing with that?

 

Best,

Johannes

 


--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: CMake build system

[Johannes]

Hello Gerrit,

I have one additional small problem with the build system. I got an 
unresolved external symbol error from a missing memmanager library in 
target simplePluginApp. That target is somehow special and does not add 
the OSG_GLOBAL_LIB dependencies. I have temporarily added the following 
line of cmake code

TARGET_LINK_LIBRARIES(simplePluginApp ${${OSG_GLOBAL_LIB}})

into

Contrib/CSMPlugin/SimpleTest/CMakeLists.Lib.OSGContribCSMSimplePlugin.txt

which resolves this error. Probably there is a more elegant solution 
that would be more in the line of the other executable targets?

Could you adapt OSGContribCSMSimplePlugin.txt accordingly?


Thanks,
Johannes



--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: Setting up the depth buffer

[Johannes]

Hello Gerrit,

once again. I did a glance at the multisampling OpenGL technique and 
compared it to the OpenSG texture/FBO usage. As I see it, multisampling 
is currently not supported by OpenSG.

Following the wikipedia entry

https://www.opengl.org/wiki/Multisampling#Allocating_a_Multisample_Render_Target

OpenSG does have to use the GL_TEXTURE_2D_MULTISAMPLE flag(s) and the 
glTexImage2DMultisample api(s) in order to support multisampling. Is 
there any reason not to uses these on a multisampling rendering context.

What is your opinion with respect to multisampling?
Do you have experience with the multisampling in OpenGL generally?
Should we add support for proper multisampling to OpenSG?

Is multisampling used by others regularily?
Do other post process their render buffers for antialiasing instead of 
hardware multisampling?

Best,
Johannes



--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: Setting up the depth buffer

[Johannes]

Hello Gerrit,

suppose we would have a corresponding FBOForeground, which manages a FBO 
and would be filled from the render buffer by blit operation at the end 
of the render task (probably on request only).
What I have in mind is to setup such a foreground in my first viewport 
and to use the FBO in the second viewport's FBOBackground in my dynamic 
case. The FBO would have to be adapted at resize and would have to 
respect the multisampling settings of the underlying render context.

Do you think that this is good plan?
Do I have overseen some constraint that could not be fulfilled?

Best,
Johannes

P.S. I did already a simple example with the new FBOBackground and it 
worked well.




--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: Setting up the depth buffer

[Johannes]

Hello Gerrit,

below you can find my simple not finished example with the 
FBOBackground. It works reasonably with a standard render context but 
fails with a multisampling context.

I have currently not figured out what exactly is going wrong, so.

Best,
Johannes


// User interface:
//  a) mouse=> standard navigator
//  b) keyboard =>
//  '1': toggle between static and dynamic mode
//

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifdef OSG_BUILD_ACTIVE
// Headers
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#else
// Headers
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#endif

OSG_USING_NAMESPACE; // just for convenience but not recommended

#define USE_MULTISAMPLING

#ifdef _DEBUG
const int max_tori =  500;
#else
const int max_tori = 1;
#endif

//
// Helper class for building FBO
//
class FBOBuilder
{
public:
 struct TextureData {
 TextureData()
 : enable(true)
 , pixel_format(Image::OSG_RGBA_PF)
 , type(Image::OSG_UINT8_IMAGEDATA)
 , main_memory(true)
 , texObj(nullptr)
 , image(nullptr) {}
~TextureData() {texObj = nullptr; image = nullptr; }

 bool enable;
 UInt32 pixel_format;
 Int32 type;
 bool main_memory;
 TextureObjChunkUnrecPtr texObj;
 ImageUnrecPtr image;
 };

 typedef std::vector VecTextureDataT;

public:
 FBOBuilder(const VecTextureDataT& buffers, bool depth, 
bool stencil, const TextureData& ds_buffer)
 : _buffers(buffers) , _depth(depth) , _stencil(stencil) 
, _ds_buffer(ds_buffer) {}
~FBOBuilder() {}

public:
 FrameBufferObjectTransitPtroperator()(UInt32 width, UInt32 
height) const;

private:
 VecTextureDataT _buffers;
 bool_depth;
 bool_stencil;
 TextureData _ds_buffer;
};

FrameBufferObjectTransitPtr FBOBuilder::operator()(
 UInt32 width,
 UInt32 height) const
{
 //
 // Setup the FBO
 //
 FrameBufferObjectUnrecPtr fbo = FrameBufferObject::create();
 //
 // multiple color buffers
 //
 for (UINT32 idx = 0; idx < _buffers.size(); ++idx) {
 //
 // use textures?
 //
 if (_buffers[idx].enable) {
 ImageUnrecPtr   texImg = (_buffers[idx].image  == 
nullptr ? Image::create()   : _buffers[idx].image);
 TextureObjChunkUnrecPtr texObj = (_buffers[idx].texObj == 
nullptr ? TextureObjChunk::create() : _buffers[idx].texObj);
 TextureBufferUnrecPtr   texBuf = TextureBuffer::create();

 if (_buffers[idx].image == nullptr)
 texImg->set(_buffers[idx].pixel_format,
 width, height, 1, 1, 1, 0.f, nullptr,
 _buffers[idx].type,
 _buffers[idx].main_memory);

 texObj->setImage(texImg);
 texBuf->setTexture(texObj);

 fbo->setColorAttachment(texBuf, idx);
 } else
 //
 // no, then use simple render buffer
 //
 {
 RenderBufferUnrecPtr renBuf = RenderBuffer::create();
 renBuf->setInternalFormat(_buffers[idx].pixel_format);
 fbo->setColorAttachment(renBuf, idx);
 }
 fbo->editMFDrawBuffers()->push_back(GL_COLOR_ATTACHMENT0_EXT + 
idx);
 }
 //
 // a sole depth buffer
 //
 if (_depth && !_stencil) {
 //
 // use textures?
 //
 if (_ds_buffer.enable) {
 ImageUnrecPtr   texImg = (_ds_buffer.image  == 
nullptr ? Image::create()   : _ds_buffer.image);
 TextureObjChunkUnrecPtr texObj = (_ds_buffer.texObj == 
nullptr ? TextureObjChunk::create() : _ds_buffer.texObj);
 TextureBufferUnrecPtr   texBuf = TextureBuffer::create();

 if (_ds_buffer.image == nullptr)
 texImg->set(_ds_buffer.pixel_format,
 width, height, 1, 1, 1, 0.f, nullptr,
 _ds_buffer.type,
 _ds_buffer.main_memory);

 texObj->setImage(texImg);

 if (_ds_buffer.texObj == nullptr) {
 texObj->setInternalFormat(GL_DEPTH_COMPONENT24);
 texObj->setExternalFormat(GL_DEPTH_COMPONENT24);
 }
 texBuf->setTexture(texObj);

 fbo->setDepthAttachment(texBuf);
 } else
 //
 // no, then use simple render buffer
 //
 {
 RenderBufferUnrecPtr renB

Re: [Opensg-users] OpenSG 2: Setting up the depth buffer

[Johannes]

Hello Gerrit,

On 09.10.2015 12:52, Gerrit Voß wrote:
>
> I added a new OSGFBOBackground which takes a FramebufferObject and
> on clear tries to blit all color, depth and stencil buffers,
> either to the active FBO or to the window framebuffer.
>
This is really great. I will immediately take an OpenSG snapshot and 
look into it. However, I will be offline the next week and can not give 
you direct response, so.

> I only came around to do some quick testing, but it gives you
> something to start with (and ideally it already does what you
> need). I will do some further testing, especially on robustness.
>
I have started with an example as I have written. I think it can be 
properly extended to be part of the OpenSG examples when finished.

One point I have in mind with respect to robustness is the support of 
multisampled render context/buffers. But, I don't currently know every 
nut, bolt and screw in this area.

Thanks, and best regards,
Johannes



--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: CMake build system

[Johannes]

On 06.10.2015 19:38, Gerrit Voß wrote:

> I have a look, currently all the file information is collected and
> temporarily stored. I would probably add a OSG_ADD_GLOBAL_EXE_SRC to
> have a distinction between libs and executables.
>
I'm fine with that :-)

Best,
Johannes




--
Full-scale, agent-less Infrastructure Monitoring from a single dashboard
Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
Physical-Virtual-Cloud Infrastructure monitoring from one console
Real user monitoring with APM Insights and performance trend reports 
Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: Setting up the depth buffer

[Johannes]

On 07.10.2015 14:52, Gerrit Voß wrote:
>
> For your shader problem below, ...
> The easiest way around this is to use a SimpleSHLChunk instead ...

I did not know about that one :-(

I took a look into the PassiveBackground implementation and it seems 
that it is quite near to what is needed here if I understand correctly.
If ClearFrameBufferObject is set and no ClearCallback is defined it does 
perform some blitting by

osgGlBindFramebuffer(GL_READ_FRAMEBUFFER_EXT, 0)
osgGlBlitFramebuffer(
 pEnv->getPixelLeft (),
 pEnv->getPixelBottom(),
 pEnv->getPixelRight (),
 pEnv->getPixelTop (),
 pEnv->getPixelLeft (),
 pEnv->getPixelBottom(),
 pEnv->getPixelRight (),
 pEnv->getPixelTop (),
 (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT),
 GL_NEAREST);

osgGlBindFramebuffer(
 GL_READ_FRAMEBUFFER_EXT,
 win->getGLObjectId(pEnv->getActiveFBO()));


Am I correct that this blit from the main render buffer into the active FBO?


Assume that we store the FBO into the FancyBackground. How do we do the 
opposite blit operation?

glBindFramebuffer(GL_READ_FRAMEBUFFER, my_fbo);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);

glReadBuffer(GL_COLOR_ATTACHMENT0);
glDrawBuffer(GL_COLOR_ATTACHMENT0);

osgGlBlitFramebuffer(
 pEnv->getPixelLeft (),
 pEnv->getPixelBottom(),
 pEnv->getPixelRight (),
 pEnv->getPixelTop (),
 pEnv->getPixelLeft (),
 pEnv->getPixelBottom(),
 pEnv->getPixelRight (),
 pEnv->getPixelTop (),
 (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT),
 GL_NEAREST);

What is my_fbo actually, i.e. where do I get the id of the stored FBO?

I have no experience with GL framebuffer handling, so any hints are 
welcomed.

Best,
Johannes






--
Full-scale, agent-less Infrastructure Monitoring from a single dashboard
Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
Physical-Virtual-Cloud Infrastructure monitoring from one console
Real user monitoring with APM Insights and performance trend reports 
Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911=/4140
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG 2: CMake build system

[Johannes Brunen]

Hello Gerrit,

 

the OpenSG 2 build system does provide the 'OSG_GLOBAL_PREP' variable,
which allows me to call my own cmake configuration file. In that file
I'm allowed to define another variable 'OSG_ADD_GLOBAL_SRC' that is
evaluated for each of the OpenSG libraries. By that, I'm able to add a
special memory management source file to the OpenSG libraries. That is
working pretty fine. However, when I build any executable in OpenSG,
e.g. the test*.exe or the example executables, then I have to add my
memory management source file explicitly to the project. Both, the
library and the executable must include this file. This is a little
inconvenient and I would like to ask if it is possible to add the above
variable evaluation in all ADD_EXECUTABLE statements, i.e.
ADD_EXECUTABLE(... ${OSG_ADD_GLOBAL_SRC}).

 

I have tested this change in my local setup and it works fine.

 

The following files do contain the ADD_EXECUTABLE statement:

d:\_xxx\Comp\builder\support\opensg\Tools\unittest-cpp\CMakeLists.txt

d:\_xxx\Comp\builder\support\opensg\Source\Contrib\CSMPlugin\SimpleTest\
CMakeLists.Lib.OSGContribCSMSimplePlugin.txt

d:\_xxx\Comp\builder\support\opensg\Examples\Tutorial\CMakeLists.standal
one.txt

d:\_xxx\Comp\builder\support\opensg\Examples\Tutorial\CMakeLists.fromosg
.txt

d:\_xxx\Comp\builder\support\opensg\Examples\Simple\CMakeLists.standalon
e.txt

d:\_xxx\Comp\builder\support\opensg\Examples\Simple\CMakeLists.fromosg.t
xt

d:\_xxx\Comp\builder\support\opensg\Examples\CustomIntegration\NewContai
nerType\CubesAppUnified\CMakeLists.txt

d:\_xxx\Comp\builder\support\opensg\Examples\CustomIntegration\NewContai
nerType\CubesApp\CMakeLists.txt

d:\_xxx\Comp\builder\support\opensg\Examples\Advanced\DeferredShading\CM
akeLists.standalone.txt

d:\_xxx\Comp\builder\support\opensg\Examples\Advanced\DeferredShading\CM
akeLists.fromosg.txt

d:\_xxx\Comp\builder\support\opensg\Examples\Advanced\Character\CMakeLis
ts.standalone.txt

d:\_xxx\Comp\builder\support\opensg\Examples\Advanced\Character\CMakeLis
ts.fromosg.txt

d:\_xxx\Comp\builder\support\opensg\CMake\OSGBuildFunctions.cmake

 

Best,

Johannes

 


--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] openSG Status, August 2015

[Johannes]

Hello,

On 26.08.2015 09:32, Altenhofen, Christian wrote:
 I asked this question several times now:
 Why don't you just re-upload the old opensg.org website to another server and 
 host it there?

- who is paying the bill?
- who is doing the work?
- who is qualified to do the work?
- who is maintaining the server?
- who is working on the content?

I would really be interested to get some feedback about who is working 
and in what way with OpenSG as of today.

What do you think is the future of OpenSG?

Are there enough interested parties around to vivify OpenSG again?

Please speak up so that we can gain some measure of the relevance of OpenSG.

We, my company and I are using OpenSG in a commercial product line. 
OpenSG is important for us, but we are lacking of man power and know how 
to drive OpenSG substantially. We are once transitioned from 1.8 to 2.0 
successfully and never looked back wistfully.

What I would like to see is some community exchange about problems that 
the individuals have already solved, e.g. with respect to modern render
techniques, fancy materials etc. I did provide some examples to OpenSG 
for problems that I have faced in my venture in 3D with OpenSG.

Best,
Johannes



--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG 2.0: Dot file generator error correction

[Johannes Brunen]

Hello Carsten,

 

attached you can find a small patch for the
OSGDotFileGeneratorGraphOp.cpp file. Could you please commit this patch
into the OpenSG 2.0 repository.

 

Best,

Johannes

 

 



OSGDotFileGeneratorGraphOp.cpp.diff
Description: OSGDotFileGeneratorGraphOp.cpp.diff
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG Web site

[Johannes Brunen]

Hi,

 

Short question: What happend to the OpenSG Web site
(http://www.opensg.org/)?

 

Is this no longer valid or is it just a machine or administration issue?

 

Best,

Johannes

 


--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG2: GUI intergration...

[Johannes Brunen]

Hello,

 

Does anyone has some experience with GUI integration into OpenSG? 

 

I have found the following open source libraries and was wondering how
easily they could be sensibly integrated into an OpenSG based
application:

 

http://mygui.info/

http://anttweakbar.sourceforge.net/doc/

http://cegui.org/

 

Did anyone actually wrapped one of these libraries with OpenSG?

 

Do you know any other GUI framework that could be used together with
OpenSG?

 

Best,

Johannes

 


--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] [OpenSG 2.x] Bug fixes

[Johannes]

Hello Gerrit and Carsten,

I really would like to close this case. Did you have any time to look 
into my patch? Hopefully, I'm not pestering to much.

Kind regards,
Johannes


On 11.02.2015 08:33, Gerrit Voß wrote:

 Hi,

 On Fri, 2015-02-06 at 09:33 -0600, Carsten Neumann wrote:
  Hello Johannes,

 On 02/06/2015 07:15 AM, Johannes Brunen wrote:
 back to OpenSG :-)

 2. OSGShaderCacheTree.inl: The ShaderCacheTreeV3::sub() method is imho
 incorrect. The ShaderCache::clear() function currently does not work
 properly. I was facing references to already destroyed ShaderCache
 objects from ShaderProgramVariableChunks.

 I'll hold off applying this one for a couple of days so that either
 Gerrit has a chance to comment or I can read up on how the cache works.
   From you description it sounds like you have found the source of some
 mysterious (and hard to find) bugs that have come up over time. Thanks
 for finding this one!

 I'll try to find some time to go over this one, but it might be more
 towards this weekend.

 kind regards
gerrit




 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] [OpenSG 2.x] Bug fixes

[Johannes]

Ping :-)


On 11.02.2015 08:33, Gerrit Voß wrote:

 Hi,

 On Fri, 2015-02-06 at 09:33 -0600, Carsten Neumann wrote:
  Hello Johannes,

 On 02/06/2015 07:15 AM, Johannes Brunen wrote:
 back to OpenSG :-)

 2. OSGShaderCacheTree.inl: The ShaderCacheTreeV3::sub() method is imho
 incorrect. The ShaderCache::clear() function currently does not work
 properly. I was facing references to already destroyed ShaderCache
 objects from ShaderProgramVariableChunks.

 I'll hold off applying this one for a couple of days so that either
 Gerrit has a chance to comment or I can read up on how the cache works.
   From you description it sounds like you have found the source of some
 mysterious (and hard to find) bugs that have come up over time. Thanks
 for finding this one!

 I'll try to find some time to go over this one, but it might be more
 towards this weekend.

 kind regards
gerrit




 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/




--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] [OpenSG 2.x] Bug fixes

[Johannes Brunen]

Hello Carsten and Gerrit,

 

back to OpenSG :-)

 

Attached you can find a patch file for some errors I have found. I have
created the patch file against the current master.

 

Could you please review my corrections and check them into the git
repository if they are fine.

 

I have found the following problems:

1. OSGShaderCache: Usage of incorrect end iterator types

2. OSGShaderCacheTree.inl: The ShaderCacheTreeV3::sub() method is imho
incorrect. The ShaderCache::clear() function currently does not work
properly. I was facing references to already destroyed ShaderCache
objects from ShaderProgramVariableChunks.

3. OSGShaderCacheTree.inl: Minor issue with the dumpDot function.

4. OSGShaderProgamVariableChunk.cpp: Imho, the resolveLinks function
should clear the _mfDestroyedFunctors container (?).  

 

Best,

Johannes

 



original.patch
Description: original.patch
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] FindGLUT_OpenSG.cmake doesn't find freeglut

[Johannes Zarl]

Hi,

I'm having trouble in getting OpenSG to find freeglut on a Windows7/VS2013 
build.

Looking into the FindGLUT_OpenSG.cmake file reveals that only the library names 
glut and glut32 are searched for, while freeglut is using the name 
freeglut.

Is it possible to change the FindGLUT_OpenSG.cmake as shown in the attachment? 
I changed the file so that library names can be extended, similarly to how it 
is done in FindGLEW_OpenSG.cmake.

Cheers,
  Johannes# - try to find glut library and include files
#  GLUT_INCLUDE_DIR, where to find GL/glut.h, etc.
#  GLUT_LIBRARIES, the libraries to link against
#  GLUT_FOUND, If false, do not try to use GLUT.
# Also defined, but not for general use are:
#  GLUT_glut_LIBRARY = the full path to the glut library.
#  GLUT_Xmu_LIBRARY  = the full path to the Xmu library.
#  GLUT_Xi_LIBRARY   = the full path to the Xi Library.


IF (WIN32)

  FIND_PATH( GLUT_INCLUDE_DIR NAMES GL/glut.h 
PATHS  ${GLUT_ROOT_PATH}/include )

  SET( GLUT_NAMES_RELEASE ${GLUT_NAMES_RELEASE} freeglut glut glut32 )
  FIND_LIBRARY( GLUT_glut_LIBRARY_RELEASE NAMES ${GLUT_NAMES_RELEASE}
PATHS
${OPENGL_LIBRARY_DIR}
${GLUT_ROOT_PATH}/Release
)

  SET( GLUT_NAMES_DEBUG ${GLUT_NAMES_DEBUG} freeglutd glutd glut32d )
  FIND_LIBRARY( GLUT_glut_LIBRARY_DEBUG NAMES ${GLUT_NAMES_DEBUG}
PATHS
${OPENGL_LIBRARY_DIR}
${GLUT_ROOT_PATH}/Debug
)
ELSE (WIN32)

  MESSAGE(ERROR Only to be used on WIN32 platforms)
  
  IF (APPLE)
# These values for Apple could probably do with improvement.
FIND_PATH( GLUT_INCLUDE_DIR glut.h
  /System/Library/Frameworks/GLUT.framework/Versions/A/Headers
  ${OPENGL_LIBRARY_DIR}
  )
SET(GLUT_glut_LIBRARY -framework GLUT CACHE STRING GLUT library for OSX) 
SET(GLUT_cocoa_LIBRARY -framework Cocoa CACHE STRING Cocoa framework for OSX)
  ELSE (APPLE)

FIND_PATH( GLUT_INCLUDE_DIR GL/glut.h
  /usr/include/GL
  /usr/openwin/share/include
  /usr/openwin/include
  /opt/graphics/OpenGL/include
  /opt/graphics/OpenGL/contrib/libglut
  )
  
FIND_LIBRARY( GLUT_glut_LIBRARY glut
  /usr/openwin/lib
  )

FIND_LIBRARY( GLUT_Xi_LIBRARY Xi
  /usr/openwin/lib
  )

FIND_LIBRARY( GLUT_Xmu_LIBRARY Xmu
  /usr/openwin/lib
  )

  ENDIF (APPLE)
  
ENDIF (WIN32)

SET( GLUT_FOUND NO )
IF(GLUT_INCLUDE_DIR)
  IF(GLUT_glut_LIBRARY_DEBUG OR GLUT_glut_LIBRARY_RELEASE)
# Is -lXi and -lXmu required on all platforms that have it?
# If not, we need some way to figure out what platform we are on.
#SET( GLUT_LIBRARIES
#  ${GLUT_glut_LIBRARY}
#  ${GLUT_Xmu_LIBRARY}
#  ${GLUT_Xi_LIBRARY} 
#  ${GLUT_cocoa_LIBRARY}
#  )
SET( GLUT_FOUND YES )

#The following deprecated settings are for backwards compatibility with CMake1.4
#SET (GLUT_LIBRARY ${GLUT_LIBRARIES})
SET (GLUT_INCLUDE_PATH ${GLUT_INCLUDE_DIR})

  ENDIF(GLUT_glut_LIBRARY_DEBUG OR GLUT_glut_LIBRARY_RELEASE)
ENDIF(GLUT_INCLUDE_DIR)

MARK_AS_ADVANCED(
  GLUT_INCLUDE_DIR
  GLUT_glut_LIBRARY_RELEASE
  GLUT_glut_LIBRARY_DEBUG
#  GLUT_Xmu_LIBRARY
#  GLUT_Xi_LIBRARY
  )
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG 2: Porting to VC12

[Johannes]

Hello Carsten,


 b) opensg\Source\Contrib\VTK\OSGVTKPolyDataMapper.cpp line 394
 #ifdef OSG_WITH_VTK_6
   pMapper-Update();
 #else
   pMapper-GetInput()-Update();
 #endif

 and added a the flag OSG_WITH_VTK_6. I'm not sure if this change is
 semantically correct, but at least it compiles fine :-)

 hmm, I suspect it does change the meaning (not sure though), but I'm
 wondering more why this is necessary? At least according to the docs
 vtkMapper::GetInput() has not been removed in vtk 6.
 Could you post the error message?

No, not currently. But the vtkDataObject does not have an Update() 
method anymore.

See:
http://www.vtk.org/Wiki/VTK/VTK_6_Migration_Guide
http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Removal_of_Methods_for_Manipulating_Update_Extent


 You should have OPENEXR_USE_DLL show up as an option in your cmake
 configuration; the line OSG_OPTION(OPENEXR_USE_DLL OFF) just sets the
 default value.

Ok, I will try this option :-)

Best,
Johannes



--
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

[Opensg-users] OpenSG 2: Porting to VC12

[Johannes Brunen]

Hello,

 

I'm in the process of porting our application to the MS Visual Studio
2013 (a.k.a. VC12) compiler and have found some minor problems.

 

1. In file opensg\Source\System\Cluster\Window\Base\OSGClusterWindow.cpp
at line 235 I have changed

from

SFATAL  Error starting:   command  std::endl;

to

SFATAL  Error starting:   command.str() 
std::endl;

 

because I got the following error message:

...\OSGClusterWindow.cpp(235): error C2678: binary '' : no operator
found which takes a left-hand operand of type
'std::basic_ostreamchar,std::char_traitschar' (or there is no
acceptable conversion) 

 

2. The next two issues are relevant only because I switched to VTK 6.1:

 

a) CMakeLists.txt line 735

I changed the line 

from

  OSG_SET(OSG_VTK_LIBS
vtkCommon;vtkFiltering;vtkGraphics;vtkIO;vtkRendering)

to

  include(${VTK_USE_FILE})

  OSG_SET(OSG_VTK_LIBS ${VTK_LIBRARIES})

 

b) opensg\Source\Contrib\VTK\OSGVTKPolyDataMapper.cpp line 394

I changed the line 

from

pMapper-GetInput()-Update();

to

#ifdef OSG_WITH_VTK_6

pMapper-Update();

#else

pMapper-GetInput()-Update();

#endif

 

and added a the flag OSG_WITH_VTK_6. I'm not sure if this change is
semantically correct, but at least it compiles fine :-)

 

3. The last issue is not related to the port. I compile and update all
the support libraries independent of OpenSG. Especially, OpenEXR is
compiled  as a dynamic link library in my setup. Therefore the
OPENEXR_DLL flag must be set. However, the OSGConfigurePackages.cmake
forces the OPENEXR_USE_DLL option to be OFF which in turn forces not to
the the OPENEXT_DLL flag. Currently, I change the generated
CMakeCache.txt file, but it would be fine to have at least an option for
the flag.

 

No other problems so far...

 

Best,

Johannes

 


--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Shading problems

[Johannes]

Hello Gerrit,

finally, I can give you some feedback for the changes you have provided 
to the code base. I have tested the changes on my three graphic 
platforms, namely

ATI Radeon 5700 series
NVidia GTX 560
Intel HD Graphics 4000

and they all work fine so far. However, in the debug case, I still have 
to set the OSG_NO_GL_CHECK_ON_FRAMEEXIT environment variable for the 
Intel platform in order to not get trap into the infinite loop.

I would like to thank you for the considerable effort you have invested 
to solve this particular shading problem.

Additionally, it is good to see that the number of OpenSG flags has also 
reduced a little.

Best,
Johannes



--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2: Shading problems

[Johannes]

Hello Gerrit,

On 15.07.2014 12:33, Gerrit Voß wrote:

 I pushed the commit, could you try and let me know if it works.

Good and bad news...

The rendering does now work with and without shader on all of my tested 
graphic platforms with reasonably current drivers installed:

ATI Radeon 5700 series
NVidia GTX 560
Intel HD Graphics 4000

It works, however, only for newly created models. My stored scenes do 
not work anymore. No graphic is visible at all.


With respect to the Intel HD Graphics 4000 platform I have another 
problem. I'm facing a stray OpenGL error which I'm unable to track down. 
In my debug sessions this error showed up in the Windows::doFrameExit 
due to the error checking loop. Unfortunately, the error flag 
(GL_INVALID_OPERATION) is not cleared by the glGetError call and the 
application is trapped in this loop.

I have tried hard to find the cause for the error but have not succeeded 
so far. I do know that this loop implementation is in accordance with 
the GL specs but it would nevertheless be fine if I could disable the 
check for the debug session.

Best,
Johannes



--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users