OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Setting the transform matrices


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
ckuliukas
User


Joined: 22 Nov 2014
Posts: 32

PostPosted: Wed Aug 09, 2017 8:35 am    Post subject:
Setting the transform matrices
Reply with quote

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
Back to top
View user's profile Send private message
SMesserschmidt (Sebastian Messerschmidt)
Forum Moderator


Joined: 10 Sep 2013
Posts: 799

PostPosted: Wed Aug 09, 2017 8:41 am    Post subject:
Setting the transform matrices
Reply with quote

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


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









------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11275

PostPosted: Wed Aug 09, 2017 10:01 am    Post subject:
Setting the transform matrices
Reply with quote

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
ckuliukas
User


Joined: 22 Nov 2014
Posts: 32

PostPosted: Thu Aug 10, 2017 1:11 am    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11275

PostPosted: Thu Aug 10, 2017 5:46 am    Post subject:
Setting the transform matrices
Reply with quote

HI Chris,

On 10 August 2017 at 02:11, Chris Kuliukas < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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.

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




 

------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
ckuliukas
User


Joined: 22 Nov 2014
Posts: 32

PostPosted: Wed Aug 30, 2017 6:50 am    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
SMesserschmidt (Sebastian Messerschmidt)
Forum Moderator


Joined: 10 Sep 2013
Posts: 799

PostPosted: Wed Aug 30, 2017 6:56 am    Post subject:
Setting the transform matrices
Reply with quote

Hi Chris,> Hi Robert,
Quote:

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

Quote:

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









------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11275

PostPosted: Wed Aug 30, 2017 8:08 am    Post subject:
Setting the transform matrices
Reply with quote

Hi Chris,

On 30 August 2017 at 07:50, Chris Kuliukas < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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.


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

------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
ckuliukas
User


Joined: 22 Nov 2014
Posts: 32

PostPosted: Wed Aug 30, 2017 9:03 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
ckuliukas
User


Joined: 22 Nov 2014
Posts: 32

PostPosted: Sat Sep 02, 2017 2:47 am    Post subject:
Reply with quote

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 <osgDB/ReadFile>
#include <osgUtil/Optimizer>
#include <osg/CoordinateSystemNode>

#include <osg/Switch>
#include <osg/Types>
#include <osgText/Text>

#include <osgViewer/Viewer>
#include <osgViewer/ViewerEventHandlers>

#include <osgGA/TrackballManipulator>
#include <osgGA/FlightManipulator>
#include <osgGA/DriveManipulator>
#include <osgGA/KeySwitchMatrixManipulator>
#include <osgGA/StateSetManipulator>
#include <osgGA/AnimationPathManipulator>
#include <osgGA/TerrainManipulator>
#include <osgGA/SphericalManipulator>

#include <osgGA/Device>

#include <iostream>

#include <osg/ShapeDrawable>
#include <osg/MatrixTransform>
#include <osg/Point>
#include <osg/PointSprite>


#include <osgParticle/ParticleSystem>
#include <osgParticle/ParticleSystemUpdater>
#include <osgParticle/ModularEmitter>
#include <osgParticle/ModularProgram>

#include <osgParticle/AccelOperator>
#include <osgParticle/DampingOperator>
#include <osgParticle/BounceOperator>
#include <osgParticle/SinkOperator>

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

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

   // Multiply each particle's velocity by a damping constant.
   osg::ref_ptr<osgParticle::DampingOperator> 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<osgParticle::BounceOperator> 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<osgParticle::SinkOperator> 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<osgGA::KeySwitchMatrixManipulator> 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());
      keyswitchManipulator->addMatrixManipulator('4', "Terrain", new osgGA::TerrainManipulator());
      keyswitchManipulator->addMatrixManipulator('5', "Orbit", new osgGA::OrbitManipulator());
      keyswitchManipulator->addMatrixManipulator('6', "FirstPerson", new osgGA::FirstPersonManipulator());
      keyswitchManipulator->addMatrixManipulator('7', "Spherical", new osgGA::SphericalManipulator());

      std::string pathfile;
      double animationSpeed = 1.0;
      while (arguments.read("--speed", animationSpeed)) {}
      char keyForAnimationPath = '8';
      while (arguments.read("-p", pathfile))
      {
         osgGA::AnimationPathManipulator* apm = new osgGA::AnimationPathManipulator(pathfile);
         if (apm || !apm->valid())
         {
            apm->setTimeScale(animationSpeed);

            unsigned int num = keyswitchManipulator->getNumMatrixManipulators();
            keyswitchManipulator->addMatrixManipulator(keyForAnimationPath, "Path", apm);
            keyswitchManipulator->selectMatrixManipulator(num);
            ++keyForAnimationPath;
         }
      }

      viewer.setCameraManipulator(keyswitchManipulator.get());
   }

   // add the state manipulator
   viewer.addEventHandler(new osgGA::StateSetManipulator(viewer.getCamera()->getOrCreateStateSet()));

   // add the thread model handler
   viewer.addEventHandler(new osgViewer::ThreadingHandler);

   // add the window size toggle handler
   viewer.addEventHandler(new osgViewer::WindowSizeHandler);

   // add the stats handler
   viewer.addEventHandler(new osgViewer::StatsHandler);

   // add the help handler
   viewer.addEventHandler(new osgViewer::HelpHandler(arguments.getApplicationUsage()));

   // add the record camera path handler
   viewer.addEventHandler(new osgViewer::RecordCameraPathHandler);

   // add the LOD Scale handler
   viewer.addEventHandler(new osgViewer::LODScaleHandler);

   // add the screen capture handler
   viewer.addEventHandler(new osgViewer::ScreenCaptureHandler);

   // load the data
   osg::ref_ptr<osg::Node> loadedModel = osgDB::readRefNodeFiles(arguments);

   // any option left unread are converted into errors to write out later.
   arguments.reportRemainingOptionsAsUnrecognized();

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

   /***
   Customize particle template and system attributes
   ***/
   osg::ref_ptr<osgParticle::ParticleSystem> ps = new osgParticle::ParticleSystem;

   ps->getDefaultParticleTemplate().setLifeTime(5.0f);

   if (customShape)
   {
      // osgParticle now supports making use of customized drawables. The draw() method will be executed
      // and display lists will be called for each particle. It is always a huge consumption of memory, and
      // hardly to use shaders to render them, so please be careful using this feature.
      ps->getDefaultParticleTemplate().setShape(osgParticle::Particle::USER);
      ps->getDefaultParticleTemplate().setDrawable(new osg::ShapeDrawable(new osg::Box(osg::Vec3(), 1.0f)));
      useShaders = false;
   }
   else
   {
      // The shader only supports rendering points at present.
      ps->getDefaultParticleTemplate().setShape(osgParticle::Particle::POINT);
   }

   // Set the visibility distance of particles, due to their Z-value in the eye coordinates.
   // Particles that are out of the distance (or behind the eye) will not be rendered.
   ps->setVisibilityDistance(visibilityDistance);

   if (useShaders)
   {
      // Set using local GLSL shaders to render particles.
      // At present, this is slightly efficient than ordinary methods. The bottlenack here seems to be the cull
      // traversal time. Operators go through the particle list again and again...
      ps->setDefaultAttributesUsingShaders(textureFile, true, 0);
   }
   else
   {
      // The default methods uses glBegin()/glEnd() pairs. Fortunately the GLBeginEndAdapter does improve the
      // process, which mimics the immediate mode with glDrawArrays().
      ps->setDefaultAttributes(textureFile, true, false, 0);

      // Without the help of shaders, we have to sort particles to make the visibility distance work. Sorting is
      // also useful in rendering transparent particles in back-to-front order.
      if (visibilityDistance>0.0)
         ps->setSortMode(osgParticle::ParticleSystem::SORT_BACK_TO_FRONT);
   }

   // At last, to make the point sprite work, we have to set the points size and the sprite attribute.
   osg::StateSet* stateset = ps->getOrCreateStateSet();
   stateset->setAttribute(new osg::Point(pointSize));
   stateset->setTextureAttributeAndModes(0, new osg::PointSprite, osg::StateAttribute::ON);

   /***
   Construct other particle system elements, including the emitter and program
   ***/
   osg::ref_ptr<osgParticle::ModularEmitter> emitter = new osgParticle::ModularEmitter;
   emitter->setParticleSystem(ps.get());

   osg::ref_ptr<osgParticle::ModularProgram> program = new osgParticle::ModularProgram;
   program->setParticleSystem(ps.get());

   createFountainEffect(emitter.get(), program.get());

   /***
   Add the entire particle system to the scene graph
   ***/
   osg::ref_ptr<osg::MatrixTransform> parent = new osg::MatrixTransform;
   parent->addChild(emitter.get());
   parent->addChild(program.get());

   // The updater can receive particle systems as child drawables now. The addParticleSystem() method
   // is still usable, with which we should define another geode to contain a particle system.
   osg::ref_ptr<osgParticle::ParticleSystemUpdater> updater = new osgParticle::ParticleSystemUpdater;
   //updater->addDrawable( ps.get() );

   osg::ref_ptr<osg::Group> root = new osg::Group;
   root->addChild(parent.get());
   root->addChild(updater.get());

   // FIXME 2010.9.19: the updater can't be a drawable; otehrwise the ParticleEffect will not work properly. why?
   updater->addParticleSystem(ps.get());

   osg::ref_ptr<osg::Geode> geode = new osg::Geode;
   geode->addDrawable(ps.get());
   root->addChild(geode.get());

   std::string cowFile(OSG_DATA_FOLDER + "cow.osg");
   auto cow = osgDB::readNodeFile(cowFile);
   root->addChild(cow);
   
   viewer.setSceneData(root);

   viewer.realize();

   auto cams = std::vector<osg::Camera*>();


   viewer.getCameras(cams, false);
   for (int i = 0; i < cams.size(); i++) {
      if(cams.at(i)->getGraphicsContext() ) cams.at(i)->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(useVertexAttributeAliasing);
      if (cams.at(i)->getGraphicsContext()) cams.at(i)->getGraphicsContext()->getState()->setUseModelViewAndProjectionUniforms(useModelViewAndProjectionUniforms);
   }

   viewer.run();


}

_________________
http://www.hrwallingford.com/facilities/ship-simulation-centre
Back to top
View user's profile Send private message
ckuliukas
User


Joined: 22 Nov 2014
Posts: 32

PostPosted: Fri Sep 29, 2017 1:27 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11275

PostPosted: Fri Sep 29, 2017 2:46 pm    Post subject:
Setting the transform matrices
Reply with quote

On 29 September 2017 at 14:27, Chris Kuliukas < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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.



 

------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
ckuliukas
User


Joined: 22 Nov 2014
Posts: 32

PostPosted: Sat Sep 30, 2017 2:35 am    Post subject:
Reply with quote

No worries, thanks anyway

_________________
http://www.hrwallingford.com/facilities/ship-simulation-centre
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11275

PostPosted: Mon Oct 09, 2017 10:51 am    Post subject:
Setting the transform matrices
Reply with quote

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.

------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
ckuliukas
User


Joined: 22 Nov 2014
Posts: 32

PostPosted: Thu Oct 26, 2017 1:03 pm    Post subject:
Re: Setting the transform matrices
Reply with quote

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

Encouraging that there's a branch for this, if for nothing else then because it's an acknowledgement that OSG shader support isn't ideal. I wasn't aware of that and I'll take a look at it and see if I can learn from your approach.


Bear in mind we both agree OSG is of huge value, that I'm no expert, and we both want what's best for your system and both share frustrations with the OpenGL transition. These are just my thoughts and experiences so don't take them as an attack on your work.

All the best,
Chris
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Transform matrix as Uniform to shaders freqfly General 3 Thu Oct 05, 2017 4:19 am View latest post
No new posts Setting up a shadowDepthCamera wernerM General 0 Fri Sep 08, 2017 11:28 am View latest post
No new posts using modern shaders with osg - setti... antiro42 General 18 Fri Sep 01, 2017 9:30 am View latest post
No new posts setting 2D manipulator bhanu406 General 1 Wed May 31, 2017 4:55 am View latest post
No new posts Setting vertex attribute array of float Bruno Oliveira General 1 Mon Mar 20, 2017 9:55 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP