opensg-users — User Communication

Re: [Opensg-users] Deferred Shading and Multisampling

[Carsten N. <car...@gm...>]

Hello Victor,

I've not used that combination and it is my understanding that is not the
most popular AA method when using deferred shading (because of the
increased memory and memory bandwidth requirements). You'll need all
G-Buffer render buffers/textures to be multisampled as well as the depth
buffer used to fill the G-Buffer. Without that the lighting shaders don't
have access to per-sample data and the final image does not change compared
to using just one sample. Off the top of my head I'm not sure if the
lighting shaders need to be aware of the MSAA G-Buffer or if they just work
unchanged.

Cheers,
Carsten

On Thu, Apr 22, 2021 at 6:55 AM Victor Haefner <vic...@gm...>
wrote:

> Hallo,
>
> I am trying to get multisampling working with the deferred shading stage.
> I tried setting the render target with an FBO with
>
>     fbo->setEnableMultiSample(true);
>     fbo->setColorSamples(4);
>     fbo->setCoverageSamples(4);
>
> but this does nothing, I also tried to set those on the color attachment
> (a render buffer).
> ..but still no luck :/
>
> Anyone an idea on getting multisampling to work with deferred shading?
>
> thanks a lot!
>
> best regards,
> Victor
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

[Opensg-users] Deferred Shading and Multisampling

[Victor H. <vic...@gm...>]

Hallo,

I am trying to get multisampling working with the deferred shading stage.
I tried setting the render target with an FBO with

    fbo->setEnableMultiSample(true);
    fbo->setColorSamples(4);
    fbo->setCoverageSamples(4);

but this does nothing, I also tried to set those on the color attachment (a
render buffer).
..but still no luck :/

Anyone an idea on getting multisampling to work with deferred shading?

thanks a lot!

best regards,
Victor

Re: [Opensg-users] Changing a field name

[Carsten N. <car...@gm...>]

Hello Johannes,

I assume you are asking about .osb file io? You can create a class to
handle reading of your container type, see e.g.
Source/System/FileIO/OSB/OSGOSBGeometryElement.{h,cpp} and in theory there
is a "version" value written (per FC IIRC), so that could be used to
distinguish old/new files. I'm not sure that was ever used to change a
field name, but the OSBGeometryElement uses it to load older style geometry.
Another option would be to use the getSFType() accessor in generic code -
that gives you the Field object instead of the value stored in it.

Cheers,
Carsten

On Thu, Mar 11, 2021 at 11:11 AM Johannes Brunen <jb...@da...>
wrote:

> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

[Opensg-users] Changing a field name

[Johannes B. <jb...@da...>]

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.

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

[Carsten N. <car...@gm...>]

    Hello Johannes,

On Wed, Mar 10, 2021 at 2:43 PM Johannes Brunen <jb...@da...>
wrote:
> 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<OSG::ReflexiveContainerType*> shareTypes;
> shareTypes.push_back(&MyMaterial::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<const ReflexiveContainerType *>(
>                     &pointerType->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 ;-)

ok, I think I understand what you are saying, but believe the issue is that
the declared type of the field is being used to determine if something
should be shared while for your use-case you want the dynamic type of the
pointed to object to be used. So the situation is a bit like having a
pointer to a base class (the static type of the field) that points to a
derived type object (dynamic type of object pointed to by the field) and
you want behavior to depend on the dynamic type, but currently it uses the
static one.
I don't think changing typeDerivedFrom to typeBaseOf would do the right
thing for you either, because that would mean any field with a type that is
a base of MyMaterial (which includes FieldContainer) would be shared; i.e.
everything would be shared. To be honest even if it did do the right thing
I'm not sure it would be safe to change the functions semantics in this way
- although I can definitely see the usefulness of your proposed behavior ;)

Cheers,
Carsten

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

[Johannes B. <jb...@da...>]

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<OSG::ReflexiveContainerType*> shareTypes;
shareTypes.push_back(&MyMaterial::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<const ReflexiveContainerType *>(
                    &pointerType->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 <class InIteratorTypeT> inline
bool TypePredicates::typeDerivedFrom(      InIteratorTypeT  begin,
                                           InIteratorTypeT  end,
                                     const OSG::TypeBase   &type  )
{
    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 OSG::ReflexiveContainerType *> &shareTypes,
    const std::vector<const OSG::ReflexiveContainerType *> &ignoreTypes,
    const std::vector<OSG::UInt16>                         &shareGroupIds,
    const std::vector<OSG::UInt16>                         &ignoreGroupIds)
{
    if(src == NULL)
        return FieldContainerTransitPtr(NULL);

    const FieldContainerType &fcType  = 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 &contentType = 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<const PointerType *>(&contentType);

            // 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<const ReflexiveContainerType *>(
                    &pointerType->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(srcField);
                }
                else
                {
                    dstField->cloneValues(srcField,
                                          shareTypes,
                                          ignoreTypes,
                                          shareGroupIds,
                                          ignoreGroupIds);
                }
            }
        }
    }

    return fcClone;
}


________________________________
From: Carsten Neumann <car...@gm...>
Sent: Wednesday, March 10, 2021 7:52 PM
To: OpenSG (ope...@li...)
Subject: Re: [Opensg-users] Method deepClone possibly not correct

    Hello Johannes,

On Wed, Mar 10, 2021 at 1:08 PM Johannes Brunen <jb...@da...<mailto:jb...@da...>> wrote:
> 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)      )

the way I'm reading this, it means if the field we are looking at is derived from any of the types in shareTypes it gets shared, which sounds correct to me.

> 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\<const FieldContainerType *\>.
>
>     \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 <class InIteratorTypeT> inline
> bool TypePredicates::typeDerivedFrom(      InIteratorTypeT  begin,
>                                            InIteratorTypeT  end,
>                                      const OSG::TypeBase   &type  )
>
>
> 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.

I'm not following this reasoning; I think I'm overlooking something, sorry. If you put MyMaterial's type into the list, other Materials should not be shared, but MyMaterials (and types derived from MyMaterial) should be shared; at least I believe that was the idea modulo bugs.

Cheers,
Carsten

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

[Carsten N. <car...@gm...>]

    Hello Johannes,

On Wed, Mar 10, 2021 at 1:08 PM Johannes Brunen <jb...@da...>
wrote:
> 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)      )

the way I'm reading this, it means if the field we are looking at is
derived from any of the types in shareTypes it gets shared, which sounds
correct to me.

> 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\<const FieldContainerType *\>.
>
>     \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 <class InIteratorTypeT> inline
> bool TypePredicates::typeDerivedFrom(      InIteratorTypeT  begin,
>                                            InIteratorTypeT  end,
>                                      const OSG::TypeBase   &type  )
>
>
> 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.

I'm not following this reasoning; I think I'm overlooking something, sorry.
If you put MyMaterial's type into the list, other Materials should not be
shared, but MyMaterials (and types derived from MyMaterial) should be
shared; at least I believe that was the idea modulo bugs.

Cheers,
Carsten

[Opensg-users] Method deepClone possibly not correct

[Johannes B. <jb...@da...>]

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\<const FieldContainerType *\>.

    \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 <class InIteratorTypeT> inline
bool TypePredicates::typeDerivedFrom(      InIteratorTypeT  begin,
                                           InIteratorTypeT  end,
                                     const OSG::TypeBase   &type  )


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\<const FieldContainerType *\>.

    \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 <class InIteratorTypeT> inline
bool TypePredicates::typeBaseOf(      InIteratorTypeT  begin,
                                      InIteratorTypeT  end,
                                const OSG::TypeBase   &type  )


instead?


Any help is appreciated.

All the best,
Johannes

[Opensg-users] OSG file format and UInt64 fields

[Johannes B. <jb...@da...>]

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

Re: [Opensg-users] Installation of OpenSG on Ubuntu 20.04

[Dreer, J. <Jut...@lr...>]

Hello Carsten, Hello Victor,

first of all: Thank you so much for your advice!

I cloned the sources from Gerrit’s repo and compared it to the master branch that I had fetched from Sourceforge before: these are identical (apart from one little typo in a source file that was corrected on Sourceforge). I did not fetch the sources from Victor’s repo so far, because in the meantime I was successful to compile the Sourceforge version of OpenSG. Next step will be to compile some older applications based on OpenSG 2.0 which we want to keep running after the migration to Ubuntu 20.0, and test them.

Here’s some information on dependencies I used:

  *   We had Boost 1.58.0 in use with OpenSG 2.0 under Ubuntu 16.04 for quite some time, although Boost 1.44 seems to be the recommended version. I kept 1.58.0 also for the new installation
  *   Newer Versions of opennurbs caused problems, so I used the old sources and recompiled them. This was version 5.0.20130711.
  *   The Ubuntu repo contains a version of qhull (2015.2) which does not seem to be suitable, I left it away
  *   The collada version from the Ubuntu repo seems to be o.k (version 2.4). As we don’t have any applications with Collada data, we may never get feedback if this is really working.

Would be interesting to know if the version in the cpp17 branch of Sourceforge has any API changes and if it would be “ready to use” or in an experimental state.

Best Regards

Jutta





Von: Victor Haefner <vic...@gm...>
Gesendet: Dienstag, 16. Februar 2021 22:24
An: ope...@li...
Betreff: Re: [Opensg-users] Installation of OpenSG on Ubuntu 20.04

Hello Jutta,

I would normally have a Ubuntu 20.04 port if I wasn't busy with the windows port of our VR engine, hopefully I will soon find the time to check out 20.04..

I usually get the OpenSG source from Gerrit's repo on Github
https://github.com/vossg/OpenSGDevMaster
or my fork of it:
https://github.com/Victor-Haefner/OpenSGDevMaster

I have a packaging repo for my engine, also with OpenSG, should work for Ubuntu 18.04, until I get the time to build for Ubuntu 20.04
https://github.com/Victor-Haefner/polyvr-packaging
There you can find shell scripts to compile Collada or OpenSG using CMake

I also scrap together a debian package I put in
https://github.com/Victor-Haefner/polyvr-depends
There you can also find the list of ubuntu packages I install as well as a Collada package

I am skipping a few optional dependencies when building OpenSG, but maybe it might help a bit..

best regards,
Victor

On Wed, Feb 3, 2021 at 3:48 PM Dreer, Jutta <Jut...@lr...<mailto:Jut...@lr...>> wrote:

Dear OpenSG experts,



we had an installation of OpenSG 2.0 under Ubuntu 16.04 for quite some time. Now a migration to Ubuntu 20.04 is being planned. I would like to compile and install OpenSG 2.0 again, but I would like to use as many dependencies as possible from the Ubuntu repository. Unfortunatelly there is not much activity on OpenSG any more as it seems.



It seems that my choices are:

- take the old source, which are a commit from February 2017 from www.opensg.org<http://www.opensg.org> (which does not exist anymore)

- use the master branch from sourceforge.net<http://sourceforge.net> which seems to be more recent

- use the cpp17 branch from sourceforge.net<http://sourceforge.net> which might be more suitable for a more recent Gnu compiler (gcc-9), but is this kind of experimental ?



I would be grateful for any hint on experiences with an installation on some "new" Linux, and also for information on which of the dependency libs really need to be the one from the support directory or could be replaced by the system standard version. (a new boost version is certainly not a good idea ... but how about the others?)



Thanks for any information.



Best Regards



Jutta Dreer
_______________________________________________
Opensg-users mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] (no subject)

[Victor H. <vic...@gm...>]

Hello Carsten,

yep, totally forgot about the mipmaps :D
I just set the texture to GL_LINEAR and I got 60 fps! (and still looks good
because its not a static texture on geometry)
Thanks a lot!

Yes, we are using changelists, but its quite some load on the network each
frame.. "works" for small resolutions, meh
The best solution I think would be an OpenSG Video Node, and just sync the
frame ID, I'll try maybe when I'm on vacation ;)

best regards,
Victor


On Tue, Feb 16, 2021 at 10:49 PM Carsten Neumann <
car...@gm...> wrote:

> Hello Victor,
>
> On Tue, Feb 16, 2021 at 4:33 PM Victor Haefner <vic...@gm...>
> wrote:
>
>> I use libav and OpenAL, but this should not matter as I decode everything
>> in a thread..
>> There I also write the frame data into OSG Images and store them for
>> later..
>>
>> When I reach a certain frame I set the OSG Image to a texture chunk, and
>> my draw time goes up drastically..
>>
>
> does the time go up only for the frame where the TextureChunk gets a new
> Image or for all subsequent frames? Do you generate mipmaps for these
> images? Is the texture configured to use (or not) mipmaps?
> It could be the texture upload, but I think it might be worthwhile to do a
> little profiling to determine what operation is causing the bottleneck.
>
>
>> Is it possible to send and cache the images to the GPU to avoid the drop
>> in fps?
>>
>
> Is your decoded video already in GPU memory? I think there was a way to
> make use of textures that were not created by OpenSG itself, but perhaps
> I'm just imagining that?
>
> I would also be interested in displaying video in a distributed
>> visualization environment, does OpenSG have infrastructure for that
>> somewhere?
>>
>
> There is the "normal" distribution path via the ChangeList mechanism, but
> that would copy the (decoded video) image data over the network for each
> OpenSG cluster node. Not sure if that is what you'd want to happen here.
>
> Cheers,
> Carsten
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

Re: [Opensg-users] (no subject)

[Carsten N. <car...@gm...>]

Hello Victor,

On Tue, Feb 16, 2021 at 4:33 PM Victor Haefner <vic...@gm...>
wrote:

> I use libav and OpenAL, but this should not matter as I decode everything
> in a thread..
> There I also write the frame data into OSG Images and store them for
> later..
>
> When I reach a certain frame I set the OSG Image to a texture chunk, and
> my draw time goes up drastically..
>

does the time go up only for the frame where the TextureChunk gets a new
Image or for all subsequent frames? Do you generate mipmaps for these
images? Is the texture configured to use (or not) mipmaps?
It could be the texture upload, but I think it might be worthwhile to do a
little profiling to determine what operation is causing the bottleneck.


> Is it possible to send and cache the images to the GPU to avoid the drop
> in fps?
>

Is your decoded video already in GPU memory? I think there was a way to
make use of textures that were not created by OpenSG itself, but perhaps
I'm just imagining that?

I would also be interested in displaying video in a distributed
> visualization environment, does OpenSG have infrastructure for that
> somewhere?
>

There is the "normal" distribution path via the ChangeList mechanism, but
that would copy the (decoded video) image data over the network for each
OpenSG cluster node. Not sure if that is what you'd want to happen here.

Cheers,
Carsten

[Opensg-users] (no subject)

[Victor H. <vic...@gm...>]

Dear all,


I just spend some time to finally get video+audio working together

My issue is the frame rate.. it drops to 13-16 fps for a resolution
of 1920x1080

I use libav and OpenAL, but this should not matter as I decode everything
in a thread..
There I also write the frame data into OSG Images and store them for later..

When I reach a certain frame I set the OSG Image to a texture chunk, and my
draw time goes up drastically..

Is it possible to send and cache the images to the GPU to avoid the drop in
fps?


I would also be interested in displaying video in a distributed
visualization environment, does OpenSG have infrastructure for that
somewhere?


best regards,
Victor

Re: [Opensg-users] Installation of OpenSG on Ubuntu 20.04

[Victor H. <vic...@gm...>]

Hello Jutta,

I would normally have a Ubuntu 20.04 port if I wasn't busy with the windows
port of our VR engine, hopefully I will soon find the time to check out
20.04..

I usually get the OpenSG source from Gerrit's repo on Github
https://github.com/vossg/OpenSGDevMaster
or my fork of it:
https://github.com/Victor-Haefner/OpenSGDevMaster

I have a packaging repo for my engine, also with OpenSG, should work for
Ubuntu 18.04, until I get the time to build for Ubuntu 20.04
https://github.com/Victor-Haefner/polyvr-packaging
There you can find shell scripts to compile Collada or OpenSG using CMake

I also scrap together a debian package I put in
https://github.com/Victor-Haefner/polyvr-depends
There you can also find the list of ubuntu packages I install as well as a
Collada package

I am skipping a few optional dependencies when building OpenSG, but maybe
it might help a bit..

best regards,
Victor

On Wed, Feb 3, 2021 at 3:48 PM Dreer, Jutta <Jut...@lr...> wrote:

> Dear OpenSG experts,
>
>
> we had an installation of OpenSG 2.0 under Ubuntu 16.04 for quite some
> time. Now a migration to Ubuntu 20.04 is being planned. I would like to
> compile and install OpenSG 2.0 again, but I would like to use as many
> dependencies as possible from the Ubuntu repository. Unfortunatelly there
> is not much activity on OpenSG any more as it seems.
>
>
> It seems that my choices are:
>
> - take the old source, which are a commit from February 2017 from
> www.opensg.org (which does not exist anymore)
>
> - use the master branch from sourceforge.net which seems to be more recent
>
> - use the cpp17 branch from sourceforge.net which might be more suitable
> for a more recent Gnu compiler (gcc-9), but is this kind of experimental ?
>
>
> I would be grateful for any hint on experiences with an installation on
> some "new" Linux, and also for information on which of the dependency libs
> really need to be the one from the support directory or could be replaced
> by the system standard version. (a new boost version is certainly not a
> good idea ... but how about the others?)
>
>
> Thanks for any information.
>
>
> Best Regards
>
>
> Jutta Dreer
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

Re: [Opensg-users] Installation of OpenSG on Ubuntu 20.04

[Carsten N. <car...@gm...>]

Hello Jutta,

On Wed, Feb 3, 2021 at 9:48 AM Dreer, Jutta <Jut...@lr...> wrote:

> Dear OpenSG experts,
>
well, that rules me out, at this point I've not used it for so long that I
certainly don't qualify as an expert ;)


> we had an installation of OpenSG 2.0 under Ubuntu 16.04 for quite some
> time. Now a migration to Ubuntu 20.04 is being planned. I would like to
> compile and install OpenSG 2.0 again, but I would like to use as many
> dependencies as possible from the Ubuntu repository. Unfortunatelly there
> is not much activity on OpenSG any more as it seems.
>
Unfortunately true. In our work game engines have replaced the role OpenSG
used to have.


> It seems that my choices are:
>
> - take the old source, which are a commit from February 2017 from
> www.opensg.org (which does not exist anymore)
>
> - use the master branch from sourceforge.net which seems to be more recent
>
> - use the cpp17 branch from sourceforge.net which might be more suitable
> for a more recent Gnu compiler (gcc-9), but is this kind of experimental ?
>

Gerrit would have to comment on the cpp17 branch, but "master" should be a
good choice. It is the most likely to have seen bug fixes or adjustments
for changes in dependencies.

> I would be grateful for any hint on experiences with an installation on
> some "new" Linux, and also for information on which of the dependency libs
> really need to be the one from the support directory or could be replaced
> by the system standard version. (a new boost version is certainly not a
> good idea ... but how about the others?)
>
I don't have experience to share, but the support libraries were
(originally) primarily for Windows where it is much more painful to get
them all compiled and installed (these days with various package managers
out there that may no longer be such a big problem). The image format
libraries are probably all very stable in their API, so I would not expect
(big) problems from using newer versions there. For some of the more
complex dependencies (collada comes to mind) the situation may be more
complicated and I'm afraid you'll have to try it and see how many compiler
errors you get and how complicated they are to resolve.

Cheers,
Carsten

[Opensg-users] Installation of OpenSG on Ubuntu 20.04

[Dreer, J. <Jut...@lr...>]

Dear OpenSG experts,


we had an installation of OpenSG 2.0 under Ubuntu 16.04 for quite some time. Now a migration to Ubuntu 20.04 is being planned. I would like to compile and install OpenSG 2.0 again, but I would like to use as many dependencies as possible from the Ubuntu repository. Unfortunatelly there is not much activity on OpenSG any more as it seems.


It seems that my choices are:

- take the old source, which are a commit from February 2017 from www.opensg.org<http://www.opensg.org> (which does not exist anymore)

- use the master branch from sourceforge.net which seems to be more recent

- use the cpp17 branch from sourceforge.net which might be more suitable for a more recent Gnu compiler (gcc-9), but is this kind of experimental ?


I would be grateful for any hint on experiences with an installation on some "new" Linux, and also for information on which of the dependency libs really need to be the one from the support directory or could be replaced by the system standard version. (a new boost version is certainly not a good idea ... but how about the others?)


Thanks for any information.


Best Regards


Jutta Dreer

Re: [Opensg-users] OpenSG and Gtk+ 3

[Dirk R. <dir...@gm...>]

Hi Victor,

Happy to hear you could get it to work!

Have a good weekend!

  Dirk


On Sat, Dec 12, 2020 at 4:43 AM Victor Haefner <vic...@gm...>
wrote:

> Good morning,
>
> just a final update on this issue, now its working:
> - added a baseFramebufferID in FrameBufferObject::deactivate
> - removed texBuf->setReadBack(true); when creating the fbo, this was
> messing with rendering to texture.
>
> thanks for the help!
>
> best regards,
> Victor
>
>
> On Fri, Dec 11, 2020 at 7:51 PM Victor Haefner <vic...@gm...>
> wrote:
>
>> Hmm, I realized the simplestage does also allow to register pre/post
>> render functors
>> In the pre render function the active fbo corresponds to the stage fbo
>> I the post render function too.
>> When changing the fbo in the pre render function the stage draws to the
>> widget as expected.
>> When changing it in the post rendering it does nothing.
>> In OSGRenderPartition.cpp, in doExecution, the postrender functions are
>> called before _pRenderTarget->deactivate
>> I guess the fbo gets deactivated then..
>>
>> furthermore the active FBO during renderEnter and renderLeave corresponds
>> to the gtk fbo,
>> thus replacing them wont help.
>>
>> I may still try with a stage as you suggested,
>>
>> best regards,
>> Victor
>>
>> On Fri, Dec 11, 2020 at 5:48 PM Carsten Neumann <
>> car...@gm...> wrote:
>>
>>> Hello Victor,
>>>
>>> On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner <
>>> vic...@gm...> wrote:
>>>
>>>> ..hmm, I think thats what glarea is already doing, and rendering most
>>>> scenes works perfectly.
>>>> It is only when using a stage that the gtk fbo get unbound.
>>>>
>>>
>>> right, I meant putting a Stage at the top of your scene graph so that
>>> OpenSG does not attempt to render anything into the default frame buffer
>>> and manually blit that image to the GtkGLArea.
>>>
>>>
>>>> I thought I could rebind them on renderLeave of the stage, but
>>>> subclassing it is tricky ;)
>>>> Any hints on how to do this without necessarly registering a new type
>>>> in OpenSG?
>>>> I just want to override the renderLeave function.
>>>>
>>>> Maybe is there another way by messing with the render action?
>>>> I'm not sure..
>>>>
>>>
>>> I believe there is a CallbackStage (or similar name) that allows you to
>>> execute code before/after the subtree below that stage is rendered; that
>>> should allow you to bind the Gtk framebuffer object.
>>>
>>> Cheers,
>>> Carsten
>>>
>>>
>>>
>>>> On Thu, Dec 10, 2020 at 11:18 PM Carsten Neumann <
>>>> car...@gm...> wrote:
>>>>
>>>>> Hello Victor,
>>>>>
>>>>> hmm, I can't really claim to have any understanding of how this works
>>>>> any longer, but a quick look at
>>>>> Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740
>>>>> suggests that it always binds the default framebuffer (i.e.
>>>>> glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there
>>>>> is a customization point for this behaviour.
>>>>> Can you perform all your OpenSG rendering into an FBO and when it has
>>>>> completed manually blit to the GtkGLArea? It's a bit unnecessary work
>>>>> performing that extra copy, but may be the quickest way to get it running.
>>>>>
>>>>> Cheers,
>>>>> Carsten
>>>>>
>>>>> On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner <
>>>>> vic...@gm...> wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> I just ported my application from Gtk2 to Gtk3.
>>>>>> Until now I used gtkglext to render with OpenSG into a widget.
>>>>>> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't
>>>>>> get rid of.
>>>>>> So I tried GtkGLArea, it works, but I have a problem when using
>>>>>> framebuffers (for example for texture rendering).
>>>>>> GtkGLArea does not render directly to the window but instead to a
>>>>>> framebuffer and later cairo drawns the framebuffer to the widget vie a
>>>>>> shared GL context..
>>>>>> When I use a framebuffer from OpenSG then once the rendering to it is
>>>>>> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall
>>>>>> correctly.
>>>>>> Normally this would be fine, but with the GtkGLArea it results in a
>>>>>> black window.
>>>>>> Instead It would need to bind to the framebuffers from the gtkglarea.
>>>>>> There is a convenience function to do this, how can I tell OpenSG to
>>>>>> call it after using a framebuffer?
>>>>>>
>>>>>> best regards,
>>>>>> Victor
>>>>>> _______________________________________________
>>>>>> Opensg-users mailing list
>>>>>> Ope...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>>>>
>>>>> _______________________________________________
>>>>> Opensg-users mailing list
>>>>> Ope...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>>>
>>>> _______________________________________________
>>>> Opensg-users mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>>
>>> _______________________________________________
>>> Opensg-users mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>
>> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

Re: [Opensg-users] OpenSG and Gtk+ 3

[Victor H. <vic...@gm...>]

Good morning,

just a final update on this issue, now its working:
- added a baseFramebufferID in FrameBufferObject::deactivate
- removed texBuf->setReadBack(true); when creating the fbo, this was
messing with rendering to texture.

thanks for the help!

best regards,
Victor


On Fri, Dec 11, 2020 at 7:51 PM Victor Haefner <vic...@gm...>
wrote:

> Hmm, I realized the simplestage does also allow to register pre/post
> render functors
> In the pre render function the active fbo corresponds to the stage fbo
> I the post render function too.
> When changing the fbo in the pre render function the stage draws to the
> widget as expected.
> When changing it in the post rendering it does nothing.
> In OSGRenderPartition.cpp, in doExecution, the postrender functions are
> called before _pRenderTarget->deactivate
> I guess the fbo gets deactivated then..
>
> furthermore the active FBO during renderEnter and renderLeave corresponds
> to the gtk fbo,
> thus replacing them wont help.
>
> I may still try with a stage as you suggested,
>
> best regards,
> Victor
>
> On Fri, Dec 11, 2020 at 5:48 PM Carsten Neumann <
> car...@gm...> wrote:
>
>> Hello Victor,
>>
>> On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner <vic...@gm...>
>> wrote:
>>
>>> ..hmm, I think thats what glarea is already doing, and rendering most
>>> scenes works perfectly.
>>> It is only when using a stage that the gtk fbo get unbound.
>>>
>>
>> right, I meant putting a Stage at the top of your scene graph so that
>> OpenSG does not attempt to render anything into the default frame buffer
>> and manually blit that image to the GtkGLArea.
>>
>>
>>> I thought I could rebind them on renderLeave of the stage, but
>>> subclassing it is tricky ;)
>>> Any hints on how to do this without necessarly registering a new type in
>>> OpenSG?
>>> I just want to override the renderLeave function.
>>>
>>> Maybe is there another way by messing with the render action?
>>> I'm not sure..
>>>
>>
>> I believe there is a CallbackStage (or similar name) that allows you to
>> execute code before/after the subtree below that stage is rendered; that
>> should allow you to bind the Gtk framebuffer object.
>>
>> Cheers,
>> Carsten
>>
>>
>>
>>> On Thu, Dec 10, 2020 at 11:18 PM Carsten Neumann <
>>> car...@gm...> wrote:
>>>
>>>> Hello Victor,
>>>>
>>>> hmm, I can't really claim to have any understanding of how this works
>>>> any longer, but a quick look at
>>>> Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740
>>>> suggests that it always binds the default framebuffer (i.e.
>>>> glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there
>>>> is a customization point for this behaviour.
>>>> Can you perform all your OpenSG rendering into an FBO and when it has
>>>> completed manually blit to the GtkGLArea? It's a bit unnecessary work
>>>> performing that extra copy, but may be the quickest way to get it running.
>>>>
>>>> Cheers,
>>>> Carsten
>>>>
>>>> On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner <
>>>> vic...@gm...> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I just ported my application from Gtk2 to Gtk3.
>>>>> Until now I used gtkglext to render with OpenSG into a widget.
>>>>> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't
>>>>> get rid of.
>>>>> So I tried GtkGLArea, it works, but I have a problem when using
>>>>> framebuffers (for example for texture rendering).
>>>>> GtkGLArea does not render directly to the window but instead to a
>>>>> framebuffer and later cairo drawns the framebuffer to the widget vie a
>>>>> shared GL context..
>>>>> When I use a framebuffer from OpenSG then once the rendering to it is
>>>>> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall
>>>>> correctly.
>>>>> Normally this would be fine, but with the GtkGLArea it results in a
>>>>> black window.
>>>>> Instead It would need to bind to the framebuffers from the gtkglarea.
>>>>> There is a convenience function to do this, how can I tell OpenSG to
>>>>> call it after using a framebuffer?
>>>>>
>>>>> best regards,
>>>>> Victor
>>>>> _______________________________________________
>>>>> Opensg-users mailing list
>>>>> Ope...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>>>
>>>> _______________________________________________
>>>> Opensg-users mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>>
>>> _______________________________________________
>>> Opensg-users mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>
>> _______________________________________________
>> Opensg-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
>

Re: [Opensg-users] OpenSG and Gtk+ 3

[Victor H. <vic...@gm...>]

Hmm, I realized the simplestage does also allow to register pre/post render
functors
In the pre render function the active fbo corresponds to the stage fbo
I the post render function too.
When changing the fbo in the pre render function the stage draws to the
widget as expected.
When changing it in the post rendering it does nothing.
In OSGRenderPartition.cpp, in doExecution, the postrender functions are
called before _pRenderTarget->deactivate
I guess the fbo gets deactivated then..

furthermore the active FBO during renderEnter and renderLeave corresponds
to the gtk fbo,
thus replacing them wont help.

I may still try with a stage as you suggested,

best regards,
Victor

On Fri, Dec 11, 2020 at 5:48 PM Carsten Neumann <car...@gm...>
wrote:

> Hello Victor,
>
> On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner <vic...@gm...>
> wrote:
>
>> ..hmm, I think thats what glarea is already doing, and rendering most
>> scenes works perfectly.
>> It is only when using a stage that the gtk fbo get unbound.
>>
>
> right, I meant putting a Stage at the top of your scene graph so that
> OpenSG does not attempt to render anything into the default frame buffer
> and manually blit that image to the GtkGLArea.
>
>
>> I thought I could rebind them on renderLeave of the stage, but
>> subclassing it is tricky ;)
>> Any hints on how to do this without necessarly registering a new type in
>> OpenSG?
>> I just want to override the renderLeave function.
>>
>> Maybe is there another way by messing with the render action?
>> I'm not sure..
>>
>
> I believe there is a CallbackStage (or similar name) that allows you to
> execute code before/after the subtree below that stage is rendered; that
> should allow you to bind the Gtk framebuffer object.
>
> Cheers,
> Carsten
>
>
>
>> On Thu, Dec 10, 2020 at 11:18 PM Carsten Neumann <
>> car...@gm...> wrote:
>>
>>> Hello Victor,
>>>
>>> hmm, I can't really claim to have any understanding of how this works
>>> any longer, but a quick look at
>>> Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740
>>> suggests that it always binds the default framebuffer (i.e.
>>> glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there
>>> is a customization point for this behaviour.
>>> Can you perform all your OpenSG rendering into an FBO and when it has
>>> completed manually blit to the GtkGLArea? It's a bit unnecessary work
>>> performing that extra copy, but may be the quickest way to get it running.
>>>
>>> Cheers,
>>> Carsten
>>>
>>> On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner <vic...@gm...>
>>> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I just ported my application from Gtk2 to Gtk3.
>>>> Until now I used gtkglext to render with OpenSG into a widget.
>>>> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't
>>>> get rid of.
>>>> So I tried GtkGLArea, it works, but I have a problem when using
>>>> framebuffers (for example for texture rendering).
>>>> GtkGLArea does not render directly to the window but instead to a
>>>> framebuffer and later cairo drawns the framebuffer to the widget vie a
>>>> shared GL context..
>>>> When I use a framebuffer from OpenSG then once the rendering to it is
>>>> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall
>>>> correctly.
>>>> Normally this would be fine, but with the GtkGLArea it results in a
>>>> black window.
>>>> Instead It would need to bind to the framebuffers from the gtkglarea.
>>>> There is a convenience function to do this, how can I tell OpenSG to
>>>> call it after using a framebuffer?
>>>>
>>>> best regards,
>>>> Victor
>>>> _______________________________________________
>>>> Opensg-users mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>>
>>> _______________________________________________
>>> Opensg-users mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>
>> _______________________________________________
>> Opensg-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

Re: [Opensg-users] OpenSG and Gtk+ 3

[Victor H. <vic...@gm...>]

Hi Dirk,

we still use it as the core of our VR System, its perfect when working with
distributed systems.
We even recently worked on synchronizing parts of the scenegraph by
filtering the changelist thus enabling collaborative applications.

hehe, I tried to add such an ID, it does work partially, at least the scene
is rendered to the widget,
but the resulting texture is flickering, I'd say 50% of the time it renders
properly to the texture, 50% is just a gray image.
.. and it felt a bit too hacky.

I found the registerLeaveFunction and got to override the stage
renderLeave,
but setting the fbo there didn't help, widget stays black.

best regards,
Victor

On Fri, Dec 11, 2020 at 5:42 PM Dirk Reiners <dir...@gm...> wrote:

> Hi Victor,
>
> Wow, this must be the first time in 15 years or so that I look at OpenSG
> code... ;) Thanks to Carsten and Gerrit for keeping it alive, and you and
> the others for still using it!
>
> Yes, subclassing is tricky, that was always a weakness of OpenSG. What may
> be easier is extension. How about adding a 'baseFramebufferID' field to
> indicate which FBO to use instead of 0?
>
> Just my $.02...
>
> Yours
>
>   Dirk
>
>
> On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner <vic...@gm...>
> wrote:
>
>> Hello Carsten,
>>
>> thanks for the quick reply!
>> ..hmm, I think thats what glarea is already doing, and rendering most
>> scenes works perfectly.
>> It is only when using a stage that the gtk fbo get unbound.
>>
>> I thought I could rebind them on renderLeave of the stage, but
>> subclassing it is tricky ;)
>> Any hints on how to do this without necessarly registering a new type in
>> OpenSG?
>> I just want to override the renderLeave function.
>>
>> Maybe is there another way by messing with the render action?
>> I'm not sure..
>>
>> best regards,
>> Victor
>>
>> On Thu, Dec 10, 2020 at 11:18 PM Carsten Neumann <
>> car...@gm...> wrote:
>>
>>> Hello Victor,
>>>
>>> hmm, I can't really claim to have any understanding of how this works
>>> any longer, but a quick look at
>>> Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740
>>> suggests that it always binds the default framebuffer (i.e.
>>> glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there
>>> is a customization point for this behaviour.
>>> Can you perform all your OpenSG rendering into an FBO and when it has
>>> completed manually blit to the GtkGLArea? It's a bit unnecessary work
>>> performing that extra copy, but may be the quickest way to get it running.
>>>
>>> Cheers,
>>> Carsten
>>>
>>> On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner <vic...@gm...>
>>> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I just ported my application from Gtk2 to Gtk3.
>>>> Until now I used gtkglext to render with OpenSG into a widget.
>>>> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't
>>>> get rid of.
>>>> So I tried GtkGLArea, it works, but I have a problem when using
>>>> framebuffers (for example for texture rendering).
>>>> GtkGLArea does not render directly to the window but instead to a
>>>> framebuffer and later cairo drawns the framebuffer to the widget vie a
>>>> shared GL context..
>>>> When I use a framebuffer from OpenSG then once the rendering to it is
>>>> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall
>>>> correctly.
>>>> Normally this would be fine, but with the GtkGLArea it results in a
>>>> black window.
>>>> Instead It would need to bind to the framebuffers from the gtkglarea.
>>>> There is a convenience function to do this, how can I tell OpenSG to
>>>> call it after using a framebuffer?
>>>>
>>>> best regards,
>>>> Victor
>>>> _______________________________________________
>>>> Opensg-users mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>>
>>> _______________________________________________
>>> Opensg-users mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>
>> _______________________________________________
>> Opensg-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

Re: [Opensg-users] OpenSG and Gtk+ 3

[Carsten N. <car...@gm...>]

Hello Victor,

On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner <vic...@gm...>
wrote:

> ..hmm, I think thats what glarea is already doing, and rendering most
> scenes works perfectly.
> It is only when using a stage that the gtk fbo get unbound.
>

right, I meant putting a Stage at the top of your scene graph so that
OpenSG does not attempt to render anything into the default frame buffer
and manually blit that image to the GtkGLArea.


> I thought I could rebind them on renderLeave of the stage, but subclassing
> it is tricky ;)
> Any hints on how to do this without necessarly registering a new type in
> OpenSG?
> I just want to override the renderLeave function.
>
> Maybe is there another way by messing with the render action?
> I'm not sure..
>

I believe there is a CallbackStage (or similar name) that allows you to
execute code before/after the subtree below that stage is rendered; that
should allow you to bind the Gtk framebuffer object.

Cheers,
Carsten



> On Thu, Dec 10, 2020 at 11:18 PM Carsten Neumann <
> car...@gm...> wrote:
>
>> Hello Victor,
>>
>> hmm, I can't really claim to have any understanding of how this works any
>> longer, but a quick look at
>> Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740
>> suggests that it always binds the default framebuffer (i.e.
>> glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there
>> is a customization point for this behaviour.
>> Can you perform all your OpenSG rendering into an FBO and when it has
>> completed manually blit to the GtkGLArea? It's a bit unnecessary work
>> performing that extra copy, but may be the quickest way to get it running.
>>
>> Cheers,
>> Carsten
>>
>> On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner <vic...@gm...>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I just ported my application from Gtk2 to Gtk3.
>>> Until now I used gtkglext to render with OpenSG into a widget.
>>> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't
>>> get rid of.
>>> So I tried GtkGLArea, it works, but I have a problem when using
>>> framebuffers (for example for texture rendering).
>>> GtkGLArea does not render directly to the window but instead to a
>>> framebuffer and later cairo drawns the framebuffer to the widget vie a
>>> shared GL context..
>>> When I use a framebuffer from OpenSG then once the rendering to it is
>>> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall
>>> correctly.
>>> Normally this would be fine, but with the GtkGLArea it results in a
>>> black window.
>>> Instead It would need to bind to the framebuffers from the gtkglarea.
>>> There is a convenience function to do this, how can I tell OpenSG to
>>> call it after using a framebuffer?
>>>
>>> best regards,
>>> Victor
>>> _______________________________________________
>>> Opensg-users mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>
>> _______________________________________________
>> Opensg-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

Re: [Opensg-users] OpenSG and Gtk+ 3

[Dirk R. <dir...@gm...>]

Hi Victor,

Wow, this must be the first time in 15 years or so that I look at OpenSG
code... ;) Thanks to Carsten and Gerrit for keeping it alive, and you and
the others for still using it!

Yes, subclassing is tricky, that was always a weakness of OpenSG. What may
be easier is extension. How about adding a 'baseFramebufferID' field to
indicate which FBO to use instead of 0?

Just my $.02...

Yours

  Dirk


On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner <vic...@gm...>
wrote:

> Hello Carsten,
>
> thanks for the quick reply!
> ..hmm, I think thats what glarea is already doing, and rendering most
> scenes works perfectly.
> It is only when using a stage that the gtk fbo get unbound.
>
> I thought I could rebind them on renderLeave of the stage, but subclassing
> it is tricky ;)
> Any hints on how to do this without necessarly registering a new type in
> OpenSG?
> I just want to override the renderLeave function.
>
> Maybe is there another way by messing with the render action?
> I'm not sure..
>
> best regards,
> Victor
>
> On Thu, Dec 10, 2020 at 11:18 PM Carsten Neumann <
> car...@gm...> wrote:
>
>> Hello Victor,
>>
>> hmm, I can't really claim to have any understanding of how this works any
>> longer, but a quick look at
>> Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740
>> suggests that it always binds the default framebuffer (i.e.
>> glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there
>> is a customization point for this behaviour.
>> Can you perform all your OpenSG rendering into an FBO and when it has
>> completed manually blit to the GtkGLArea? It's a bit unnecessary work
>> performing that extra copy, but may be the quickest way to get it running.
>>
>> Cheers,
>> Carsten
>>
>> On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner <vic...@gm...>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I just ported my application from Gtk2 to Gtk3.
>>> Until now I used gtkglext to render with OpenSG into a widget.
>>> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't
>>> get rid of.
>>> So I tried GtkGLArea, it works, but I have a problem when using
>>> framebuffers (for example for texture rendering).
>>> GtkGLArea does not render directly to the window but instead to a
>>> framebuffer and later cairo drawns the framebuffer to the widget vie a
>>> shared GL context..
>>> When I use a framebuffer from OpenSG then once the rendering to it is
>>> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall
>>> correctly.
>>> Normally this would be fine, but with the GtkGLArea it results in a
>>> black window.
>>> Instead It would need to bind to the framebuffers from the gtkglarea.
>>> There is a convenience function to do this, how can I tell OpenSG to
>>> call it after using a framebuffer?
>>>
>>> best regards,
>>> Victor
>>> _______________________________________________
>>> Opensg-users mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>
>> _______________________________________________
>> Opensg-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

Re: [Opensg-users] OpenSG and Gtk+ 3

[Victor H. <vic...@gm...>]

Hello Carsten,

thanks for the quick reply!
..hmm, I think thats what glarea is already doing, and rendering most
scenes works perfectly.
It is only when using a stage that the gtk fbo get unbound.

I thought I could rebind them on renderLeave of the stage, but subclassing
it is tricky ;)
Any hints on how to do this without necessarly registering a new type in
OpenSG?
I just want to override the renderLeave function.

Maybe is there another way by messing with the render action?
I'm not sure..

best regards,
Victor

On Thu, Dec 10, 2020 at 11:18 PM Carsten Neumann <
car...@gm...> wrote:

> Hello Victor,
>
> hmm, I can't really claim to have any understanding of how this works any
> longer, but a quick look at
> Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740
> suggests that it always binds the default framebuffer (i.e.
> glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there
> is a customization point for this behaviour.
> Can you perform all your OpenSG rendering into an FBO and when it has
> completed manually blit to the GtkGLArea? It's a bit unnecessary work
> performing that extra copy, but may be the quickest way to get it running.
>
> Cheers,
> Carsten
>
> On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner <vic...@gm...>
> wrote:
>
>> Hello everyone,
>>
>> I just ported my application from Gtk2 to Gtk3.
>> Until now I used gtkglext to render with OpenSG into a widget.
>> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't get
>> rid of.
>> So I tried GtkGLArea, it works, but I have a problem when using
>> framebuffers (for example for texture rendering).
>> GtkGLArea does not render directly to the window but instead to a
>> framebuffer and later cairo drawns the framebuffer to the widget vie a
>> shared GL context..
>> When I use a framebuffer from OpenSG then once the rendering to it is
>> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall
>> correctly.
>> Normally this would be fine, but with the GtkGLArea it results in a black
>> window.
>> Instead It would need to bind to the framebuffers from the gtkglarea.
>> There is a convenience function to do this, how can I tell OpenSG to call
>> it after using a framebuffer?
>>
>> best regards,
>> Victor
>> _______________________________________________
>> Opensg-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

Re: [Opensg-users] OpenSG and Gtk+ 3

[Carsten N. <car...@gm...>]

Hello Victor,

hmm, I can't really claim to have any understanding of how this works any
longer, but a quick look at
Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740
suggests that it always binds the default framebuffer (i.e.
glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there
is a customization point for this behaviour.
Can you perform all your OpenSG rendering into an FBO and when it has
completed manually blit to the GtkGLArea? It's a bit unnecessary work
performing that extra copy, but may be the quickest way to get it running.

Cheers,
Carsten

On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner <vic...@gm...>
wrote:

> Hello everyone,
>
> I just ported my application from Gtk2 to Gtk3.
> Until now I used gtkglext to render with OpenSG into a widget.
> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't get
> rid of.
> So I tried GtkGLArea, it works, but I have a problem when using
> framebuffers (for example for texture rendering).
> GtkGLArea does not render directly to the window but instead to a
> framebuffer and later cairo drawns the framebuffer to the widget vie a
> shared GL context..
> When I use a framebuffer from OpenSG then once the rendering to it is
> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall
> correctly.
> Normally this would be fine, but with the GtkGLArea it results in a black
> window.
> Instead It would need to bind to the framebuffers from the gtkglarea.
> There is a convenience function to do this, how can I tell OpenSG to call
> it after using a framebuffer?
>
> best regards,
> Victor
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

[Opensg-users] OpenSG and Gtk+ 3

[Victor H. <vic...@gm...>]

Hello everyone,

I just ported my application from Gtk2 to Gtk3.
Until now I used gtkglext to render with OpenSG into a widget.
There is a gtk3 port of gtkglext, but I had artifacts that I couldn't get
rid of.
So I tried GtkGLArea, it works, but I have a problem when using
framebuffers (for example for texture rendering).
GtkGLArea does not render directly to the window but instead to a
framebuffer and later cairo drawns the framebuffer to the widget vie a
shared GL context..
When I use a framebuffer from OpenSG then once the rendering to it is done,
OpenSG resets the buffer with glBindFramebuffer(0) if I recall correctly.
Normally this would be fine, but with the GtkGLArea it results in a black
window.
Instead It would need to bind to the framebuffers from the gtkglarea.
There is a convenience function to do this, how can I tell OpenSG to call
it after using a framebuffer?

best regards,
Victor