Re: [osg-users] Picking based on Render order, not depth
Thanks Christian and Robert, I took Christian's advice and was able to get the render order (by looking at the bin number) of each node that was hit and just return the node with the highest render order. I didn't attempt incorporating the z buffer. Seemed a little over my head. Thanks so much! Cheers, John-Luke -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62955#62955 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SummerSim'15 Deadline Extended (Summersim '15 Computer Graphics for Simulation Paper track Call for papers)
Hello, Note the inclusion of your favorite open source system in the list of topics…J Deadline Extended again…… Summersim’15 final call for papers. DEADLINE EXTENDED to March 20, 2015. Notification: April 20, 2015 = First, the Computer Graphics Paper track at Summersim’15 info Topics The theme of the paper track is interoperability between Computer Graphics and Simulation. However, general graphics and simulation visualization are also primary themes. Topics include but are not restricted to; - 3D visualization of simulations - Open Source in simulation visualizations - Scenegraph's / X3D / Web3D / COLLADA / FBX / GML / OSG / OpenSG - 3D modeling and animation tools for virtual environments [Blender, Maya,... GIS tools / Terrain,...] - Game engines and simulation - DEVS and Computer Graphics - GPGPU's and simulations [CUDA, OpenCL,...] - General Computer Graphics - General Simulation Methodology - Sensors, CG and simulations - Ocean modeling, atmospheric and weather modelling, visualization - Business Information Modelling NEXT – The Summersim’15 info [THERE ARE REALLY GREAT TRACKS…J] AND DETAILS THE SOCIETY FOR MODELING SIMULATION INTERNATIONAL (SCS) * Summer Simulation Multiconference 2015: http://scs.org/summersim July 26-29, 2015 Palmer House Hilton Hotel; Chicago, IL, USA Complexity and the Role of Modeling Simulation *NEW SCSC TRACKS ADDED! SEE BELOW! Important Dates: Special Sessions Proposals (workshops, tutorials, etc): January 10, 2015 (SPECTS - February 20, 2015 Paper Submission: March 20, 2015(SPECTS - February 20, 2015) Notification of Acceptance: April 20, 2015(SPECTS - March 31, 2015) Work in Progress: April 20, 2015 Camera-ready Papers Due: May 1, 2015 = Aims and Scope: The Summer Simulation Conference 2015 (SummerSim’15) is SCS’s premier international conference in cooperation with ACM SIGSIM. The conference focuses on modeling and simulation, tools, theory, methodologies and applications and provides a forum for the latest RD results in academia and industry. This year’s focus is on hybrid, discrete and continuous systems, and the role of MS in addressing complexity. We encourage you to take this opportunity to experience the tutorials, tracks, and workshops that will be available. Organizing Committee: ◦General Chair: Saurabh Mittal, Dunip Technologies, LLC, Colorado, USA (smit...@duniptech.com) ◦General Co-Chair: Floriano De Rango, University of Exeter, UK (dera...@deis.unical.it) ◦Awards Chair: Andreas Tolk, SimIS Inc., Virginia, USA (andreas.t...@simisinc.com) ◦Program Chair: José Luis Risco Martín, Universidad Complutense de Madrid, Spain (jlri...@ucm.es) ◦Proceedings Chair: Deniz Cetinkaya, University of Turkish Aeronautical Association, Turkey (dcetink...@thk.edu.tr) ◦Publicity Chair: Justyna Zander, HumanoidWay, USA (justyna.zan...@gmail.com) ◦Sponsorship Chair: Umut Durak, Clausthal University of Technology, Germany (umut.du...@dlr.de) ◦Tutorial Chair: Pending confirmation ◦PhD Colloquium Chair: Miroslav Velev, Aries Design Automation, USA (mve...@gmail.com) Steering Committee: ◦Abdolreza Abhari, Ryerson University, Canada (aabh...@scs.ryerson.ca) ◦Francesco Longo, University of Calabria, Italy (f.lo...@unical.it) ◦Pere Vila, University of Girona, Spain (pere.v...@udg.edu) ◦Pieter J. Mosterman, MathWorks, Inc., USA (pieter.moster...@mathworks.com) ◦Justyna Zander, HumanoidWay, USA (justyna.zan...@gmail.com) Advisory Committee: ◦Tuncer Ören, SITE, University of Ottawa, Canada (oren.tun...@sympatico.ca) ◦Mohammad Obaidat, Monmouth University, USA (obai...@monmouth.edu) ◦Agostino Bruzzone, University of Genoa, Italy (agost...@itim.unige.it) ◦François Cellier, ETH Zurich, Switzerland (fcell...@inf.ethz.ch) ◦Bernard P. Zeigler, University of Arizona, Tucson, USA (zeig...@ece.arizona.edu) ◦Jerzy Rozenblit, University of Arizona, Tucson, USA (j...@ece.arizona.edu) A selected group of the best papers of SummerSim 2015 will be invited to be published in a Special Issue devoted to SummerSim 2015. At the moment, the committee is looking for appropriate venues of journal publications. All authors are encouraged to submit extended versions of their papers to the Special Issue according to the guidelines found on the webpage. Authors of accepted papers are expected to attend the conference, present their work to their peers, transfer copyright, and pay a conference registration fee at the time their camera-ready paper is submitted. All papers will be included in the conference proceedings and archived in both the SCS digital library and the ACM Digital Library, and will be indexed in DBLP and SCOPUS. SummerSim'15 Includes the Following Events (please see
Re: [osg-users] Android not building. Can someone have a look...
Hi Robert, works perfectly as can be seen: http://cdash.openscenegraph.org/index.php?project=OpenSceneGraphdate=2015-03-04 thanks Mattias On Tue, Mar 3, 2015 at 1:02 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Mattias, It looks like a revision to the PolygonMode.cpp to better handle GL3 onwards has caused this regression. I have amended the #ifdef usage to avoid compiling the glPolygonMode call under GLES1 and GLES2. Could you do an svn update and let me know how you get on. Cheers, Robert. On 3 March 2015 at 10:38, Mattias Helsing helsin...@gmail.com wrote: Hi all, As I said in a previous I occasionally build the OSG using an older ndk (r7 something). I'm not really using it right now, I just wanted to test out the PlatformSpecifics/Android/android.toolchain.cmake stuff that was added a couple of months ago. However: The builds have been failing for different reasons for months. Now things look more stable and the only error left is that glPolygonMode isn't available in the ndk. See for example: http://cdash.openscenegraph.org/viewBuildError.php?buildid=6110 I think the fix is trivial for someone who knows the android ndk and have a better knowledge in OpenGL variants better than I do. So if someone could have a look and submit a fix OR reply here and I'll prepare a submission in your name to Robert. We have a stable release coming up so this should be sorted before that I think. cheers Mattias ___ 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] Remote Deskstop Display issue
Your remote display problem is a limitation of Windows Remote Desktop's OpenGL support. There are three potential solutions: 1) Only use OpenGL 1.1 features if you're using remote desktop - not very practical possibly not even possible with OpenSceneGraph. 2) Use ANGLE and OpenGL ES - Angle is a wrapper for Direct3D that exposes the OpenGL ES 2.0 and 3.0 API. Direct3D works across RDP, but only from windows 7 SP1, or the equivalent server version via a technology called RemoteFX. This also will require rebuilding OpenSceneGraph, and writing your own replacement for GraphicsWindowWin32 using GraphicsWindoEmbedded and EGL (or QT 5). Also you'll be restricted to OpenGL Es's feature-set. 3) Use Mesa. If you can get builds of OPENGL32.DLL and GLU32.DLL for Mesa, you can just drop them into your executable directory, and your app will support desktop OpenGL 2.1 using software rendering. You'll need to remove those two dlls to return to using proper desktop OpenGL. Obviously that's awkward, and Mesa is slow and restricted in features compared to full, modern desktop OpenGL (although conveniently it's a similar feature set to compatibility mode on OSX). Internally, we use option 2 and option 3 on different products. Your only other alternative is to use a different remote desktop protocol product, like VNC or something commercial. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Remote Deskstop Display issue
Hi Alistair, Thanks for your details answer. I will try option 3. Thanks. Regards, Clement From: osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf of Alistair Baxter [alist...@mve.com] Sent: Wednesday, 4 March 2015 21:50 To: OpenSceneGraph Users Subject: Re: [osg-users] Remote Deskstop Display issue Your remote display problem is a limitation of Windows Remote Desktop's OpenGL support. There are three potential solutions: 1) Only use OpenGL 1.1 features if you're using remote desktop - not very practical possibly not even possible with OpenSceneGraph. 2) Use ANGLE and OpenGL ES - Angle is a wrapper for Direct3D that exposes the OpenGL ES 2.0 and 3.0 API. Direct3D works across RDP, but only from windows 7 SP1, or the equivalent server version via a technology called RemoteFX. This also will require rebuilding OpenSceneGraph, and writing your own replacement for GraphicsWindowWin32 using GraphicsWindoEmbedded and EGL (or QT 5). Also you'll be restricted to OpenGL Es's feature-set. 3) Use Mesa. If you can get builds of OPENGL32.DLL and GLU32.DLL for Mesa, you can just drop them into your executable directory, and your app will support desktop OpenGL 2.1 using software rendering. You'll need to remove those two dlls to return to using proper desktop OpenGL. Obviously that's awkward, and Mesa is slow and restricted in features compared to full, modern desktop OpenGL (although conveniently it's a similar feature set to compatibility mode on OSX). Internally, we use option 2 and option 3 on different products. Your only other alternative is to use a different remote desktop protocol product, like VNC or something commercial. ___ 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] Remote Deskstop Display issue
Hi Alistair, I forgot to ask a question. Remote desktop works on the machine which has Nivida Quadro display card installed. Do you know why it works probably? Regards, Clement From: osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf of Alistair Baxter [alist...@mve.com] Sent: Wednesday, 4 March 2015 21:50 To: OpenSceneGraph Users Subject: Re: [osg-users] Remote Deskstop Display issue Your remote display problem is a limitation of Windows Remote Desktop's OpenGL support. There are three potential solutions: 1) Only use OpenGL 1.1 features if you're using remote desktop - not very practical possibly not even possible with OpenSceneGraph. 2) Use ANGLE and OpenGL ES - Angle is a wrapper for Direct3D that exposes the OpenGL ES 2.0 and 3.0 API. Direct3D works across RDP, but only from windows 7 SP1, or the equivalent server version via a technology called RemoteFX. This also will require rebuilding OpenSceneGraph, and writing your own replacement for GraphicsWindowWin32 using GraphicsWindoEmbedded and EGL (or QT 5). Also you'll be restricted to OpenGL Es's feature-set. 3) Use Mesa. If you can get builds of OPENGL32.DLL and GLU32.DLL for Mesa, you can just drop them into your executable directory, and your app will support desktop OpenGL 2.1 using software rendering. You'll need to remove those two dlls to return to using proper desktop OpenGL. Obviously that's awkward, and Mesa is slow and restricted in features compared to full, modern desktop OpenGL (although conveniently it's a similar feature set to compatibility mode on OSX). Internally, we use option 2 and option 3 on different products. Your only other alternative is to use a different remote desktop protocol product, like VNC or something commercial. ___ 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] Remote Deskstop Display issue
If you mean, why does it work if the program is started before connecting, then it's to do with the way Windows controls access to its graphics hardware. Microsoft could probably have fixed it, but they have chosen not to, and so we have to live with working around it. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of clement@csiro.au Sent: 04 March 2015 12:54 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Remote Deskstop Display issue Hi Alistair, I forgot to ask a question. Remote desktop works on the machine which has Nivida Quadro display card installed. Do you know why it works probably? Regards, Clement From: osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf of Alistair Baxter [alist...@mve.com] Sent: Wednesday, 4 March 2015 21:50 To: OpenSceneGraph Users Subject: Re: [osg-users] Remote Deskstop Display issue Your remote display problem is a limitation of Windows Remote Desktop's OpenGL support. There are three potential solutions: 1) Only use OpenGL 1.1 features if you're using remote desktop - not very practical possibly not even possible with OpenSceneGraph. 2) Use ANGLE and OpenGL ES - Angle is a wrapper for Direct3D that exposes the OpenGL ES 2.0 and 3.0 API. Direct3D works across RDP, but only from windows 7 SP1, or the equivalent server version via a technology called RemoteFX. This also will require rebuilding OpenSceneGraph, and writing your own replacement for GraphicsWindowWin32 using GraphicsWindoEmbedded and EGL (or QT 5). Also you'll be restricted to OpenGL Es's feature-set. 3) Use Mesa. If you can get builds of OPENGL32.DLL and GLU32.DLL for Mesa, you can just drop them into your executable directory, and your app will support desktop OpenGL 2.1 using software rendering. You'll need to remove those two dlls to return to using proper desktop OpenGL. Obviously that's awkward, and Mesa is slow and restricted in features compared to full, modern desktop OpenGL (although conveniently it's a similar feature set to compatibility mode on OSX). Internally, we use option 2 and option 3 on different products. Your only other alternative is to use a different remote desktop protocol product, like VNC or something commercial. ___ 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] Pragmatic shader composition fails on windows
Hi Robert,
If I put a complex version line line
#version 400 compatibility
at the beginning of my shader's source a non-valid shader code is produced.
I've dived into the problem and found that finding the end line
terminator is non-robust in this case.
It determines the line's end with find_first_of(\n\r, ...)
This will cause the string for the version to end up having \r as the
last character, thus not a newline.
A quick fix is to add a newline (\n) to the version line, as done in the
attached submission against trunk revision.
I didn't spot this in my first tests, as I'm using some own code/include
injection adding extra newlines for the version.
Cheers
Sebastian
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
* Copyright (C) 2003-2005 3Dlabs Inc. Ltd.
* Copyright (C) 2004-2005 Nathan Cournia
* Copyright (C) 2008 Zebra Imaging
* Copyright (C) 2010 VIRES Simulationstechnologie GmbH
*
* 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.
*
*/
/* file: src/osg/Shader.cpp
* author: Mike Weiblen 2008-01-02
* Holger Helmich 2010-10-21
*/
#include fstream
#include list
#include sstream
#include iomanip
#include osg/Notify
#include osg/State
#include osg/Timer
#include osg/FrameStamp
#include osg/buffered_value
#include osg/ref_ptr
#include osg/Shader
#include osg/GLExtensions
#include OpenThreads/ScopedLock
#include OpenThreads/Mutex
using namespace osg;
///
//
// ShaderComponent
//
ShaderComponent::ShaderComponent()
{
}
ShaderComponent::ShaderComponent(const ShaderComponent sc,const CopyOp
copyop):
osg::Object(sc, copyop),
_shaders(sc._shaders)
{
}
unsigned int ShaderComponent::addShader(osg::Shader* shader)
{
for(unsigned int i=0; i_shaders.size();++i)
{
if (_shaders[i]==shader) return i;
}
_shaders.push_back(shader);
return _shaders.size()-1;
}
void ShaderComponent::removeShader(unsigned int i)
{
_shaders.erase(_shaders.begin()+i);
}
void ShaderComponent::compileGLObjects(State state) const
{
for(Shaders::const_iterator itr = _shaders.begin();
itr != _shaders.end();
++itr)
{
(*itr)-compileShader(state);
}
}
void ShaderComponent::resizeGLObjectBuffers(unsigned int maxSize)
{
for(Shaders::const_iterator itr = _shaders.begin();
itr != _shaders.end();
++itr)
{
(*itr)-resizeGLObjectBuffers(maxSize);
}
}
void ShaderComponent::releaseGLObjects(State* state) const
{
for(Shaders::const_iterator itr = _shaders.begin();
itr != _shaders.end();
++itr)
{
(*itr)-releaseGLObjects(state);
}
}
///
//
// ShaderBinary
//
ShaderBinary::ShaderBinary()
{
}
ShaderBinary::ShaderBinary(const ShaderBinary rhs, const osg::CopyOp copyop):
osg::Object(rhs, copyop),
_data(rhs._data)
{
}
void ShaderBinary::allocate(unsigned int size)
{
_data.clear();
_data.resize(size);
}
void ShaderBinary::assign(unsigned int size, const unsigned char* data)
{
allocate(size);
if (data)
{
for(unsigned int i=0; isize; ++i)
{
_data[i] = data[i];
}
}
}
ShaderBinary* ShaderBinary::readShaderBinaryFile(const std::string fileName)
{
std::ifstream fin;
fin.open(fileName.c_str(), std::ios::binary);
if (!fin) return 0;
fin.seekg(0, std::ios::end);
int length = fin.tellg();
if (length==0) return 0;
osg::ref_ptrShaderBinary shaderBinary = new osg::ShaderBinary;
shaderBinary-allocate(length);
fin.seekg(0, std::ios::beg);
fin.read(reinterpret_castchar*(shaderBinary-getData()), length);
fin.close();
return shaderBinary.release();
}
///
// static cache of glShaders flagged for deletion, which will actually
// be deleted in the correct GL context.
typedef std::listGLuint GlShaderHandleList;
typedef osg::buffered_objectGlShaderHandleList DeletedGlShaderCache;
static OpenThreads::Mutexs_mutex_deletedGlShaderCache;
static DeletedGlShaderCache s_deletedGlShaderCache;
void Shader::deleteGlShader(unsigned int contextID, GLuint shader)
{
if( shader )
{
OpenThreads::ScopedLockOpenThreads::Mutex
lock(s_mutex_deletedGlShaderCache);
// add glShader to the cache for the appropriate context.
s_deletedGlShaderCache[contextID].push_back(shader);
}
}
void Shader::flushDeletedGlShaders(unsigned int contextID,double
