Re: [osg-users] RayTracedTechnique hangs with Intel HD Graphics - Update

2017-09-02 Thread Clement.Chu
Hi,

This is two different problems.  The length method problem is fixed since 
osg 3.2.3.  See this post http://forum.openscenegraph.org/viewtopic.php?t=15148 
for the details.

Recently, I found the problem is related to Intel graphic driver.  Specify 
on latest Intel graphic cards.  My work laptop is dell and there is no problem 
on old Intel graphic card.  Since I changed to new dell laptop with latest 
Intel graphic card, I found the problem is on gl_Vertex which value is not 
normalised and causes the crash on sampling loop.  So far I tested 5 different 
laptops with different Intel graphic cards.  Only Intel graphic card with 3 
digit version number will cause the problem (old Intel card is using 4 digit 
for version).

Regards,
Clement Chu


From: osg-users  on behalf of 
Julien Valentin 
Sent: Sunday, 3 September 2017 04:00
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] RayTracedTechnique hangs with Intel HD Graphics -  
Update

Hi,
it surely is the duplicate of
http://forum.openscenegraph.org/viewtopic.php?t=14304
I thought this issue was fixed since all this time
The hack i use is there
curious bug indeed, and so curious solution too
@robert
Perhaps it may be merged into master...your call...

cheers


Clement wrote:
> Hi,
>
> Finally I found where causes the problem.  For some reasons, gl_Vertex is not 
> normalized.  I looked at osg shader source code (src\osgVolume\Shaders).  For 
> example, in file volume_frag.cpp,
>
> vec4 t0 = vertexPos;
> vec4 te = cameraPos;
>
> // by default te did to check the range (0 and 1), but t0 did not.
> // If I added  some codes to check the range, then the problem is completed 
> gone.
>
> if (t0.x<0.0) t0.x = 0.0; if (t0.x>1.0) t0.x = 1.0;
> if (t0.y<0.0) t0.y = 0.0; if (t0.y>1.0) t0.y = 1.0;
> f (t0.z<0.0) t0.z = 0.0; if (t0.z>1.0) t0.z = 1.0;
>
>
> I believe the problem is related to GLSL version and latest Intel HD Graphics 
> driver is using higher version of GLSL, but gl_Vertex does not normalize or 
> the value is just over 1 or less then 0 (eg. 1.1).  Then it causes the 
> crash when running the sampling loop.  I am not an expert on GLSL, so I would 
> like to confirm the best solution to handle this problem. Thanks.
>
>
> Regards,
> Clement Chu
>
> 
> From: osg-users <> on behalf of  <>
> Sent: Wednesday, 30 August 2017 17:31
> To:
> Subject: [ExternalEmail]  RayTracedTechnique hangs with Intel HD Graphics
>
> Hi,
>
> My program uses RayTracedTechnique for volume rendering, but it hangs with 
> Intel HD graphics 520, 530 and 620. My old laptop works fine which is using 
> Intel HD Graphic 3000.  Other machines with Nvidia cards are working fine 
> too.  I believe the problem is on shaders in the sampling loop.  My program 
> is using osg 3.2.3.  I also tried to upgrade to osg 3.4.1, but the same 
> problem occurred with Intel HD Graphic 520, 530 and 620.  Do anyone have 
> similar problem and any solution to fix it?  Many thanks.
>
>
> Regards,
> Clement Chu
> ___
> osg-users mailing list
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>  --
> Post generated by Mail2Forum


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





___
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] CullVisitor::apply(Geode&) detected NaN,

2017-09-02 Thread Rômulo Cerqueira
Hi guys,

I found and solved the problem! :D

When I grab the osg scene at first time, my view matrix is NaN; from the second 
time, this matrix is correctly filled. 

Then, I modified the grabImage method to replace when the view matrix is NaN by 
the identity matrix, as follows:


Code:

osg::ref_ptr 
ImageViewerCaptureTool::grabImage(osg::ref_ptr node) {
// set the current root node
_viewer->setSceneData(node);

// if the view matrix is invalid (NaN), use the identity
osg::ref_ptr camera = _viewer->getCamera();
if (camera->getViewMatrix().isNaN())
camera->setViewMatrix(osg::Matrix::identity());

// grab the current frame
_viewer->frame();
return _capture->captureImage();
}




Thanks for all messages!

Cheers,

Rômulo

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





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


Re: [osg-users] using modern shaders with osg - setting vertex attribute layout

2017-09-02 Thread Sebastian Messerschmidt
Hi. Sorry I don't on my computer right now, but it seems you are not providing vertex shaders. I'm not sure, but that might cause trouble. I'll get back to the issue tommorow or on Monday. 

Cheers
Sebastian
-- 
Sent from my Android phone with GMX Mail. Please excuse my brevity.On 9/2/17, 21:36 antiro black  wrote:
Hi Sebastian,
I'm compiling under debian jessie 64 bits and am running a NVIDIA GTX 970. The drivers have been updates recently and I am running version 384.69 now.
I included a compilable minimal example based on the osgmultiplerendertargets example. Without VertexAttributeAliasing it generates two texture using MRT, a red and a green one, it then combines these in a second pass to generate the final texture (yellow). (The red and green intermediate textures are shown in small quads to the side.)
When I enable the attribute aliasing (as in the included code), the two textures generated in the MRT pass turn into gradients, as if something has gone wrong with the mapping.
Screenshots:
The expected result (which I get without attribute aliasing): https://ibb.co/kHEogv
The result with aliasing: https://ibb.co/d9cfuF
Code:
/* OpenSceneGraph example, osgmultiplerendertargets.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
//#include "RenderingUtility.h" //to easily view intermediate textures
//
// Below is relatively straight forward example of using the OpenGL multiple render targets (MRT) extension
// to FrameBufferObjects/GLSL shaders.
//
// Another, more sophisticated MRT example can be found in the osgstereomatch example.
//
osg::Geode *createScreenQuad(float width,
		 float height,
		 float scale,
		 osg::Vec3 corner)
{
		osg::Geometry* geom = osg::createTexturedQuadGeometry(
corner,
osg::Vec3(width, 0, 0),
osg::Vec3(0, height, 0),
0,
0,
scale,
scale);
		osg::ref_ptr quad = new osg::Geode;
		quad->addDrawable(geom);
		int values = osg::StateAttribute::OFF | osg::StateAttribute::PROTECTED;
		quad->getOrCreateStateSet()->setAttribute(
new osg::PolygonMode(osg::PolygonMode::FRONT_AND_BACK,
		 osg::PolygonMode::FILL),
values);
		quad->getOrCreateStateSet()->setMode(GL_LIGHTING, values);
		return quad.release();
}
osg::Camera *createHUDCamera(double left=0,
		 double right=1,
		 double bottom=0,
		 double top=1)
{
		osg::ref_ptr camera = new osg::Camera;
		camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
		camera->setClearMask(GL_DEPTH_BUFFER_BIT);
		camera->setRenderOrder(osg::Camera::POST_RENDER);
		camera->setAllowEventFocus(false);
		camera->setProjectionMatrix(osg::Matrix::ortho2D(left, right, bottom, top));
		camera->getOrCreateStateSet()->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
		return camera.release();
}
osg::ref_ptr createTextureDisplayQuad(
		const osg::Vec3 ,
		osg::StateAttribute *tex,
		float scale,
		float width=0.3,
		float height=0.2)
{
		osg::ref_ptr hc = createHUDCamera();
		hc->addChild(createScreenQuad(width, height, scale, pos));
		hc->getOrCreateStateSet()->setTextureAttributeAndModes(0, tex);
		return hc;
}
// The callback modifies an input image.
struct MyCameraPostDrawCallback : public osg::Camera::DrawCallback
{
MyCameraPostDrawCallback(osg::Image* image):
_image(image)
{
}
virtual void operator () (const osg::Camera& /*camera*/) const
{
if (_image && _image->getPixelFormat()==GL_RGBA && _image->getDataType()==GL_UNSIGNED_BYTE)
{
// we'll pick out the center 1/2 of the whole image,
int column_start = _image->s()/4;
int column_end = 3*column_start;
int row_start = _image->t()/4;
int row_end = 3*row_start;
// and then halve their contribution
for(int r=row_start; rdirty();
}
else if 

Re: [osg-users] using modern shaders with osg - setting vertex attribute layout

2017-09-02 Thread antiro black
Hi Sebastian,

I'm compiling under debian jessie 64 bits and am running a NVIDIA GTX 970. The 
drivers have been updates recently and I am running version 384.69 now.

I included a compilable minimal example based on the osgmultiplerendertargets 
example. Without VertexAttributeAliasing it generates two texture using MRT, a 
red and a green one, it then combines these in a second pass to generate the 
final texture (yellow). (The red and green intermediate textures are shown in 
small quads to the side.)

When I enable the attribute aliasing (as in the included code), the two 
textures generated in the MRT pass turn into gradients, as if something has 
gone wrong with the mapping.

Screenshots:
The expected result (which I get without attribute aliasing): 
https://ibb.co/kHEogv
The result with aliasing: https://ibb.co/d9cfuF


Code:
/* OpenSceneGraph example, osgmultiplerendertargets.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

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

#include 
#include 
#include 

#include 

#include 
#include 

#include 
//#include "RenderingUtility.h" //to easily view intermediate textures
//
// Below is relatively straight forward example of using the OpenGL multiple 
render targets (MRT) extension
// to FrameBufferObjects/GLSL shaders.
//
// Another, more sophisticated MRT example can be found in the osgstereomatch 
example.
//

osg::Geode *createScreenQuad(float width,

 float height,

 float scale,

 osg::Vec3 corner)
{
osg::Geometry* geom = osg::createTexturedQuadGeometry(
corner,
osg::Vec3(width, 0, 0),
osg::Vec3(0, height, 0),
0,
0,
scale,
scale);
osg::ref_ptr quad = new osg::Geode;
quad->addDrawable(geom);
int values = osg::StateAttribute::OFF | 
osg::StateAttribute::PROTECTED;
quad->getOrCreateStateSet()->setAttribute(
new 
osg::PolygonMode(osg::PolygonMode::FRONT_AND_BACK,

 osg::PolygonMode::FILL),
values);
quad->getOrCreateStateSet()->setMode(GL_LIGHTING, values);
return quad.release();
}


osg::Camera *createHUDCamera(double left=0,

 double right=1,

 double bottom=0,

 double top=1)
{
osg::ref_ptr camera = new osg::Camera;
camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
camera->setClearMask(GL_DEPTH_BUFFER_BIT);
camera->setRenderOrder(osg::Camera::POST_RENDER);
camera->setAllowEventFocus(false);
camera->setProjectionMatrix(osg::Matrix::ortho2D(left, right, 
bottom, top));
camera->getOrCreateStateSet()->setMode(GL_LIGHTING, 
osg::StateAttribute::OFF);
return camera.release();
}

osg::ref_ptr createTextureDisplayQuad(
const osg::Vec3 ,
osg::StateAttribute *tex,
float scale,
float width=0.3,
float height=0.2)
{
osg::ref_ptr hc = createHUDCamera();

Re: [osg-users] [osganimation branch] Review, test, critics

2017-09-02 Thread michael kapelko
Hi. It would be nice to know WHAT changed and WHY.
Otherwise the news is kinda funny. Something has been changed and
everyone is welcome to test it. Sounds like a github project just went
live! But so did thousands of others.


On 3 September 2017 at 01:36, Julien Valentin
 wrote:
>
> mp3butcher wrote:
>> Hi,
>> A new development branch on refactoring of osgAnimation has been open.
>> https://github.com/openscenegraph/OpenSceneGraph/tree/osganimation
>> It provides also some new features and bug fixes.
>> I invite you all to test, review and critic  new design and features.
>> Feel free to give your feedback here
>>
>> Things to know:
>> -using RigTransformHW, the skinning.vert in $OSG_FILE_PATH  must bemodified 
>> changing
>>
>> Code:
>> uniform int nbBonesPerVertex;
>>
>>
>> to
>>
>> Code:
>> uniform uint nbBonesPerVertex;
>>
>>
>> Perhaps it breaks backward compatibility, please tell me
>>
>> PS:Further, from a personal point of view I would push refactoring toward 
>> backward miscompatibilities with few renaming so tell here if anyone 
>> manipulate VertexInfluence in their work.
>>
>>
>>
>> Thank you!
>>
>> Cheers,
>> Julien
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=71611#71611
>
>
>
>
>
> ___
> 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] [osganimation branch] Review, test, critics

2017-09-02 Thread Julien Valentin

mp3butcher wrote:
> Hi,
> A new development branch on refactoring of osgAnimation has been open. 
> https://github.com/openscenegraph/OpenSceneGraph/tree/osganimation
> It provides also some new features and bug fixes.
> I invite you all to test, review and critic  new design and features.
> Feel free to give your feedback here
> 
> Things to know:
> -using RigTransformHW, the skinning.vert in $OSG_FILE_PATH  must bemodified 
> changing 
> 
> Code:
> uniform int nbBonesPerVertex;
> 
> 
> to
> 
> Code:
> uniform uint nbBonesPerVertex;
> 
> 
> Perhaps it breaks backward compatibility, please tell me
> 
> PS:Further, from a personal point of view I would push refactoring toward 
> backward miscompatibilities with few renaming so tell here if anyone 
> manipulate VertexInfluence in their work.
> 
> 
> 
> Thank you!
> 
> Cheers,
> Julien


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





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


Re: [osg-users] using modern shaders with osg - setting vertex attribute layout

2017-09-02 Thread Sebastian Messerschmidt


Hi,

Unfortunately your example doesn't compile. If you provide a minimal 
(i.e. compileable ) example showing the problem we could take a look 
into it.

Due to copyright reasons I cannot give you an example from my code base.

Cheers
Sebastian

Hi,

I'm still struggling with getting setUseVertexAttributeAliasing(true) to 
combine rendering to textures.

To this end, I made made a tiny change to the osgmultiplerendertargets example 
to see if I could adapt that example to work with 
setUseVertexAttributeAliasing(true).

Aside from adding some lines to view the intermediate textures, my only change 
was enabling VertexAttributeAliasing as follows:


Code:
viewer.realize();
viewer.getCamera()->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(true);




Given that the code only uses some fragment shaders, which use fixed colors and 
don't rely on things like gl_Vertex or gl_Normal I assumed no changes to them 
would be needed. Yet enabling VertexAttribute shaders breaks rendering, 
disabling it again fixes it.

Maybe I'm completely misunderstanding the idea behind VertexAttributeAliasing, 
all I want is to reuse the shaders from my other project, which requires 
control over the vertex attribute layout...
If anyone can tell me what I'm doing wrong or has a working example of MRT with 
setUseVertexAttributeAliasing(true), that would be highly appreciated.

For reference, here is the entire modified code:

Code:

/* OpenSceneGraph example, osgmultiplerendertargets.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

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

#include 
#include 
#include 

#include 

#include 
#include 

#include "RenderingUtility.h" //to easily view intermediate textures
//
// Below is relatively straight forward example of using the OpenGL multiple 
render targets (MRT) extension
// to FrameBufferObjects/GLSL shaders.
//
// Another, more sophisticated MRT example can be found in the osgstereomatch 
example.
//


// The callback modifies an input image.
struct MyCameraPostDrawCallback : public osg::Camera::DrawCallback
{
 MyCameraPostDrawCallback(osg::Image* image):
 _image(image)
 {
 }

 virtual void operator () (const osg::Camera& /*camera*/) const
 {
 if (_image && _image->getPixelFormat()==GL_RGBA && 
_image->getDataType()==GL_UNSIGNED_BYTE)
 {
 // we'll pick out the center 1/2 of the whole image,
 int column_start = _image->s()/4;
 int column_end = 3*column_start;

 int row_start = _image->t()/4;
 int row_end = 3*row_start;

 // and then halve their contribution
 for(int r=row_start; rdata(column_start, r);
 for(int c=column_start; cdirty();
 }
 else if (_image && _image->getPixelFormat()==GL_RGBA && 
_image->getDataType()==GL_FLOAT)
 {
 // we'll pick out the center 1/2 of the whole image,
 int column_start = _image->s()/4;
 int column_end = 3*column_start;

 int row_start = _image->t()/4;
 int row_end = 3*row_start;

 // and then halve their contribution
 for(int r=row_start; rdata(column_start, r);
 for(int c=column_start; cdirty();

 //print 

Re: [osg-users] using modern shaders with osg - setting vertex attribute layout

2017-09-02 Thread Sebastian Messerschmidt

Hi Chris,

I'm also transitioning a legacy GL OSG project with a mix of custom shaders to 
modern GL bit by bit. And I've also had lots of trouble and headache with the 
built-in modern GL vertex attrib aliasing setting.

It seems crazy that the official advice is to write shaders and use OSG just like legacy GL, and 
OSG will then change your shader code and reinterpret deprecated calls to make it work via 
"modern" GL: Obviously in years to come when GL newcomers want to use OSG the official 
line can't be "learn how GL was 20 years ago, write your OSG code like that, and the system 
will make it work".

So I'm afraid this isn't as simple as it could be, but of course it's still 
easier than converting raw GL calls..
Who told you something like this? OSG is totally capable of using modern 
GLSL. For some legacy support you might need to write appropriate 
visitors, but there is nothing stopping you using modern approaches.



Here is my only advice since I'm not yet finished myself:
My recommendation is just leave that attrib aliasing setting alone; you can use 
modern GL anyway. Just make sure that you use the setVertexAttribute() calls 
instead of setTextureCoords() / setNormals() / etc, and use the same attrib 
location numbering convention as OSG (I believe NVidia's drivers enforce those 
conventions, so you can get the vertex positions at loc=0).
Basically you're duplicating the vertexAttributeAliasing mechanism. 
There might be problems with non-conforming drivers, but in general the 
mapping is fixed on all conforming OpenGL drivers I've used (And the 
mechanism works on a lot of heterogeneous machines)





Then you'll want to get a copy of the ShaderGen class so you can customize  
because you'll likely want to modify it yourself. You can use this code to hook 
into osgDB::readNode()'s behavior to setup your shaders/attribs/etc the way you 
want.
I don't see how this is related to ShaderGen (I suppose you're talking 
about the old class). I strongly suggest to write your own shaders and 
use the setDefine (#pragmatic shader composition) mechanism to create 
shader variations.


Cheers
Sebastian

You then need to set useModelViewUniforms, which seems to be less harmful than 
useVertexAttribAliasing and will make sure osg_ModelViewMatrix is set.


Interested to compare notes on how you go 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=71598#71598





___
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] using modern shaders with osg - setting vertex attribute layout

2017-09-02 Thread Sebastian Messerschmidt


Hi Antiro,

Hi,

I'm still struggling with getting setUseVertexAttributeAliasing(true) to 
combine rendering to textures.

To this end, I made made a tiny change to the osgmultiplerendertargets example 
to see if I could adapt that example to work with 
setUseVertexAttributeAliasing(true).

Aside from adding some lines to view the intermediate textures, my only change 
was enabling VertexAttributeAliasing as follows:


Code:
viewer.realize();
viewer.getCamera()->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(true);
That's interesting. I've just checked my code-base and I definitively 
set up the aliasing very early before adding anything to the scene graph.




Given that the code only uses some fragment shaders, which use fixed colors and 
don't rely on things like gl_Vertex or gl_Normal I assumed no changes to them 
would be needed. Yet enabling VertexAttribute shaders breaks rendering, 
disabling it again fixes it.

Maybe I'm completely misunderstanding the idea behind VertexAttributeAliasing, 
all I want is to reuse the shaders from my other project, which requires 
control over the vertex attribute layout...
If anyone can tell me what I'm doing wrong or has a working example of MRT with 
setUseVertexAttributeAliasing(true), that would be highly appreciated.
Enabling the aliasing will also replace all gl_ things in the shaders 
you pass to the scene graph and it will simple add vertex attributes for 
all default attributes. See the State.cpp resetVertexAttributeAlias for 
reference.
There is no magic involved. Unfortunately I don't have any spare time to 
check your code sample, but I can promise that this definitively working 
without trouble. I've been using MRT with modern shaders for years in my 
deferred pipeline, and I don't recall having any problems at all. If 
you're using NVidia under windows you might consider using NSight to 
check your bindings.

What kind of GPU are you using? I experienced a lot of trouble using Intel.

Cheers
Sebastian


For reference, here is the entire modified code:

Code:

/* OpenSceneGraph example, osgmultiplerendertargets.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

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

#include 
#include 
#include 

#include 

#include 
#include 

#include "RenderingUtility.h" //to easily view intermediate textures
//
// Below is relatively straight forward example of using the OpenGL multiple 
render targets (MRT) extension
// to FrameBufferObjects/GLSL shaders.
//
// Another, more sophisticated MRT example can be found in the osgstereomatch 
example.
//


// The callback modifies an input image.
struct MyCameraPostDrawCallback : public osg::Camera::DrawCallback
{
 MyCameraPostDrawCallback(osg::Image* image):
 _image(image)
 {
 }

 virtual void operator () (const osg::Camera& /*camera*/) const
 {
 if (_image && _image->getPixelFormat()==GL_RGBA && 
_image->getDataType()==GL_UNSIGNED_BYTE)
 {
 // we'll pick out the center 1/2 of the whole image,
 int column_start = _image->s()/4;
 int column_end = 3*column_start;

 int row_start = _image->t()/4;
 int row_end = 3*row_start;

 // and then halve their contribution
 for(int r=row_start; rdata(column_start, r);
 for(int c=column_start; cdirty();
 }
 else if (_image && _image->getPixelFormat()==GL_RGBA && 
_image->getDataType()==GL_FLOAT)
 {
 // we'll pick out the center 1/2 of the whole image,
 int column_start = _image->s()/4;
 int column_end = 3*column_start;

 int 

Re: [osg-users] RayTracedTechnique hangs with Intel HD Graphics - Update

2017-09-02 Thread Julien Valentin
Hi,
it surely is the duplicate of
http://forum.openscenegraph.org/viewtopic.php?t=14304 
I thought this issue was fixed since all this time
The hack i use is there
curious bug indeed, and so curious solution too
@robert
Perhaps it may be merged into master...your call...

cheers


Clement wrote:
> Hi,
> 
> Finally I found where causes the problem.  For some reasons, gl_Vertex is not 
> normalized.  I looked at osg shader source code (src\osgVolume\Shaders).  For 
> example, in file volume_frag.cpp, 
> 
> vec4 t0 = vertexPos;
> vec4 te = cameraPos;
> 
> // by default te did to check the range (0 and 1), but t0 did not.
> // If I added  some codes to check the range, then the problem is completed 
> gone.
> 
> if (t0.x<0.0) t0.x = 0.0; if (t0.x>1.0) t0.x = 1.0; 
> if (t0.y<0.0) t0.y = 0.0; if (t0.y>1.0) t0.y = 1.0; 
> f (t0.z<0.0) t0.z = 0.0; if (t0.z>1.0) t0.z = 1.0; 
> 
> 
> I believe the problem is related to GLSL version and latest Intel HD Graphics 
> driver is using higher version of GLSL, but gl_Vertex does not normalize or 
> the value is just over 1 or less then 0 (eg. 1.1).  Then it causes the 
> crash when running the sampling loop.  I am not an expert on GLSL, so I would 
> like to confirm the best solution to handle this problem. Thanks.
> 
> 
> Regards,
> Clement Chu
> 
> 
> From: osg-users <> on behalf of  <>
> Sent: Wednesday, 30 August 2017 17:31
> To: 
> Subject: [ExternalEmail]  RayTracedTechnique hangs with Intel HD Graphics
> 
> Hi,
> 
> My program uses RayTracedTechnique for volume rendering, but it hangs with 
> Intel HD graphics 520, 530 and 620. My old laptop works fine which is using 
> Intel HD Graphic 3000.  Other machines with Nvidia cards are working fine 
> too.  I believe the problem is on shaders in the sampling loop.  My program 
> is using osg 3.2.3.  I also tried to upgrade to osg 3.4.1, but the same 
> problem occurred with Intel HD Graphic 520, 530 and 620.  Do anyone have 
> similar problem and any solution to fix it?  Many thanks.
> 
> 
> Regards,
> Clement Chu
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum


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





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


Re: [osg-users] RayTracedTechnique hangs with Intel HD Graphics - Update

2017-09-02 Thread Julien Valentin
Hi,
it surely is the duplicate of
http://forum.openscenegraph.org/viewtopic.php?t=14304 
I thought this issue was fixed since all this time
The hack i use is there
curious bug indeed, and so curious solution too
@robert
Perhaps it may be merged into master...your call...

cheers


Clement wrote:
> Hi,
> 
> Finally I found where causes the problem.  For some reasons, gl_Vertex is not 
> normalized.  I looked at osg shader source code (src\osgVolume\Shaders).  For 
> example, in file volume_frag.cpp, 
> 
> vec4 t0 = vertexPos;
> vec4 te = cameraPos;
> 
> // by default te did to check the range (0 and 1), but t0 did not.
> // If I added  some codes to check the range, then the problem is completed 
> gone.
> 
> if (t0.x<0.0) t0.x = 0.0; if (t0.x>1.0) t0.x = 1.0; 
> if (t0.y<0.0) t0.y = 0.0; if (t0.y>1.0) t0.y = 1.0; 
> f (t0.z<0.0) t0.z = 0.0; if (t0.z>1.0) t0.z = 1.0; 
> 
> 
> I believe the problem is related to GLSL version and latest Intel HD Graphics 
> driver is using higher version of GLSL, but gl_Vertex does not normalize or 
> the value is just over 1 or less then 0 (eg. 1.1).  Then it causes the 
> crash when running the sampling loop.  I am not an expert on GLSL, so I would 
> like to confirm the best solution to handle this problem. Thanks.
> 
> 
> Regards,
> Clement Chu
> 
> 
> From: osg-users <> on behalf of  <>
> Sent: Wednesday, 30 August 2017 17:31
> To: 
> Subject: [ExternalEmail]  RayTracedTechnique hangs with Intel HD Graphics
> 
> Hi,
> 
> My program uses RayTracedTechnique for volume rendering, but it hangs with 
> Intel HD graphics 520, 530 and 620. My old laptop works fine which is using 
> Intel HD Graphic 3000.  Other machines with Nvidia cards are working fine 
> too.  I believe the problem is on shaders in the sampling loop.  My program 
> is using osg 3.2.3.  I also tried to upgrade to osg 3.4.1, but the same 
> problem occurred with Intel HD Graphic 520, 530 and 620.  Do anyone have 
> similar problem and any solution to fix it?  Many thanks.
> 
> 
> Regards,
> Clement Chu
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum


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





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


Re: [osg-users] RayTracedTechnique hangs with Intel HD Graphics - Update

2017-09-02 Thread Julien Valentin
http://forum.openscenegraph.org/viewtopic.php?t=14304 


Clement wrote:
> Hi,
> 
> Finally I found where causes the problem.  For some reasons, gl_Vertex is not 
> normalized.  I looked at osg shader source code (src\osgVolume\Shaders).  For 
> example, in file volume_frag.cpp, 
> 
> vec4 t0 = vertexPos;
> vec4 te = cameraPos;
> 
> // by default te did to check the range (0 and 1), but t0 did not.
> // If I added  some codes to check the range, then the problem is completed 
> gone.
> 
> if (t0.x<0.0) t0.x = 0.0; if (t0.x>1.0) t0.x = 1.0; 
> if (t0.y<0.0) t0.y = 0.0; if (t0.y>1.0) t0.y = 1.0; 
> f (t0.z<0.0) t0.z = 0.0; if (t0.z>1.0) t0.z = 1.0; 
> 
> 
> I believe the problem is related to GLSL version and latest Intel HD Graphics 
> driver is using higher version of GLSL, but gl_Vertex does not normalize or 
> the value is just over 1 or less then 0 (eg. 1.1).  Then it causes the 
> crash when running the sampling loop.  I am not an expert on GLSL, so I would 
> like to confirm the best solution to handle this problem. Thanks.
> 
> 
> Regards,
> Clement Chu
> 
> 
> From: osg-users <> on behalf of  <>
> Sent: Wednesday, 30 August 2017 17:31
> To: 
> Subject: [ExternalEmail]  RayTracedTechnique hangs with Intel HD Graphics
> 
> Hi,
> 
> My program uses RayTracedTechnique for volume rendering, but it hangs with 
> Intel HD graphics 520, 530 and 620. My old laptop works fine which is using 
> Intel HD Graphic 3000.  Other machines with Nvidia cards are working fine 
> too.  I believe the problem is on shaders in the sampling loop.  My program 
> is using osg 3.2.3.  I also tried to upgrade to osg 3.4.1, but the same 
> problem occurred with Intel HD Graphic 520, 530 and 620.  Do anyone have 
> similar problem and any solution to fix it?  Many thanks.
> 
> 
> Regards,
> Clement Chu
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum


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





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


Re: [osg-users] using modern shaders with osg - setting vertex attribute layout

2017-09-02 Thread antiro black
Hi,

I'm still struggling with getting setUseVertexAttributeAliasing(true) to 
combine rendering to textures.

To this end, I made made a tiny change to the osgmultiplerendertargets example 
to see if I could adapt that example to work with 
setUseVertexAttributeAliasing(true).

Aside from adding some lines to view the intermediate textures, my only change 
was enabling VertexAttributeAliasing as follows: 


Code:
viewer.realize();
viewer.getCamera()->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(true);




Given that the code only uses some fragment shaders, which use fixed colors and 
don't rely on things like gl_Vertex or gl_Normal I assumed no changes to them 
would be needed. Yet enabling VertexAttribute shaders breaks rendering, 
disabling it again fixes it.

Maybe I'm completely misunderstanding the idea behind VertexAttributeAliasing, 
all I want is to reuse the shaders from my other project, which requires 
control over the vertex attribute layout...
If anyone can tell me what I'm doing wrong or has a working example of MRT with 
setUseVertexAttributeAliasing(true), that would be highly appreciated. 

For reference, here is the entire modified code:

Code:

/* OpenSceneGraph example, osgmultiplerendertargets.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

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

#include 
#include 
#include 

#include 

#include 
#include 

#include "RenderingUtility.h" //to easily view intermediate textures
//
// Below is relatively straight forward example of using the OpenGL multiple 
render targets (MRT) extension
// to FrameBufferObjects/GLSL shaders.
//
// Another, more sophisticated MRT example can be found in the osgstereomatch 
example.
//


// The callback modifies an input image.
struct MyCameraPostDrawCallback : public osg::Camera::DrawCallback
{
MyCameraPostDrawCallback(osg::Image* image):
_image(image)
{
}

virtual void operator () (const osg::Camera& /*camera*/) const
{
if (_image && _image->getPixelFormat()==GL_RGBA && 
_image->getDataType()==GL_UNSIGNED_BYTE)
{
// we'll pick out the center 1/2 of the whole image,
int column_start = _image->s()/4;
int column_end = 3*column_start;

int row_start = _image->t()/4;
int row_end = 3*row_start;

// and then halve their contribution
for(int r=row_start; rdata(column_start, r);
for(int c=column_start; cdirty();
}
else if (_image && _image->getPixelFormat()==GL_RGBA && 
_image->getDataType()==GL_FLOAT)
{
// we'll pick out the center 1/2 of the whole image,
int column_start = _image->s()/4;
int column_end = 3*column_start;

int row_start = _image->t()/4;
int row_end = 3*row_start;

// and then halve their contribution
for(int r=row_start; rdata(column_start, r);
for(int c=column_start; cdirty();

//print out the first three values
float* data = (float*)_image->data(0, 0);
fprintf(stderr,"Float pixel data: r %e g %e b %e\n", data[0], 
data[1], data[2]);
}
}

osg::Image* _image;
};

#define NUM_TEXTURES 4

// The quad geometry is used by the render to texture 

Re: [osg-users] using modern shaders with osg - setting vertex attribute layout

2017-09-02 Thread Robert Osfield
Hi Chris,

On 2 September 2017 at 03:40, Chris Kuliukas  wrote:

> It seems crazy that the official advice is to write shaders and use OSG
> just like legacy GL, and OSG will then change your shader code and
> reinterpret deprecated calls to make it work via "modern" GL: Obviously in
> years to come when GL newcomers want to use OSG the official line can't be
> "learn how GL was 20 years ago, write your OSG code like that, and the
> system will make it work".
>

No one has suggested you should learn how GL was 20  years ago.  Pure BS.
Please leave such nonsense off the list/forum as it doesn't help anyone.

What has been suggested is that the OSG's management of mdelview and
projection matrices works well for both fixed function and shaders, the OSG
is a scene graph it does lots of helpful stuff for application developers,
one of these useful things is it's management of modelview and projection
matrices.

If you are fighting against this design that doesn't fit with your
preconceptions then this is likely why you are struggling.  Once you stop
trying to fit the OSG around think it should work and leverage it's power
then things should be easier.

Lots of people use the OSG with shaders and have done for well over a
decade - the OSG actually support GLSL even before the ARB officially
released it (3DLabs used the OSG as a testbed).  OpenGL has evolved a lot
since the early days of GLSL and the OSG with it,  Both continue to evolve.


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


Re: [osg-users] using modern shaders with osg - setting vertex attribute layout

2017-09-02 Thread antiro black
Hi,

When using the shaders to render only one of  color/normal/position to a normal 
viewer/camera (not to a texture) they all seem to work.

I continued to modify a small MRT example which used older shader code which 
relied on gl_Vertex / gl_Normal etc. The moment I added a 
setUseVertexAttributeAliasing(true) it stopped working even with changes to the 
shader which replaced gl_Vertex with osg_Vertex etc.

I could not find any MRT / deferred rendering code online which uses more 
modern glsl and setUseVertexAttributeAliasing(true).

My main question now is: Do you (or anyone else) happen to have some 
example code for multi-target rendering which uses 
setUseVertexAttributeAliasing(true) ?

In response to ckuliukas: Is that really the official advice? My other project 
was already using modern GLSL and can't be converted back to ancient glsl 
easily (nor do I want to). Perhaps I'll have a look at your suggestion if all 
else fails. I'm still hoping I can reuse the existing shaders with minimal 
changes. 

In general my experience with OSG is that the code is well organized and pretty 
easy to read, however there is a real lack of documentation, both with regards 
to comments in the code and in the form of an (up to date) wiki / manual / etc. 
I don't mind a learning curve, but I have no idea where to start. Reading 
through the osg quick start guide didn't get me anywhere and the few recipes in 
the OSG cookbook which touched upon more advanced opengl using shaders were 
using ancient GLSL code. If anyone has some advice with regards to other 
learning resources focussed on more advanced usage that would be very helpful.

Thanks in advance!

Cheers,
antiro

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





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