Re: [osg-users] Setting the transform matrices

[Chris Kuliukas]

Thanks for the informative reply, much appreciated.


robertosfield wrote:
> I have run with the various command 1-8 options and get different behaviour 
> but looking at the code I really don't know what is expected. The black cow 
> is likely occurring because no shader is being provided that handles texgen 
> that the cow.osg uses from the fixed function pipeline.  

Based on your earlier response here ..

robertosfield wrote:
> you don't need to add ANY more complexity than just replacing gl_ModelView* 
> with osg_ModelView*, the OSG will even automatically remap for you. 
> 
> 
> The OSG automatically accumulates all view and projection matrices for you, 
> sets the when required, it does a shed load of work for you to make you life 
> easy.  All the osg::Camera and osg::Transform subclasses all work in coherent 
> and robust fashion, whether you are using fixed function pipeline of shaders 
> and they function in the same way in both. 

.. I would have thought the expected behavior is that using vertex attrib 
aliasing and use model/view/projection uniforms would work because osg remaps 
etc and replaces fixed transforms and deprecated gl_ uniforms with osg_ 
uniforms.

I realize the difficulty / impossibility of automatically taking people from 
fixed function / legacy shaders to modern GL. But that's what prompted this 
thread; that it seems difficult to hook into the power of OSG in a modern GL 
context.



robertosfield wrote:
> In OSG-3.4.x there isn't good automatic way to mix and match fixed function 
> and shader, the use of the vertex aliasing etc. also doesn't help matters.  
> It's an area where OpenGL drops us in it, it's either shaders or fixed 
> function, OpenGL provides no mapping for us to leverage, particularly when 
> building GL3/core profile or GLES2 where built ins't like glLight etc. have 
> no gl_Light uniforms associated with them like there is in GL2.
> 
> 
> The OSG tries to walk between there two worlds - fixed function and shader 
> based, you can mix and match a bit but it's not seamless, and once you start 
> talking about GL3/core profule and GLES2 there's a whole heap more things to 
> deal with and you essentially have to build everything with your own shaders. 

Agreed 100%; my problem is that building your own shaders within OSG currently 
has a couple of seemingly minor, but quite frustrating, stumbling blocks. 

For me the main one is that if you're using your own shaders you need to be 
able to access the model/view/projection matrices and set them within your own 
shaders. Right now I need to write my shader with osg_ModelView* as a uniform, 
which means you need to set setUseModelViewAndProjectionUniforms. This then 
breaks other legacy shaders since it's a global flag for the state.

It seems like if there was a way to set the matrices as uniforms like any 
other, by giving a hook so that you can define your own behavior when OSG wants 
to change the matrices during drawing, then I could selectively choose where 
and when to use fixed and modern.


The value of OSG for us is in scene organization, memory management, wrapping 
around C-oriented OpenGL calls, multiple data format handling, culling, all the 
libraries built around it, sensible and flexible design, etc. The value of 
modern shader pipelines is being able to take a set of input uniforms, vertex 
attributes and texture maps, and have lots of rendering flexibility from that.

i.e. I don't need OSG to be able to take a legacy / modern project mixed up and 
be able to sort it all out. osg::Fog and Light and Particles and Shadows I am 
happy to leave to legacy because in a modern pipeline world you want to do that 
yourself. I would like OSG to offer something where it says: "I have figured 
out the render order, transformation matrices, loaded up the textures, set the 
vertex attribs, applied your shader programs and applied the global uniforms, 
done all that magic: Now for this sub-tree as requested you can set the 
bindings, and I won't try and look inside your shader program and modify it."



robertosfield wrote:
> So for your example, well you've written an test case that tries to walk the 
> line between fixed function and shader worlds and area that doesn't isn't 
> properly supported by OSG-3.4.
> 
> 
> In the shader_pipeline branch of the OSG master there is some work that 
> attempts to bridge the gap between fixed function and shaders by providing a 
> solution for mapping fixed function state attributes to uniforms and 
> providing shader composition but it's a bleeding edge work in progress.  
> Getting a seamless mashup isn't a really tough nut to crack, but 
> shader_pipeline is our current best attempt at this.
> 
> 
> For your own application you'll need to decide what your goals and 
> constraints are - if you have to support GL3/core profile and/or GLES2+ then 
> you'll need to think about how you provide your own shaders and how you remap 
> fixed function models into your shader 

Re: [osg-users] Setting the transform matrices

[Robert Osfield]

Hi Chris,

I have now had an opportunity to try your example, it doesn't compile
against OSG master are some of the osgParticular API has changed, so I
built against the OSG-3.4 branch.

I have run with the various command 1-8 options and get different behaviour
but looking at the code I really don't know what is expected. The black cow
is likely occurring because no shader is being provided that handles texgen
that the cow.osg uses from the fixed function pipeline.

In OSG-3.4.x there isn't good automatic way to mix and match fixed function
and shader, the use of the vertex aliasing etc. also doesn't help matters.
It's an area where OpenGL drops us in it, it's either shaders or fixed
function, OpenGL provides no mapping for us to leverage, particularly when
building GL3/core profile or GLES2 where built ins't like glLight etc. have
no gl_Light uniforms associated with them like there is in GL2.

The OSG tries to walk between there two worlds - fixed function and shader
based, you can mix and match a bit but it's not seamless, and once you
start talking about GL3/core profule and GLES2 there's a whole heap more
things to deal with and you essentially have to build everything with your
own shaders.

So for your example, well you've written an test case that tries to walk
the line between fixed function and shader worlds and area that doesn't
isn't properly supported by OSG-3.4.

In the shader_pipeline branch of the OSG master there is some work that
attempts to bridge the gap between fixed function and shaders by providing
a solution for mapping fixed function state attributes to uniforms and
providing shader composition but it's a bleeding edge work in progress.
Getting a seamless mashup isn't a really tough nut to crack, but
shader_pipeline is our current best attempt at this.

For your own application you'll need to decide what your goals and
constraints are - if you have to support GL3/core profile and/or GLES2+
then you'll need to think about how you provide your own shaders and how
you remap fixed function models into your shader approach.  Trying to
maship fixed function with shaders will likely cause problems though as
your test example shows, it's not a "bug" in the OSG that we can fix
though, rather you've stepped no-mans land which can't be properly
supported which different back-end completely i.e. shader_pipeline.

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

Re: [osg-users] Setting the transform matrices

[Chris Kuliukas]

No worries, thanks anyway


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)

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





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

Re: [osg-users] Setting the transform matrices

[Robert Osfield]

On 29 September 2017 at 14:27, Chris Kuliukas  wrote:

> I would be interested and grateful to know what you think of the
> (apparent) bug I posted Robert, if you get a chance!
>
> The code I posted should compile, and you just need to feed in different
> numbers to the first command line arg to see the effects of changing the
> vertex attrib and matrix uniform settings.
>

I way rather overloaded with other work at this moment so can't go looking
at general community issues right now.

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

Re: [osg-users] Setting the transform matrices

[Chris Kuliukas]

I would be interested and grateful to know what you think of the (apparent) bug 
I posted Robert, if you get a chance! 

The code I posted should compile, and you just need to feed in different 
numbers to the first command line arg to see the effects of changing the vertex 
attrib and matrix uniform settings.


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)

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





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

Re: [osg-users] Setting the transform matrices

[Chris Kuliukas]

Oops, forgot that most readers are on the mailing list. Here is the code which 
breaks with vertex attrib aliasing:


Code:
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
 *
 * This application is open source and may be redistributed and/or modified
 * freely and without restriction, both in commercial and non commercial 
applications,
 * as long as this copyright notice is maintained.
 *
 * This application 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.
*/

#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 

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

#include 

#include 

#include 
#include 
#include 
#include 


#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

void createFountainEffect(osgParticle::ModularEmitter* emitter, 
osgParticle::ModularProgram* program)
{
// Emit specific number of particles every frame
osg::ref_ptr rrc = new 
osgParticle::RandomRateCounter;
rrc->setRateRange(500, 2000);

// Accelerate particles in the given gravity direction.
osg::ref_ptr accel = new 
osgParticle::AccelOperator;
accel->setToGravity();

// Multiply each particle's velocity by a damping constant.
osg::ref_ptr damping = new 
osgParticle::DampingOperator;
damping->setDamping(0.9f);

// Bounce particles off objects defined by one or more domains.
// Supported domains include triangle, rectangle, plane, disk and 
sphere.
// Since a bounce always happens instantaneously, it will not work 
correctly with unstable delta-time.
// At present, even the floating error of dt (which are applied to 
ParticleSystem and Operator separately)
// causes wrong bounce results. Some one else may have better solutions 
for this.
osg::ref_ptr bounce = new 
osgParticle::BounceOperator;
bounce->setFriction(-0.05);
bounce->setResilience(0.35);
bounce->addDiskDomain(osg::Vec3(0.0f, 0.0f, -2.0f), osg::Z_AXIS, 8.0f);
bounce->addPlaneDomain(osg::Plane(osg::Z_AXIS, 5.0f));

// Kill particles going inside/outside of specified domains.
osg::ref_ptr sink = new 
osgParticle::SinkOperator;
sink->setSinkStrategy(osgParticle::SinkOperator::SINK_OUTSIDE);
sink->addSphereDomain(osg::Vec3(), 20.0f);

emitter->setCounter(rrc.get());
program->addOperator(accel.get());
program->addOperator(damping.get());
program->addOperator(bounce.get());
program->addOperator(sink.get());
}

const std::string 
OSG_DATA_FOLDER("C:/Users/User/Desktop/OpenSceneGraph/OpenSceneGraph-Data/");

int main(int argc, char** argv)
{

auto useVertexAttributeAliasing = false;
auto useModelViewAndProjectionUniforms = true;
bool useShaders = false;
if (argc > 1) {
auto caseNo = atoi(argv[1]);
// 8 pemutations of 3 options, 0-7
// Case 4 : Black cow
// Case 5 : Black cow, purple particle smoke
// Case 6 : Black cow
useVertexAttributeAliasing = (0x4 & caseNo)!=0;
useModelViewAndProjectionUniforms = (0x2 & caseNo) != 0;
useShaders = (0x1 & caseNo) != 0;
}

// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(&argc, argv);

osgViewer::Viewer viewer(arguments);

std::string textureFile(OSG_DATA_FOLDER + "Images/smoke.rgb");
while (arguments.read("--texture", textureFile)) {}

float pointSize = 20.0f;
while (arguments.read("--point", pointSize)) {}

double visibilityDistance = -1.0f;
while (arguments.read("--visibility", visibilityDistance)) {}

bool customShape = false;
while (arguments.read("--enable-custom")) { customShape = true; }

unsigned int helpType = 0;
if ((helpType = arguments.readHelpType()))
{
arguments.getApplicationUsage()->write(std::cout, helpType);
return 1;
}

// report any errors if they have occurred when parsing the program 
arguments.
if (arguments.errors())
{
arguments.writeErrorMessages(std::cout);
return 1;
}

// set up the camera manipulators.
{
osg::ref_ptr 
keyswitchManipulator = new osgGA::KeySwitchMatrixManipulator;

keyswitchManipulator->addMatrixManipulator('1', "Trackball", 
new osgGA::TrackballManipulator());
keyswitchManipulator->addMatrixManipulator('2', "Flight", new 
osgGA::FlightManipulator());
keyswitchManipulator->addMatrixManipulator('3', "Drive", new 
osgGA::DriveManipulator());
  

Re: [osg-users] Setting the transform matrices

[Chris Kuliukas]

Fair enough.. I do understand the frustration of supporting unfamiliar devs in 
an FOSS project.

I already understand and agree with your post, but I think you took me wrong 
I'm not making a big deal out of anything and value OSG highly. 


Based on your post I'll move on to something more concrete: Attached is a 
example OSG program in OSG 3.4.1 demonstrating vertex attribute aliasing 
causing issues.

There are 8 option permutations to try viewing cow.osg and a osgParticle system 
with vertex attribute aliasing, uniforms, and shader based particles either on 
or off. A number provided as a command line arg decides the case.

The results are:

Code:
// 8 pemutations of 3 options, 0-7
// Case 4 : Black cow (vertex attrib aliasing)
// Case 5 : Black cow, purple particle smoke (vertex attrib 
aliasing, shaders)
// Case 6 : Black cow (vertex attrib aliasing, 
modelviewandprojectionuniforms)
// Other cases: Shiny cow, white particles




And I can't seem to turn it on only for the required programs and off otherwise.


Since I can't use legacy gl_* uniforms/attribs in modern shaders you need OSG 
to set them or to set them yourself. And if you can't enable vertex attrib 
aliasing or modelviewandprojectionuniforms because they break other things as 
above you can end up trying unusual things and causing grief on the support 
mailing list.


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)

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



/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
 *
 * This application is open source and may be redistributed and/or modified
 * freely and without restriction, both in commercial and non commercial 
applications,
 * as long as this copyright notice is maintained.
 *
 * This application 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.
*/

#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 

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

#include 

#include 

#include 
#include 
#include 
#include 


#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

void createFountainEffect(osgParticle::ModularEmitter* emitter, 
osgParticle::ModularProgram* program)
{
// Emit specific number of particles every frame
osg::ref_ptr rrc = new 
osgParticle::RandomRateCounter;
rrc->setRateRange(500, 2000);

// Accelerate particles in the given gravity direction.
osg::ref_ptr accel = new 
osgParticle::AccelOperator;
accel->setToGravity();

// Multiply each particle's velocity by a damping constant.
osg::ref_ptr damping = new 
osgParticle::DampingOperator;
damping->setDamping(0.9f);

// Bounce particles off objects defined by one or more domains.
// Supported domains include triangle, rectangle, plane, disk and 
sphere.
// Since a bounce always happens instantaneously, it will not work 
correctly with unstable delta-time.
// At present, even the floating error of dt (which are applied to 
ParticleSystem and Operator separately)
// causes wrong bounce results. Some one else may have better solutions 
for this.
osg::ref_ptr bounce = new 
osgParticle::BounceOperator;
bounce->setFriction(-0.05);
bounce->setResilience(0.35);
bounce->addDiskDomain(osg::Vec3(0.0f, 0.0f, -2.0f), osg::Z_AXIS, 8.0f);
bounce->addPlaneDomain(osg::Plane(osg::Z_AXIS, 5.0f));

// Kill particles going inside/outside of specified domains.
osg::ref_ptr sink = new 
osgParticle::SinkOperator;
sink->setSinkStrategy(osgParticle::SinkOperator::SINK_OUTSIDE);
sink->addSphereDomain(osg::Vec3(), 20.0f);

emitter->setCounter(rrc.get());
program->addOperator(accel.get());
program->addOperator(damping.get());
program->addOperator(bounce.get());
program->addOperator(sink.get());
}

const std::string 
OSG_DATA_FOLDER("C:/Users/User/Desktop/OpenSceneGraph/OpenSceneGraph-Data/");

int main(int argc, char** argv)
{

auto useVertexAttributeAliasing = false;
auto useModelViewAndProjectionUniforms = true;
bool useShaders = false;
if (argc > 1) {
auto caseNo = atoi(argv[1]);
// 8 pemutations of 3 options, 0-7
// Case 4 : Black cow
// Case 5 : Black cow, purple particle smoke
// Case 6 : Black cow
useVertexAttributeAliasing = (0x4 & caseNo)!=0;
useModelViewAndProjectionUniforms = (0x2 & caseNo) != 0;
   

Re: [osg-users] Setting the transform matrices

[Robert Osfield]

Hi Chris,

On 30 August 2017 at 07:50, Chris Kuliukas  wrote:

> For now it'd be too time consuming to isolate a test case. Supporting
> modern OpenGL does seem like it would be more natural if you had some way
> of hooking into the setting of the model matrix and vertex attributes so
> that you could assign / name / alter them yourself.
>

Ahh, sorry but you just don't seem to grasping it, the OSG fully
supports setting the view and projection matrices in GLES2 and GL3+ core
profile, you don't need to add ANY more complexity than just replacing
gl_ModelView* with osg_ModelView*, the OSG will even automatically remap
for you.

The OSG automatically accumulates all view and projection matrices for you,
sets the when required, it does a shed load of work for you to make you
life easy.  All the osg::Camera and osg::Transform subclasses all work in
coherent and robust fashion, whether you are using fixed function pipeline
of shaders and they function in the same way in both.

This capability is massive strength of the OSG.

I can't help but feel you are making a massive deal from your own
mis-understandings and see restrictions where there aren't any.  Just use
the OSG, while it's not perfect, the flaws it has aren't related to
management of modelview and projection martrices, this has all been working
well in fixed function and shaders for a decade, it's a solved problem.

If all this power and convinience is not for then please go right your own
scene graph as I really shouldn't have to keep replying to a pointless
thread where the solutions are already provided.

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

Re: [osg-users] Setting the transform matrices

[Sebastian Messerschmidt]

Hi Chris,> Hi Robert,


For now it'd be too time consuming to isolate a test case. Supporting modern 
OpenGL does seem like it would be more natural if you had some way of hooking 
into the setting of the model matrix and vertex attributes so that you could 
assign / name / alter them yourself.


You can use any matrix you like. Simply set it up as uniform and use it 
in the shader. Since there is underlying scenegraph you need to consider 
disabling culling for the node or set its matrix accordingly.


Your hooking can be done by simply adding a transform-group over your 
element and set the the desired matrix from there.
A minimal example explaining what you want to achieve might be very 
helpful.



Cheers
Sebastian



Cheers,
Chris


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)

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





___
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] Setting the transform matrices

[Chris Kuliukas]

Hi Robert,

For now it'd be too time consuming to isolate a test case. Supporting modern 
OpenGL does seem like it would be more natural if you had some way of hooking 
into the setting of the model matrix and vertex attributes so that you could 
assign / name / alter them yourself.

Cheers,
Chris


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)

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





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

Re: [osg-users] Setting the transform matrices

[Robert Osfield]

HI Chris,

On 10 August 2017 at 02:11, Chris Kuliukas  wrote:

> The problem is whenever I try to use
> gc->getState()->setUseModelViewAndProjectionUniforms(true);
> gc->getState()->setUseVertexAttributeAliasing(true);
> it always seems to screw up something, like the precipitation or particle
> effects.
>

This sounds like a bug somewhere.  Could you be specific so we can see if
we can reproduce the problem and then hunt down and resolve it.


> I figure if there is a way I can set the projection matrices etc to new
> variables, instead of overwriting existing gl_whatever variables in
> shaders, then I can supply my shaders with the data they need without
> affecting anything else.
>

There is currently a transition between old fixed function, early GLSL and
new GLSL, the introduction of the attribute and built uniform aliasing is
part of this transition.  The OSG has to go wholly over to supporting the
new GLSL standards so the osg_ uniforms is the way forward.

What specifically is at issue for you is not possible to say as we really
don't have enough to go on, attempting to allow local workarounds for the
problems you are seeing isn't a good long term solution for you or for us
(the more non standard stuff you do locally the less able we are to support
you,)

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

Re: [osg-users] Setting the transform matrices

[Chris Kuliukas]

The problem is whenever I try to use 
gc->getState()->setUseModelViewAndProjectionUniforms(true);
gc->getState()->setUseVertexAttributeAliasing(true); 
it always seems to screw up something, like the precipitation or particle 
effects.

I figure if there is a way I can set the projection matrices etc to new 
variables, instead of overwriting existing gl_whatever variables in shaders, 
then I can supply my shaders with the data they need without affecting anything 
else.


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)

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





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

Re: [osg-users] Setting the transform matrices

[Robert Osfield]

Hi Chris,

I would recommend using the osg_ModelViewMatrix etc. as these are fully
supported once you enable them and is far simpler than workarounds like you
are trying.  All you need to do is enable the aliasing to get the OSG to
generate the uniforms.  The osgsimplegl3 example illustrates how :


// for non GL3/GL4 and non GLES2 platforms we need enable the osg_
uniforms that the shaders will use,
// you don't need thse two lines on GL3/GL4 and GLES2 specific builds
as these will be enable by default.
gc->getState()->setUseModelViewAndProjectionUniforms(true);
gc->getState()->setUseVertexAttributeAliasing(true);

Could you explain what the problem was when trying to the OSG's built in
aliasing?

Robert.

On 9 August 2017 at 09:35, Chris Kuliukas  wrote:

> Hi,
>
> What is the proper way to set the view/projection matrix to a uniform
> yourself? I've found that trying to deal with the osg_ built-in uniforms
> which do all sorts of renaming etc is unreliable and would like to be able
> to just set everything myself manually.
>
> At the moment I'm setting the view / projection matrix uniforms within the
> camera's initialdrawcallback, but I'm not sure if this is the right way to
> do it that will ensure the uniform value will only be used within that
> camera and not within other cameras (since it needs to work across multiple
> screens and render stages).
>
> Is there some code within OSG that ensures that a uniform assigned to a
> camera will only apply to the graphics context for the thread that set it?
>
>
> Thank you!
>
> Cheers,
> Chris
>
> 
> http://www.hrwallingford.com/facilities/ship-simulation-centre (
> http://www.hrwallingford.com/facilities/ship-simulation-centre)
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=71391#71391
>
>
>
>
>
> ___
> 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] Setting the transform matrices

[Sebastian Messerschmidt]

Hi Chris,


Why are you trying to override the default behavior in the first place?
Simply set the node's matrices by adding a transform node with absolute 
reference frame as parent/modify the camera's projection matrix. If you 
need it per graphics context you might consider using different scene 
graphs per camera(thus context).


Rather than asking for on obscure seeming approach, you might get more 
ideas by describing what you are after.


Cheers
Sebastian



Hi,

What is the proper way to set the view/projection matrix to a uniform yourself? 
I've found that trying to deal with the osg_ built-in uniforms which do all 
sorts of renaming etc is unreliable and would like to be able to just set 
everything myself manually.

At the moment I'm setting the view / projection matrix uniforms within the 
camera's initialdrawcallback, but I'm not sure if this is the right way to do 
it that will ensure the uniform value will only be used within that camera and 
not within other cameras (since it needs to work across multiple screens and 
render stages).

Is there some code within OSG that ensures that a uniform assigned to a camera 
will only apply to the graphics context for the thread that set it?


Thank you!

Cheers,
Chris


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)

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





___
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] Setting the transform matrices

[Chris Kuliukas]

Hi,

What is the proper way to set the view/projection matrix to a uniform yourself? 
I've found that trying to deal with the osg_ built-in uniforms which do all 
sorts of renaming etc is unreliable and would like to be able to just set 
everything myself manually.

At the moment I'm setting the view / projection matrix uniforms within the 
camera's initialdrawcallback, but I'm not sure if this is the right way to do 
it that will ensure the uniform value will only be used within that camera and 
not within other cameras (since it needs to work across multiple screens and 
render stages).

Is there some code within OSG that ensures that a uniform assigned to a camera 
will only apply to the graphics context for the thread that set it?


Thank you!

Cheers,
Chris


http://www.hrwallingford.com/facilities/ship-simulation-centre 
(http://www.hrwallingford.com/facilities/ship-simulation-centre)

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





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