Re: [Opensg-users] Deferred Shading and Multisampling

[Carsten Neumann]

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 
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
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Changing a field name

[Carsten Neumann]

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

[Carsten Neumann]

Hello Johannes,

On Wed, Mar 10, 2021 at 2:43 PM Johannes Brunen 
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 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 ;-)

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
___
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

[Carsten Neumann]

Hello Johannes,

On Wed, Mar 10, 2021 at 1:08 PM Johannes Brunen 
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\.
>
> \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.

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 mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] (no subject)

[Carsten Neumann]

Hello Victor,

On Tue, Feb 16, 2021 at 4:33 PM Victor Haefner 
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
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

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

[Carsten Neumann]

Hello Jutta,

On Wed, Feb 3, 2021 at 9:48 AM Dreer, Jutta  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 mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

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

[Carsten Neumann]

Hello Victor,

On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner 
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 <
> carsten.p.neum...@gmail.com> 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 
>> 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
>>> Opensg-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>>
>> ___
>> Opensg-users mailing list
>> Opensg-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/opensg-users
>>
> ___
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

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

[Carsten Neumann]

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 
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
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] webassembly port

[Carsten Neumann]

Hello Victor,

as you've noticed NativeWindow is a typedef for the platform specific
implementation of accessing an OpenGL context. PassiveWindow is
intended for cases where you supply an OpenGL context that you have
created for use by OpenSG. As such you are correct that if you don't
need that functionality you don't need the PassiveWindow. For
WebAssembly I guess you could either add a native window
implementation that uses whatever mechanism is available to create
OpenGL contexts or go with the GLUTWindow; unless GLUTWindow also
derives from a NativeWindow - sorry I don't remember off the top of my
head...
Good luck!

Cheers,
Carsten

On Tue, Nov 5, 2019 at 8:34 AM Victor Haefner  wrote:
>
> Hi all,
>
>
> I am attempting a webassembly port of OpenSG
> ..I got to over 60% :D
>
> I'm stuck at VRPassiveWindow.h including VRNativeWindow.h
>
> As far as I can tell there are 4 native windows, X, Win32, Cocoa and EAGL
> Does anybody know how to proceed from there?
> Would I even need the passive window?
> Webassembvly ports do have GLUT, so GLUTWindow would work..
>
> hmm, the more I write.. I guess I'll try without the passive window..
>
> Is someone else working on this? Any help/hints would be greatly appreciated! 
> :D
>
>
> best regards,
> Victor
> ___
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users


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

Re: [Opensg-users] OpenSG2: Documentation

[Carsten Neumann]

Hello Johannes,

On 2018-05-16 02:37, Johannes Brunen wrote:
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.?


hmm, not sure why that is not happening. Can you take a look at the 
generated doxygen config file (${CMAKE_BINARY_DIR}/Doc/opensg-doxy). At 
the end it should have a list of directories to scan.
If the Contrib directories do not show up I would start by putting debug 
output in FUNCTION(OSG_SETUP_DOXYDOC) in CMake/OSGBuildFunctions.cmake 
which is the place that should append the directories for each lib to 
the config file. Hope that helps,


Cheers,
Carsten

--
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...

[Carsten Neumann]

Hello Johannes,

On 2017-05-11 01:23, Johannes wrote:

 > - 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.


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.

This also matches what we do for the face culling mode where GL requires 
a glEnable(GL_CULL_FACE) call and glCullFace(GL_BACK) call, but there is 
only a single field. If it has a value that is valid for glCullFace() we 
issue the glEnable and glCullFace calls otherwise we call glDisable (see 
PolygonChunk).


Cheers,
Carsten

>From e6ed2ea8b451a68d650189fe553fb4a72b7e40e7 Mon Sep 17 00:00:00 2001
From: Carsten Neumann <carsten_neum...@gmx.net>
Date: Tue, 16 May 2017 14:48:04 -0500
Subject: [PATCH] Use GL_NONE to indicate no memory barrier, remove
 useMemoryBarrier field

---
 Examples/Advanced/computeshader3.cpp   |  1 -
 Examples/Advanced/computeshader4.cpp   |  1 -
 Examples/Advanced/computeshader5.cpp   |  1 -
 Examples/Advanced/computeshader6.cpp   |  1 -
 .../ComputeShader/OSGComputeShaderAlgorithm.cpp|  4 +-
 .../ComputeShader/OSGComputeShaderAlgorithm.fcd| 18 +---
 .../OSGComputeShaderAlgorithmBase.cpp  | 99 ++
 .../ComputeShader/OSGComputeShaderAlgorithmBase.h  | 18 +---
 .../OSGComputeShaderAlgorithmBase.inl  | 28 --
 9 files changed, 15 insertions(+), 156 deletions(-)

diff --git a/Examples/Advanced/computeshader3.cpp 
b/Examples/Advanced/computeshader3.cpp
index 871d310..b602dfe 100644
--- a/Examples/Advanced/computeshader3.cpp
+++ b/Examples/Advanced/computeshader3.cpp
@@ -366,7 +366,6 @@ OSG::NodeTransitPtr createScene()
 compShaderChunk->addComputeShader(compShader);
 compShaderChunk->setVariables(compShader->getVariables());
 
-compShaderAlgo->setUseMemoryBarrier(true);
 compShaderAlgo->setUseVariableWorkGroupSize(true);
 compShaderAlgo->setMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT);
 compShaderAlgo->setComputeShader(compShaderChunk);
diff --git a/Examples/Advanced/computeshader4.cpp 
b/Examples/Advanced/computeshader4.cpp
index c24f5d4..88d352c 100644
--- a/Examples/Advanced/computeshader4.cpp
+++ b/Examples/Advanced/computeshader4.cpp
@@ -426,7 +426,6 @@ OSG::AlgorithmComputeElementTransitPtr createComputation()
 compShaderChunk->setVariables(compShader->getVariables());
 
 OSG::ComputeShaderAlgorithmRefPtr compShaderAlgo = 
OSG::ComputeShaderAlgorithm::create();
-compShaderAlgo->setUseMemoryBarrier(true);
 compShaderAlgo->setMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT);
 compShaderAlgo->setComputeShader(compShaderChunk);
 compShaderAlgo->setDispatchConfig(work_group_count);
diff --git a/Examples/Advanced/computeshader5.cpp 
b/Examples/Advanced/computeshader5.cpp
index ef68085..0d1b71a 100644
--- a/Examples/Advanced/computeshader5.cpp
+++ b/Examples/Advanced/computeshader5.cpp
@@ -407,7 +407,6 @@ OSG::AlgorithmComputeElementTransitPtr createComputation()
 compShaderChunk->setVariables(compShader->getVariables());
 
 OSG::ComputeShaderAlgorithmRefPtr compShaderAlgo = 
OSG::ComputeShaderAlgorithm::create();
-compShaderAlgo->setUseMemoryBarrier(true);
 compShaderAlgo->setMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT);
 compShaderAlgo->setComputeShader(compShaderChunk);
 compShaderAlgo->setDispatchConfig(work_group_count);
diff --git a/Examples/Advanced/computeshader6.cpp 
b/Examples/Advanced/computeshader6.cpp
index b096fa6..aef3055 100644
--- a/Examples/Advanced/computeshader6.cpp
+++ b/Examples/Advanced/computeshader6.cpp
@@ -373,7 +373,6 @@ OSG::AlgorithmComputeElementTransitPtr createComputation()
 compShaderChunk->setVariables(compShader->getVariables());
 
 OSG::ComputeShaderAlgorithmRefPtr compShaderAlgo = 
OSG::ComputeShaderAlgorithm::create();
-compShaderAlgo->setUseMemoryBarrier(true);
 compShaderAlgo->setMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT);
 compShaderAlgo->setComputeShader(compShaderChunk);
 compShaderAlgo->setDispatchConfig(work_group_count);
diff --git 
a/Source/Contrib/ComputeBase/ComputeShader/OSGComputeShaderAlgorithm.cpp 
b/Source/Contrib/ComputeBase/ComputeShader/OSGComputeShaderAlgorithm.cpp
index 6b2bd43..d267de5 100644
--- a/Source/Contrib/ComputeBase/ComputeShader/OSGComputeShaderA

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

[Carsten Neumann]

Hi Gerrit,

On 2017-05-10 13:22, Gerrit Voß wrote:
> sorry for being mostly silent, I'm chasing one deadline after another
> since beginning of the year.

not worries, good to hear it's still you doing the chasing instead of 
the deadlines hunting you ;)

> On Wed, 2017-05-10 at 11:11 -0500, Carsten Neumann wrote:
>> On 2017-05-04 01:56, Johannes wrote:
>>> is this still in the pipeline?
>>
>> yes, thank you for the reminder though. Since this modifies existing
>> code (as opposed to mostly adding new classes) I wanted to take a little
>> closer look.
>> - 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.
>> - Can you imagine a situation where a barrier is needed/useful before
>> the compute shader? If so, should we have
>> preMemoryBarrier/postMemoryBarrier fields instead?
>> - In OSGGeo{Integral/Vector}BufferRefProperty you add getOpenGLId helper
>> functions, but then they appear to not be used. Did I miss something?
>
> 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 the changes to OSGGeo{Integral/Vector}BufferRefProperty will break
> existing code and kind of duplicate what the normal properties do.
>
> What was the reason behind these changes ?

Oh right, I missed the part about this being external GL ids that do not 
need mapping. 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. Sorry about the (potential) 
breakage.

Cheers,
Carsten

--
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...

[Carsten Neumann]

Hello Johannes,

On 2017-05-04 01:56, Johannes wrote:
> is this still in the pipeline?

yes, thank you for the reminder though. Since this modifies existing 
code (as opposed to mostly adding new classes) I wanted to take a little 
closer look.
- 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.
- Can you imagine a situation where a barrier is needed/useful before 
the compute shader? If so, should we have 
preMemoryBarrier/postMemoryBarrier fields instead?
- In OSGGeo{Integral/Vector}BufferRefProperty you add getOpenGLId helper 
functions, but then they appear to not be used. Did I miss something?

Other than these small things this is great and if the above triggers 
changes they can be done as follow-ups; I'll commit the current state 
now. Thank you for the additions!

Cheers,
Carsten

--
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: dependency problem

[Carsten Neumann]

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.

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

On 2017-03-09 00:13, Johannes wrote:
> 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 :-)

ah, I see, that makes sense.

> 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

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

[Carsten Neumann]

Hello Johannes,

On 2017-03-08 00:36, Johannes Brunen wrote:
> 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.

hmm, I haven't written the DepthPeelingStage and don't know its details 
well enough - or rather I don't know it at all

> 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.

I'm afraid I have no idea what that does, I can't recall ever having 
seen a transparency mode enum :(

> 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.

> 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?

Transparent objects are rendered after opaque ones in back to front 
order (IIRC using the bounding box center).

> 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 scenariowhere both stages
> are active?

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.

Cheers,
Carsten

--
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

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

[Carsten Neumann]

Hello Johannes,

On 2017-01-18 04:58, Johannes Brunen wrote:
> This one is at the center of what I'm currently working on. We would
> like to have shadows according to a combination of the following resources:

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.

Cheers,
Carsten

--
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] Fwd: Re: OpenSG2: Accumulated changes... part 6: LiPSM

[Carsten Neumann]

[I accidentally dropped the ML]

 Forwarded Message 
Subject: Re: OpenSG2: Accumulated changes... part 6: LiPSM
Date: Mon, 13 Feb 2017 15:47:31 -0600
From: Carsten Neumann <carsten.p.neum...@gmail.com>
To: Johannes Brunen <jbru...@datasolid.de>

Hello Johannes,

On 2017-01-18 04:58, Johannes Brunen wrote:
> This one is at the center of what I'm currently working on. We would
> like to have shadows according to a combination of the following resources:

hmm, is the patch you sent complete? I started converting it into a 
series of commits, but noticed that there are only changes in 
Source/Base/Base - in other words there is no user of LiSPSMTechnique in 
the tree at this point; is that intentional?
That also seems to mean that there is no user of the GL addititions in 
part 5 (yet)?

Thanks & Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

On 2017-02-01 09:03, Johannes wrote:
> finally I have finished the link flag undertaking :-)
> Attached you can find the final diff file.

thank you for the patch. Everybody involved seemed happy with this, so 
I've applied it now.

Cheers,
Carsten


--
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

[Carsten Neumann]

Hello Johannes,

On 2017-01-18 04:58, Johannes Brunen wrote:
> 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.

hmm, this simply exceeds my understanding of the MS tools and their 
options, so I'm just going to take your word for it that this is an 
improvement :)
Unless I hear some objections here I'm planning to apply this in the 
near future. Thanks for the patch,

Cheers,
Carsten


--
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

[Carsten Neumann]

Hello Johannes,

On 2017-01-23 02:05, Johannes wrote:
> 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 :-)

thank you. It appears this in a small way depends on the GL changes in 
part 5 though? I've added the missing function pointer type for 
glFramebufferTextureLayer to OSGGLFuncProtos.h to make it independent of 
that change. Thanks again,

Cheers,
Carsten

--
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] Build problems with boost

[Carsten Neumann]

Hello,

On 2017-01-23 11:21, Andy Somogyi wrote:
> I’m trying to build opensg on MacOS 10.12 Sierra, and it fails when trying 
> accessing boost.
> What version of boost is opensg supposed to work with?. I’m using 1.63.0 
> installed from Brew.

I usually just use what comes with the linux distro, in my case that is 
currently still Fedora 23, that would mean boost 1.59.0 (I think).

> Boost it built without C++11 support, and I try to build Opensg the same way, 
> i.e. disabling C++11.
> I’m using Clang 8.0.
>
> On another note, how does opensg compare complexity wise to openscenegraph. 
> Reason I ask is I’m looking for a simple scene graph library that does not 
> add a significant amount on top of OpenGL, I’m looking to stay as simple and 
> as close to the underlying OpenGL as possible.

I'm not deeply familiar with OpenSceneGraph. I would imagine the level 
of abstraction is somewhat comparable. In general scene graphs have 
fallen a bit out of favor and game engines become more popular as the 
basis for interactive applications. What makes the most sense (as ever 
;) ) depends on your application.

> /Users/andy/src/opensg/Source/Base/Base/OSGAtomic.h:72:27: error: no member 
> named 'atomic_exchange_and_add' in namespace 'boost::detail'
> return boost::detail::atomic_exchange_and_add(pValue, rcDelta);
>~~~^
> /Users/andy/src/opensg/Source/Base/Base/OSGAtomic.h:81:37: error: cannot 
> initialize a parameter of type 'atomic_int_least32_t *'
>   (aka '_Atomic(boost::int_least32_t) *') with an lvalue of type 
> 'RefCountStore *' (aka 'int *')
> boost::detail::atomic_increment(pValue);
> ^~
> /usr/local/include/boost/smart_ptr/detail/sp_counted_base_clang.hpp:29:54: 
> note: passing argument to parameter 'pw' here
> inline void atomic_increment( atomic_int_least32_t * pw )

Hmm, looks like this is making use of boost atomic internals which 
appear to have changed in more recent boost. This would require a little 
bit of investigation to find out what the replacement should be.

Cheers,
Carsten


--
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

[Carsten Neumann]

Hello Johannes,

On 2017-01-20 03:45, Johannes wrote:
> 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 (?)

yes, looks like it is missing. I think it should make use of 
glFramebufferTexture for the cubemap array case though.

> 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.

I think OSG::TextureBuffer is the one that should use 
glFramebufferTextureLayer (for cubemap array and similar cases) to make 
non-layer attachments. To me that seems in line with it's other uses 
where it binds a plain 2D image as the attachment.
Since you have a use case for these, you are likely in a much better 
position to verify changes. Can you adjust the changes to 
TextureBuffer/LayeredTextureBuffer to be in line with the above? Thanks!

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

On 2017-01-18 04:58, Johannes Brunen wrote:
> 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.

I think this changes the semantics of LayeredTextureBuffer in an 
incompatible way, so I'm not sure we can do this right away. See below 
why I think this changes semantics.

> 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.

My understanding of glFramebufferTextureLayer is that it is used to 
attach a single face of a cubemap array texture as a framebuffer 
attachment. While when using a cubemap array texture with 
glFramebufferTexture3D this attaches all 6 faces of the cubemap as a 
layered attachment point. Which of the layers a primitive is rendered to 
is decided at runtime using a geometry shader that assigns to the 
builtin variable gl_Layer.
Therefore (assuming the above is correct and I didn't misread the patch) 
you are changing LayeredTextureBuffer from creating such a layered 
attachment to a non-layered attachment.
I think the use of 'glFramebufferTextureLayer' should only be in 
TextureBuffer, since that is used for non-layered framebuffer attachments.

Cheers,
Carsten

--
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 1: examples

[Carsten Neumann]

Hello Johannes,

On 2017-01-18 04:58, Johannes Brunen wrote:
> on request of Carsten I have split up my 'accumulated changes' into
> smaller chunks so that it easier to look at them.

thank you, this is very helpful.

> This one is an easy on I think. The  examples shader.cpp  and
> phongshaderwithglmaterials.cpp are not working. They were not ported to
> OpenSG 2.
> What I have done is simply use the SimpleSHLChunk instead of the
> SHLChunk class.

I've committed this one, thanks for fixing up those examples!

Cheers,
Carsten

--
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] Compiling opensg2

[Carsten Neumann]

Hello,

I believe the usual way to call cmake is to create the build directory, 
change to it and call cmake with the path to the source dir, e.g.

mkdir build
cd build
cmake 

I typically specify the type of build and the install destination as 
well, leading to a cmake call like:

cmake -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_INSTALL_PREFIX=$HOME/software/opensg2 

This will check for optional components (image format libraries, VTK, 
Qt, etc.) and configure the build with what is available.

Cheers,
Carsten

On 2017-01-06 13:10, Daniel Sperka wrote:
>Can someone please give me commands to build opensg2 on linux? I'm
> looking at porting existing osg1.8 code to osg2, so I need to build
> libOSGSystem and libOSGWindowX (don't need GLUT or Qt)
>
> I'm not familiar with cmake or its conventions and cannot grok the
> correct incantations. Here is what I've tried so far:
>
> * Downloaded snapshot of opensg2 from sourceforge
> * create folder 'Build' root dir of opensg code
> * run cmake like so:
>
> cmake -DOpenSG_BINARY_DIR=./Build \
>   -DOSG_ENABLE_VTK=OFF \
>   -DOSG_ENABLE_C++11=ON \
>   -DOSG_ENABLE_FCD2CODE=ON \
>   -DOSG_VERBOSE_BUILD_MESSAGES=ON
>
> [ Note - I fumbled with the variables here by scanning CCacheLists.txt -
> please advise ]
>
> * cmake gives error like this:
>
> Error copying file "/home/dan/src/opensg2/OpenSG/OSGConfigured.h.cmake"
> to
> "/home/dan/src/opensg2/OpenSG/Source/Base/Base/OSGConfigured.h.tmp.cmake".
>
> - running make in spite of error gives
>
>
> [---cut---]
> /home/dan/src/opensg2/OpenSG/Source/Base/Base/OSGConfigured.h:14:2:
> error: #endif without #if
>  #endif // _OSGCONFIGURED_H_
> [---cut---]
>
>
>
> *** Contents of OSGConfigured.h
>
> [---START---]
> /* #undef OSG_WITH_NVSDKCOMMON */
>
> /* #undef OSG_WITH_NVOCLUTILS */
>
> /* #undef OSG_WITH_CUDACOMMON */
>
> /* #undef OSG_WITH_CUDAUTIL */
>
> /* #undef OSG_WITH_CUDPP */
>
> /* #undef OSG_WITH_CG */
>
> #endif // _OSGCONFIGURED_H_
> [---END---]
>
>
>
>
>
> Clearly something is broke, and I suspect I've just missed some obvious
> cmake setting. Can anyone guide me?
>
> Thanks!
>
> Dan
>
>
> --
> Daniel J. Sperka, Ph. D.
> UC Davis Center for Neuroscience
>
>
> --
> 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
>

--
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] Patch to use 64-bit integers in statistics elements

[Carsten Neumann]

Hello Marcus,

thanks for the patch, I've committed it.

Cheers,
 Carsten

On Fri, Nov 18, 2016 at 6:02 AM, Marcus Lindblom Sonestedt
 wrote:
> Attached is a patch that changes StatElemInt(Once) to use 64-bit integers 
> instead of 32-bits to accumulate the value.
>
> Since we are now successfully rendering more than 2.1 GB of geometry (!), the 
> number of geometry bytes processed previously wrapped around to negative in 
> the statistics foreground.
>
> We're pushing between 1-2 billion triangles per second on a single Nvidia 
> 1080 GTX card.
> (I think we may be getting double the amount due to how statistics work in 
> 2.0 w.r.t the rendering setup they have here.  Still, it's quite a lot.)
>
> These kind of problems are the fun kind of problems. :)
>
> Cheers
> /Marcus
> --
> Med vänliga hälsningar,
> Marcus Lindblom Sonestedt
> Systemarkitekt
> BIT ADDICT - Passion för utveckling
> +46 (0)706 43 63 28
> marcus.lindblom.sonest...@bitaddict.se
> www.bitaddict.se
>
>
> --
>
> ___
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

--
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] tesselation shader

[Carsten Neumann]

Hello Victor,

On 2016-11-01 15:08, Victor Haefner wrote:
> I tried with
>
> char errbuf[4096];
> GLsizei len;
> GLint link_ok = GL_FALSE;
> VRWindowPtr window =
> VRSetup::getCurrent()->getWindows().begin()->second;
> if (!window) return;
> Window* pWin = window->getOSGWindow();
> GLuint uiProgram = GLuint(pWin->getGLObjectId(p->getGLId()));
> if (!uiProgram) return;
>
> glGetProgramInfoLog(uiProgram, sizeof(errbuf), , errbuf);
> glGetProgramiv(uiProgram, GL_LINK_STATUS, _ok);
> if (!link_ok)  {
> string e = "The shaders did not link correctly: ";
> e += string(errbuf);
> VRGuiManager::get()->printToConsole("Errors", e);
> }
>
> but I did not get anything usefull.

hmm, the only things that come to mind are:
- is the OpenGL context for that OSG::Window active at the point in time 
when you make those calls?
- has OpenSG had a chance to create, compile, and link the program? This 
would probably happen as part of the first render that uses the program.

> So I just compile the shader and get the logs
>
> GLuint shaderObject = glCreateShader(type);
> int N = shader.size();
> const char* str = shader.c_str();
> glShaderSourceARB(shaderObject, 1, , );
> glCompileShaderARB(shaderObject);
>
> GLint compiled;
> glGetObjectParameterivARB(shaderObject, GL_COMPILE_STATUS, );
> if (!compiled) gm->printToConsole("Errors", "Shader "+name+" of
> material "+getName()+" did not compiled!\n");
>
> GLint blen = 0;
> GLsizei slen = 0;
> glGetShaderiv(shaderObject, GL_INFO_LOG_LENGTH , );
> if (blen > 1) {
> GLchar* compiler_log = (GLchar*)malloc(blen);
> glGetInfoLogARB(shaderObject, blen, , compiler_log);
> VRGuiManager::get()->printToConsole("Errors", string(compiler_log));
> free(compiler_log);
> }
>
> Would there be a downside on that approach?
> At least it works with the osg attributes

Well, the shader gets compiled twice (once by OpenSG, once by you for 
error checking).

Cheers,
Carsten

--
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

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

[Carsten Neumann]

Hello Johannes,

On 2016-10-21 02:40, Johannes Brunen wrote:
> 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?

I think so and you have probably looked much closer at this than I have 
in a while ;)

> 2. Is it a bug or is it intentional?

I think that was the intention, basically having a LightEngine takes 
over how to render that light - including which state needs to be set. 
Basically it swaps out the lights implementation (in terms of how it 
affects rendering) while keeping the interface (the standard light cores).

> 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.

But if your lights have additional information you will have to extend 
the standard light cores anyway, so you might as well drop them entirely 
and build ones that construct the necessary state for your shaders?
I think either writing a LightEngine that populates the UBO or a 
completely different set of lights is what I'd look at for this.

Cheers,
Carsten

--
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] tesselation shader

[Carsten Neumann]

Hello Victor,

On 2016-10-19 02:41, Victor Haefner wrote:
> I have a tool, an editor, where users can write GLSL shader,
> but I am still missing warning and error output in the gui.
>
> How could I get the error logs of the shader compilation and linkage
> from OpenSG?

I don't think that is exposed at the moment. When a shader is compiled 
it is checked for success and any errors are logged (through the usual 
OpenSG log).
IIRC there are ways to intercept the log streams - but you would likely 
get other messages as well, not just those from the shader compiles. I 
guess the other option could be to get the real GL id of the shader 
object (Window::getGLObjectId, I think) and make the necessary GL calls 
directly - ensuring that the correct GL context corresponding to the 
Window is active at the time.

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

On 07/13/2016 06:41 AM, Johannes wrote:
> You can find a patch file that contains the CMake build system
> adaptation for AntTweakBar on Wikisend:

thanks! I've committed the AntTweakBar related changes.

> 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

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

> 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.

Cheers,
Carsten

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

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

[Carsten Neumann]

Hello Johannes,

On 2016-07-01 01:53, Johannes wrote:
> 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 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.

> 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?

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.

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

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

> 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.

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

On 06/27/2016 04:42 AM, Johannes wrote:
> 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.

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.

> 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?

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.
Thank you for contributing this!

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

On 06/21/2016 05:58 PM, Carsten Neumann wrote:
> On 2016-06-18 03:23, Johannes wrote:
>> 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 HDR background image seems the biggest difference in the pictures
> you sent and what I had tried to run.
> I'll try to run it on linux with an HDR background image tomorrow and
> see if it reproduces - somehow it seems unlikely to me that it is
> OS/platform related since most of the code involved here is platform
> independent.

ok, using the HDR background image I can reproduce the problem on linux. 
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.

I've spent some time looking at the OpenGL calls made as captured by 
apitrace. I compared what happens on a frame before the resize and the 
one where the resize happens. The only differences I could find  were 
the expected resize operations on the various textures.
I don't know what debugging attempts you have made so far, my basic 
approach with the above has been to attempt to find what differences in 
OpenGL calls there are before/after the first resize and (assuming those 
can be found) work backwards from there to find where in OpenSG they 
originate. Perhaps this gives you some ideas on things to try as well. I 
may be able to look some more early next week.

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

On 2016-06-18 03:23, Johannes wrote:
> On 17.06.2016 20:28, Carsten Neumann wrote:
>> 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

ok, got the files this time. Thanks!

>> 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 HDR background image seems the biggest difference in the pictures 
you sent and what I had tried to run.
I'll try to run it on linux with an HDR background image tomorrow and 
see if it reproduces - somehow it seems unlikely to me that it is 
OS/platform related since most of the code involved here is platform 
independent.

> 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.

The changed member function is supposed to update any derived 
values/state based on which fields have changed. However, I think most 
of the state depends on window/viewport sizes which are only known at 
render time.

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

That typically means avoiding to recompute values that are still valid 
from the previous frame. One thing that comes to mind in the case of the 
HDR2 stage is only filling and uploading the uniform buffer if any 
values have changed. I'm not sure how much difference that makes in 
practice though.

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

sorry for the very long delay on this. I had a severe deadline that 
prevented me from looking at anything unrelated to ${DAYJOB}.


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?
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).
The next two weeks should be a bit calmer for me, so I can be more 
responsive ;)


Cheers,
Carsten
--
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

[Carsten Neumann]

Hello Johannes,

On 05/03/2016 10:26 AM, Johannes Brunen wrote:
> 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.

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?

> 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 CallbackAlgorithmForeground is indeed a nice addition, thanks! What 
exactly do you mean by "... provide CMake support for AntTweakBar", i.e. 
what is missing to make it work or work better?

Cheers,
Carsten

--
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] appCSM Crash on Mac OS X

[Carsten Neumann]

Hello Venkat,

I don't have access to an OS X system, but I suspect the problem is 
really this: Unknow container type DrawManager
The data files read by appCSM contained references to a type DrawManager 
which does not exist, there is only CSMDrawManager. I've adjusted (and 
committed) the files to use CSMDrawManager instead, which for me allows 
the application to start.

Cheers,
Carsten

On 05/09/2016 12:22 PM, Venkat B wrote:
> Good day,
>
> Mac OS X El Capitan, OpenSG git latest, Xcode 7.2
>
> I am trying to run the CSM sample app and I get a crash on startup with
> the following backtrace:
> (lldb) bt
> * thread #1: tid = 0x1bc2361, 0x000111ea6e3c
> libOSGBase.2.0.0.dylib`OSG::PThreadBase::getCurrentChangeList() + 28 at
> OSGThread.cpp:291, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x0)
>* frame #0: 0x000111ea6e3c
> libOSGBase.2.0.0.dylib`OSG::PThreadBase::getCurrentChangeList() + 28 at
> OSGThread.cpp:291
>  frame #1: 0x000111da0969
> libOSGBase.2.0.0.dylib`OSG::Thread::getCurrentChangeList() + 9 at
> OSGThread.inl:303
>  frame #2: 0x000111e42929
> libOSGBase.2.0.0.dylib`OSG::FieldContainer::registerChangedContainer(this=0x000113b20760)
> + 313 at OSGFieldContainer.cpp:292
>  frame #3: 0x0001014db13f libOSGContribCSM.2.0.0.dylib`void
> OSG::FieldContainer::editMField OSG::RecordedRefCountPolicy, 0> >(this=0x000113b20760, whichField=4,
> oField=0x000113b207b8) + 63 at OSGFieldContainer.inl:391
>  frame #4: 0x0001014d94f0
> libOSGContribCSM.2.0.0.dylib`OSG::ComplexSceneManagerBase::clearGlobals(this=0x000113b20760)
> + 48 at OSGComplexSceneManagerBase.cpp:704
>  frame #5: 0x0001014daebb
> libOSGContribCSM.2.0.0.dylib`OSG::ComplexSceneManagerBase::resolveLinks(this=0x000113b20760)
> + 43 at OSGComplexSceneManagerBase.cpp:1403
>  frame #6: 0x000111e4307a
> libOSGBase.2.0.0.dylib`OSG::FieldContainer::subReferenceUnrecorded(this=0x000113b20760)
> + 74 at OSGFieldContainer.cpp:470
>  frame #7: 0x0001011878f3
> libOSGContribCSM.2.0.0.dylib`OSG::UnrecordedRefCountPolicy::subRef(pObject=0x000113b20760)
> + 35 at OSGContainerRefCountPolicies.inl:112
>  frame #8: 0x0001014ce2b4
> libOSGContribCSM.2.0.0.dylib`OSG::RefCountPtr OSG::UnrecordedRefCountPolicy>::~RefCountPtr(this=0x00010174d340) +
> 20 at OSGRefCountPtr.inl:110
>  frame #9: 0x0001014ca755
> libOSGContribCSM.2.0.0.dylib`OSG::RefCountPtr OSG::UnrecordedRefCountPolicy>::~RefCountPtr(this=0x00010174d340) +
> 21 at OSGRefCountPtr.inl:109
>  frame #10: 0x7fff89d330ff
> libsystem_c.dylib`__cxa_finalize_ranges + 345
>  frame #11: 0x7fff89d33403 libsystem_c.dylib`exit + 55
>  frame #12: 0x7fff85a605b4 libdyld.dylib`start + 8
>  frame #13: 0x7fff85a605ad libdyld.dylib`start + 1
>
> The following is printed on the screen as the application starts up:
>
> ColorBuffer : 0x0001
> DepthBuffer : 0x0002
> GBuffer : 0x0004
> ShadowFactor: 0x0008
> Unknow container type DrawManager
> WARNING: -> syntax error in Line 71, read '['
> Got 0x11633c080
> loading osg file
> Source/Contrib/ComplexSceneManager/data/system-native.osg ...
> WARNING ADDING SECOND COMPLEX SCENE MANAGER, WILL SELF DESTRUCT IN 45
> SECONDSUnknow container type DrawManager
> WARNING: -> syntax error in Line 71, read '['
> loading data Examples/CSM/Models/tie.wrl ...
> WARNING: ComplexSceneManager: no mainloop exiting
> FieldConnectorFactoryBase::terminate
> WARNING: FieldContainerFactoryBase::terminate: Entry [752] is not NULL
> ([0x116560fb0]).
> WARNING:   [0] [0x116560ed0] [FileContextAttachment] [1 0]
> WARNING: FieldContainerFactoryBase::terminate: Entry [751] is not NULL
> ([0x116560e80]).
> WARNING:   [0] [0x116560dd0] [State] [1 0]
> [snip]
> WARNING:   [0] [0x113c2c760] [Node] [1 0]
> WARNING: FieldContainerFactoryBase::terminate: Entry [422] is not NULL
> ([0x113b208a0]).
> WARNING:   [0] [0x113b20760] [ComplexSceneManager] [1 0]
> WARNING: FieldContainerFactoryBase::terminate: Entry [331] is not NULL
> ([0x116553a60]).
> WARNING:   [0] [0x116553850] [VRMLGenericAtt] [37 0]
> ComplexSceneManager: no mainloop exiting
>
> Any ideas what is happening and what I can do to fix the crash?
> Thanks in advance.
>
> Regards,
> Venkat
>
>
>
> --
> 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 

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

[Carsten Neumann]

Hello Johannes,

On 04/19/2016 03:01 AM, Johannes wrote:
> 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.

done, thanks!

Cheers,
Carsten

--
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] Shader Uniform Update

[Carsten Neumann]

Hello Michael,

On Wed, Apr 6, 2016 at 2:28 AM, Michael Raab  wrote:

> Hi,
> I just realized that it is necessary to commit changes to trigger the call
> to the gl update procedure for shader uniforms.
> The reason is that in
>
> bool ShaderProgramVariables::updateMapSVariable(const Char8 *name,
> const ValueType )
> and
>
> bool ShaderProgramVariables::updateMapMVariable(const char  *name,
> const ValueType )
>
> the local uniform values are changed, but the appropriate field
> (VariableChanged) that should mark changed values is not updated.
> The field is only touched if uniforms are added or if the changed callback
> is executed.
> Can someone explain why this is implemented this way? I temporally added
> the access to the VariableChanged field in both methods like this
>
> this->editVariableChanged((*it).second.first) = true;
>
> For now this solves my issue, but I'm not sure if there are any side
> effects?! Carsten, Gerrit could you please drop some lines on this?
>

in general (re-)computation of derived state is delayed until you commit
changes, e.g. when you change a transform the parent bounding boxes are
only marked as dirty on commit changes. I believe the same principle
applies here and without having looked closely at the code I think this is
working as intended.

Cheers,
Carsten
--
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! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

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

[Carsten Neumann]

Hello Johannes,

On 2016-03-02 02:51, Johannes wrote:
> 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.

HDRStage.cpp:164 with the setRenderTarget call on the partition.

> It boils down to an understanding problem
> of Stages, Partitions and grouping of the latter, I think. Could you
> explain these concept for me?

Stages are the things you place in your scene graph to perform 
"non-conventional" rendering - things that require multiple passes over 
entire sub-graphs, rendering into a different render target, 
pre-/post-processing of the resulting image.
Partitions are the things that represent these passes to the 
RenderAction. They are created by the stages (sometimes multiple 
partitions for a single stage) to perform the individual parts of a 
rendering algorithm/effect. So the HDRStage creates a partition to 
render into the floating point buffer and one to perform the post 
processing.
IIRC partitions are executed in LIFO order, the innermost partition is 
rendered first. In case of the HDRStage one would have to create the 
post-processing partition before the render-to-float-buffer partition. 
That is a bit counter-intuitive, hence there is also the concept of a 
partition group. See HDRStage.cpp:143 this->beginPartitionGroup(a). 
Inside a group the partitions are applied in the order they are added - 
which allows specifying the two steps of the HDRStage in their "natural" 
order.

> 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?

Order is s3, s2, s1. What target they render to depends on how they set 
up the render targets of the partition(s) they create. Typically a stage 
will put its final output into the target inherited from the parent 
stage (which initially is the window framebuffer).

>>> 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.

Hmm, I don't remember the details, but this may be a missing feature for 
some (most?) of the existing stages. I think they have been written with 
the implicit assumption that their output goes to the final window 
framebuffer and not necessarily that many of them get chained together 
and get combined with other rendering - so preserving depth may not have 
been built in yet.

Cheers,
Carsten

--
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] OpenSG 2: HDR example

[Carsten Neumann]

Hello Johannes,

On 2016-03-01 10:52, Johannes Brunen wrote:
> 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?

I suspect that is controlled by the bufferFormat field of HDRStage.

> 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.

> 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.

> What does the shrinking do at all?

It makes the blur cheaper since it is only applied to a smaller texture 
- blurring requires many texture samples making it a moderately 
expensive thing memory bandwidth wise.

> 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?

Cheers,
Carsten

--
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] disable vertex colors in a material forcing the use of the diffuse color

[Carsten Neumann]

Hello Victor,

On 01/15/2016 08:27 AM, Victor Haefner wrote:
> Can I disable/ignore the vertex colors through a material option?
> If not I think the only way is my own shader, or does anybody have
> another idea?

whether the fixed function pipeline uses vertex colors for lighting 
calculations is controlled by glColorMaterial and 
glEnable(GL_COLOR_MATERIAL).
You can use a MaterialChunk with sfColorMaterial and sfBackColorMaterial 
set to GL_NONE. That will make OpenGL use only the colors in the 
material for lighting.
In case you are not using lighting (i.e. glDisable(GL_LIGHTING)) the 
fixed function pipeline will use the vertex colors and I don't think we 
have a way to _not_ pass vertex attributes that are attached to a 
geometry to the GL - so a shader would probably your best (only?) option 
in that case.

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

I've not forgotten about the FBO/scissor issue, but I think I can answer 
this one without needing to start builds ;)

On 12/10/2015 07:01 AM, Johannes Brunen wrote:
> 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?

It should be possible to make use of EXT_texture_sRGB simply by setting 
the ExternalFormat and InternalFormat of a TextureObjChunk to one 
defined by the extension.
For a bit more complete support the enum Image::PixelFormat could be 
extended to contain the sRGB formats. There may not even be any changes 
to the code of TextureObjCunk needed.

Support for ARB_framebuffer_sRGB is mostly needed in the native Window 
implementations, since you have to request and sRGB capable framebuffer 
from the window system (GLX/WGL/...). Once you have that it is mostly a 
matter of calling glEnable(GL_FRAMEBUFFER_SRGB). If you use a 
window/context that is not created by OpenSG itself you need to request 
the sRGB framebuffer there.
In order to make this work correctly when rendering to FBOs those and 
the main Window (i.e. application framebuffer) would need to be made 
aware whether they are linear or sRGB so that OpenSG can call 
glEnable/glDisable(GL_FRAMEBUFFER_SRGB) as needed. For FBOs OpenSG could 
look at the format of the color buffer attachments, but the question 
then is what to do when there are multiple and not all have sRGB 
formats? I'm not sure what OpenGL actually does in that case or if that 
is perhaps a case of FRAMEBUFFER_INCOMPLETE?

Cheers,
Carsten



--
___
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

[Carsten Neumann]

[Back from travel]

Hello Johannes,

On 2015-12-01 07:18, Johannes wrote:
> what is the state of affairs?
> Are you waiting for me to proceed or on a response from Gerrit?

I had hoped for an opinion/reason to go one way or the other :) Thinking 
some more about this now the most convenient default behavior should 
perhaps be:

// Fill FBO but only up to size of viewport. This will not scale the
// captured image unless it is larger than the destination.
w = osgMin(
 static_cast(_sfFrameBufferObject.getValue()->getWidth ()),
 pEnv->getPixelWidth ());
h = osgMin(
 static_cast(_sfFrameBufferObject.getValue()->getHeight()),
 pEnv->getPixelHeight());

osgGlBlitFramebuffer(
 pEnv->getPixelLeft  (),
 pEnv->getPixelBottom(),
 pEnv->getPixelRight ()+1,
 pEnv->getPixelTop   ()+1,

 0, 0, w, h,

Which is what I'm going to commit for now. If I've overlooked a use-case 
where this behavior is problematic/not helpful let me know and I'm happy 
to adjust it.
Thank you for your contribution,

Cheers,
Carsten

--
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] VTK rendering in an OpenGL context created by OpenSG

[Carsten Neumann]

Hello Christian,

On 2015-12-03 08:33, Christian Bar wrote:
> What I get is a crash when I call
> /externalVTKWidget->GetRenderWindow()->Render() /during the first render
> (called in the glut display function). Such crash do no happen when I
> use vtk and glut, withouth OpenSG.
> The crash is caused because vtk internally calls
> /glGetString(GL_VERSION)/, and this returns null, which obviously is an
> error. BTW, if I call /glGetString(GL_VERSION) /BEFORE
> /GLUTWindow->init()/, it returns the correct string ("4.5.0 NVIDIA
> 348.07"). Is glew somehow related to this? I thought that /GLUTWindow
> /already calls the /wglMakeCurrent/ (and related stuff), so I should
> already have a valid OpenGL context...
> BTW (again), /glGetString(GL_VERSION) /always return null after a
> /GLUTWindow->init()/, even if I do not use VTK.

the OpenSG windows only activate the GL context for the duration of the 
rendering and deactivate it when done, so anything outside of 
Window::render() typically does not have an active GL context.
You should be able to surround your additional rendering with 
GLUTWindow::activate()/deactivate() calls to get access to the context.

> Now, the real question is: do I have to build OpenSG and VTK in a way
> that makes them compatible? What are the CMAKE options that manage this?
> Has anyone ever tried to mix OpenSG and VTK?
> My machine runs Windows 8 and I am building the application with Visual
> Studio 2010 x64.

I don't think any additional care beyond the normal windows requirement 
not to mix debug/release libs is needed - but I haven't tried it.

Cheers,
Carsten

--
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

[Carsten Neumann]

Hello Johannes,

On 2015-11-19 09:50, Johannes Brunen wrote:
> 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.

nice, thank you!

> 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.

My feeling here is that it is more intuitive to use the entire FBO 
contents by default. glBlitFramebuffer is capable of performing the 
rescaling if the sizes don't match. If really needed fields could be 
added to FBOBackground that describe the source region to use (the 
destination region is always given by the targeted viewport).

> 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?

> 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.

Hmm, I think you found a bug there. glBlitFramebuffer takes x0,y0,x1,y1 
with x1,y1 being exclusive, so I believe the +1 should be added.

> 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 :-(

On a quick spot check most of the places that use those dimensions pass 
the information to glViewport/glScissor which take x,y,width,height 
arguments and DrawEnv::getPixelWidth/getPixelHeight do the correct 
calculation of those.
I'll check places where glBlitFramebuffer is used, since those seem the 
most likely to have a problem.

> 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.

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.

> 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). So my hope would be that things "just work" - although there 
are probably some details I'm missing... ;)

Cheers,
Carsten

--
___
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

[Carsten Neumann]

Hello all,

On 2015-11-11 10:02, Carsten Neumann wrote:
>> 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!

done. Thanks again,

Cheers,
Carsten

--
___
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

[Carsten Neumann]

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
diff --git 
a/Source/Contrib/CSMPlugin/SimpleTest/CMakeLists.Lib.OSGContribCSMSimplePlugin.txt
 
b/Source/Contrib/CSMPlugin/SimpleTest/CMakeLists.Lib.OSGContribCSMSimplePlugin.txt
index 6e309fa..751cded 100644
--- 
a/Source/Contrib/CSMPlugin/SimpleTest/CMakeLists.Lib.OSGContribCSMSimplePlugin.txt
+++ 
b/Source/Contrib/CSMPlugin/SimpleTest/CMakeLists.Lib.OSGContribCSMSimplePlugin.txt
@@ -11,6 +11,10 @@ IF(${OSGBUILD_OSGContribCSMSimplePlugin})
 ADD_EXECUTABLE(simplePluginApp ${OSGEXCLUDE_TESTS} 
simplePluginApp.cpp 
${OSG_ADD_GLOBAL_EXE_SRC})
 
+IF(OSG_GLOBAL_LIB)
+  TARGET_LINK_LIBRARIES(simplePluginApp ${OSG_GLOBAL_LIB})
+ENDIF()
+
 IF(UNIX)
   TARGET_LINK_LIBRARIES(simplePluginApp ${OSG_DL_LIB} ${OPENGL_gl_LIBRARY})
 ENDIF()
--
___
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

[Carsten Neumann]

Hello Johannes,

On 2015-11-09 07:00, Johannes wrote:
>>> 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.

I had been more thinking of a second "map" for chunks that are to be 
removed. I see that would not be entirely trivial given that the 
existing map field is added through a mixin.

>> Below you can find the patch file and the modified source files.

Thank you for the patch. I've applied it.

Cheers, 
Carsten

--
___
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

[Carsten Neumann]

Hello Johannes,

On 2015-10-27 07:19, Johannes wrote:
> 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 :-)

looks good to me. I think for consistency with most of the rest of the 
API (and symmetry with addOverride) it should be subOverride instead of 
removeOverride.
Could you also please add a comment to the new bool removeOverride field 
describing what it does.
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 :)

Cheers,
Carsten

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

Re: [Opensg-users] SSAO, DS stage and textures

[Carsten Neumann]

Hello Victor,

On 2015-08-24 15:48, Victor Haefner wrote:
 I have a question regarding the deferred shading stage, how could I add
 a texture to pass data (for SSAO) to the ambient shader program?

 Can I access a material somehow to add a texture chunk?

hmm, I don't think such a use case had been considered when the stage 
was written. As far as I can tell in 
DeferredShadingStage::updateStageData() only the g buffer textures and 
light chunks for the light sources are added to the state used for the 
shading passes. One option could be to add an MFStateChunkPtr (?) to the 
stage and add those chunks to all the state used for the shading passes.

Cheers,
Carsten

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

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

[Carsten Neumann]

Hello Johannes,

On Wed, Jul 15, 2015 at 5:27 AM, Johannes Brunen jbru...@datasolid.de
wrote:

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


​done, thanks for the patch!

 Cheers,
Carsten​
--
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

Re: [Opensg-users] Implementing a cutting plane with OSG::ClipPlaneChunk: flickering of geomerty on the plane

[Carsten Neumann]

Hello Christian,

On Wed, Jun 3, 2015 at 6:51 AM, Altenhofen, Christian
christian.altenho...@igd.fraunhofer.de wrote:
 This works approach works quite well, but here comes the tricky part:

 Additionally to clipping the model, we fill the hole by generating new
 geometry on the plane. When rotating the camera, one can clearly see
 flickering of the single triangles on this geometry as it gets clipped more
 or less randomly because of numerical inaccuracy.

have you seen Examples/Simple/clipplanecaps{,2}.cpp which contain
pretty complete examples how one can implement something like this?

 The problem can be compared to Z-fighting, but with the clipping plane
 instead of a second geometry…

 Introducing a small delta on the plane equation for the clipping helped a
 bit, but is more a quick hack than a proper solution.
 Is there a technique like polygon offsetting that also works for the
 ClipPlaneChunks?

It seems to me that if there is geometry that is co-planar with the
clipping plane applying an offset to the plane equation is pretty much
what polygon offset does.

 Are there some flags or something that can be set in way, that the
 ClipPlaneChunk ignores one specific child node in the scene graph?

You can keep  the exceptional object in a branch of the scene that
is not a child of MaterialChunkOverrideGroup, that way it will not be
affected by the clip planes. Alternatively you could insert a node
with a MaterialGroup above the exceptional object - everything below a
MaterialGroup uses the material set there, ignoring ChunkOverrides and
(IIRC) local materials.

Cheers,
Carsten

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

Re: [Opensg-users] OpenSG Web site

[Carsten Neumann]

Hello Johannes,

On Wed, May 27, 2015 at 2:08 AM, Johannes Brunen jbru...@datasolid.de wrote:
 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?

hmm, unfortunately it appears to require physical access to the
machine :(  I'll see if I can get someone located closer to it to give
it a nudge.

   Cheers,
  Carsten

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

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

[Carsten Neumann]

Hello Johannes,

On Wed, May 27, 2015 at 2:21 AM, Johannes Brunen jbru...@datasolid.de wrote:
 Does anyone has some experience with GUI integration into OpenSG?

not personally.

 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/

I've used a tiny bit of anttweakbar, but not together with OpenSG. It
is quite easy for simple things, but the more complex your
requirements are (or become) the more it shows that it originally was
targeted at building UIs for graphics demos.

 Did anyone actually wrapped one of these libraries with OpenSG?

I would think you can get something usable fairly quickly by making
the UI a Foreground (that is assuming you want it as an overlay to the
scene, not UI elements in the scene with perspective projection
applied to them). For that the library should be able to work with an
OpenGL context that it did not create itself and ideally save/restore
OpenGL state on entry/exit from the library (to avoid confusing
OpenSG's state tracking).

   Cheers,
  Carsten

--
___
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

[Carsten Neumann]

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/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Stages - DataSlotId

[Carsten Neumann]

Hello Michael,

On 03/16/2015 10:15 AM, Michael Raab wrote:
 just wanted to detail my question...
 I would like to access some data that is local to a certain stage.
 Stages typically store their data using iDataSlot, which makes access to
 those a bit unhandy.
 My current case refers to the DeferredShadingStage. I would like to get
 access to a certain TextureObjChunk to be able to share it with a
 successive stage.
 So could someone please tell me
   - why this iDataSlot concept was implemented and

many stages have internal objects that depend on the camera (or window) 
that is being rendered to - think framebuffer object attachments. In 
order to avoid constantly re-sizing these when the same scene is 
rendered from different viewports they are stored with the iDataSlot 
mechanism which makes them local to the RenderAction - this uses the 
assumption that different viewports are rendered with different 
RenderActions, but that is often the case.

   - what would be the appropriate approach to access that stage related
 data.

Hmm, I suppose one option could be to additionally store the last used 
object in the stage itself. Or perhaps add an interface that allows 
access to the data store when given a RenderAction.

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/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Bugfix ShadowStage

[Carsten Neumann]

Hello Michael,

On 03/11/2015 08:40 AM, Michael Raab wrote:
 I've fixed a bug in ShadowStage.cpp. If the light core of a certain
 light node of the stage was changed (e.g. switching from point light to
 directional light), the shadow handling was not updated.

thank you for the patch! The first hunk:

@@ -334,8 +334,12 @@ Action::ResultE ShadowStage::renderEnter(Action 
*action)
  //fprintf(stderr, ShadowStage::renderEnter\n);

  if(pData-getRunning() == true)
-return returnValue;
+{
+   if(getShadowOn() == false)
+   pData-setRunning(false);

+   return returnValue;
+   }

  pData-setRunning(true);

looks incorrect though. IIRC the purpose here is to avoid clobbering the 
ShadowStageData of a running stage when tree traversal happens to 
encounter the same stage a second time (e.g. because of the use of 
VisitSubTree cores). If the shadow is off setRunning(false) is called 
around line 463.
I've applied the other parts of the patch. Thanks again,

Cheers,
Carsten

PS: I know there is another patch by you pending, apologies for the very 
long delay on it, I'm just now getting some spare cycles for OpenSG again.

--
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

[Carsten Neumann]

Hello Johannes,

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

welcome back :)

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

Thank you for the bug fixes!

 I have found the following problems:

 1. OSGShaderCache: Usage of incorrect end iterator types

applied.

 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!

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

applied.

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

Agreed, it should be cleared. Applied.

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/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG with tracked HMD

[Carsten Neumann]

Hello Michael,

On 02/02/2015 04:32 AM, Michael Raab wrote:
 Hello Casten,
 do you have an idea when this change will be commited?

I've just committed it. Thanks for sending the code!

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/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG with tracked HMD

[Carsten Neumann]

Hello Michael,

On 01/26/2015 03:29 AM, Michael Raab wrote:
 I was trying to setup an application configuration with a HMD as output
 (Oculus). I wasn't able to find an appropriate camera decorator to apply
 the head orientation similar to OSGProjectionCameraDecorator.
 So I would propose to add an additional decorator, e.g.
 HeadTrackedStereoDecorator (HTSD), between StereoCameraDecorator (SCD)
 and ProjectionCameraDecorator (PCD), moving the user field from PCD to HTSD.
 I've attached a sample implementation. Let me know your thoughts.

thanks for sending the code! I've not worked very much with HMDs, but 
seem to have a vague recollection that they can be handled with 
OSGProjectionCameraDecorator - albeit perhaps not very elegantly ;)

That being said, I'm happy to insert your decorator into the inheritance 
hierarchy. If there are other opinions now would be a good time to voice 
them :) Thanks!

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/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

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

[Carsten Neumann]

Hello Johannes,

On 01/07/2015 09:08 AM, Johannes Zarl wrote:
 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.

yes, makes sense to me. Thank you for the patch, it's applied.

Cheers,
Carsten

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Clustering and attributes

[Carsten Neumann]

Hello Victor,

On 01/08/2015 06:35 AM, Victor Haefner wrote:
 I compile my server with:

 #!/bin/bash
 libs=-lOSGBase -lOSGContribTrapezoidalShadowMaps -lOSGCluster
 -lOSGDrawable -lOSGEffectGroups -lOSGFileIO -lOSGGroup -lOSGImageFileIO
 -lOSGState -lOSGSystem -lOSGUtil -lOSGText -lOSGWindow -lOSGWindowGLUT
 -lOSGWindowX -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXmu -lXi
 -lboost_system
 libpaths=-L/usr/lib/opensg

 g++ VRServer.cpp $libs $libpaths -o VRServer

 Everything on a single local machine, same opensg installation, same
 problem :(
 I tried compiling OpenSG with OSG_ENABLE_OGL_VERTEXT_ATTRIB_FUNCS=ON and
 got:

 cmake .. -DOSGBUILD_TESTS=OFF -DOSG_ENABLE_OGL_VERTEXT_ATTRIB_FUNCS=ON

 CMake Warning:
Manually-specified variables were not used by the project:

  OSG_ENABLE_OGL_VERTEXT_ATTRIB_FUNCS

yes, it appears that option (together with the code it controlled) was 
removed/rewritten in commit fadad10632f50b122fe95e0a0cf50bdda1045a85 
(from 2014-07-17).

 When I rerun cmake again I don't get that warning but after compiling
 OpenSG the problem is still there.

If the server is still printing the message about 
OSG_ENABLE_OGL_VERTEX_ATTRIB_FUNCS it is definitely using a different 
set of OpenSG libraries - the code producing that message was part of 
what was rewritten.

 I do this at the beginning of my server:
  OSG::preloadSharedObject(OSGBase);
  OSG::preloadSharedObject(OSGContribCSMSimplePlugin);
  OSG::preloadSharedObject(OSGContribWebInterface);
  OSG::preloadSharedObject(OSGGroup);
  OSG::preloadSharedObject(OSGUtil);
  OSG::preloadSharedObject(OSGCluster);
  OSG::preloadSharedObject(OSGContribCSM);
  OSG::preloadSharedObject(OSGDrawable);
  OSG::preloadSharedObject(OSGImageFileIO);
  OSG::preloadSharedObject(OSGWindowGLUT);
  OSG::preloadSharedObject(OSGContribBackgroundLoader);
  OSG::preloadSharedObject(OSGContribGUI);
  OSG::preloadSharedObject(OSGDynamics);
  OSG::preloadSharedObject(OSGState);
  OSG::preloadSharedObject(OSGWindow);
  OSG::preloadSharedObject(OSGContribCgFX);
  OSG::preloadSharedObject(OSGContribPLY);
  OSG::preloadSharedObject(OSGEffectGroups);
  OSG::preloadSharedObject(OSGSystem);
  OSG::preloadSharedObject(OSGWindowX);
  OSG::preloadSharedObject(OSGContribComputeBase);
  OSG::preloadSharedObject(OSGContribTrapezoidalShadowMaps);
  OSG::preloadSharedObject(OSGFileIO);
  OSG::preloadSharedObject(OSGText);

 commenting them did not help..

Those should not be related, I think.

 any ideas where I can continue to investigate?

You could try running with environment variable LD_DEBUG=libs to get the 
runtime linker to print information about where it loads libs from - see 
man ld.so for other settings.

Cheers,
Carsten

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Clustering and attributes

[Carsten Neumann]

Hello Victor,

On 2014-12-05 05:48, Victor Haefner wrote:
 I tried to run my application on a cluster and the slaves did not
 display the geometry with custom attributes and gave me this in console:

 WARNING: attributes given, but support not enabled, please compile with
 OSG_ENABLE_OGL_VERTEXT_ATTRIB_FUNCS=ON

 I tried to recompile the cluster server with
 -DOSG_ENABLE_OGL_VERTEXT_ATTRIB_FUNCS=ON without success, I will now
 recompile the client with that flag and then opensg.

IIRC that is a cmake flag of OpenSG's build system, so I don't think 
it'll have an effect if you recompile your application code - this is 
not a flag that is passed to the compiler to define a pre-processor 
macro on the command line; unfortunately the syntax for setting cmake 
variables on the command line looks exactly like it was.

 Any idea why it runs perfectly on the local application?

To me it sounds a bit like there are OpenSG builds compiled with 
different options in the mix. Can you make sure all machines use
OpenSG builds compiled with the same options?

Cheers,
Carsten

--
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=164703151iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Collada animations/read callback/load progress

[Carsten Neumann]

Hello Filip,

On 2014-12-01 14:37, Filip Szeliga wrote:
 I have a couple of questions about collada import.
 1) when I load a collada file with predefined blender animations and
 check for them using the code in character demo, no global attachments
 are found. do you know what the problem might be?

hmm, one side effect of the great flexibility of collada is that many 
tools store the same kind of information in slightly different ways. My 
guess would be that blender exports animation data in a way the loader 
is not able to handle.

 2) Does opensg support read progress for collada? it seems that i always
 get 0% and 100% when it is done and nothing inbetween?

I don't think that has been implemented for collada. For simple file 
formats one can often use the read position in the file being loaded as 
an indicator of progress, but for collada we first create the DOM 
representation and then convert that to OpenSG data structures.

 3) Is there a way to receive the currently processed node when loading
 collada files? Because it seems that the SceneFileHandler function
 setReadCB(fn) only returns a complete file that is currently read.

I think that is intentional. The callback is meant to allow you to 
(temporarily) completely replace the loading code for a file type that 
OpenSG already has a loader for. If a callback is registered most of the 
normal loading is skipped and the callback is expected to take care of 
parsing the file instead.


Cheers,
Carsten

--
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=157005751iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] single point geometry not visible

[Carsten Neumann]

On 11/11/2014 10:47 AM, Carsten Neumann wrote:
 On 11/10/2014 11:41 PM, Victor Haefner wrote:
   Would you happen to have a trace of GL calls issued (e.g. apitrace or
   gDEBugger)? Thanks!

 thanks for sending the info, it confirms that the draw call is actually
 issued and I suspect that this is a similar problem to the one you are
 having with gl_Color.

hmm, digging some more it turns out the difference between having a 
geometry where all properties contain just a single value vs. properties 
with multiple values is that in the former case:

glVertexAttribN{f,d,i,ui}v family of functions is used to pass the 
vertex data and in the latter case buffer objects are filled with the 
data and glVertexAttribPointer is used to make the GL take vertex data 
out of those buffers.

Also interesting is that it is sufficient to add a second position to 
the positions property and leave everything else as is (including the 
index) - that puts the positions into a buffer and seems to make 
everything work. The other properties arrive at the shader even though 
they are set with glVertexAttrib*. This is on linux x86_64 with nvidia 
331.89.
I'm not sure if the spec makes position special in this regard, or if 
OpenSG is missing a setting here, or if this is a driver bug?

Cheers,
Carsten

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] single point geometry not visible

[Carsten Neumann]

Hello Victor,

On 11/10/2014 11:41 PM, Victor Haefner wrote:
 Hi Carsten,

   ... especially with this workaround. What vertex attributes does the
   geometry have (if anything besides positions) and are you using indices?

 I use:
  GeoPnt3fPropertyRecPtr  Pos = GeoPnt3fProperty::create();
  GeoVec3fPropertyRecPtr  Norms = GeoVec3fProperty::create();
  GeoUInt32PropertyRecPtr Indices = GeoUInt32Property::create();
  GeoVec3fPropertyRecPtr  cols = GeoVec3fProperty::create();
  GeoUInt8PropertyRecPtr  Type = GeoUInt8Property::create();
  GeoUInt32PropertyRecPtr Length = GeoUInt32Property::create();

 one position, normal and color, GL_POINTS and one index '0', and one
 length '1'.

   Would you happen to have a trace of GL calls issued (e.g. apitrace or
   gDEBugger)? Thanks!

thanks for sending the info, it confirms that the draw call is actually 
issued and I suspect that this is a similar problem to the one you are 
having with gl_Color.
Could you perhaps try creating your vertex shader with 
ShaderProgram::createVertexShader(true) [1] and instead of using the 
built-in vertex attributes in the GLSL code use:

gl_Vertex -osg_Vertex
gl_Normal -osg_Normal
gl_Color  -osg_Color

Since these are then generic vertex attributes they also need to be 
declared at the top of the shader, i.e. you'd need a block like:

attribute vec4 osg_Vertex;
attribute vec4 osg_Normal;
attribute vec4 osg_Color;

Cheers,
Carsten

[1] alternatively you can call createDefaulAttribMapping() on your 
vertex shader - that function also has the full list of names if you 
need more than the three attributes above.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Shader gl_Color is wrong

[Carsten Neumann]

Hello Victor,

On 11/08/2014 07:43 PM, Victor Haefner wrote:
 I have a small problem on my
 AMD Radeon HD 7500M/7600M

 - using colors per vertex works without shader
 - using colors per vertex and a shader accessing them with gl_Color
 works in older OpenSG 2
 - the variable gl_Color in the vertex shader is black with the newest
 version of OpenSG 2

 on nvidia I have no problems.

 the shader is a simple pass through shader

  #version 120
  void main( void ) {
  gl_Position = gl_ModelViewProjectionMatrix*gl_Vertex;
  gl_FrontColor = gl_Color;
  }

  #version 120
  GLSL(
  void main( void ) {
  gl_FragColor = gl_Color;
  }

 but the problem applies to all my shaders accessing the color

hmm, sounds like it could be a problem with aliasing of the built-in 
attributes and generic (user defined) attributes. IIRC nvidia aliases 
generic attribute 0 with gl_Vertex and some other number with gl_Color 
etc. - other vendors don't do that.

 What information can I provide here to help find the issue?
 I tried gdebugger but it does not run on that system because of some
 library bug, I will look into it.

Can you try setting geo-setUseAttribCalls(true) on the relevant Geometry?
It would be helpful to know which code path in Geometry::drawPrimitives 
you hit (there is big 3 case if statement at the bottom of it) and if 
you make any changes to the fields Geometry::_sfUseVao or 
GeoProperty::_sfUsevbo from their defaults?

Cheers,
Carsten

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

Re: [Opensg-users] single point geometry not visible

[Carsten Neumann]

Hello Victor,

On 2014-11-10 15:52, Victor Haefner wrote:
 I have a case where I want to display a single point geometry, but it
 just doesn't show it.
 The stats foreground shows that the point is there:

 Drawables: (drawn)
 points: 1
 verts: 1

interesting, my first guess would have been frustum culling believing 
that the geometry has an empty bounding volume and throwing it away, but 
since it shows up as 'drawn' in the stats, that seems unlikely...

 I worked around it by drawing two points at the same position, not a big
 deal..

... especially with this workaround. What vertex attributes does the 
geometry have (if anything besides positions) and are you using indices?

 I just wanted to report it, anyone ever encountered this?

Would you happen to have a trace of GL calls issued (e.g. apitrace or 
gDEBugger)? Thanks!

Cheers,
Carsten


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

Re: [Opensg-users] Material Override

[Carsten Neumann]

Hello Michael,

On 11/05/2014 09:55 AM, Michael Raab wrote:
 Hello Carsten,
 I need to come back to this issue. I just realized that in certain
 situations it is not possible to override all material information below.
 For example if I want to highlight a sub tree that uses a clip chunk
 somewhere, I need to apply this clipping in the highlight pass, too.
 Is there a way to exclude certain chunk types from override?

I'm about to leave for travel, so this is a bit short:
The material override completely replaces the materials in the subtree, 
no exceptions AFAIK. There is a ChunkOverrideGroup that selectively 
allows overriding of certain chunks leaving  the remaining chunks of a 
mterial as is - however, there again the override chunk always takes 
precedence over what is in the material.

Cheers,
Carsten

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

Re: [Opensg-users] Billboard particle shader

[Carsten Neumann]

Hello Victor,

On 11/04/2014 06:17 PM, Victor Haefner wrote:
 the gl_ProjectionMatrix allows me to compute the up and right vector in
 view coordinates.
 vec4 right = gl_ProjectionMatrix*vec4(1,0,0);
 vec4 up = gl_ProjectionMatrix*vec4(0,1,0);
 I can use those vectors to create a nice quad in the geometry shader.
 The problem is when using head tracking (OSGProjectionCameraDecorator).
 The orientation of the head messes with the gl_ProjectionMatrix, and
 thus with the shape of my quad.
 I essentially just need the aspect ratio of the viewport in my shader.
 Passing it as a variable is not possible (I think?) because I have a
 cluster environment, multiple viewports, with different aspect ratios...

you can use one of the 'magic' OpenSG variables:
uniform vec2 OSGViewportSize;

see Source/State/Shader/Variables/OSGShaderVariableOSG.{h,cpp} and 
ShaderProgram::addOSGVariable()

Cheers,
Carsten

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

Re: [Opensg-users] Check for VAO extension

[Carsten Neumann]

Hello Michael,

On 10/16/2014 03:15 PM, Michael Raab wrote:

we had (again) a customer with an older Quadro graphics board which
unfortunately does not even support vertex array objects. As there was
no check for their support before calling the appropriate GL functions,
I added 2 tests for their extension (GL_ARB_vertex_array_object) to make
sure the application does not crash. Code it attached.


thanks! I think there are still some code paths that could hit this 
problem though, I'm proposing the attached instead. What do you think?


Cheers,
Carsten
diff --git a/Source/System/NodeCores/Drawables/Geometry/Base/OSGGeometry.cpp b/Source/System/NodeCores/Drawables/Geometry/Base/OSGGeometry.cpp
index 7d2e731..e3628cc 100644
--- a/Source/System/NodeCores/Drawables/Geometry/Base/OSGGeometry.cpp
+++ b/Source/System/NodeCores/Drawables/Geometry/Base/OSGGeometry.cpp
@@ -378,6 +378,7 @@ UInt32 Geometry::handleClassicGL(DrawEnv *pEnv,
 glEndList();
 }
 else if(_sfUseVAO.getValue() == false ||
+!pWin-hasExtension(_arbVertexArrayObject) ||
 (propGeoPumpGroup::AllVAOMask) != GeoPumpGroup::AllVAOMask)
 {
 GeoPumpGroup::SplitGeoPump pump = 
@@ -536,6 +537,7 @@ UInt32 Geometry::handleAttGL(DrawEnv *pEnv,
 glEndList();
 }
 else if(_sfUseVAO.getValue() == false ||
+!pWin-hasExtension(_arbVertexArrayObject) ||
 (propGeoPumpGroup::AllVAOMask) != GeoPumpGroup::AllVAOMask)
 {
 GeoPumpGroup::SplitGeoPump pump = 
@@ -653,6 +655,14 @@ UInt32 Geometry::handleVAOGL(DrawEnv *pEnv,
 Window   *pWin  = pEnv-getWindow();
 GLHandlerOptions  glOptions = { uiOptions };
 
+if(!pWin-hasExtension(_arbVertexArrayObject))
+{
+SWARNING  Geometry::handleVAOGL: Extension 
+  'GL_ARB_vertex_array_object' not supported by window 
+  pWin  std::endl;
+return 0;
+}
+
 if(mode == Window::initialize || mode == Window::needrefresh ||
mode == Window::reinitialize)
 {
@@ -721,6 +731,15 @@ void Geometry::handleVAODestroyGL(DrawEnv *pEnv,
 UInt32   glid;
 Window  *pWin = pEnv-getWindow();
 
+if(!pWin-hasExtension(_arbVertexArrayObject))
+{
+SWARNING  Geometry::handleVAODestroyGL: Extension 
+  'GL_ARB_vertex_array_object' not supported by window 
+  pWin
+  std::endl;
+return;
+}
+
 if(mode == Window::destroy)
 {
 OSGGETGLFUNCBYID_GL3_ES(glDeleteVertexArrays,
@@ -854,6 +873,7 @@ void Geometry::drawPrimitives(DrawEnv *pEnv, UInt32 uiNumInstances)
 }
 }
 else if( _sfUseVAO.getValue() == false ||
+!pWin-hasExtension(_arbVertexArrayObject) ||
 (propGeoPumpGroup::AllVAOMask) != GeoPumpGroup::AllVAOMask)
 {
 #if (!defined(OSG_OGL_COREONLY) || defined(OSG_CHECK_COREONLY))   \
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Redundant state changes

[Carsten Neumann]

Hello Michael,

On 10/14/2014 02:46 PM, Michael Raab wrote:
 while debugging the last days I stumbled over the fact that OpenSG does
 lots of redundant function calls. I'm attaching some screenshots of a
 gDebugger session for a simple scene (simple geometry, 4 lights).
 After rendering 81 frames I have amongst others 1312 calls to glLightf
 which are ALL redundant.

are these redundant within a single frame or only if considering state 
across frames? OpenSG does not track state between frames and looking at 
System/State/Base/OSGLightChunk.cpp:LightChunk::activate() specifying 
state for a light requires 8-10 calls to glLightf. In that sense the 
number of redundant state changes is not surprising.

 I'm not sure how much these things affect the
 overall performance of the rendering system.

I think that mostly global things like lights, fog, and perhaps a few 
others show that much redundancy between frames.
My (perhaps optimistic?) hope would be that since the drivers can detect 
and report the redundant state change that they also avoid any 
reprogramming of the GPU and so the overhead is mostly on the CPU side 
for making an unneeded GL call.
I think for more complex scenes (with multiple materials in particular) 
the ratio of such redundant calls vs. needed ones goes down sharply.

 Would something like a state cache help to minimize such redundancies,
 or do you think the cache look ups are equal or more expansive than the
 redundant calls?

Without data that shows this slows things down quite a bit, I'm not sure 
if that is something worth worrying about too much.
All that is assuming that the majority of redundant calls is between 
frames, a high number of redundant calls _within_ a single frame would 
be more important to look at IMHO.

Cheers,
Carsten

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] FBO cleanup

[Carsten Neumann]

Hello Michael,

On 10/10/2014 10:20 AM, Michael Raab wrote:
 the problem is solved but actually I'm not sure why. glCreateProgram was
 called twice by OSGSimpleSHLChunk::handleGL. Seems that the uiProgram
 value that handleGL() retrieves from pWin was no ok.
 I solved it by calling frameInit() and frameExit() around
 renderAllViewports(). In that case I did not call render() as I do not
 what the window to swap() as I have the FBO as target.
 Can you tell me what frameInit() is doing?

had to look that up first: it initializes extensions and fetches the 
relevant function pointers from the GL context to cache them. Without it 
extensions won't work properly on the context.

Cheers,
Carsten

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] FBO cleanup

[Carsten Neumann]

Hello Michael,

On 10/07/2014 05:10 PM, Michael Raab wrote:
 Am 07.10.2014 16:39 schrieb Carsten Neumann carsten.p.neum...@gmail.com:
 In the usual scene rendering the timed shader behavior stops until the
 video capturing gets stopped. I checked with gDebugger and in case of
 capturing the video the GLContext receives a copy of the initial shading
 program and the variable update seems to affect only this.

 Hmm, here I'm not sure I can follow: my understanding was that your
 setup now only has one GL context (Window) that is used for both
 rendering to the FBO as well as the regular back buffer and so there
 should only be one instance of the shader program? Do you think you can
 track down where that copy comes from, because I have a feeling that
 there should not be a copy in the first place - that way there would
 also not be any confusion which program's uniform value gets updated.


 Yes there is one context and the shader program instance should be there 
 once. Actually I have no clue where and why it is constructed. Do have an 
 idea where to start looking for it?

hmm, not sure if it's helpful, but there is essentially just one place 
that calls glCreateProgram: OSGShaderExecutableChunk.cpp:260, so that 
may be a starting point?

Cheers,
Carsten

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] FBO cleanup

[Carsten Neumann]

Hello Michael,

On 2014-10-07 13:14, Michael Raab wrote:
 this way it works much better. But there is one thing remaining. We have
 some shaders that a time dependent. So I have to update a uniform
 variable before each frame.

ok.

 During video capture I have to update that var, render to FBO (for the
 video frame) and afterwards render to backbuffer (the usual frame). The
 variable update seems to affect only the FBO rendering.

just to make sure I understand it correctly: the variable has (or should 
have) the same value when rendering to the FBO and the regular back buffer?

 In the usual scene rendering the timed shader behavior stops until the
 video capturing gets stopped. I checked with gDebugger and in case of
 capturing the video the GLContext receives a copy of the initial shading
 program and the variable update seems to affect only this.

Hmm, here I'm not sure I can follow: my understanding was that your 
setup now only has one GL context (Window) that is used for both 
rendering to the FBO as well as the regular back buffer and so there 
should only be one instance of the shader program? Do you think you can 
track down where that copy comes from, because I have a feeling that 
there should not be a copy in the first place - that way there would 
also not be any confusion which program's uniform value gets updated.

Cheers,
Carsten

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Material Override

[Carsten Neumann]

Hello Michael,

On 10/01/2014 02:14 PM, Michael Raab wrote:
 I need to correct my answer. ;-) There are still problems with the
 visual overlay of the highlight material.
   1.) If I use a wireframe as highlight the overlay works as expected..
   2.) If I use GL_FILL for the highlight it is not rendered over the
 'normal material'. For example if I render a cube with backface culling
 enabled, I can see no difference form the outside, but inside I can see
 the highlight material.
 My first guess was depth buffer related issueds. I already tried to
 manipulate the DepthChunk but even with GL_ALWAYS I can't see the
 highlight from the outside.
 3.) If I use a transparent material as highlight, the transparency is
 only correct applied within the sub tree.

hmm, I had not considered how creating a new partition affects the 
material sorting. So I think what we want here is that the stage does 
not create new partitions, but only takes control over traversing the 
tree below it. Can you try removing the {begin,end}PartitionGroup and 
{push,pop}Partition calls? That should cause the objects to be added to 
the parent partition and thus sort normally with them.

Cheers,
Carsten

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Material Override

[Carsten Neumann]

Hello Michael,

On 09/30/2014 04:46 PM, Michael Raab wrote:

thanks for your explanation. I followed your hint and tried implement a
Stage similar to DepthPeelingStage but the rendering looks broken.
The geometry to highlight looks like it is rendered unlit. I'm attaching
the source code, maybe someone has some minutes to look at.


in your case I don't think you want to disable the default partition, 
that is intended for Stages that want to take over rendering entirely [1].
You can also avoid having to copy the viewport and camera settings, by 
changing the pushPartition call to:


this-pushPartition(a, RenderPartition::CopyAll);

I think it would also be better to set the override material on the 
partition that should use it, instead of the parent partition and have 
it inherited.

I'm thinking something like the attached (completely untested).

Cheers,
Carsten


[1] and probably only makes sense for stages that are used very near the 
root of the scene - otherwise I think that is likely to skip rendering 
of objects (namely those that have already been added to the default 
partition).
/*---*\
 *OpenSG *
 *   *
 *   *
 *   Copyright (C) 2000-2013 by the OpenSG Forum *
 *   *
 *www.opensg.org *
 *   *
 * contact: Michael Raab *
 *   *
\*---*/
/*---*\
 *License*
 *   *
 * This library is free software; you can redistribute it and/or modify it   *
 * under the terms of the GNU Library General Public License as published*
 * by the Free Software Foundation, version 2.   *
 *   *
 * This library is distributed in the hope that it will be useful, but   *
 * WITHOUT ANY WARRANTY; without even the implied warranty of*
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU *
 * Library General Public License for more details.  *
 *   *
 * You should have received a copy of the GNU Library General Public *
 * License along with this library; if not, write to the Free Software   *
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. *
 *   *
\*---*/
/*---*\
 *Changes*
 *   *
 *   *
 *   *
 *   *
 *   *
 *   *
\*---*/

//---
//  Includes
//---

#include cstdlib
#include cstdio

#define OSG_COMPILEEXTLIB

#include OpenSG/OSGConfig.h

#include OpenSG/OSGRenderAction.h
#include OpenSG/OSGFrameBufferObject.h
#include OpenSG/OSGCamera.h

#include OSGVDTHighlightStage.h

OSG_BEGIN_NAMESPACE

// Documentation for this class is emitted in the
// OSGVDTHighlightStageBase.cpp file.
// To modify it, please change the .fcd file (OSGVDTHighlightStage.fcd) and
// regenerate the base file.

/***\
 *   Class variables   *
\***/

/***\
 *

Re: [Opensg-users] Material Override

[Carsten Neumann]

Hello Michael,

On 2014-09-30 12:28, Michael Raab wrote:
 I would like to highlight selected objects/geometries. Therefore I
 currently go through all materials/materialgroups of the subtree and
 replace the ChunkMaterial by a MPM to render the highlighting effect in
 a second pass. Works but has some management drawbacks..
 I was wondering if there is the possibity to define this behavior
 somewhere near the root of the subtree, e.g. insert a special core that
 defines that after normal rendering of the subtree, the whole subtree
 gets again rendering with a certain highlight material. Has OpenSG
 currently something like this?

Stages can be used to do that, but I don't think we currently have one 
that does exactly:
- render sub tree normally
- render sub tree with all materials replaced by a given one

 If not, do you think it can be
 implemented straightforward? Could you give me a hint how?

You'd create your own core derived from Stage and use that to do your 
two passes over the sub tree below it. For the second pass you'd set 
action-overrideMaterial() (just like MaterialGroup does) to have your 
highlight material take precedence over the materials on the geometry.

The backend representation of a pass is a RenderPartition which is what 
your stage would create internally. An example of a stage that performs 
multiple passes is the DepthPeelingStage in 
System/NodeCores/Groups/Effects/OIT or the ShadowStage.
Unfortunately I think that all stages that run multiple passes are doing 
rather complex things since so far a more straightforward use case like 
yours has not come up - there are of course much simpler stages, but 
they are all single pass IIRC.

Cheers,
Carsten


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] FBO cleanup

[Carsten Neumann]

Hello Michael,

On 2014-09-26 10:38, Michael Raab wrote:
 Hello Carsten,
 removal of FBO seems to work now. Thanks.
 While debugging I found out that the size of DisplayLists and VBO's
 increase also. Seems the initial set gets recreated with each
 Screenshot, and of course never destructed. I guess the PassiveWindow
 causes this as OpenSG links GLObjects to a specific window, correct?

yes, for most (all?) purposes you can think of a Window == OpenGL context.

 I think that's not the behavior I need as all the (gl)objects I need for
 the screenshot are already created. What I need to do is to redirect the
 rendering content from my main window to a specific FBO as the
 screenshot may have a different size as the main window. Is there a
 better/more efficient way to do this?

Right, that is the purpose of Stage (and derived) NodeCores, they can 
redirect the rendering of the tree below them into an FBO. 
Examples/Simple/fbotexture.cpp shows how this can be done with the 
SimpleStage.
For making screenshots you could keep the Stage above the 'normal' root 
of your scene and normally start rendering at that root. If you want to 
create a screenshot start rendering at the Stage above it, i.e. 
temporarily change the root used by the viewport.

Cheers,
Carsten

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] MultiDisplayWindow and threads

[Carsten Neumann]

Hello Victor,

On 2014-09-27 22:05, Victor Haefner wrote:
 I got it to work, I think it was that I had to commit changes in the
 main Thread before rendering and not afterwards.

glad to hear it. Yes, the commit should happen before rendering/merging 
your changelists elsewhere, that way side effects of a change are 
applied together with the change that caused them.

Cheers,
Carsten

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] MultiDisplayWindow and threads

[Carsten Neumann]

Hello Victor,

On 2014-09-25 21:35, Victor Haefner wrote:
 I see nothing on the cluster client and I get this output:
 ...
 WARNING: New container type 'GeoPnt3fProperty' local id '6476' remote id
 '1100' dies because of missing ref counts.
 WARNING: New container type 'GeoVec3fProperty' local id '6477' remote id
 '1101' dies because of missing ref counts.
[SNIP]
  Any ideas why the refcount is 'missing' ??

I haven't had a chance to look at/think about the code you've posted. 
These warnings mean that the machine received the information that a new 
FieldContainer was created, but the changes sent to the machine did not 
contain any info about a ref count increase. That means at the end of 
processing the received changes the container has zero references and 
thus is destroyed (containers are kept 'artificially' alive for the 
duration of the sync but not longer).

 I think I am doing something wrong when merging the changelists..

 I also did not fully understand what committing a changelist does.

The CL serves two (related) purposes. The first is entirely unrelated to 
multi-threading or clusters: changes are recorded (which FC and which 
Fields of the FC) and when calling OSG::commitChanges() the changed() 
member function of modified FCs is called so that they can update 
internal state that depends on the changed fields. Changes that are 
recorded but for which commitChanges() was not called yet are 
'uncommitted' changes, afterwards they are 'committed' changes.

The second purpose is to be able to transfer changes to a different 
aspect copy (local or remote) of an FC. Therefore commitChanges() does 
not throw away the change record, but keeps it until the CL is cleared 
(for single thread, non-cluster apps it can be done in one call: 
commitChangesAndClear()). In a threaded/cluster application you would 
usually clear the CL right after merging it to the destination 
aspect/sending it over the network - that way you don't loose changes 
and avoid applying them twice.

Hope the above helps, cheers,
Carsten


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] FBO cleanup

[Carsten Neumann]

Hello Michael,

On 09/25/2014 04:00 PM, Michael Raab wrote:
 I'm using a passive window with a FBOViewport attached to create
 screenshots. Works great, but while searching for a memory leak, I found
 out that the FBO attached to the FBOViewport gets not cleaned up.
 The OpenSG FieldContainers for the FBO, FBOViewport and PassiveWindow
 get destructed but glDeleteFramebuffer or glDeleteFramebufferEXT are
 never called. This should be done by FrameBufferObject::handleDestroyGL
 but this never gets called. Actually I don't know why?! Could someone
 please have I look?

is the Window going away at the same time as the FBO? In that case there 
is no Window::doFrameExit run after the FBO is destroyed, so there is no 
period where the OpenGL context is active and the corresponding GL 
object can be cleaned up - in general GL objects are only destroyed at 
the end of the (following) frame.
To allow the Window to perform this cleanup without rendering a frame 
you can call Window::runFrameExit.

Cheers,
Carsten

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG Warning Message

[Carsten Neumann]

Hello,

On 09/18/2014 04:42 PM, Благоја Стојкоски wrote:
 Now, the scenario that I have is, I have 4 threads whose changes get
 merged like so:

 OSG::Thread::getCurrentChangeList()-merge(*my_threads[i]-getChangeList());

 This is done in a for cycle that goes through all the threads.
 my_threads is an array of OSG::ThreadRefPtr

 After this the changes in the threads get cleared with this call:

  my_threads[i]-getChangeList()-clear();

 This is where the warning message appears. It gets generated in the
 FieldContainer.cpp file in line 322
 (http://sourceforge.net/p/opensg/code/ci/master/tree/Source/Base/FieldContainer/Base/OSGFieldContainer.cpp#l322)

 I managed to fix this by changing the clearing of the ChangeList to:

  my_threads[i]-getCurrentChangeList()-clear();

 However, I cannot find what is the difference between getChangeList and
 getCurrentChangeList, so I can not be sure if what I did is correct.
 When testing the program with this change in place, I can not spot
 anything wrong, but I just want to be sure.

I doubt this does what you want it to do: Thread::getCurrentChangeList() 
is a static member function that returns the ChangeList (CL) of the 
thread executing the code, while getChangeList is a (non-static) member 
function that returns the CL of the thread object it is called on. So 
after the change you are only clearing the current threads CL, not those 
you've merged from.

The message warns that multiple threads are operating on the same aspect 
(essentially copies of a FieldContainer (FC) that are associated with 
threads) and modify the same FC. This can be problematic since changes 
are recorded in a per-thread CL, but each aspect copy of a FC only has 
one pointer to a CL entry. If, for example, thread A is the first to 
modify a FC f then f._pContainerChanges is set up to point into the CL 
of A. If later a thread B on the same aspect copy also modifies f the 
change should be recorded in the CL of B, but since f._pContainerChanges 
already exists that record is just augmented to also store the latter 
change.
Whether that is a problem in practice is hard to say in general.

 That's why I decided to ask you guys. Also I would like to ask you if
 you could point me to some other sources of documentation or tutorials
 for the latest OpenSG, apart from the wiki on http://www.opensg.org/ and
 the documentation on http://opensg.fraunhofer.sg?

I don't think we have any.

Cheers,
Carsten

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] TextureObjChunk - GL_VERSION_1_2

[Carsten Neumann]

Hello Michael,

On 08/20/2014 03:16 PM, Michael Raab wrote:
 the attached patch solved that issue for me.

thanks for the patch! I've committed it.

   the GL_VERSION_x_y defines are defined by the OpenGL header(s), that is
   GL/gl.h
 Ok I see, but OSG adds the missing definitions via OSGGLExt.h. Why
 deciding which method to call (glTexSubImage3D or glTexSubImage3DEXT)
 during compile time? Depends more on the driver or?

Agreed, I think that is more in line with what we do elsewhere.

Cheers,
Carsten

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Problem with matrix decomposition

[Carsten Neumann]

Hello Michael,

On 08/15/2014 07:45 PM, Michael Raab wrote:
 Am 15.08.2014 16:51 schrieb Carsten Neumann carsten.p.neum...@gmail.com:
 assuming that recombining this back into matrices yields the starting
 matrices (i.e. it is not a bug in the decomposition) this would be
 caused by a degree of freedom in the algorithm.

 Does it really  produce the initial Matrix? Haven't tested this...

 I can think of the following options:
 - figure out where this degree of freedom is and make choose the scale
 orientation more consistently.

 Sorry I don't understand this..

 - can you use a ComponentTransform instead of a plain Transform and only
 modify the individual components. That would make the decomposed form
 the canonical representation and only build the matrix from those.

 That is not an option as the matrix is the result of a sequence of 
 transformations.

 - can you make assumptions about the matrix, e.g. is it composed from
 translation, rotation, and (uniform) scale only?

 Unfortunately not. The only assumption I can think of is that the scale 
 should be applied without any additional scale orientation.
 Usually I think of transformation matrices as a combination of the 3 
 components translation, rotation and scale. Actually I do not know where the 
 scale orientation is necessary or useful.

the problem with that is that if your sequence of transformations 
contains a scale, a rotation and another scale (i.e. M = S * R * Z) you 
can not really find a rotation R' and scale S' such that M = R' * S':

  (s_x  )  (r_xx  r_xy  r_xz   )
S =  (s_y  )  R = (r_yx  r_yy  r_yz   )
  (s_z  )  (r_zx  r_zy  r_zz   )
  (1)  (  1)

 ( s_x z_x r_xx  |  s_x z_y r_xy  |  s_x z_z r_xz  |   )
S * R * Z = ( s_y z_x r_xx  |  s_x z_y r_xy  |  s_y z_z r_xz  |   )
 ( s_z z_x r_xx  |  s_z z_y r_xy  |  s_z z_z r_xz  |   )
 (   |||  1)

In R' * S' the columns of the rotation are all scaled by the same 
factor, while in S * R * Z every row and column has its individual scale 
factor (s_* z_*). The two scaling operations S and Z happen along 
different axis. It is possible to find a rotation (call it SR) and new 
scaling factors S'' such that this 'complicated scaling along different 
axis' can again be represented as scaling along the canonical axis' in 
that rotation (!) - that is the product S * R * Z can be written:
   R' * SR * S'' * SR^-1
where R' is a rotation and S'' is a scaling matrix, SR is a rotation 
(into a coordinate system where we can scale along the canonical axis) - 
the scale orientation.

Hope this makes some sense and that I got it right ;)

Cheers,
Carsten

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Problem with matrix decomposition

[Carsten Neumann]

Hello Michael,

On 08/20/2014 10:06 AM, Michael Raab wrote:
 after reading a bit more about this, I'm aware why scale orientation is
 necessary in special cases.

ok, in that case ignore my other mail, it may get some things wrong 
since it's been a while since I touched the decomposition code and I 
also don't have access to Graphics Gems IV at the moment :)

 Our manipulation works now, too.

Glad to hear that! :)

 Thanks for the support.
 While playing around with Matrix::getTransform() we added the missing
 snuggle support. If you think it is worth to be commited, the patch is
 attached.
 (Source may be optimized but this is more or less the original code from
 Graphics Gems IV).

Thanks for the patch! I have a very vague recollection of considering 
that step of the algorithm and for some reason ended up not implementing 
it - unfortunately I don't remember what the reason was.
Do you include the snuggle operation in your source tree? Have you 
noticed it having an effect?

Thanks  Cheers,
Carsten

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] TextureObjChunk - GL_VERSION_1_2

[Carsten Neumann]

Hello Michael,

On 2014-08-20 11:11, Michael Raab wrote:
 TextureObjChunk.cpp contains the following lines:
 // define GL_TEXTURE_3D, if not defined yet
 #ifndef GL_VERSION_1_2
 #  define GL_FUNC_TEXIMAGE3DOSG_DLSYM_UNDERSCOREglTexImage3DEXT
 #  define GL_FUNC_TEXSUBIMAGE3D OSG_DLSYM_UNDERSCOREglTexSubImage3DEXT
 #else
 #  define GL_FUNC_TEXIMAGE3DOSG_DLSYM_UNDERSCOREglTexImage3D
 #  define GL_FUNC_TEXSUBIMAGE3D OSG_DLSYM_UNDERSCOREglTexSubImage3D
 #endif
 The token GL_VERSION_1_2 is nowhere defined in the source tree,
 therefore the EXT functions are used. At the moment my test Intel HD
 system crashes as extension GL_EXT_texture3D is present but function
 glTexSubImage3DEXT returns a NULL pointer.

I'll bite my tongue on this one... ;)

 Is there a reason for this construct? Who was intended to define
 GL_VERSION_1_2? Using glTexSubImage3D everything runs fine with the
 Intel chip..

the GL_VERSION_x_y defines are defined by the OpenGL header(s), that is 
GL/gl.h

Cheers,
Carsten

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] BUG: Infinite loop in OSG::Window::frameExit with PassiveWindow and no context

[Carsten Neumann]

Hello Marcus,

On 08/18/2014 12:06 PM, Marcus Lindblom Sonestedt wrote:
 This happens if a PassiveWindow is destroyed while there is no current
 active context.

hmm, arguably that is already the bug: destroying a PassiveWindow 
requires an active context (just like rendering with it does), so that 
it can clean up OpenGL objects.

Cheers,
Carsten

--
___
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

[Carsten Neumann]

Hello Johannes,

On 08/12/2014 04:52 PM, Johannes wrote:
 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.

ah, of course, I managed to confuse myself about which type had the 
function removed.

 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

Thanks for these links. Reading a bit about the upgrade recommendations 
it seems to me we can just unconditionally change it to 
_pMapper-Update() - that works with 5 and 6.
Alternatively we can just guard this with VTK_MAJOR_VERSION = 6, since 
the code is only compiled when VTK is available and thus avoid adding 
more custom defines :)
I've committed the change, thanks!

Cheers,
Carsten

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

Re: [Opensg-users] Problem with matrix decomposition

[Carsten Neumann]

Hello Michael,

On 2014-08-15 14:09, Michael Raab wrote:
 If I try to decompose 2 Matrices which are nearly the same I get a
 result scale vector that has switch axis. Here's an example:
 Matrix 1:
 1.040   -1.0400.0000.000
 0.7070.7070.0000.000
 0.0000.0001.0000.000
 0.0000.0000.0001.000
 Result 1:
Rotation 0, 0, 45
Scale 1.47031, 1, 1
Scale Orientation 0, 0, -0.382683, 0.92388
 Matrix 2:
 1.046   -1.0460.0000.000
 0.7070.7070.0000.000
 0.0000.0001.0000.000
 0.0000.0000.0001.000
 Result 2:
Rotation: 0, 0, 45
Scale: 1, 1.47986, 1
Scale Orientation: 0, 0, 0.382683, 0.92388
 Has someone an explanation for this?

assuming that recombining this back into matrices yields the starting 
matrices (i.e. it is not a bug in the decomposition) this would be 
caused by a degree of freedom in the algorithm.
I can think of the following options:
- figure out where this degree of freedom is and make choose the scale 
orientation more consistently.
- can you use a ComponentTransform instead of a plain Transform and only 
modify the individual components. That would make the decomposed form 
the canonical representation and only build the matrix from those.
- can you make assumptions about the matrix, e.g. is it composed from 
translation, rotation, and (uniform) scale only?

Cheers,
Carsten

--
___
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

[Carsten Neumann]

Hello Johannes,

On 08/08/2014 12:24 PM, Johannes Brunen wrote:
 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;

fixed.

 2. The next two issues are relevant only because I switched to VTK 6.1:
 a) CMakeLists.txt line 735
 from
OSG_SET(OSG_VTK_LIBS
 vtkCommon;vtkFiltering;vtkGraphics;vtkIO;vtkRendering)

 to
include(${VTK_USE_FILE})
OSG_SET(OSG_VTK_LIBS ${VTK_LIBRARIES})

Ok, this probably changes the set of libraries we link with. On the 
other hand IIRC this case is used for when picking up whatever libs are 
installed in the system and not assuming they were built with settings 
that are compatible with the OpenSG build - in other words this is 
probably a harmless change to make ;)

 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?

 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.

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.

Thanks for the report,

Cheers,
Carsten

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

Re: [Opensg-users] OpenSG2.0 - Issues and Improvements

[Carsten Neumann]

Hello Michael,

On 08/06/2014 10:22 AM, Michael Raab wrote:
 we have some problems, actually crashes, on client laptop that use Intel
 HD chips. The problems are linked to the usage of BlendChunk's and I
 think we have narrowed it down to the BlendEquation.
 It seems Intel HD chips and their drivers do not support GL_ARB_imaging
 extension, which is necessary for glBlendEquation. This problem arised
 with the switch from 1.8 to 2.0. I checked the BlendChunk implementation
 for differences and I've got a presumption what may be the problem. In
 1.8 the BlendChunk uses ::hasExtension() to check for GL_ARB_imaging.
 2.0 uses hasExtOrVersion(). So I guess that the GL version is large
 enough to get a true here even if the extension is not supported. What
 is the reason why this check was changed?

my guess would be because it is in the standard since GL version 1.4 or 
thereabouts - not that that would be the first time Intel drivers 
claiming some version/feature as supported and then happily ignore it ;)
Let me take a look at your follow up patch and see if we can get this to 
work for both conforming and broken drivers.

 Furthermore I've improved some other things:
 1.) TextureBuffer::processPreDeactivate(): Check if image is assigned to
 TextureObj, before accessing it..

fixed,

 2.) OSGGeoSplitVertexArrayPumpGroup/OSGGeoVertexArrayPumpGroup: We had
 some Geometries that had at certain times no vertices. Calling
 glDrawArray with vertexCount 0 caused crashes on some graphics cards. I
 added a check here.

fixed,

 3.) OSGImage: Added simple hash calculation to be able to compare images
 faster.

+this-_hashCode = seed;
+for(UInt32 i=0; i_mfPixel.size(); ++i)
+{
+this-_hashCode =
+this-_hashCode * prime + (Int32)((_mfPixel[i]));
+}
+
+this-_hashCode = seed;

err, it looks to me like there's some typos in this [1] and I'm afraid 
as is this does not give me a warm fuzzy feeling...
Is the caching of the hash value important for you (given that it gets 
invalidated by a change to _any_ field of the image)? Otherwise I would 
slightly prefer to not make this a member function (Image already has a 
hugely fat interface), but a free utility function. Also, using 
OSG::SizeT for the hash code would make this play more nicely with C++11 
std::hash, which uses std::size_t.

 4.) OSGBlendChunk: In some cases glBlendEquation was used where
 glBlendEquationEXT should have be used.

- other mail.

Thanks for the fixes!

Cheers,
Carsten


[1] hash code gets overwritten to seed,
you seem to be using the address of pixel (truncated to 32 bit) not the 
content?

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] Bug in ShaderProgramChunk and feature request for SimpleSHLChunk

[Carsten Neumann]

Hello Marcel,

On 08/06/2014 01:53 PM, Marcel Weiler wrote:
 This line should probably be

   this-addTessEvaluationShader(value);

yup, absolutely, good catch, fixed.

 Also it would be nice if there were functions for reading tessellation
 shader programs directly in a SimpleSHLChunk. Currently there are only
 the functions 'readFragmentProgram', 'readGeometryProgram' and
 'readVertexProgram'.
 I would appreciate it if 'readTessControlProgram' and
 readTessEvaluationProgram' were added.

done. Thanks for the bug report!

Cheers,
Carsten

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2.0 - Issues and Improvements

[Carsten Neumann]

Hello Michael,

On 08/06/2014 03:08 PM, Michael Raab wrote:
 quick update on that. Finally I found a laptop that has a Intel HD
 Graphics board. Indeed extension GL_ARB_imaging is not supported while
 GLversion is 4.0.0.
 I changed the hasExtOrVersion() calls back to hasExtension() and the
 crash moved ;-)

hmm, the problem with making that change is that IIUC this will break on 
GL ES, since it has imaging extension and glBlendEquation is standard there.

Gerrit: any thoughts on what the best way to handle this is? Something like:

if(hasExtension(ARB_imaging)

else if(hasExtOrversion(ARB_imaging, 0x0104, 0x0200)

?

 Extensions GL_EXT_blend_minmax and  GL_EXT_blend_subtract are
 supported but retrieving the function pointer for glBlendEquationExt is
 0x0.

hurray for driver bugs ;(

Cheers,
Carsten

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OpenSG2.0 - Issues and Improvements

[Carsten Neumann]

Hello Michael,

On 08/07/2014 11:52 AM, Michael Raab wrote:
 Caching the hash value along with the image would be a useful feature as
 at certain times we do material optimizations which include the
 necessity to compare images quickly.
 Computing the hash values over and over would cause a slowdown...

ok, thanks, I've added it.

Cheers,
Carsten

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] QuadTreeTerrain rendering problem

[Carsten Neumann]

Hello Christian,

On 07/29/2014 04:21 PM, Christian Bar wrote:
 In the meanwhile, I've discovered that the original shader actually works 
 with a directional light, but not with a point light. Otherwise, with my 
 modification it works with the point light, but not with the directional one.

 To make both lights work, I added after the line
 vec3 LightPosition = gl_LightSource[0].position.xyz;\n
 of the original shader the following lines:
 if(gl_LightSource[0].position.w != 0.0)\n
 LightPosition -= vec3(gl_ModelViewMatrix * gl_Vertex);\n
 Also, in the fragment shader I added the light color to the fragment final 
 color calculation:
 color = clamp(gl_LightSource[0].diffuse.rgb * texcolor * basecolor * 
 intensity, 0.0, 1.0);\n
 Hope this makes sense to you :)

sorry for the delay. Those are nice improvements, thanks for sending 
them! Committed.

Cheers,
Carsten

--
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] QuadTreeTerrain rendering problem

[Carsten Neumann]

Hello Christian,

On 07/28/2014 03:04 PM, Christian Bar wrote:
 I managed to make the QuadTreeTerrain rendering work inside my application.
 I changed the light position calculation inside the vertex shader. Now
 it is:

 vec3 LightPosition = gl_LightSource[0].position.xyz -
 vec3(gl_ModelViewMatrix * gl_Vertex);\n

 I'm not a shader expert, but to me now it seems to work...

hmm, that changes the lighting from a directional to a (sort of) point 
light.
In the meantime I've noticed that my last change to the shader using 
gl_ModelViewMatrixInverse was wrong; the tangent space vectors are first 
transformed to eye-space, so the light direction can be left in 
eye-space as well.

 If it's ok for you, can you commit this line, along with the
 modification you did in the other patch?

I've committed the other changes, but left the shader in its original 
form. I feel uneasy changing it without some understanding why that is 
the correct change.

Cheers,
Carsten

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Re: [Opensg-users] OSG::Quaternion to OSG::Line ?

[Carsten Neumann]

Hello,

On 07/26/2014 07:35 PM, Gerlina Steffen wrote:
 For my project I have the following things:
 - A OSG::Quaternion which represents an input device (something similar
 to a Razer hydra)
 - A OSG::Line to calculate intersections
 With the device I want to point onto things (something like a laser
 pointer) in my scene. Unfortunately, to calculate intersections OpenSG
 uses the OSG::Line class, so I need to translate my Quaternion into a
 Line. The position is no problem, but with the calculation from a
 rotation as a Quaternion to a direction as Vec3f I have problems.
 To get my direction vector I use device.getEulerAngleRad(ray_direction).

I don't think that is the function you want, it decomposes the rotation 
represented by the quaternion into euler angles and stores these angles 
(in radians) in the vector.
You probably want something like Quaternion::multVec(src, dst), which 
applies the rotation to the vector src and stores the transformed result 
in dst.

Cheers,
Carsten

--
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