date:20170901

Re: [osg-users] CullVisitor::apply(Geode&) detected NaN,

2017-09-01 Thread Chris Kuliukas

I would run your app in debug mode, break in CullVisitor::apply(osg::Geode), 
then take a look at the matrix stacks and see where the nans are coming from


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=71600#71600





___
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

2017-09-01 Thread 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(, 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] using modern shaders with osg - setting vertex attribute layout

2017-09-01 Thread Chris Kuliukas

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


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

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.

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

Re: [osg-users] LIDAR plugin

2017-09-01 Thread Michael W. Hall

I saw the pluging building during the build process.  What is the name
and where would it have been installed?  I will double check.  I am
running Ubuntu.
Thanks.
On Thu, 2017-08-31 at 22:07 -0600, Chris Hanson wrote:
> LAZ is a compressed variant of LAS.
> 
> Refer to this for how to convert to LAS: https://gis.stackexchange.co
> m/questions/188170/converting-lidar-files-from-laz-to-las-format
> 
> On Thu, Aug 31, 2017 at 7:48 PM, Michael W. Hall 
> wrote:
> > I have OSG 3.4.0 installed.  I have some LIDAR Data and when is
> > type:
> > 
> > osgviewer  
> > 
> > I get a message saying that it cannot find a plugin for the data. 
> > The
> > data has a .laz extension, but it looks like the plugin is looking
> > for
> > las extension.  I renamed the files with a .las extension and still
> > did not work.
> > 
> > Anyone using the LIDAR plugin that can tell me what I am doing
> > wrong? 
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraphorg/listinfo.cgi/osg-users-openscenegrap
> > h.org
> > 
> 
> 
> -- 
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://
> www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 •
> OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
> osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded •
> Mobile • iPhone/iPad/iOS • Android
> @alphapixel facebook.com/alphapixel (775) 623-PIXL [7495]
> ___
> 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] LIDAR plugin

2017-09-01 Thread Michael W. Hall

Thanks for the reply.  I have the files converted to .las now.  
Still when I do osgviewer Hoboken_001,las  I get the same error about
no plugin.  I have also tried osgviewer -e .las  and not luck
either.  I can see that the plugin is built.  
Here is the actual output:
Warning: Could not find plugin to read objects from file
"Hoboken_001.las".
Looks like osgviewer is looking for the plugin but for some reason
cannot find it.
On Thu, 2017-08-31 at 22:07 -0600, Chris Hanson wrote:
> LAZ is a compressed variant of LAS.
> 
> Refer to this for how to convert to LAS: https://gis.stackexchange.co
> m/questions/188170/converting-lidar-files-from-laz-to-las-format
> 
> On Thu, Aug 31, 2017 at 7:48 PM, Michael W. Hall 
> wrote:
> > I have OSG 3.4.0 installed.  I have some LIDAR Data and when is
> > type:
> > 
> > osgviewer  
> > 
> > I get a message saying that it cannot find a plugin for the data. 
> > The
> > data has a .laz extension, but it looks like the plugin is looking
> > for
> > las extension.  I renamed the files with a .las extension and still
> > did not work.
> > 
> > Anyone using the LIDAR plugin that can tell me what I am doing
> > wrong? 
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraphorg/listinfo.cgi/osg-users-openscenegrap
> > h.org
> > 
> 
> 
> -- 
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://
> www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 •
> OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
> osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded •
> Mobile • iPhone/iPad/iOS • Android
> @alphapixel facebook.com/alphapixel (775) 623-PIXL [7495]
> ___
> 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-01 Thread Julien Valentin

Hi Rômulo
If it can help,
I believe to remember to have spotted potential 0 division in osgGA
locate unguarded  /sin() or /cos in osgGA
and add guard case like 
Code:
if (sin()<10e-4)OSG_WARN<< "0 division detected";


see if your problem come from here and post your result here
cheers

romulogcerqueira wrote:
> Hi,
> 
> I have the following message when I run my OSG application:
> 
> 
> Code:
> 
> CullVisitor::apply(Geode&) detected NaN,
> depth=nan, center=(1.79588 1.50488 1.42179),
> matrix={
> nan nan -nan -nan 
> nan nan -nan -nan 
> nan nan -nan -nan 
> nan nan -nan -nan 
> }
> 
> 
> 
> 
> 
> What this kind of warning/error means?
> ... 
> 
> Thank you!
> 
> Cheers,
> Rômulo


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





___
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-01 Thread Robert Osfield

Hi Romulo,

There is a lot of code in there which I wouldn't expect to affect the
modelview and project matrices, my recommendation would be to create a
small test example to test loading your data and setting your view and
projection matrices as required without any of the frame capture code that
will be getting in the way of working out what might be amiss.

You code also nothing about your scene graph, as this might well be the
source of the issue there isn't much more we can guess at.

The best thing you can do at this point is go test your models against a
standard example like osgviewer.  If the error occurs there then posting
this so others can try and reproduce the problem.

Robert.


On 1 September 2017 at 16:10, Rômulo Cerqueira 
wrote:

> Ok Robert,
>
> this is my current code (only .cpp):
>
>
> Code:
>
> #include "ImageViewerCaptureTool.hpp"
> #include 
> #include 
> #include 
>
> namespace normal_depth_map {
>
> ImageViewerCaptureTool::ImageViewerCaptureTool(uint width, uint height) {
>
> // initialize the hide viewer;
> initializeProperties(width, height);
> }
>
> ImageViewerCaptureTool::ImageViewerCaptureTool( double fovY, double fovX,
> uint value, bool isHeight) {
> uint width, height;
>
> if (isHeight) {
> height = value;
> width = height * tan(fovX * 0.5) / tan(fovY * 0.5);
> } else {
> width = value;
> height = width * tan(fovY * 0.5) / tan(fovX * 0.5);
> }
>
> double aspectRatio = width * 1.0 / height;
>
> initializeProperties(width, height);
> _viewer->getCamera()->setComputeNearFarMode(osg::
> CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
>
> _viewer->getCamera()->setProjectionMatrixAsPerspective(fovY * 180.0 /
> M_PI, aspectRatio, 0.1, 1000);
> }
>
> void ImageViewerCaptureTool::initializeProperties(uint width, uint
> height) {
> // initialize the hide viewer;
> _viewer = new osgViewer::Viewer;
> osg::Camera *camera = this->_viewer->getCamera();
> osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
> traits->width = width;
> traits->height = height;
> traits->pbuffer = true;
> traits->readDISPLAY();
> osg::ref_ptr gc = osg::GraphicsContext::
> createGraphicsContext(traits.get());
> camera->setGraphicsContext(gc);
> camera->setDrawBuffer(GL_FRONT);
> camera->setViewport(new osg::Viewport(0, 0, width, height));
>
> // initialize the class to get the image in float data resolution
> _capture = new WindowCaptureScreen(gc);
> _viewer->getCamera()->setFinalDrawCallback(_capture);
> }
>
> osg::ref_ptr ImageViewerCaptureTool::
> grabImage(osg::ref_ptr node ) {
>
> _viewer->setSceneData(node);
> _viewer->frame();
> return _capture->captureImage();;
> }
>
> osg::ref_ptr ImageViewerCaptureTool::getDepthBuffer() {
> return _capture->getDepthBuffer();
> }
>
>
> void ImageViewerCaptureTool::setCameraPosition( const osg::Vec3d& eye,
> const osg::Vec3d& center, const osg::Vec3d& up) {
> _viewer->getCamera()->setViewMatrixAsLookAt(eye, center, up);
> }
>
> void ImageViewerCaptureTool::getCameraPosition( osg::Vec3d&
> eye,osg::Vec3d& center, osg::Vec3d& up) {
> _viewer->getCamera()->getViewMatrixAsLookAt(eye, center, up);
> }
>
> void ImageViewerCaptureTool::setBackgroundColor(osg::Vec4d color) {
> _viewer->getCamera()->setClearColor(color);
> }
>
> 
> WindowCaptureScreen METHODS
> 
>
> WindowCaptureScreen::WindowCaptureScreen(osg::ref_ptr
> gc) {
> _mutex = new OpenThreads::Mutex();
> _condition = new OpenThreads::Condition();
> _image = new osg::Image();
> _depth_buffer = new osg::Image();
>
> // checks the GraficContext from the camera viewer
> if (gc->getTraits()) {
>
> GLenum pixelFormat;
> if (gc->getTraits()->alpha) pixelFormat = GL_RGBA;
> else pixelFormat = GL_RGB;
>
> int width = gc->getTraits()->width;
> int height = gc->getTraits()->height;
>
> // allocates the image memory space
> _image->allocateImage(width, height, 1, pixelFormat, GL_FLOAT);
> _depth_buffer->allocateImage(width, height, 1, GL_DEPTH_COMPONENT,
> GL_FLOAT);
> }
> }
>
> WindowCaptureScreen::~WindowCaptureScreen() {
> delete (_condition);
> delete (_mutex);
> }
>
> osg::ref_ptr WindowCaptureScreen::captureImage() {
>
> //wait to finish the capture image in call back
> _condition->wait(_mutex);
> return _image;
> }
>
> osg::ref_ptr WindowCaptureScreen::getDepthBuffer() {
> return _depth_buffer;
> }
>
>
> void WindowCaptureScreen::operator ()(osg::RenderInfo& renderInfo) const {
> osg::ref_ptr gc = renderInfo.getState()->
> getGraphicsContext();
> if (gc->getTraits()) {
> _mutex->lock();
> _image->readPixels( 0, 0, _image->s(), _image->t(),
> _image->getPixelFormat(), GL_FLOAT);
> _depth_buffer->readPixels(0, 0, _image->s(), _image->t(),
> _depth_buffer->getPixelFormat(), GL_FLOAT);
>
> //grants the access to image
> _condition->signal();
> _mutex->unlock();
> }
> }
>
> }
>
>
>
>
>
> ...
>
> Thank you!
>
> Cheers,
> Rômulo
>
> --
> Read this topic online here:
>

Re: [osg-users] CullVisitor::apply(Geode&) detected NaN,

2017-09-01 Thread Rômulo Cerqueira

Ok Robert,

this is my current code (only .cpp):


Code:

#include "ImageViewerCaptureTool.hpp"
#include 
#include 
#include 

namespace normal_depth_map {

ImageViewerCaptureTool::ImageViewerCaptureTool(uint width, uint height) {

// initialize the hide viewer;
initializeProperties(width, height);
}

ImageViewerCaptureTool::ImageViewerCaptureTool( double fovY, double fovX, uint 
value, bool isHeight) {
uint width, height;

if (isHeight) {
height = value;
width = height * tan(fovX * 0.5) / tan(fovY * 0.5);
} else {
width = value;
height = width * tan(fovY * 0.5) / tan(fovX * 0.5);
}

double aspectRatio = width * 1.0 / height;

initializeProperties(width, height);
_viewer->getCamera()->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

_viewer->getCamera()->setProjectionMatrixAsPerspective(fovY * 180.0 / M_PI, 
aspectRatio, 0.1, 1000);
}

void ImageViewerCaptureTool::initializeProperties(uint width, uint height) {
// initialize the hide viewer;
_viewer = new osgViewer::Viewer;
osg::Camera *camera = this->_viewer->getCamera();
osg::ref_ptr traits = new 
osg::GraphicsContext::Traits;
traits->width = width;
traits->height = height;
traits->pbuffer = true;
traits->readDISPLAY();
osg::ref_ptr gc = 
osg::GraphicsContext::createGraphicsContext(traits.get());
camera->setGraphicsContext(gc);
camera->setDrawBuffer(GL_FRONT);
camera->setViewport(new osg::Viewport(0, 0, width, height));

// initialize the class to get the image in float data resolution
_capture = new WindowCaptureScreen(gc);
_viewer->getCamera()->setFinalDrawCallback(_capture);
}

osg::ref_ptr 
ImageViewerCaptureTool::grabImage(osg::ref_ptr node ) {

_viewer->setSceneData(node);
_viewer->frame();
return _capture->captureImage();;
}

osg::ref_ptr ImageViewerCaptureTool::getDepthBuffer() {
return _capture->getDepthBuffer();
}


void ImageViewerCaptureTool::setCameraPosition( const osg::Vec3d& eye, const 
osg::Vec3d& center, const osg::Vec3d& up) {
_viewer->getCamera()->setViewMatrixAsLookAt(eye, center, up);
}

void ImageViewerCaptureTool::getCameraPosition( osg::Vec3d& eye,osg::Vec3d& 
center, osg::Vec3d& up) {
_viewer->getCamera()->getViewMatrixAsLookAt(eye, center, up);
}

void ImageViewerCaptureTool::setBackgroundColor(osg::Vec4d color) {
_viewer->getCamera()->setClearColor(color);
}


WindowCaptureScreen METHODS


WindowCaptureScreen::WindowCaptureScreen(osg::ref_ptr gc) 
{
_mutex = new OpenThreads::Mutex();
_condition = new OpenThreads::Condition();
_image = new osg::Image();
_depth_buffer = new osg::Image();

// checks the GraficContext from the camera viewer
if (gc->getTraits()) {

GLenum pixelFormat;
if (gc->getTraits()->alpha) pixelFormat = GL_RGBA;
else pixelFormat = GL_RGB;

int width = gc->getTraits()->width;
int height = gc->getTraits()->height;

// allocates the image memory space
_image->allocateImage(width, height, 1, pixelFormat, GL_FLOAT);
_depth_buffer->allocateImage(width, height, 1, GL_DEPTH_COMPONENT, GL_FLOAT);
}
}

WindowCaptureScreen::~WindowCaptureScreen() {
delete (_condition);
delete (_mutex);
}

osg::ref_ptr WindowCaptureScreen::captureImage() {

//wait to finish the capture image in call back
_condition->wait(_mutex);
return _image;
}

osg::ref_ptr WindowCaptureScreen::getDepthBuffer() {
return _depth_buffer;
}


void WindowCaptureScreen::operator ()(osg::RenderInfo& renderInfo) const {
osg::ref_ptr gc = 
renderInfo.getState()->getGraphicsContext();
if (gc->getTraits()) {
_mutex->lock();
_image->readPixels( 0, 0, _image->s(), _image->t(), _image->getPixelFormat(), 
GL_FLOAT);
_depth_buffer->readPixels(0, 0, _image->s(), _image->t(), 
_depth_buffer->getPixelFormat(), GL_FLOAT);

//grants the access to image
_condition->signal();
_mutex->unlock();
}
}

}





... 

Thank you!

Cheers,
Rômulo

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





___
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-01 Thread antiro black

Hi Sebastian,

I'm using the latest stable version from git (which is indeed 3.4.something).
I applied it to the camera of the viewer. Should I have also changed the state 
of the camera's which are used to render to the textures (they are part of the 
scenegraph of the viewer)?

After trying every imaginable change the shaders I've started to suspect that 
that there is something wrong with (my usage of) the EffectCompositor recipe 
from the OSG Cookbook, which I'm using to load the shaders and compile the 
shader program. Hence I'm now changing the code to create the osg::Program and 
load the osg::Shaders manually.



Thank you!

Cheers,
antiro

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





___
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-01 Thread Robert Osfield

HI Clement,

On 1 September 2017 at 10:26,  wrote:

>   Since I don't know how to debug or print message in shader code, I am
> not sure what exact value of vertex.  I guess the value of vertex is not in
> the range (0.0 to 1.0), so texture3D method cannot get correct color value
> by coordinate.  In file volume_frag.cpp,  variable texcoord is assigned
> from vertex data. If vertex data is not the 0.0f to 1.0f range, variable
> color (type vec4) will become strange value.  Even I added some codes
> to make sure values of color.x, color.y, color.z and color.w  in the range
> (0.0 to 1.0), it still cause the crash. Unless vertex is in the range (0.0
> to 1.0). So far, this problem occurs in Intel HD Graphics 520 or above.  My
> old laptop is Intel HD Graphics 3000, but it works fine and Nvidia cards
> work fine too.
>

Debugging shaders is *really* hard because you just can't put in break
points, print out values, do any of the normal debugging approaches we take
for granted on the desktop.  So it's a case of think of idea what might be
wrong, adapt the shaders to test that, run them app and just and make sense
of the results.

The fact that shaders can be loaded and compiled at runtime helps reduce
the time takes to see changes so this can help a bit, for yourself I would
certainly recommend copying the volume.vert and volume.frag shaders from
OpenSceneGraph-Data, put  them on your path as use in testing.

Another thing that might help if you are having to put "workaround" code in
just for a certain hardware vendor then the vendor string and #pragma(tic)
shader composition might be of help.  I use this facility to detect and
provide a workaround for an NVidia issue - look at how NVIDIA_Corporation
is used in the shaders.  The osg::State object checks the GL_VENDOR string
at runtime and sets a #define with this value that you can then reference
using #pragma import_defines(..).

I don't know what the string will be for Intel.  Run an OSG application
with the OSG_NOTIFY_LEVEL set to INFO and search the console output for a
"GL_VENDOR = " entry.  You can they use this in the shader mods.

--

On the specific issue of the vertex value clamping, RayTracedTechnique
creates a box with dimensons of 0,0,0 to 1,1,1 so there shouldn't be any
values outside this being passed to the vertex shader. However, the
CPU->driver->GPU might be changing the precision enough that you are
getting values outside this range.  I find it odd that the shaders would be
sensitive to such small precision issues though.

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-01 Thread Sebastian Messerschmidt


Hi Antiro,

I don't have an idea why it is not working.
For which camera's state set did you enable it?
Have you tried to check this with a simplistic non-MRT/FBO setup?
Which OSG-Version do you use (its working with 3.4.x definitively)

I've been using this for years, so there must be some error somewhere else.

Cheers
Sebastian

Hi Sebastian,

I was under the impression that the "layout(...) in ..." command was 
essentially a variable declaration and that hence only the location and type needed to 
match. I now also changed the name, this does not seem to have any effect though..

new vertex shader code:

Code:
#version 330 core
layout(location = 0) in vec4 osg_Vertex;
layout(location = 1) in vec3 osg_Normal;
layout(location = 2) in vec4 osg_Color;
layout(location = 3)in vec4 osg_MultiTexCoord0;
layout(location = 4)in vec4 osg_MultiTexCoord1;
layout(location = 5)in vec4 osg_MultiTexCoord2;
layout(location = 6)in vec4 osg_MultiTexCoord3;
layout(location = 7)in vec4 osg_MultiTexCoord4;
layout(location = 8)in vec4 osg_MultiTexCoord5;
layout(location = 9)in vec4 osg_MultiTexCoord6;
layout(location = 10)in vec4 osg_MultiTexCoord7;

out vec3 Normal;
out vec2 TexCoords;
out vec3 WorldPos;

uniform mat4 osg_ModelViewMatrix;
uniform mat3 osg_NormalMatrix;
uniform mat4 osg_ProjectionMatrix;


void main()
{
 gl_Position = osg_ProjectionMatrix * osg_ModelViewMatrix * osg_Vertex;
 WorldPos = (osg_ModelViewMatrix * osg_Vertex).xyz;
 Normal = osg_NormalMatrix * osg_Normal;
 TexCoords = osg_MultiTexCoord0.xy;

}



If I use the shader without the UseVertexAttributeAliasing enabled I see red 
silhouettes for the different models, when looking at the normals texture output (as 
if all normals are <1,0,0> ), which I expect is caused by the shader reading 
wrong  on unitialized attributes.

with UseVertexAttributeAliasing enabled I get no output.



Thank you!

Cheers,
antiro

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





___
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-01 Thread antiro black

Hi Sebastian,

I was under the impression that the "layout(...) in ..." command was 
essentially a variable declaration and that hence only the location and type 
needed to match. I now also changed the name, this does not seem to have any 
effect though..

new vertex shader code:

Code:
#version 330 core
layout(location = 0) in vec4 osg_Vertex;
layout(location = 1) in vec3 osg_Normal;
layout(location = 2) in vec4 osg_Color;
layout(location = 3)in vec4 osg_MultiTexCoord0;
layout(location = 4)in vec4 osg_MultiTexCoord1;
layout(location = 5)in vec4 osg_MultiTexCoord2;
layout(location = 6)in vec4 osg_MultiTexCoord3;
layout(location = 7)in vec4 osg_MultiTexCoord4;
layout(location = 8)in vec4 osg_MultiTexCoord5;
layout(location = 9)in vec4 osg_MultiTexCoord6;
layout(location = 10)in vec4 osg_MultiTexCoord7;

out vec3 Normal;
out vec2 TexCoords;
out vec3 WorldPos;

uniform mat4 osg_ModelViewMatrix;
uniform mat3 osg_NormalMatrix;
uniform mat4 osg_ProjectionMatrix;


void main()
{
gl_Position = osg_ProjectionMatrix * osg_ModelViewMatrix * osg_Vertex;
WorldPos = (osg_ModelViewMatrix * osg_Vertex).xyz;
Normal = osg_NormalMatrix * osg_Normal;
TexCoords = osg_MultiTexCoord0.xy;

}



If I use the shader without the UseVertexAttributeAliasing enabled I see red 
silhouettes for the different models, when looking at the normals texture 
output (as if all normals are <1,0,0> ), which I expect is caused by the shader 
reading wrong  on unitialized attributes.

with UseVertexAttributeAliasing enabled I get no output.



Thank you!

Cheers,
antiro

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





___
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-01 Thread Sebastian Messerschmidt


Hi Antiro,> Hi Sebastian,


Thanks for the quick response. The osg_XXX matrices work perfectly. The 
setUseVertexAttributeAliasing() however does not seem to work. Where I had some 
output before, now don't get anything with it enabled

Does osg always give the exact layout which you posted? or is this dependent on 
the data that is loaded?

for refence, here is a stripped down version of a geometry pass which I'm 
currently testing with (all 3 outputs are black with the attributeAliasing 
turned on):




Your code doesn't use the osg_ prefixed aliases at all. You really need 
to make the name and slot match...


Cheers
Sebastian
___
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-01 Thread antiro black

Hi Sebastian,

Thanks for the quick response. The osg_XXX matrices work perfectly. The 
setUseVertexAttributeAliasing() however does not seem to work. Where I had some 
output before, now don't get anything with it enabled

Does osg always give the exact layout which you posted? or is this dependent on 
the data that is loaded? 

for refence, here is a stripped down version of a geometry pass which I'm 
currently testing with (all 3 outputs are black with the attributeAliasing 
turned on):


Code:
#version 330 core
layout (location = 0) in vec4 position;
layout (location = 1) in vec3 normal;
layout (location = 2) in vec4 color;
layout (location = 3) in vec4 texCoords;

/*OSG input layout
layout(location = 0) in vec4 osg_Vertex;
layout(location = 1) in vec3 osg_Normal;
layout(location = 2) in vec4 osg_Color;
layout(location = 3)in vec4 osg_MultiTexCoord0;
layout(location = 4)in vec4 osg_MultiTexCoord1;*/

out vec3 Normal;
out vec2 TexCoords;
out vec3 WorldPos;

uniform mat4 osg_ModelViewMatrix;
uniform mat3 osg_NormalMatrix;
uniform mat4 osg_ProjectionMatrix;


void main()
{
gl_Position = osg_ProjectionMatrix * osg_ModelViewMatrix * position;
WorldPos = (osg_ModelViewMatrix * position).xyz;
Normal = osg_NormalMatrix * normal;
TexCoords = texCoords.xy;
}



and the fragment shader:

Code:
#version 330

in vec2 TexCoords;
in vec3 Normal;
in vec3 WorldPos;

layout (location = 0) out vec3 gWorldPos;
layout (location = 1) out vec4 gColorSpec;
layout (location = 2) out vec3 gNormalOut;

uniform vec3 gDiffuseColor=vec3(1,0,0);

void main()
{
gWorldPos = WorldPos;
gColorSpec.rgb=gDiffuseColor;
gNormalOut = normalize(Normal);
}



For the actual creation and compilation of the shader program I'm using the 
EffectCompositor recipe from the OSG cookbook.

Thank you!

Cheers,
antiro[/code]

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





___
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-01 Thread Sebastian Messerschmidt



Hi Antiro,


Hi,

I am converting a project written in pure opengl to use OSG to improve 
compatibility and reduce maintenance.  The original project used a deferred 
rendering pipeline with a pretty big set of custom shaders. I would like to 
reuse these shaders with minimum adjustments.

In order to do this I want to use the same uniform names and the same layout 
for the VAO. I figured out that I can add callbacks to set the ModelView / 
Projection / etc matrices to uniforms with the same names as used in in the 
shaders, so that is taken care of.

I do however not know how to specify the vertex attribute layout. My shaders 
all start with the following:
#version 330 core //so can't use gl_Normal etc
layout(location = 0) in vec3 position
layout(location = 1) in vec3 normal
layout(location = 2) in vec2 texCoords
layout(location = 

I'm currently just using osgDB::readNodeFile() to read in the geometry and I'm 
assuming I need to do something more sophisticated to control how the vertex 
attributes are organized, but have been unable to figure out what.

If anyone could point me in the right direction, that would be most helpful!


The easiest way is to convert the shaders to use the osg_ -prefix and to 
turn on the vertex attribute aliasing (basically all OSG will provide 
all gl_ inputs)


A list:

//OSG inputs
layout(location = 0) in vec4 osg_Vertex;
layout(location = 1) in vec3 osg_Normal;
layout(location = 2) in vec4 osg_Color;
layout(location = 3)in vec4 osg_MultiTexCoord0;
layout(location = 4)in vec4 osg_MultiTexCoord1;
layout(location = 5)in vec4 osg_MultiTexCoord2;
layout(location = 6)in vec4 osg_MultiTexCoord3;
layout(location = 7)in vec4 osg_MultiTexCoord4;
layout(location = 8)in vec4 osg_MultiTexCoord5;
layout(location = 9)in vec4 osg_MultiTexCoord6;
layout(location = 10)in vec4 osg_MultiTexCoord7;


In order to turn on aliasing:

viewer->getCamera()->getGraphicsContext()->getState()->setUseModelViewAndProjectionUniforms(true);
viewer->getCamera()->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(true);

Note, that the first line will set up the gl_XYZMatrix aliases, so no 
need for a custom callback for this (at least for the std-matrices)


So you get these:
uniform mat4 osg_ModelViewProjectionMatrix;
uniform mat4 osg_ModelViewMatrix;
uniform mat4 osg_ViewMatrixInverse;
uniform mat3 osg_NormalMatrix;
uniform mat4 osg_ViewMatrix;
etc.

Cheers
Sebastian





Thank you!

Cheers,
antiro

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





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

2017-09-01 Thread antiro black

Hi,

I am converting a project written in pure opengl to use OSG to improve 
compatibility and reduce maintenance.  The original project used a deferred 
rendering pipeline with a pretty big set of custom shaders. I would like to 
reuse these shaders with minimum adjustments.

In order to do this I want to use the same uniform names and the same layout 
for the VAO. I figured out that I can add callbacks to set the ModelView / 
Projection / etc matrices to uniforms with the same names as used in in the 
shaders, so that is taken care of. 

I do however not know how to specify the vertex attribute layout. My shaders 
all start with the following:
#version 330 core //so can't use gl_Normal etc
layout(location = 0) in vec3 position
layout(location = 1) in vec3 normal
layout(location = 2) in vec2 texCoords
layout(location = 

I'm currently just using osgDB::readNodeFile() to read in the geometry and I'm 
assuming I need to do something more sophisticated to control how the vertex 
attributes are organized, but have been unable to figure out what.

If anyone could point me in the right direction, that would be most helpful!


Thank you!

Cheers,
antiro

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





___
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-01 Thread Clement.Chu

Hi Robert,

  Since I don't know how to debug or print message in shader code, I am not 
sure what exact value of vertex.  I guess the value of vertex is not in the 
range (0.0 to 1.0), so texture3D method cannot get correct color value by 
coordinate.  In file volume_frag.cpp,  variable texcoord is assigned from 
vertex data. If vertex data is not the 0.0f to 1.0f range, variable color (type 
vec4) will become strange value.  Even I added some codes to make sure values 
of color.x, color.y, color.z and color.w  in the range (0.0 to 1.0), it still 
cause the crash. Unless vertex is in the range (0.0 to 1.0). So far, this 
problem occurs in Intel HD Graphics 520 or above.  My old laptop is Intel HD 
Graphics 3000, but it works fine and Nvidia cards work fine too.

Regards,
Clement Chu

From: osg-users  on behalf of 
Robert Osfield 
Sent: Friday, 1 September 2017 18:29
To: OpenSceneGraph Users
Subject: Re: [osg-users] RayTracedTechnique hangs with Intel HD Graphics - 
Update

Hi Clement,

The numerical issue you have found causing a crash is a curious one.

The gl_Vertex isn't a normalized on any system, osgVolume::RayTracedTechnique 
does use a unit cube for it's geometry though, so the vertex data should all be 
in the 0.0f to 1.0f range.  Perhaps the intel driver/hardware combination is 
resulting in some numerical precision issue so that the values are going 
slightly outside the 0 to 1.0f range, but even if it does I wouldn't expect the 
fragment shaders to suddenly have problems.

Is there are specific line in the shader that you think is cause the crash?

FYI, osgVolume checks for the shader/volume.vert and shader/volume.frag 
filenames first then fallsback to the built in shaders that are found in the 
src/osgVolume/Shaders/volume_frag.cpp.  The shader/volume.frag can be found in 
OpenSceneGraph-Data/shader so if you have this available and it's on the 
OSG_FILE_PATH then you should be able to edit the shader files without 
recompiling the application.

Robert.

Robert.

On 1 September 2017 at 08:11, 
> 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 clement@csiro.au 
Sent: Wednesday, 30 August 2017 17:31
To: 
osg-users@lists.openscenegraph.org
Subject: [ExternalEmail] [osg-users] 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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] CullVisitor::apply(Geode&) detected NaN,

2017-09-01 Thread Robert Osfield

On 31 August 2017 at 21:14, Rômulo Cerqueira 
wrote:

> Up!
>

Down!

The report looks like the modelview matrix has NaN's in for some reason.
Without any information at when it happens, what you data is we can't say
what might be causing this.

Robert.
___
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-01 Thread Robert Osfield

Hi Clement,

The numerical issue you have found causing a crash is a curious one.

The gl_Vertex isn't a normalized on any system,
osgVolume::RayTracedTechnique does use a unit cube for it's geometry
though, so the vertex data should all be in the 0.0f to 1.0f range.
Perhaps the intel driver/hardware combination is resulting in some
numerical precision issue so that the values are going slightly outside the
0 to 1.0f range, but even if it does I wouldn't expect the fragment shaders
to suddenly have problems.

Is there are specific line in the shader that you think is cause the crash?

FYI, osgVolume checks for the shader/volume.vert and shader/volume.frag
filenames first then fallsback to the built in shaders that are found in
the src/osgVolume/Shaders/volume_frag.cpp.  The shader/volume.frag can be
found in OpenSceneGraph-Data/shader so if you have this available and it's
on the OSG_FILE_PATH then you should be able to edit the shader files
without recompiling the application.

Robert.

Robert.

On 1 September 2017 at 08:11,  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
> clement@csiro.au 
> Sent: Wednesday, 30 August 2017 17:31
> To: osg-users@lists.openscenegraph.org
> Subject: [ExternalEmail] [osg-users] 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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

2017-09-01 Thread Clement.Chu

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 
clement@csiro.au 
Sent: Wednesday, 30 August 2017 17:31
To: osg-users@lists.openscenegraph.org
Subject: [ExternalEmail] [osg-users] 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
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,

Re: [osg-users] Setting the transform matrices

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

Re: [osg-users] LIDAR plugin

Re: [osg-users] LIDAR plugin

Re: [osg-users] CullVisitor::apply(Geode&) detected NaN,

Re: [osg-users] CullVisitor::apply(Geode&) detected NaN,

Re: [osg-users] CullVisitor::apply(Geode&) detected NaN,

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

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

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

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

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

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

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

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

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

Re: [osg-users] CullVisitor::apply(Geode&) detected NaN,

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

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

20 matches

Site Navigation

Mail list logo

Footer information