from:"Robert Milharcic"

Re: [osg-users] [build] DAE build failure.. dae.h not found

2016-06-06 Thread Robert Milharcic


Hi Dave,


I apologize for not providing the detail. Let me attempt to. Rather than 
compile the DOM, I downloaded the full set of 3rd party dependencies from this 
page.

http://www.openscenegraph.org/index.php/download-section/dependencies
The specific download I used is this one 
(http://download.osgvisual.org/3rdParty_VS2013_v120_x86_x64_V9_full.7z).

There is a 1.4 and a 1.5 DOM within this set. I extracted the dependcies and 
placed them under my OSG source tree.

You can see their location within my tree here.
https://drive.google.com/open?id=0BzUf-8Ad-iIkQ0Jzd245eHZGTWM

I went through several iterations of trying to get COLLADA configured. This is 
my current latest.
https://drive.google.com/open?id=0BzUf-8Ad-iIkOGVWTDJ6LWNDT1E


I believe COLLADA_INCLUDE_DIR shouldn't point to DOM headers. You should 
probably set it to 
c:/osg/OpenSceneGraph-3.4.0/OpenSceneGraph-3.4.0/3rdParty/x64/include . You 
should also set DEBUG variants of the boost libraries to point to  
libboost_*mt-gd*.lib (mt = multi threaded, gd = debug) and 
COLLADA_PCRECPP_LIBRARY_DEBUG to pcrecppd.lib (pcrecpp(with d suffix).lib) and 
also COLLADA_PCRE_LIBRARY_DEBUG to pcred.lib.

Cheers,
Robert M.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Speed of Shaders

2016-04-04 Thread Robert Milharcic



Hi Daniel,

Based on my recent benchmark I'd say there shouldn't be much difference in 
overall performance between fixed and programmable pipeline, at least not on 
Windows OS. The benchmark uses standard lighting and phong/blinn materials, 
with the lighting done in fragment shader. The shaders are auto generated with 
osg shader composer (no branching at all). With the GPU bound scene I've got:

CAD Model:
Vertices: 990
Faces: 49500
Display lists OFF, vertex buffers ON


AMD Radeon HD 6900 Series

Fixed Function
DrawThreadPerContext: 83.7974 fps, warm up 0.355743 s

With Shader - Per fragment lighting / Phong
DrawThreadPerContext: 83.2916 fps, warm up 0.321948 s


GeForce GTX 970/PCIe/SSE2

Fixed Function
DrawThreadPerContext: 58.0693 fps, warm up 1.57383 s

With Shader - Per fragment lighting / Phong
DrawThreadPerContext: 57.2264 fps, warm up 0.338653 s

Robert Milharcic


Hi there

I have experienced that generally as soon as I use shaders, my DRAW time starts 
to increase significantly, and this even if I just reimplement the fixed 
function pipeline basic functionality.

I wonder if some out there make the same experiences. Either it is my poor 
shader programming (i know about if's and branches that kill performance) or is 
there really a price for the added flexibility?
I'm running a GTX TITAN so usually there is plenty of power...

Cheers,
Daniel




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-15 Thread Robert Milharcic


Hi Robert Osfield et. al.,

On 14.1.2016 16:34, Robert Osfield wrote:

I'm still open to making the shader parsing extensible, it seems like
an interesting experimental tool.


As Sebastian already pointed out, the actual parsing can be done outside osg, 
perhaps before Shader::setShaderSource() call or at some already provided 
callback. In my opinion, it is more interesting to have a spot where all the 
necessary information for the preprocessing step converge, so that at this 
point user can regain some useful control over the shader composition.

I was going through a Shader.cpp to find a spot/function where all the information 
needed for the shader composition is at hand. Unsurprisingly, that function turned 
out to be void PerContextShader::compileShader(osg::State& state);. The 
PerContextShader::compileShader() does all the preprocessing on a shader source, 
like state.convertVertexShaderSourceToOsgBuiltIns(), insertion of the #version, 
inserting line numbers for debug purposes and generates the define string based on 
current define set found in osg::State.

The PerContextShader::compileShader() is a function of an internal class but the 
osg::Shader::compileShader(osg::State& state) (which calls 
PerContextShader::compileShader()) isn't. That being said, minimum work required to 
provide some degree of extensibility is to simply make 
osg::Shader::compileShader(osg::State& state) virtual.

Thoughts?

Cheers,
Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-15 Thread Robert Milharcic


Hi Nick,

On 14.1.2016 15:31, Trajce Nikolov NICK wrote:

Hi Robert M.

I went through this thread fast and I see you are trying (at least your
show case) is lighting and use of shader composition. The approach you are
taking is what I was using too, some years ago. But there are other methods
that does not require any mods and will work just fine with the existing
shader composition features. You can for example encode all the light
attributes into a texture buffer object (think of this as an image where
each float texel is one light attribute like color, etc).


Frankly, I never thought  about multi-light problem this way. I wonder if such 
technique can be generalized enough, e.g. hidden behind the scenes, so the user 
of the lighting framework doesn't have to deal with the texture objects. My 
guess is yes, but of course, I should look into technical merits of the 
implementation first.


Have a look at this, it is Forward+ implementation in opensource project
https://www.youtube.com/watch?v=beSkETJ_vgY

impressive!


We are releasing a new version with F+ lighting available these days, so
you might want to keep an eye on it.


Looking forward.

Cheers,
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-15 Thread Robert Milharcic

Hi Sebastian,

Hi Robert,

Hi Sebastian ,

First of all, the lightning shader only illustrates one of the cases where
(optionally) repeating a code block containing substitution parameter can be
useful. I used the multi-light lightning as an illustration only.

First, thank you for your input. Yes, that is more or less the same approach
I'm currently using. The downside of this approach is that it requires
additional nontrivial code logic for the uniform array management
(u_LightColor) and that is why I started to look at the alternatives.

What could be more complicated there than to setup individual uniforms? Sorry
this doesn't pass as a valid argument. If you have to hold the number of used
lights somewhere you can hold a reference to the uniform as well.

Sorry, but that is not what I had in mind. The problem here is the management of the array
uniform's content and not the reference to it or the light count etc. Let say I only want to
disable one of the lights, say LIGHT0 eg. stateset->setDefines("LIGHT0",
osg::StateAttribute::OFF). What will you do?

Let's say you have a fixed maximum on N, than you create a UBO/Array of this
size and provide a count-uniform for the maximum valid entries.
If a light gets disabled, you simply remove it, copy it to the back and set
your count to N-1.
In the shader you simply loop from 0 to count instead of N. That might break
compiler optimization, but it won't hurt too much I guess.
When using the setDefine, OSG will have to issue a recompile of this new
variant, which will degrade performance if all combinations are needed.

Assume 16 Lightsource, that will produce 65536 possible shader programs ... and
that is only 16, not 500, or 1000 ...
Having 1024 individually switchable Lightsources would totally wreck your idea
of having an alternative to my solution.
2^1024 might exceed the numbers of atoms in the known universe, so there is not
a remote chance to solve this with shader combinations...

The question was purely rhetorical. I just wanted to prove my point regarding the
uniform's content management vs already provided setDefines("LIGHT0",
osg::StateAttribute::OFF). I didn't expect all that. Sorry for the fuzz :) BTW, I'm not
planing to toggle all possible on/off combinations just to see all the permutations, the
normal graph usage is what I'm after.

Normal graph usage might exactly trigger a lot of combinations. My point is not
that theoretical if you take into account that basically everyone could have
used the feature if it was part of the core, thus the example is a practical
one :-)
I didn't want to prove anything here, I simply wanted to point out some
practical problems.

I know and I'm grateful for that. Anyway, based on feedback, I already ditched
the idea and I'm now looking into alternative possibilities, mainly if shader
composition can be extended in a nonintrusive way.

Exactly, that was my intention, to add a higher degree of complexity and hopefully solve
some problems that "turing-complete" language can't.
Turing complete solves all computable problems ;-)
I do understand your motivation, but I still don't see the gain really.
I've presented some alternative ways to solve your problem, as I came across
some of those challenges too.
The idea Robert mentioned might be a good one, basically we could use some kind
of callback to let the user-code preprocess the shader, wait actually we can
already do this, when it is loaded via a LoadCallback :-)
Actually I'm preprocessing my shader code when it's loaded to perform "include" and
automated shader-define setup, so this might work for your "loop" too.

That would defeat the purpose of the #pragma(tic) shader composition. You may
then as well pre-parse #pragma import_defines and #pragma requires and
pre-generate all the shader permutations. The purpose of #pragma(tic) shader
composition is shader generation based on current define set (see the
osg::State).

Yes and? I'm parsing include hierarchies and therefore need to add the defines
found there to the #pragma import_defines. The bulk work done by the osg::State
is to determine if a new program needs to be compiled based on the set of
defines.
My composition is purely to keep the shader code maintainable and reusable. Currently
some of the "Ubershaders" have 20-30 defines, which seriously don't want to
write in the the import_defines by hand.
Again I simply wanted to point out some possibilities to get you your
loop-mechanism.

I see. Thank you for that, too.

Cheers,
Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-14 Thread Robert Milharcic



Hi all,

With the pragmatic shader one could implement multiple lights and other 
repetitive constructs like this:

-- start of shader code --
#pragma import_defines ( LIGHTING, LIGHT0, LIGHT1 )

#ifdef LIGHTING
  #ifdef LIGHT0
uniform vec4 u_LightColor0;
  #endif
  #ifdef LIGHT1
uniform vec4 u_LightColor1;
  #endif

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
  #ifdef LIGHT0
light( u_LightColor0, basecolor);
  #endif
  #ifdef LIGHT1
light( u_LightColor1, basecolor);
  #endif
#endif

gl_Position   = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

... and to enable both lights:

stateset->setDefine("LIGHTING");
stateset->setDefine("LIGHT0");
stateset->setDefine("LIGHT1");

The problem with this approach is that nobody really knows in advance how many 
more lights will be needed. Moreover, the shader can get heavily bloated when 
more and more lights are added. As a solution I would like to propose a new 
#pragma construct:

#pragma repeat_begin( DEFINE_IDENTIFIER${SubstitutionParameter} )
(shader code block)
#pragma repeat_end()

... and the shader code supporting arbitrary number of lights would then look 
like this:

-- start of shader code --
#pragma import_defines ( LIGHTING, LIGHT${Member} )

#ifdef LIGHTING
#pragma repeat_begin( LIGHT${Member} )
uniform vec4 u_LightColor${Member};
#pragma repeat_end()

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
#pragma repeat_begin( LIGHT${Member} )
light( u_LightColor${Member}, basecolor);
#pragma repeat_end()
#endif

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

... where ${Member} is a substitution parameter and LIGHT is define identifier. 
Then with:

stateset->setDefine("LIGHTING");
stateset->setDefine("LIGHT${0}");
stateset->setDefine("LIGHT${1}");
stateset->setDefine("LIGHT${5}");

... where ${0}, ${1}, ${5} are substitution values, osg would produce following 
shader code:

-- start of shader code --
#define LIGHTING
#define LIGHT0
#define LIGHT1
#define LIGHT5

#ifdef LIGHTING
uniform vec4 u_LightColor0;
uniform vec4 u_LightColor1;
uniform vec4 u_LightColor5;

varying vec4 basecolor;

void light( in vec4 lightColor, inout vec4 color );
#endif

void main(void)
{
basecolor = gl_Color;

#ifdef LIGHTING
light( u_LightColor0, basecolor);
light( u_LightColor1, basecolor);
light( u_LightColor5, basecolor);
#endif

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
-- end of shader code --

Before I do any coding I'd like to know if proposed solution would be of any 
use to the osg community? Or maybe there is a better way? I'm currently solving 
these kinds of problems with uniform arrays, but unfortunately, the uniform 
array has its own max number of elements and the management code of such 
approach tend to be complicated...

Cheers,
Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-14 Thread Robert Milharcic


On 14.1.2016 9:52, Sebastian Messerschmidt wrote:

Hi Robert,

This seems more complicated than needed.
Why not pass the number of lights as a compile time constant

#pragma import_defines (NUM_LIGHTS)

shader_state->setDefine("NUM_LIGHTS",12);

and use uniform arrays:

uniform vec4 u_LightColor[NUM_LIGHTS];

for (int i = 0; i < NUM_LIGHTS;++i)
{
light+=calcLight(u_LightColor[i], ...):
}

I feel your approach will bloat the preprocessor code path and will complicate the use. 


Hi Sebastian,

First, thank you for your input. Yes, that is more or less the same approach 
I'm currently using. The downside of this approach is that it requires 
additional nontrivial code logic for the uniform array management 
(u_LightColor) and that is why I started to look at the alternatives. There is 
also an upper limit for the size of the array that needs to be taken into 
account.  Also, the loop represents unnecessary overhead (though, this is not a 
problem on a never hardware). On the other hand, my suggestion fits well into 
existing pragmatic shader composition logic and probably has less downsides.

Cheers,
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-14 Thread Robert Milharcic


Hi Robert Osfield,

On 14.1.2016 10:10, Robert Osfield wrote:

Hi Robert M, et. al,

I understand the motivation the proposal but it does look like it'll
complicate the parsing significantly so am inclined to suggest we look
at the problem at look for easier ways to implement it.


Actually, while I was waiting for a feedback I made a proof of concept 
implementation which turns out to be relatively straightforward task. For the 
parser part I have to add only a few more lines (excluding sanity checks):

void Shader::_computeShaderDefines()
{
...

if (keyword == "import_defines") _parseShaderDefines(str, _shaderDefines);
else if (keyword == "requires") _parseShaderDefines(str, 
_shaderRequirements);
else if (keyword == "repeat_begin")
{
ShaderDefines shaderCodeBlockIdentifers;
_parseShaderDefines(str, shaderCodeBlockIdentifers);

ShaderCodeBlock shaderCodeBlock;

shaderCodeBlock._begin = eol;
shaderCodeBlock._end = std::string::npos;

shaderCodeBlock._identifier = *shaderCodeBlockIdentifers.begin();
_shaderCodeBlocks.push_back(shaderCodeBlock);
}
else if (keyword == "repeat_end")
{
ShaderCodeBlock& shaderCodeBlock = _shaderCodeBlocks.back();
shaderCodeBlock._end = _shaderSource.find_last_not_of(" \t", pos - 8);
}

...
}

In terms of code bloat in shaders, the #pragma(tic) shader composition
ensures that the final code passed the OpenGL will have all the
unimplemented paths removed so performance won't be an issue.  For
developers code bloat in shaders is an potential issue, one thing you
do to help would be to wrap up all the lighting calls into a small set
of functions that are called from the main, these functions are
implemented in separate shaders that handle all the different code
paths so at least the complexity is kept in one place and can be
reused easily.

Agreed.


A second possibility would be to have developers auto generate shaders
so avoid creating bloated shaders directly.

A third approach might be to have the ability to provide a custom
parser to the OSG so that it can handle custom syntax that developers
feel suits their needs better than the default set of features
provided by the core #pragma(tic) shader composition.


Third approach is the approach I like most. I wonder what others have to say 
about this, though...

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-14 Thread Robert Milharcic

Hi Sebastian,

There is also an upper limit for the size of the array that needs to be taken into account.

At least 512. If this is not enough you can use Uniform buffer objects (UBO)[1]
or Shader Storage Blocks[2] which support
If this is not enough for your light-count you will probably hit performance
problems first.

Yes, that is true. The upper limit is not a problem for this specific
multi-light problem.

Also, the loop represents unnecessary overhead (though, this is not a problem on a never hardware).

That's an assumption of yours. Usually constant folded loops with single return
and without break, continue-statements are unrolled by the compiler.
I'll accept performance comparisons however ;)

Yes, you are right about that. The constant loop will most probably be unrolled
by the compiler. Of courses, that is another assumption on top of the previous
assumption :)

On the other hand, my suggestion fits well into existing pragmatic shader
composition logic and probably has less downsides.

Downside is that you're trying to invent a meta-language here out of reasons
that I commented on. The downside of your approach is a preprocessor language
with no clear advantages over the tools already at your disposal.
So to say, the current language is already turing-complete and you're trying to
put some syntactic sugar on top, which adds some high degree of complexity to
the parser and to the shader-code.

Exactly, that was my intention, to add a higher degree of complexity and hopefully solve
some problems that "turing-complete" language can't.

An alternative for you is to manage this part yourself by simply overriding the
parts managing the define-states. Maybe Robert O. can fill in on the details
here.

Cheers
Sebastian

Cheers,
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-14 Thread Robert Milharcic

Hi Sebastian ,

On 14.1.2016 15:47, Sebastian Messerschmidt wrote:

Am 14.01.2016 um 15:01 schrieb Robert Milharcic:

Hi Sebastian,

There is also an upper limit for the size of the array that needs to be taken into account.

Yes, that is true. The upper limit is not a problem for this specific
multi-light problem.

Even so, UBOs support in the order of ten-tousands. If this is still isn't
enough, a texture will provide maximum space.
Might be your example, but the number of individual uniforms is less than that.
And putting a heap of uniforms into the stateset will fasten the handbrake on
the CPU side.

Also, the loop represents unnecessary overhead (though, this is not a problem on a never hardware).

That's an assumption of yours. Usually constant folded loops with single return
and without break, continue-statements are unrolled by the compiler.
I'll accept performance comparisons however ;)

Yes, you are right about that. The constant loop will most probably be unrolled
by the compiler. Of courses, that is another assumption on top of the previous
assumption :)

On the other hand, my suggestion fits well into existing pragmatic shader
composition logic and probably has less downsides.

Exactly, that was my intention, to add a higher degree of complexity and hopefully solve
some problems that "turing-complete" language can't.

Turing complete solves all computable problems ;-)
I do understand your motivation, but I still don't see the gain really.
I've presented some alternative ways to solve your problem, as I came across
some of those challenges too.
The idea Robert mentioned might be a good one, basically we could use some kind
of callback to let the user-code preprocess the shader, wait actually we can
already do this, when it is loaded via a LoadCallback :-)
Actually I'm preprocessing my shader code when it's loaded to perform "include" and
automated shader-define setup, so this might work for your "loop" too.

Tha

Re: [osg-users] Pragmatic shader - a new #pragma directive proposition

2016-01-14 Thread Robert Milharcic


On 14.1.2016 15:20, Robert Osfield wrote:

Hi Robert M. et. al.

I don't have any answers/recommendations at this stage but one first
reading the proposal has relative to traditional C/C++ features seems
a bit out of place.

#pragma(tic) shader composition currently have a very close mapping to
C macro's, my hope has always been that because of this close mapping
it'd be quick to pick up and use - this is one of the key reasons why
I went for this approach to shader composition.

This makes me wonder if C/C++ features itself might be able to inspire
any proposed extensions to #pragma(tic) shader composition.

Robert.

Hi Robert O.

If I'm not mistaken, the #pragmadirective is used by the C/C++ preprocessor for 
providing additional information, beyond what the language itself can offer. I 
thought this was the main inspiration for #pragma(tic) shader composition. 
Anyway, based on feedback I'm now convinced that my proposition isn't that 
useful as I thought :)  and on that note, I rest my case.

Cheers
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Maximizing rendering throughput

2015-10-23 Thread Robert Milharcic


On 23.10.2015 13:46, Robert Osfield wrote:

Hi Robert,

On 23 October 2015 at 12:36, Robert Milharcic <robert.milhar...@ib-caddy.si>
wrote:


First of all, I didn't know that cull and draw traversal can execute in
parallel on a single scene. I always thought that cull and draw can only
execute sequential (serial) in all available threading models. Anyway,
what I know for sure is that update and draw traversal can indeed execute
in parallel within some threading models, and that is the reason why we
need DYNAMIC variance, to tell drawing thread it must process dynamic
elements first, and then immediately allow execution of the update
traversal in a main thread while STATIC elements are still being rendered
in a draw thread. I also suspect that next frame cannot start before all
the static+dynamic elements are rendered. If I'm correct on this one, then
few DYNAMIC elements should not affect frame rate at all, because there is
plenty of time to do the processing while STATIC elements are still being
rendered.


With the DrawThreadPerContext and DrawThreadPerContextCullThreadPerCamera
threading models the static part of the rendering can be done in parallel
with the next frame.  You guess this correct.

The one thing I'd add is that the OSG itself doesn't attempt to sort
DYNAMIC objects so that are drawn first.  You can set up your
StateSet::RenderBinDetails to force the dynamic objects to be drawn first,
but you can only do this for objects that don't affect the rendering of
other objects, or are affected by what is the fame buffer already.

In the case of text it has to be placed in the depth sorted bin which is
drawn after the main opaque bin, so if there are text objects set to
DYNAMIC then you stop the next frame from start till the end of dispatch of
the last depth sorted dynamic object.  This may well be very near the end
of the draw dispatch so you come pretty close to nullifying all the
capacity for running the draw thread in parallel with the next frames'
update and cull traversals.  This is likely the situation for Sebastian.

Using double buffering of Text object's is probably the best way to avoid
updating a Text object while it's being drawn, allowing the Text
DataVariance to remain STATIC.  Such double buffering could be done a
custom Node that has two Text objects, one for current frame being updated,
and one for the previous frame still being rendered.

Robert.


Hi Robert Osfield,

Thank you very much for the more in-depth explanation. I pretty sure that this 
additional info can benefit Sebastian and others as well(including me).

Cheers,
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Maximizing rendering throughput

2015-10-23 Thread Robert Milharcic


On 22.10.2015 18:36, Sebastian Messerschmidt wrote:

Hi,

I have a couple of elements in the scene which data variance is set to DYNAMIC 
to change them thread safe.
This will effectively kill performance as cull and draw are no longer executed 
in parallel. So if I'd set those elements to STATIC, where is the safe place to 
update them?
For instance I have some osg::Text which has to be changed every frame. Is it 
safe to change it in between the update and renderingTraversals?
Also, what about updateOperation? Is considered to modify drawables from there?

Cheers
Sebastian 


Hi Sebastian,

First of all, I didn't know that cull and draw traversal can execute in 
parallel on a single scene. I always thought that cull and draw can only 
execute sequential (serial) in all available threading models. Anyway,  what I 
know for sure is that update and draw traversal can indeed execute in parallel 
within some threading models, and that is the reason why we need DYNAMIC 
variance, to tell drawing thread it must process dynamic elements first, and 
then immediately allow execution of the update traversal in a main thread while 
STATIC elements are still being rendered in a draw thread. I also suspect that 
next frame cannot start before all the static+dynamic elements are rendered. If 
I'm correct on this one, then few DYNAMIC elements should not affect frame rate 
at all, because there is plenty of time to do the processing while STATIC 
elements are still being rendered.

You might also want to have a look at osgBullet project where calculations are 
done in its own thread and then the results are synchronised with a scene graph 
in an update traversal through a triple buffering mechanism.

I also did a benchmark recently that shows what is the effect of different 
threading models on a geometry intensive scene. If someone is interested in 
results let me know...

Best Regards,
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Using a custom StateAttribute

2015-10-19 Thread Robert Milharcic


On 18.10.2015 22:58,
 Jannik Heller wrote:

To me it seems the feature advertised in docs of creating your own 
StateAttributes simply isn't possible, just because of this one function 
returning enum instead of int, which would be an easy fix. Am I missing 
something here?

Probably not. The underlying integral type for the enum Type could be (and 
probably is) int8_t. That implies that possible values for the user type should 
be within range +- 127 or the conversion to Type will be undefined.

Best Regards
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Advice on how to best inject behavoir regarding FBOs

2015-08-10 Thread Robert Milharcic


On 9.8.2015 17:04, BjXXrn Blissing wrote:

Hi Robert,

Well, I was hoping to be able to do the integration without modifications to 
OSG. If such modifications proves to be necessary, then I agree with Jan that 
we should wait for v0.7 to see if that integration is easier. It seems 
unnecessary to change OSG for a problem that may disappear in later Oculus SDK 
versions.

But I am happy to report that I have a working, flicker free solution. Although 
I had to make a rather cumbersome call inside my pre draw camera callback to 
get the FBO handle:


Code:

osg::Camera* camera = renderInfo.getCurrentCamera();
osgViewer::Renderer *camRenderer = 
(dynamic_castosgViewer::Renderer*(camera-getRenderer()));
if (camRenderer != NULL) {
   osgUtil::SceneView* sceneView = camRenderer-getSceneView(0);
   if (sceneView != NULL) {
 osgUtil::RenderStage* renderStage = sceneView-getRenderStage();
 if (renderStage != NULL) {
   osg::FrameBufferObject* fbo = renderStage-getFrameBufferObject();
   GLuint fboHandle = fbo-getHandle(ctx);
 }
   }
}




This also forced me to link with osgUtil. I don't know if there is a simpler 
way of getting the FBO handle, which does not involve osgUtil?

Best regards

Björn



Hi Björn,

If you need low level manipulation of the FBO, it migh be best to simply create 
one that is fully independent/transparent to the osg (as opposed to fully 
automated high-level camera attachment). Having said that, you could simply 
create new FBO, in let's say, CustomCamera constructor:

CustomCamera::CustomCamera()
{
//usual camera setup for rtt
//...

osg::Texture2D* texture =  createTexture();
//attach(osg::Camera::COLOR_BUFFER, texture);

_fbo = new osg::FrameBufferObject;
_fbo-setAttachment(osg::Camera::COLOR_BUFFER, 
osg::FrameBufferAttachment(texture));
setPreDrawCallback(new BindFboPreDrawCallback(_fbo.get()));
setPostDrawCallback(new UnBindFboPostDrawCallback);
}

class BindFboPreDrawCallback : public osg::Camera::DrawCallback
{
public:
BindFboPreDrawCallback(osg::FrameBufferObject* fbo) : _fbo(fbo) {}
virtual void operator () (osg::RenderInfo renderInfo) const
{
_fbo-apply(*renderInfo.getState()); //bind FBO
}
protected:
osg::ref_ptrosg::FrameBufferObject _fbo;
};

class UnBindFboPostDrawCallback : public osg::Camera::DrawCallback
{
public:
virtual void operator () (osg::RenderInfo renderInfo) const
{
renderInfo.getState()-getosg::GLExtensions()-glBindFramebuffer(osg::FrameBufferObject::READ_DRAW_FRAMEBUFFER,
 0);
}
};

You can the manipulate CustomCamera's owned fbo or reattach textures at any 
suitable stage ...

P.S.: You may also need to call _fbo-resizeGLObjectBuffers(maxSize) and 
_fbo-releaseGLObjects(state) when appropriate.

Best Regards,
Robert Milharcic


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk

2015-02-20 Thread Robert Milharcic


Hi Robert,


I have just unpacked the zip file, but am not sure yet what I'm going to be
looking at.  These are mods that provide what functionality, what should I
be expecting the example to do?


The idea here is to load any osg supported node file and then convert all the 
FFP StateAttributes to shaders. For example:

osg::ref_ptrosg::Node node = osgDB::readNodeFiles(arguments);

and then with ...

osgEx::ShaderComposerHelper sch;
 sch.apply(node.get());

... you can convert all FFP attributes found in scene to shaders. Then the 
shader composition must be enabled:

osgViewer::ViewerBase::Windows windows;
viewer.getWindows(windows);
for(osgViewer::ViewerBase::Windows::iterator itr = windows.begin();
itr != windows.end();
++itr)
{
(*itr)-getState()-setShaderCompositionEnabled(true);
(*itr)-getState()-setUseModelViewAndProjectionUniforms(true);
(*itr)-getState()-setUseVertexAttributeAliasing(true);
(*itr)-getState()-setShaderComposer(new osgEx::ShaderComposer);
}

.. and at this point all you have are one or more shader programs and then the 
viewer can be run as usual.

At the time, I wasn't able to find node file that containing all the various 
FFP attributes, so the example is a bit crowded with the code for the test 
scene .

If you are trying to compile the example, then you will first need to checkout 
SVN revision 13962 and then overwrite the files and enable OSG_EXPERIMENTAL 
option in cmake. You can find complete FFP emulation shader in 
examples/osgshadercomposerhelper/ShaderInjections.cpp.glsl, which is the main 
source to feed the shader composer.

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] #pragma(tic) shader composition support now checked into svn/trunk

2015-02-19 Thread Robert Milharcic


Hi Robert,

I was amazed by the simplicity of the new pragmatic shader composition - 
but yet it is so powerful. Well done! So, I was making good progress 
porting old shader composition code to pragmatic one until I hit the 
wall. The problem is, I don't see any obvious way to extend the current 
pragmatic shader composition API. If I may, I would suggest two things 
for consideration:


1. Add a new layer of abstraction for StateSet's define API, lets say 
class object ShaderDefine that we can subclass. The ShaderDefine (or any 
other suitable name) would contain std:string _defineName, std::string 
_defineValue and at least a less operator, since you are inserting 
definition into map, and virtual void apply(State) const {}. Of course, 
the apply would then be called from State::applyDefineList() giving the 
user an opportunity for define's customization. So the new 
StateSet::setDefine() would look something like this: 
setDefine(ShaderDefine*, StateAttribute::OverrideValue);. Also, with the 
proposed abstraction it would be easier to write serialization support.


2. The greatest strength of old shader composer is 
ShaderComposer::getOrCreateProgram(). As others have already mentioned, 
this is the point where we used to gain control over the program 
composition. I'm personally using this control point for things like 
program-addBindAttribLocation/addBindFragDataLocation/addBindUniformBlock 
and for some other sanity checks. It would be great if we can somehow 
install a callback or overload some member to regain the control of the 
program composition.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] shader composition

2015-01-29 Thread Robert Milharcic


On 29.1.2015 0:23, Trajce Nikolov NICK wrote:

I read the shader composition code and the used classes - which are really
without any documentation:-). Can someone give a fast intro into this, the
sample for example?

Thanks a bunch as always


Hi Nick,

I once did some experimental coding on shader composition. The idea was 
to emulte all the FFP attributes with shaders and possibly extend the 
composition with custom shaders. Although the code is working and it 
produces optimal shaders with zero branching or defines, I have never 
had time to polish it up and send it for a review. I could post the 
sample I used for testing, if you are interested. The bad news is that 
it requires some osg core modifications to work properly. I can send 
those, too.


Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Problem replacing shader built-ins (gl_EyePlane)

2014-01-07 Thread Robert Milharcic


On 7.1.2014 22:12, Garrett Cope wrote:

I am using the VDSM implementation and passing in the 4 planes as found in 
assignTexGenSettings(...), but they seem to be different than what is actually 
found in the built-ins during shader execution. I am guessing there is some 
sort of modelview transformation happening, but having trouble with it.

Any ideas on how to recreate these planes for passing into the shader would be 
appreciated.


Hi Garrett,

If I remember correctly all the built-in  gl_EyePlaneX planes are 
pre-multiplied with the inverse model-view matrix. Also, if you need 
projective texture fetch you will need to divide generated texure 
coordinate  st with q component (tex_coord.st/tex_coord.q) or do the 
fetch with a textureXDProj sampler.



Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Model attached to Camera

2013-11-14 Thread Robert Milharcic


On 14.11.2013 11:32, Trajce Nikolov NICK wrote:

It doesn't look right. What is wrong with this code? Also, there is some
delay (when I don't apply the orientation just for debug), the model when
attached is sort of delayed following the camera. Any hints?


Hi Nick,

I'm just guessing here, but if model is delayed, it probably means that 
camera's view matrix wasn't updated yet. If I remember correctly, Viewer 
will update its camera by calling cameraManipulator-updateCamera() 
somewhere in the update traversal too... so, maybe node callback is 
called before updateCamera()? Maybe you could cast camera-getView() to 
osg::Viewer::View and then call getViewerBase(), cast it to proper 
Viewer and call viewer-getCameraManipulator()-updateCamera() ...


Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] compatibity profile

2013-10-07 Thread Robert Milharcic


On 5.10.2013 20:15, Sajjadul Islam wrote:

Code:

#version 400

in vec3 VertexPosition;
in vec3 VertexColor;

out vec3 Color;

void main()
{
 Color = VertexColor;

 gl_Position = vec4(VertexPosition,1.0);
}


Please try it on your end and let me know!!


Hi Sajjadu,

I can't try your code at the moment, but from what I can tell, the 
vertex shader is missing :


uniform mat4 osg_ModelViewProjectionMatrix;

and then in vertex shader main use:

gl_Position = osg_ModelViewProjectionMatrix*vec4(VertexPosition,1.0);

The osg_ModelViewProjectionMatrix, osg_ModelViewMatrix and others are 
automatically set by the osg. Also, don't forget to call:


gc-getState()-setUseModelViewAndProjectionUniforms(true);

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] compatibity profile

2013-10-04 Thread Robert Milharcic


On 4.10.2013 13:17, Sajjadul Islam wrote:

Hi Forum,

I know that this topic is widely discussed here to run shading language 4 with 
OpenGL 3 and onwards using the compatibility profile. I checked the 
osgsimplegl3 and osgvertexattrib array example. Then i try to compile the a 
simple application with a pass through shader only , but i am having the 
following error:


Code:

Got an X11ErrorHandling call display=0x9c41880 event=0xb3fadf2c
GLXBadDrawable
Major opcode: 135
Minor opcode: 11
Error code: 146
Request serial: 9503
Current serial: 9503
   ResourceID: 73400323




I am also attaching the code snippet for your kind review:


Code:


Hi Sajjadul,

1. add some window dimensions to the traits like:

  traits-x = traits-y = 20;
  traits-width = 800;
  traits-height = 600;

2. set viewport to the camera

  camera-setViewport(0,0,traits-width,traits-height);

3. you may also want to enable 
gc-getState()-setUseModelViewAndProjectionUniforms(true);


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform

2013-09-24 Thread Robert Milharcic


On 23.9.2013 23:24, Aurelien Albert wrote:

Thanks for the sharing offer, I'm interested !

I think I've made some progress in the analysis of my problem, could you just test the 
following inside your experimental shader composition project ?

(I would like to know if you have any side effects.)

in osg/State.cpp :
in the method : State::apply(const StateSet* dstate)
comment the following line :

_currentShaderCompositionUniformList.clear();

Hi Aurelien,

I'm using StateSet::AddUniform() but I changed them to 
state::applyShaderCompositionUniform() and commented out 
currentShaderCompositionUniformList.clear() . Everyting works like 
before but I spoted one side effect: the 
currentShaderCompositionUniformList is now growing and composition 
uniforms gets applied to non-related programs that doesn't need them. In 
other words, comenting out clear() will result in redundant calls to 
Uniform::apply().


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform

2013-09-24 Thread Robert Milharcic


On 24.9.2013 8:40, Aurelien Albert wrote:

- Node A : Shader Program + Shader Composition Uniforms
 Child node B : nothing
 Child node C : Shader Program

In this case, Shader Composition Uniforms are properly applied on the Shader 
Program from node A, but not on shader program from node C


Hi,

I think you should simply call standar StateSet::AddUniform() at Node A 
so that every node below can inherit them. I think composition uniforms 
are good only if used in conjunction with osg::ShaderAttribute set to 
StateSet at leaf node.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform

2013-09-24 Thread Robert Milharcic


On 24.9.2013 9:05, Aurelien Albert wrote:

I know this is more like a workaround, but it is really usefull to be able to 
write StateAttributes classes which manage and apply their own uniforms.

To solve my problem described in this post, my guess is I have to replace the _currentShaderCompositionUniformList 
with a stack in which we can push and pop uniforms when StateAttributes are pushed and 
poped.


Hi,

If you do change the list to stack so you can push/pop uniforms you will 
end up redoing standard uniform handling but this time with a parallel 
uniform list. In my opinion the usage scenario with osg::ShaderAttribute 
/ coposition uniforms is: Traverse graph, push and merge StateSets down 
to the Drawable where osg::ShaderAttribute(s) / coposition uniforms are 
to be set. It was my first attempt to do it like this but I later 
changed my aproach and rolled out my own custom shader attribute. I call 
it ShaderComponentAttribute, where I store a map of uniforms that were 
applied at parent (owning) StatSet. When ShaderComponentAttribute is 
removed, it also removes its managed uniforms.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform

2013-09-24 Thread Robert Milharcic


On 24.9.2013 14:40, Aurelien Albert wrote:

Yes, and I think this is what I need :

- a standard uniform list, which contains uniforms setted from regular 
osg::Uniform instances
- a comes-from-stateAttribute uniform list, in the same way there is associated 
modes with some StateAttributes

In my opinion, theses uniforms are not really linked to the ShaderComposition system, but 
complementary : sometimes you just want to push some 
StateAttribute-associated uniforms in the state.


Hi,

I think I now understand what you are trying to do, but I don't 
understand to what purpose? What would be the benefit of having 
StateAttribute associated uniforms pushed into state?


Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform

2013-09-23 Thread Robert Milharcic


On 23.9.2013 12:51, Aurelien Albert wrote:

I've spotted the problem source : in void State::apply(const StateSet* dstate), 
there is this line :

 _currentShaderCompositionUniformList.clear();

So all shader composition uniforms are cleared at each StateSet apply. I've 
tried to comment this line and everything seems to work.

Since I don't really understand the shader cmoposition uniforms system, can you 
give me some advices on this issue ?


Hi Aurelien,

I'm almost done with my experimental shader composition project. So 
far I was able to port 3/4 of FFP attributes to the shader compositor. 
I've designed ShaderComposerVisitor that will populate graph with shader 
attributes, either by replacing existing FFP attributes (for core 
profile and ES 2.0) or add them to coexist with existing FFP attributes 
to provide fallback for old hardware.


I wasn't able to pull it through with osg::ShaderAttribute or with 
composition uniforms (having current state-set's local scope), instead I 
had to roll my own ShaderComponentAttribute based on 
osg::ShaderAttribute that is able to manage standard uniforms and 
ShaderComponent and apply standard osg matrices if requested.  I've also 
made a few nonintrusive changes to the osg core to support RenderStage 
scope uniforms to be able to handle position state attributes properly.


If there is some interest I could send all the stuff to the submissions 
at the end of this week to at least hang in there until somone else find 
a better solution.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Shader composer and position state

2013-09-05 Thread Robert Milharcic


On 4.9.2013 15:39, Robert Osfield wrote:

Hi Robert,

When implementing the osg::ShaderComposer functionality I had in mind that
ability to have a custom StateAttribute/ShaderAttribute::apply() compute
the view dependent uniform state and apply this to the osg::State.  The
apply() method would get the modelview matrix from the osg::State and apply
this to the local uniform before passing it on to osg::State.


Might this work for you?


No, I don't think so. I'm basically trying to implement a special 
uniform or maybe custom shader attribute, having a global scope, but to 
be set localy at the node or stateset. Special uniform would then be 
multiplied with a local modelview matrix and applied to all programs.  
This is analogus to position state handling already implemented for FFP 
(LightSource/Light for example).


Best Regards
Robert Milharcic


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Shader composer and position state

2013-09-04 Thread Robert Milharcic


Hi all,

My goal is to replace shader generator with shader composer, so I spent 
a few days playing with it. It proved to be very flexible and powerful 
tool but unfortunately, it lacks the support for a key feature I would 
consider necessary, and that is support for the position state. 
Putting it differently, shader composer is blind for position state 
attributes (Light, ClipPlane, TexGen) stored within LightSource, 
ClipNode and TexGenNode. I was able to workaround the problem with cull 
calbacks or with custom cull visitor where I'm able to identify 
positioned uniform multiply it with model-view matrix and then force 
shader composer to accept the uniform and ShaderComponent attached to 
the state attribure. Unfortnatelly, this workaround introduced some 
unnecessary code complications and problems with uniform management and 
that is why I strongly feel that the solution should be integrated into 
OSG core.


I believe the implementation of such a feature should be straightforward 
task and since I might be able to post the core solution @submissions 
for a review, I am asking you for advice on how user interface should 
look. I have two ideas for now:


1. easy to implement solution dedicated to LightSource, ClipNode and 
TexGenNode. In addition to LightSource::setLight we could introduce two 
new methods: LightSource::addPositionedUniform(name, VecX) that will be 
collected into PositionalStateContainer and get special treatment with 
model-view matrix before applied at RenderStage and 
LightSource::addUniform(osg::Uniform*) to set other non-poisitioned 
uniforms that won't be multiplied but applied in a same way before any 
other attribure.
2. general soution by introducing two new types of uniforms: 
osg::PositionedUniform and global? scene? uniform, Both can be set at 
any StateSet and will be applied at RenderStage before any other attribure.
3. both solutions: First dedicated and after that general solution which 
will replace internal logic of LightSource and others leaving the 
interface as is.

4. ?

Best Regards
Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Changing material of geodes/drawables during rendering - crash

2013-08-29 Thread Robert Milharcic


On 29.8.2013 10:30, Peter Bako wrote:

Hello guys.

What is the correct way to change materials during rendering? What callbacks 
should I use, update callback?
Sometimes I get a crash and I assume it is becasue of changing the material.

Should I use special updateCallback on every geode/geometry I am changing, or 
it is enough to use the callback on a parent and change the state attributes 
also on children?

Should the data variance be DYNAMIC on these nodes?

Hi Peter,

If I'm not mistanken, DYNAMIC variance has to be set only at the Node(s) 
associated with the state set (containing material state attribute)  you 
want to modify. Then you can change material before or after frame, in 
update or event traversal, or you can attach update operation to the 
viewer/view with addUpdateOperation/removeUpdateOperation .


Changing variance to DYNAMIC will introduce some performance penalty. If 
this is unacceptable you can always use clone state set trick. You 
simply clone state set, change it, and then assign new stateset and 
update its parents. Old state set will be deleted by ref_ptr when no 
longer needed. This will prevent disruption of the rendering traversals. 
See how it is done in StateSetManipulator::clone() in osgGA module.


If I'm wrong please someone correct me :)

Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Changing material of geodes/drawables during rendering - crash

2013-08-29 Thread Robert Milharcic


On 29.8.2013 15:07, Glenn Waldron wrote:

For rendering, data variance only applies to Drawables and StateSets, not
to Nodes. Data variance on Nodes is only honored by the osgUtil::Optimizer.
So if you want to change your materials at runtime in multi-threaded mode,
set the StateSet d.v. to DYNAMIC.
Yes of course, my bad. Although data variance can be set on any 
osg::Object, it is only feasible to set it on drawables and state sets. 
Anyway, DYNAMIC variance will force the frame to wait till the dynamic 
draw is complete.


Thanks for the correction Glenn.

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] regular osg-models result in notifications with osg built for opengl-3.x / opengl-es-2.0 support

2013-08-27 Thread Robert Milharcic


On 26.8.2013 22:32, deniz diktas wrote:

Is there a method or utility (maybe some visitor) inside osg that can modify 
the models so that the rendered model is consistent with opengl-3.x and 
opengl-es2.0 features, and that these notifications are disabled?

Hi Deniz,

The short answer is: To my best knowledge, and i might be wrong, osg 
doesn't provide utility or visitor that can remove fixed pipeline state 
attributes from the graph or visitor that is able to output core opengl 
or ES2.0  compatible shaders to be used as a replacement for the fixed 
pipeline state attributes.


Anyway, you might want to have a look at the osgshadergen example to see 
how to do it with osgUtils:ShaderGenVisitor but I believe it won't 
produce opengl 3 core or ES 2 compatible shaders. You can of course 
modify ShaderGenVisitor source...


Also, there is osg::ShaderComposer you might want to have a look at, 
designed to solve problems like one you are describing.  The idea here 
is to attach shader componet to any? fixed pipeline state attribute 
and then let osg automatically compose final shader program for you. The 
bad news here is that shader composer isn't finished yet, I believe. Of 
course, you can have a look at the osgshadercomposition example ...


Robert Milharcic

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] shader composing related link

2013-08-05 Thread Robert Milharcic


On 5.8.2013 15:23, Sergey Kurdakov wrote:

en sourced so maybe it might be of some interest to look at.

Best regards
Sergey
Very Interesting indeed.  One more thing is needed though, the osg 
implementation of the nvFX interfaces (currently implemented for GL, 
D3D, CUDA and OPTIX) . On the other hand, Wang Rui's effect compositor 
looks cleaner, more osg-ish and maybe easier to extend... In any case, a 
decent effect framework is needed now more then ever.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt5 integration first try

2013-06-12 Thread Robert Milharcic



Hi Martin,


in reference to my submission here:
http://forum.openscenegraph.org/viewtopic.php?p=54555#54555

as I said, I simply submitted Vitezslavs patch. I can certainly try to remove 
the extra hooks from the osg main classes.
The moveToThread command must be called with the Qt widget and the Qt graphics 
thread before makeCurrent is called the first time.
Maybe there is a way to achieve multithreaded rendering in a 
non-intrusive way by simply calling both new members (moveToThread and 
moveBack) from GraphicsWindowQt itself. We could overload 
GraphicsContext::setGraphicsThread and 
GraphicsContext::releaseContextImplementation with something like this:


void GraphicsWindowQt::setGraphicsThread(osg::GraphicsThread* gt)
{
if (gt)
{
moveToThread(gt);
}

osgViewer::GraphicsWindow::setGraphicsThread(gt);
}

bool GraphicsWindowQt::releaseContextImplementation()
{
existing stuff here ...

// move context back to main thread
if (_widget-context()-thread() != qApp-thread())
{
moveBack();
}

return result;
}

Of course, setGraphicsThread should be made virtual if not already.


Another thing I just realized: The code will only work when CMake option 
BUILD_OPENTHREADS_WITH_QT  is set! Otherwise the static_cast in 
GraphicsWindowQt::moveToThread will fail.
How can I solve this? For multithreading to work with Qt5 it seems we need the 
render threads to be QThreads. Maybe add a flag to OpenThreads/Config and 
#ifdef against that?

Flag is ok ... or maybe we could add new api to OT, an api that can 
return string like qt, win32, pthreads, sproc, c++11... , 
benign but useful ...


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MousepressEvent not able to capture from osg::Viewer by Qt

2013-05-08 Thread Robert Milharcic


On 8.5.2013 7:04, Sujan Dasmahapatra wrote:
I am trying to implement a mouse press event with QT and OSG but 
unable to do it. Pls help.


Below is my ViewerWidget class which is derived from QWidget and 
osg::CompositeViewer..In the constructor I got gView which is a 
osg::GLWidget, I am trying override mousePressEvent but when I click 
message not coming. What I am doing wrong pls help..


[snip]

osg::Camera* ViewerWidget::createCamera( int x, int y, int w, int h, 
const std::string name, bool windowDecoration )

{
osg::DisplaySettings* ds = osg::DisplaySettings::instance().get();
osg::ref_ptrosg::GraphicsContext::Traits traits = new 
osg::GraphicsContext::Traits;

traits-windowName = name;
traits-windowDecoration = windowDecoration;
traits-x = x;
traits-y = y;
traits-width = w;
traits-height = h;
traits-doubleBuffer = true;
traits-alpha = ds-getMinimumNumAlphaBits();
traits-stencil = ds-getMinimumNumStencilBits();
traits-sampleBuffers = ds-getMultiSamples();
traits-samples = ds-getNumMultiSamples();
osg::ref_ptrosg::Camera camera = new osg::Camera;
camera-setGraphicsContext( new 
osgQt::GraphicsWindowQt(traits.get()) );

camera-setClearColor( osg::Vec4(0.2, 0.2, 0.6, 1.0) );
camera-setViewport( new osg::Viewport(0, 0, traits-width, 
traits-height) );

camera-setProjectionMatrixAsPerspective(
30.0f, 
static_castdouble(traits-width)/static_castdouble(traits-height), 1.0f, 
1.0f );

return camera.release();
 }

I don't know why this code didn't crash, I think it should. Anyway, you 
should create an instance of the CSGraphicsView somewhere within 
createCamera:


CSGraphicsView* gView = new CSGraphicsView;
gView-setGeometry(x, y, w, h);
traits-inheritedWindowData = new osgQt::GraphicsWindowQt::WindowData( 
gView );


...
or you can pass an instance of the CSGraphicsView to the 
osgQt::GraphicsWindowQt constructor.



Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MousepressEvent not able to capture from osg::Viewer by Qt

2013-05-08 Thread Robert Milharcic


On 8.5.2013 10:16, Sujan Dasmahapatra wrote:

Thanks Robert. It is working fine...

On the left mouse press I am showing a message using QMessagBox. But 
on the middle mouse press was having pan and right mouse press was 
having zoom in zoom out. How can I retain those functionalities. With 
this these functionalities are gone.


void CSGraphicsView::mousePressEvent(QMouseEvent *e)
{
if(e-button()==Qt::LeftButton)
{
QMessageBox msg;
msg.setText(Mouse pressed);
msg.exec();
}
}

Call base class implementation in a case where you need to retain 
original functionality:


void CSGraphicsView::mousePressEvent(QMouseEvent *e)
{
if(e-button()==Qt::LeftButton)
{
QMessageBox msg;
msg.setText(Mouse pressed);
msg.exec();
}
else
GLWidget::mousePressEvent(e);
}

Also, calling frame on paintEvent might not be enough. You should also 
call frame on every user input, on all mouse and keyboard events for 
example... or you can mount a QTimer and make it call frame at some 
interval.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] GLWidget resizeEvent

2013-03-07 Thread Robert Milharcic


On 6.3.2013 9:36, Gianni Ambrosio wrote:

Hi Robert,
then there is something missing somewhere or a mistake from my side.

I derived from osgQT::GLWidget to have a QGLWidget to insert in my GUI.

The usual way to get to the osgQT::GLWidget is something like this:

osg::ref_ptrosgQt::GraphicsWindowQt gwQt = new 
osgQt::GraphicsWindowQt( traits.get() );

camera-setGraphicsContext( gwQt.get() );

osgQt::GLWidget* glWidget = gwQt-getGLWidget();
// insert glWidget into GUI here

If you must derive from osgQT::GLWidget then you will need to pass your 
custom GL widget to the GraphicsWindowQt constructor through 
GraphicsContext::Traits::inheritedWindowData or call GraphicsWindowQt 
constructor with your custom widget:


traits-inheritedWindowData = new osgQT::GraphicsWindowQt::WindowData( 
myCustomGLWidget );
osg::ref_ptrosgQt::GraphicsWindowQt gwQt = new 
osgQt::GraphicsWindowQt( traits.get() );
// osg::ref_ptrosgQt::GraphicsWindowQt gwQt = new 
osgQt::GraphicsWindowQt( myCustomGLWidget );

camera-setGraphicsContext( gwQt.get() );
// insert myCustomGLWidget into GUI here

I would first check if GLWidget/GraphicsWindow/Camera setup is done 
correctly.



When the application starts I basically add an osgWidget::Widget (or even a 
osgWidget::Label) to an osgWidget::WindowManager. The problem is that all 
widgets have a small size even if the resizeEvent implementation of 
osgQt::GLWidget is executed. Only when I resize the Qt window containing the 
osgQt::GLWidget and the resizeEvent in executed again, the widgets are 
correctly resized.
On the other side if I resize the Qt window before adding widgets to the 
osgWidget::WindowManager then, in this case, widgets are correctly shown immediately.

I'm sorry but at the moment I don't have a simple example.


If the GraphicsWindowQt *did pick the resize event* maybe all you need 
is to call viewer-frame() for the events to be processed by the osg. 
Also try with viewer-setRunFrameScheme(ON_DEMAND). This will prevent 
osg to discard accumulated events picked outside the predefined time frame.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] PolytopeIntersector distance and Transform

2013-03-07 Thread Robert Milharcic


On 4.3.2013 11:05, Andreas Roth wrote:

hanks to Aurelien for the work-around.

Hi Andreas,

That is of course my personal opinion, but i think PolytopeIntersector 
is overkill for most, if not all usage scenarios plus it doesn't work 
correctly on a scaled geometry. I simply took LineSegmentIntersector 
renamed it to IntersectorPrivate, added some sensitive area along 
picking vector, added suport for lines, points etc...  As I remember 
it,  it was pretty straight foward task... I'm not saying my solution is 
perfect nor thoroughly tested but it works well for our needs. Of course 
if someone would like to see what I did I can paste code here...


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] GLWidget resizeEvent

2013-03-05 Thread Robert Milharcic


On 5.3.2013 16:12, Gianni Ambrosio wrote:

Hi All,
I'm experiencing an issue that seems related to the size of a osgQt::GLWidget. 
Since my case it is pretty hard to explain, first of all I would like to know 
if it is correct to completely override the 
QGLWidget::resizeEvent(QResizeEvent*) implementation. In fact, in a previous 
implementation of an AdapterWidget (derived from QGLWidget and embedding a 
osgViewer::GraphicsWindow) resizeGL(w, h) was reimplemented instead of 
resizeEvent(). Both methods are virtual of QGLWidget but resizeGL() is called 
by QGLWidget::resizeEvent(). The latest also does something more:


Code:
void QGLWidget::resizeEvent(QResizeEvent *)
{
 Q_D(QGLWidget);
 if (!isValid())
 return;
 makeCurrent();
 if (!d-glcx-initialized())
 glInit();
 resizeGL(width(), height());
 if (d-olcx) {
 makeOverlayCurrent();
 resizeOverlayGL(width(), height());
 }
}



That means osgQt::resizeEvent() implementation overrides the original code of 
QGLWidget. Is that really not necessary and can be correctly skipped?



I'm just guessing here but i think the QGLWidget's resizeEvent was 
intentionally suppressed by the author to prevent the execution of the 
makeCurrent() call. It is probably done so to  avoid crashes when 
running osg in multi-threaded threading model.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] qtOsg EventHandler issue

2011-09-27 Thread Robert Milharcic


 1 - The program starts with no scenario windows
 2 - I can add or remove Windows with a new/open file operation.
 3 - for the first window to be opened everything works perfect regarding
 events ( mouse click, mouse press, drag, etc ).
 4 - For all the others i have to wait a time till the event handler starts to
 work. Sometimes, It takes more than 5 seconds.
 
 Do i have to force some call to make the current window active together
 with its current viewer's event handler ?
 
 When using osg 2.9.15 i had no trouble with this.
 
 Now I'm using osg 3.0.1
 

Try with ON_DEMAND frame scheme:

setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND);

Why? In the viewer event traversal there is a line:

double cutOffTime = (_runFrameScheme==ON_DEMAND) ? DBL_MAX : 
_frameStamp-getReferenceTime();

Your app is waiting because osg cannot pull all queued events within a period 
of cutOffTime. Sometimes many frames are needed to process all accumulated 
events to get to your mouse/keyboard events. You can also leave default frame 
scheme as is and clear osg event queue yourself.

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG Collada plugin

2011-09-09 Thread Robert Milharcic


As Jean-Sebastien  already said, If the dae plugin is linked against, for 
example, msvcr90d.dll, then it is generally good idea to link all its dependant 
dlls to the same runtime (msvcr90d.dll). That usually means you will have to 
recompile collada and all its external libs from source. Of course, it is 
posible that the problem is elsewhere...

Robert Milharcic

 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-
 boun...@lists.openscenegraph.org] On Behalf Of Héctor Martínez
 Sent: Friday, September 09, 2011 12:15 PM
 To: 'OpenSceneGraph Users'
 Subject: Re: [osg-users] OSG Collada plugin
 
 Hi,
 
 I am still having the same problem. Does somebody have any idea of what is
 happening?
 
 Thank you.
 
 Héctor
 
 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Héctor
 Martínez
 Sent: miércoles, 24 de agosto de 2011 9:29
 To: 'OpenSceneGraph Users'
 Subject: Re: [osg-users] OSG Collada plugin
 
 Hi Jean-Sebastien,
 
 thank you for your response. It is possible that I am missing something, but
 it seems that every library is in debug mode. I have checked with
 Dependency Walker the libs and I have all the debug dependencies in the
 folder. I have exported one single cube with Blender, just to check that
 there are no problems with textures and the same problem is happening.
 
 If I try to run the application from command line instead of from Visual
 Studio, this is the error that I find:
 
   HEAP CORRUPTION DETECTED: after Normal block (#37612) at
 0x0047CF58.
   CRT detected that the application wrote to memory after end of
 heap buffer.
 
 And I have seen that the messages in the command line goes a bit further
 than in VS:
   ReaderWriterDAE( OSG/box.dae )
   URI loaded: OSG/box.dae
   Adding parent0039C498
   Adding parent0039C498
 
 Maybe those lines can be helpful to see where the problem is...
 
 Héctor
 
 
 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-
 Sébastien Guay
 Sent: martes, 23 de agosto de 2011 15:35
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] OSG Collada plugin
 
 Hi Héctor,
 
  I am having some problems to load collada files into my project. I
  have used the collada dom lib (libcollada14dom21) to build the plugin.
 
  The line that is throwing the breakpoint is:
 
  osg::ref_ptrosg::Node model = osgDB::readNodeFile(modelFilePath);
 
 This line will be loading the collada plugin, as well as the collada DOM DLLs
 and others the plugin depends on. So if that line is making your app crash, I
 would suspect the common gotcha about linking debug and release
 together (or in general, different runtimes).
 
 So check your compile settings and make sure all your libs and DLLs (even
 the collada ones and its dependencies) are differentiated between debug
 and release, and that they all match in the linker settings.
 
 Hope this helps,
 
 J-S
 --
 __
 Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
 http://www.cm-labs.com/
  http://whitestar02.dyndns-web.com/
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

2011-09-08 Thread Robert Milharcic

 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-
 boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi
 Sent: Wednesday, September 07, 2011 2:44 PM
 To: osg-users@lists.openscenegraph.org
 Subject: Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

 openvrml-dl project was built correctly.
 I added a dependency to openvrml-dld.lib to openvrml project too. Now the
 osgviewerd.exe can fing the wrl plugin, but it gives me this error in
 http://imageshack.us/photo/my-images/685/errorosg.jpg/

This error indicates that you didn't build vrml97.dll node or the node cannot 
be found. The search paths can be put into registry under 
HKEY_LOCAL_MACHINE\SOFTWARE\OpenVRML\OpenVRML:

NodePath ... the path to .dll nodes
Datadir ... data dir must contain component subdirectory with  component xml 
files
ScriptPath ... can be empty

I also had to comment out following lines in ReaderWriterVRML2.cpp:

/*std::string unixFileName = osgDB::convertFileNameToUnixStyle(fileName);

#ifdef WIN32
if(unixFileName[1] == ':') // absolute path
fileName = file:/// + unixFileName;
#else
if (unixFileName[0] == '/') // absolute path
fileName = file:// + unixFileName;
#endif
else
// relative path
fileName = unixFileName;*/

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

2011-09-08 Thread Robert Milharcic

 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-
 boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi
 Sent: Thursday, September 08, 2011 10:38 AM
 To: osg-users@lists.openscenegraph.org
 Subject: Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

 I don't have this code in ReaderWriterVRML2.cpp!
 Do you confirm me that osg VRML plugin doesn't play a vrml like an
 animation, but it only navigate through nodes searching for properties?

Sorry, I opened snoman.wrl found under sample models in source distribution and 
*it does not animate* only static gemoetry is shown . I also tried orbit3.wrl, 
still no animation. BTW, if you use x64 os jo have to put keys  under 
Wow6432Node   (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\OpenVRML\OpenVRML).

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

2011-09-08 Thread Robert Milharcic

 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-
 boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi
 Sent: Thursday, September 08, 2011 11:55 AM
 To: osg-users@lists.openscenegraph.org
 Subject: Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

 rmilh wrote:

  Sorry, I opened snoman.wrl found under sample models in source
 distribution and *it does not animate* only static gemoetry is shown . I also
 tried orbit3.wrl, still no animation.

 So, you can really see the snowman, but there is no animation?

That is correct. I executed the comman line osganimationviewer.exe -e vrml 
snoman.wrl and I can see snowman but play button does nothing.  I also  tried 
collada plugin (dae) (osganimationviewer.exe Seymour_anim2.dae) and the 
animation worked. If you are looking for plugin that can handle animation then 
I suggest you try collada plugin.

Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

2011-09-07 Thread Robert Milharcic

I don't have VS2010. My libs and dlls are build with VS2008. What does the 
compiler say when yout try to build  openvrml-dl project? Maybe the main 
project openvrml is missing a dependency to the openvrml-dl.lib. 

 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-
 boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi
 Sent: Wednesday, September 07, 2011 1:13 PM
 To: osg-users@lists.openscenegraph.org
 Subject: Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

 I think there is also another problem: probably the openvrmld.lib that I
 compiled has an error.
 Is it possible to have the openvrml.lib, openvrmld.lib and .dll ?

 Thank you!

 Cheers,
 Paolo

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=42485#42485

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG + QT and QTabWidget: Disappearing scene graph

2011-09-06 Thread Robert Milharcic

();
return app.exec();
}

Robert Milharcic

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Joseph Louis
Sent: Tuesday, September 06, 2011 1:10 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] OSG + QT and QTabWidget: Disappearing scene graph

Hi Angus,

I am trying to do the same with my program but the scene does not even appear 
in any of the tbs. I am also using the osgviewerQT example. Were you able to 
get your's to work?

Thank you!

Cheers,
Joseph

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42433#42433





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] VRML plugin: help in compiling

2011-09-05 Thread Robert Milharcic

1. use any open vrml library 0.18.x
2. set environment variable BOOST_ROOT to point to the root of the boost. 
(needed for cmake to set boost entries automatically)
3. you will have to replace  the outdated content of 
OpenSceneGraph\src\osgPlugins\vrml\CMakeLists.txt with this:

FIND_PACKAGE(Boost 1.40.0 COMPONENTS thread)

IF(NOT Boost_FOUND)
RETURN()
ENDIF()

INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})

INCLUDE_DIRECTORIES(${OPENVRML_INCLUDE_DIR})
INCLUDE_DIRECTORIES(${OPENVRML_INCLUDE_DIR}/openvrml)

IF (WIN32)

INCLUDE_DIRECTORIES(${JPEG_INCLUDE_DIR})
INCLUDE_DIRECTORIES(${PNG_INCLUDE_DIR})
INCLUDE_DIRECTORIES(${ZLIB_INCLUDE_DIR})

SET(TARGET_LIBRARIES_VARS
OPENVRML_LIBRARY
JPEG_LIBRARY
PNG_LIBRARY
ZLIB_LIBRARY)
SET(TARGET_EXTERNAL_LIBRARIES
Ws2_32.lib)
ELSE()
SET(TARGET_LIBRARIES_VARS
OPENVRML_LIBRARY)
ENDIF()

ADD_DEFINITIONS(-D OPENVRML_USE_DLL)


SET(TARGET_SRC 
IndexedFaceSet.cpp
Primitives.cpp
ReaderWriterVRML2.cpp 
ConvertToVRML.cpp
)

SET(TARGET_H
ReaderWriterVRML2.h
ConvertToVRML.h
)

 end var setup  ###
SETUP_PLUGIN(vrml vrml)

4. rerun cmake and set vrml and/or boost related  entries

Robert Milharcic

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paolo Piazzi
Sent: Friday, September 02, 2011 3:07 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] [osgPlugins] VRML plugin: help in compiling

Hi,

I followed the instructions for VRML plugin, but I wasn't able to compile it 
with openVRML 0.14. Then I downloaded openVRML 0.18  Boost 1.46, but I wasn't 
able to compile openVRML in order to use the .lib in the VRML plugin in OSG.
The error are like this:
Error  536 error LNK2019: riferimento al simbolo esterno void * __cdecl 
openvrml::local::dl::sym(struct HINSTANCE__ *,class 
std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar 
 const ) 
(?sym@dl@local@openvrml@@YAPAXPAUHINSTANCE__@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
 non risolto nella funzione _openvrml_open_node_module   
...\Projects\openvrml-0.18.8\src\libopenvrml\node_metatype_registry_impl.obj
openvrml

There are 14 errors like that. In the recent past, I tried to compile openVRML 
also in Linux Ubuntu, but I coudn't do it.

Thank you!

Cheers,
Paolo

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42382#42382





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] (Qt) single GraphicsWindowQt completely filling parent widget

2011-09-02 Thread Robert Milharcic

When the child widget completely fills a parent widget the QPaintEvent  is no 
longer send to the parent. If you have something like this:

connect( timer, SIGNAL(timeout()),myParent, SLOT(update()) );

 virtual void MyParent::paintEvent(QPaintEvent* event)
 {
osgViewer-frame();
 }

... the frame will never be called.

Robbert Milharcic

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of jamie robertson
Sent: Wednesday, August 31, 2011 12:00 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] (Qt) single GraphicsWindowQt completely filling parent 
widget

Hi,

For some reason I'm struggling to get a GraphicsWindowQt (GraphicsWindowQt 
::getGLWidget) to completely fill a parent widget. I've tried various ways and 
always seem to fail (the GraphicsWindowQt isnt displayed) unless there is a non 
zero margin on a layout, in which case it works as expected.

It's the same for setting the mainwidget of a qmainwindow, it doesnt appear 
unless I set a non zero margin.

I can simply reproduce the problem in the osgviewerqt example with the 
following modification:


Code:
QGridLayout* grid = new QGridLayout;
grid-setSpacing(0);
grid-setMargin(0);



Setting either the margin or spacing to something other than zero displays the 
viewers ok.

Anyone encountered this before?

Im using osg 3.0.1, windows7.

Thanks,

Jamie Robertson[/code]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42314#42314





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] draw callbacks

2010-09-02 Thread Robert Milharcic


You can use osgFX node kit framework to implement described capping tehnique. 
You do that by inheriting osgFX::Effect class. In your derived class you have 
to override/implement  virtual bool define_techniques() member of the 
osgFX::Effect class  like this:

 bool CappingEffect::define_techniques()
{
CappingTechnique* technique = new CappingTechnique(this);
addTechnique(technique);
return true;
}

CappingTechnique must inherit from osgFX::Technique. In the derived class you 
will have to  implement virtual bool validate(osg::State) const, virtual void 
define_passes() and optionally virtual osg::Node* getOverrideChild(int pass) 
like this:

bool CappingTechnique::validate(osg::State) const
{
return true;
}

bool CappingTechnique:: define_passes()
{
// pass #1
{
osg::ref_ptrosg::StateSet ss = new osg::StateSet;
   ... setup states for  stencil operation
addPass(ss.get());
}
// implement pass #2
{
osg::ref_ptrosg::StateSet ss = new osg::StateSet;
   ... setup states for solid color draw
addPass(ss.get());
}
}

You can optionally implement getOverrideChild (int pass) to supply some other 
graph for a particlular pass. You then add your group to the CappingEffect (the 
osgFX::Effect inherits from osg::Group node) and CappingEffect  to the camera.

Robert Milharcic

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Javier Taibo
Sent: Thursday, September 02, 2010 1:09 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] draw callbacks

  Hi,

  I have some solid geometry clipped by some clipping planes in an OSG 
application. I am trying to use the capping technique described in chapter 10 
of the Red Book using the stencil buffer. I have successfully implemented this 
technique in raw OpenGL, but I would like to use it whithin the OSG 
application. The technique is based on storing on the stencil buffer the 
regions that are open and then in a later pass draw a solid color in these 
regions.

  I have put the clipped geometry under an osg::Camera node with the stencil 
function configured. To do the second pass (the one that draws the caps in the 
regions marked in the stencil), I am trying to use a post-draw callback with 
the OpenGL calls (saving and restoring the states to avoid breaking things). 
The problem is that I need to set the NESTED rendering order to see all the 
scene graph, and when I do it, the post-draw callback is not called anymore.

  I do not have full control over the application, so the solution I am looking 
for has to be transparent to the rest of the scene graph. I must activate 
this behaviour to a group in the scene graph without breaking anything outside 
this branch.  What is the best way to do it? camera post-draw callbacks? 
rendering bins? any other?

  I am not very familiar with render passes in OSG, so the way I am trying is 
probably not the best way. I would appreciate any suggestion, advice or pointer 
to any related documentation or source code.


  Thanks in advance.


  Javier Taibo.
attachment: Robert Milharcic.vcf___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

49 matches

Mail list logo