Re: [osg-users] Multiple Node Intersection
Hi ,
Maybe you figured it out by now, but you are only looking at the
"first intersection" of the picker ( getFirstIntersection). You need
to iterate over all intersections.
Andrew
On Fri, Dec 18, 2020 at 9:15 AM marco@elmansrl.eu
wrote:
>
> Hi,
>
> I need to make the selection (pick) of a node, going to check if that node is
> present within an area built around the mouse click point.
>
> This should mean that, if there are more nodes inside that area, the pick
> event returns them to me.
>
> Currently for the point selection, therefore of a single node in a specific x
> and y, I successfully use osgUtil :: LineSegmentIntersector.
>
> Studying on the OSG book, I read that selection existed by checking inside a
> box, implemented by osgUtil :: PolytopeIntersector.
>
> Below I propose part of the code,
>
> double w(200), h(200);
> osgUtil::PolytopeIntersector* picker = new
> osgUtil::PolytopeIntersector(osgUtil::Intersector::CoordinateFrame::WINDOW, x
> - w, y - h, x + w, y + h);
> osgUtil::IntersectionVisitor iv(picker);
> viewer->getCamera()->accept(iv);
> if (picker->containsIntersections())
> {
> const osg::NodePath& nodePath = picker->getFirstIntersection().nodePath;
> auto intersections = picker->getIntersections();
> if (intersections.size() != 0) {
> auto hitr = intersections.begin();
> if (hitr->nodePath.size() != 0) {
> for (int i = 0; i < hitr->nodePath.size(); i++) {
> if (systemTargetMap[hitr->nodePath.at(i)->getName()]) {
> cout << "Node Name: " <<
> systemTargetMap[hitr->nodePath.at(i)->getName()] << endl;
> }
> }
> }
> }}
>
> Unfortunately, this selection only returns me one node, even if there are two
> (or more) very close together.
>
> What am I doing wrong?
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/d757a21a-bab6-4718-a6bf-2ebdf59650a7n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osg-users/CAGTJuHijBs3EbXDFeDpiLkaZkApKQQqaP%2BrOg_%3DNng2KXXYsaw%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crasch in extension->createShader when using remote desktop (Windows)
Hi, I connect using Microsoft RDP from Windows 10 to Windows 10 and from Mac OS X 10.15 to Windows 10 and I can verify that my shaders work fine using OSG 3.6.4 when running my application over RDP. The Windows 10 machine I am connecting to is using an nVidia graphics card and as far as OSG is concerned it sees OpenGL as if I was running "locally" However, if you are connecting to a Windows 7 machine ( even if it has the same nVidia card), however, it all falls apart. Using RDP OSG only sees the default MS Windows OpenGL, v1.1... thus shaders won't work and OSG 3.6.4 is non-functional. Andrew On Tue, Dec 17, 2019 at 6:30 AM Anders Backman wrote: > Hi all. > Using OSG 3.6.4, Windows 10. > > Not sure what the current state of the world regarding Remote Desktop and > OpenGL is. > Perhaps someone can share some light onto this. > > If I run an application that use shaders over remote desktop from one > windows machine to another I get: > > c:\build\VS2017\x64\osg\bin>osgsimpleshaders.exe > Windows Error #127: [Screen #0] ChooseMatchingPixelFormat() - > wglChoosePixelFormatARB extension not found, trying GDI. Reason: The > specified procedure could not be found. > > Rendering in software: pixelFormatIndex 3 > Warning: detected OpenGL error 'invalid enumerant' at Before > Renderer::compile > > > crash. > > This does not happen when using fixed functionality only, for example > running osgviewer with some standard obj-model works just fine. > However, as soon as a shader is requested, OSG crashes: > > _glShaderHandle = _extensions->glCreateShader( shader->getType() ); > > Exception thrown at 0x in agxViewer.exe: 0xC005: > Access violation executing location 0x. > > > () Unknown > > osg160-osg.dll!osg::Shader::PerContextShader::PerContextShader(const > osg::Shader * shader, unsigned int contextID) Line 533 C++ > osg160-osg.dll!osg::Shader::ShaderObjects::createPerContextShader(const > std::basic_string,std::allocator > & > defineStr) Line 426 C++ > osg160-osg.dll!osg::Shader::getPCS(osg::State & state) Line 470 C++ > > Anyone with more info on this? > Is there any way around this? > > -- > __ > Anders Backman, HPC2N > 90187 Umeå University, Sweden > and...@cs.umu.se http://www.hpc2n.umu.se > Cell: +46-70-392 64 67 > ___ > 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] multiple matrix transfromations cause severe slowness in performance
Hi Gianluca, We have performance problems with scene graphs when we end up with thousands of nodes and "small=low triangle count" geometries at each node. After investigation, it is clearly not so much the scene graph traversal itself, as the large number of small "primitive sets". I tested this by writing a node visitor that collected all the primitive sets from our scene graph into one Geode - thus removed all overhead of scene graph traversal.The performance, was better, but nothing special. However, coalescing all the primitive sets into one primitive set caused a massive FPS improvement. Orders of magnitude. Andrew On Tue, Oct 8, 2019 at 7:47 AM Voerman, L. wrote: > Hi Gianluca, > I have a feeling something is wrong with your setup, as we do these sort > of graphs in our viewer and get way higher framerates. > I get about 60 fps rendering 1920x1080x2 (=red-green stereo) on my Geforce > 1080, > with a static scene of 1.1 M vertices (886k triangels) > and in a similar shape ~9200 matixTransforms each with a ref to mostly the > same tree (4.5k vertices, vk triangels) > A few questions: > where seems to be the bottelneck when you enable the stats? > What os/gfx combo do you use? > if you dump out the scene and load it into the osgviewer, does the > framerate improve? > are you sure you're not useing a windows debug build? > > Regards, Laurens. > > On Tue, Oct 8, 2019 at 2:21 PM Gianluca Natale > wrote: > >> Hi all, >> >> I have a performance issue in my scenegraph that I cannot completely >> understand. >> >> My scenegraph is made by a main matrix transform, with these 2 children: >> >>- One geode that renders a big object on screen (the geometry in the >>drawable can take up to several thousands vertices); >>- One group node that in its turn has 200 children, each made by a >>matrix transform and a geode. The drawable in each of those geodes is very >>simple (no more than 100 vertices) >> >> It seems that this configuration allows me to have at most 50 fps. >> >> I feel that this should be rendered much faster. >> >> >> >> So I made some experiment. If I remove the 200 matrix transform attached >> to the group node I mentioned above, >> and directly apply the transformations to the vertices of the geometries >> in the 200 drawables of the small objects, performance improves a lot, till >> 100 fps. >> I investigatd a bit inside OSG code (I’m using OG ver.3.4.1), and >> apparently the only overhead due to the additional matrix transformations >> is a call to glLoadMatrix (I’m using the old ffp). >> How can you explain such an improvement? >> >> My real problem is that I would like to replace the 200 matrix >> transfromations with 200 auto-transform matrices, since I’d like those >> small objects to keep constant size on screen. >> >> But if I do that, I cannot remove the 200 transformations at all, and >> I’ll end up with a bad performance. >> >> Any idea about what I can try to make rendering of my scenegraph faster? >> >> >> >> Thanks, >> >> Gianluca >> ___ >> 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] Performance regression 3.6.3 vs 3.4.0
Hi Robert, To clarify what I meant by 'link'. If you post on the forum, a matching email would go to the mailing list. At some point that stopped working - various SMTP errors would display and so on. Simply put, if someone posts on the forum, I don't think this mailing list gets the message. Andrew On Thu, Aug 8, 2019 at 1:16 AM Robert Osfield wrote: > Hi Andrew, > > Forgot to ask: > > On Wed, 7 Aug 2019 at 23:43, Andrew Cunningham > wrote: > >> The link to the mailing list failed some time ago. >> > > I am not aware of any stability issues on the osg-users mailing list, so > this might be an issue with the link. Could you point me at the webpage > where you had an issue with the link? > > Robert. > > ___ > 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] Performance regression 3.6.3 vs 3.4.0
Firstly, has anyone noticed that http://forum.openscenegraph.org is
basically off-line and has been malfunctioning for some time. The link to
the mailing list failed some time ago.
In any case
I have noticed a serious performance regression when moving to 3.6.3 from
3.4.0
It's become such an issue for me, such that I had to revert to 3.4.0.
The problem starts with Geometry::addPrimitiveSet
Note the commented out /*if (_useVertexBufferObjects)*/
bool Geometry::addPrimitiveSet(PrimitiveSet* primitiveset)
{
if (primitiveset)
{
/*if (_useVertexBufferObjects)*/
addElementBufferObjectIfRequired(primitiveset);
The performance regression happens when adding large numbers of
PrimitiveSet*.
In 3.4.0 I did not use VBO's for this particular Geometry, but in 3.6.3 one
is required to use VBOs for all geometry.
The performance regression is caused by repeated patterns in the VBO code
that searches through vectors, an example below. As more and more data is
added, the slower the code gets.
unsigned int BufferObject::addBufferData(BufferData* bd)
{
if (!bd) return 0;
// check to see if bd exists in BufferObject already, is so return
without doing anything
for(BufferDataList::iterator itr = _bufferDataList.begin();
itr != _bufferDataList.end();
++itr)
{
if (*itr == bd) return bd->getBufferIndex();
}
I can eventually work around the issue, by doing my work to coalesce
PrimitiveSets , but might be a FYI for some users.
Andrew
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compiling vertext shader fails on Intel
Hi Chris, I managed to work around the issue by falling back to a slower rendering system. Also it turns out the laptop has a switchable graphics subsystem to nVidia ( which works perfectly) or Intel, so there are two workarounds. I'll check out that validator. Thanks Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75312#75312 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compiling vertext shader fails on Intel
Sadly although the driver is old, apparently it can't be updated to a newer version on this DELL laptop. Also, I am struggling a bit to detect/recover from the failure of "glLinkProgram". It appears this is delayed until the "first render" using the shader. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75310#75310 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Compiling vertext shader fails on Intel
Hi,
I am using a vertex shader to do some hardware instancing and on Intel graphics
drivers I am getting the error ( after I set OSG_NOTIFY_LEVEL=DEBUG).
Everything works great on nVidia.
OpenGL Information:
OpenGL Version: 4.2.0 - Build 10.18.10.3574
Vendor: Intel
Renderer: Intel(R) HD Graphics 4600
Compiling VERTEX source:
1: #version 110
2: //varying vec3 N;
3: //varying vec3 v;
4: attribute vec3 d;
5: void main()
6: {
7: vec3 pos = vec3(gl_Vertex) + d;
8: vec4 finalPos = vec4(pos, 1.0);
9: vec3 v = vec3(gl_ModelViewMatrix * finalPos);
10: vec3 N = normalize(gl_NormalMatrix * gl_Normal);
11: vec4 Iamb = gl_FrontLightProduct[0].ambient;
12: vec3 L = normalize(gl_LightSource[0].position.xyz - v);
13: vec4 Idiff = gl_FrontLightProduct[0].diffuse * abs(dot(N,L));
14: Idiff = clamp(Idiff, 0.0, 1.0);
15: vec4 Iamb2 = gl_FrontLightProduct[1].ambient;
16: vec3 L2 = normalize(gl_LightSource[1].position.xyz - v);
17: vec4 Idiff2 = gl_FrontLightProduct[1].diffuse * abs(dot(N,L2));
18: Idiff2 = clamp(Idiff2, 0.0, 1.0);
19: gl_FrontColor = Idiff+Iamb+Idiff2+Iamb2;
20: gl_BackColor = Idiff+Iamb+Idiff2+Iamb2;
21: gl_Position = gl_ModelViewProjectionMatrix * finalPos;
22: gl_ClipVertex = gl_ModelViewMatrix * finalPos;
23: }
Linking osg::Program "" id=2 contextID=0
Program's vertex attrib binding 1, d
glLinkProgram "" FAILED
OpenGL extension '' is not supported.
I gather this might be something to do with gl_ClipVertex but it's not clear
what I can do.
Thanks
Andrew
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75307#75307
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Moving from 3.4.1 to 3.5.7 breaks my "hardware instancing"
Hi Robert,
Updating to 3.6.3 fixed the problem!
I did find a possible subtle issue with 3.6.3 when OSG_NOTIFY_LEVEL=DEBUG.
No issues at other OSG_NOTIFY_LEVELs.
I am getting a crash at program exit at this line, called from
GraphicsObjectManager::~GraphicsObjectManager
std::ostream& osg::notify(const osg::NotifySeverity severity)
{
if (osg::isNotifyEnabled(severity))
{
getNotifySingleton()._notifyStream.setCurrentSeverity(severity);
return getNotifySingleton()._notifyStream; <---crash here
}
return getNotifySingleton()._nullStream;
}
GraphicsObjectManager::~GraphicsObjectManager()
{
OSG_INFO<<_name<<"::~"<<_name<<"()"<::~ref_ptr() Line
41 C++
[External Code]
osg158-osgd.dll!osg::ContextData::~ContextData() Line 35C++
[External Code]
osg158-osgd.dll!osg::Referenced::signalObserversAndDelete(bool
signalDelete, bool doDelete) Line 292C++
osg158-osgd.dll!osg::Referenced::unref() Line 194 C++
>
> osg158-osgd.dll!osg::ref_ptr::~ref_ptr()
> Line 41C++
Anyway, it's a minor issue and does not affect release code.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75029#75029
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Moving from 3.4.1 to 3.5.7 breaks my "hardware instancing"
Hi Robert, Not sure where the 3.5.7 came from - another dev must have grabbed it from GIT a while ago. I'll update to 3.6.3 and see what happens. Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75020#75020 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Moving from 3.4.1 to 3.5.7 breaks my "hardware instancing"
Hi, I upgraded from 3.4.1 to 3.5.7 and my code that uses "hardware instancing" (to render a large number of simple geometry) renders nothing now. I had no need to make any source code changes when I updated, and other parts of the code that uses vertex/fragment shaders works fine. I am wondering what could have changed to break this code? The outline is that I have a class that inherits from Drawable and overrides drawImplementation/computeBoundingBox/supports/accept I am adding a VertexAttribDivisor to the Program OSG_NOTIFY_LEVEL=DEBUG shows nothing interesting. Any ideas where I should start looking? Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75000#75000 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Back on the original topic :) This is a really simple QtOSGWidget that I used as a starting point for an OSG widget in a QDialog. Simple and works fine. https://github.com/vicrucann/QtOSG-hello -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74426#74426 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
robertosfield wrote: > > Personally I think Qt is broken in a number of ways. It's really time > that the computer industry had a C++11 based cross platform Windowing > API so we can all dump Qt, > I would agree QT is not perfect but on the flip-side - It is the 'last man standing' of x-platform UI's. - It's actively developed using the latest C++11/14 standards and supported by both a commercial organization and a robust LGPL community - Is has a new lease of life through PyQT5 and PySide being the 'de-facto' way to build Python based desktop UI's. - QML is quite interesting I don't know why QT and OSG seem to fight each other so much, but it seems a PITA to get things working properly as the OP and I have both found mysterious issues popping up that require trips into the debugger and the QT and OSG source. I had to advocate for OSG as other developers were keen to use QT3D instead. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74404#74404 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Stuart, If you resolve this please let us know. As a data point , I had a lot of trouble with OSG 3.4.1 and QT 5.7 and the "black" window problem. I only resolved it with some experimentation and I am still not sure why it worked. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74395#74395 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!
Great news and very timely given Apple’s just announced decision to deprecate OpenGL -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73979#73979 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using 'NodeTrackerManipulator' while holding camera steady
The osgmanipulators example is very clear. I should have checked the examples first! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73606#73606 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using 'NodeTrackerManipulator' while holding camera steady
Clearly I **am** barking up the wrong tree and should be looking at osgManipulators :) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73582#73582 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using 'NodeTrackerManipulator' while holding camera steady
Hi, I am trying to use NodeTrackerManipulator to rotate a single "node" while holding the camera view steady. That is the NodeTrackerManipulator will modify the transform of a single node not the camera viewMatrix. Am I barking up the wrong tree here. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73581#73581 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] "hooking" into the Trackballmanipulator transform
Yup you are right, that works great! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73570#73570 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] "hooking" into the Trackballmanipulator transform
Hi, I need to "hook" into the TrackballManipulator to provide feedback to the user. As the user rotates the model, I want to get the matrix and extract Euler angles. I'm stuck at how to get notified when the when the view matrix changes. Should I derive a new class from TrackballManipulator ? OSG 3.4.1 Thanks Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73567#73567 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG crash on startup
Hi Guy, I'm using OSG 3.4.0 with both VS 2013 and lately VS2015 and the only issue I had was the exactly what I described. It was my mistake, I was including the header from the distro, not the build area. And the symptoms were very similar to what you described. Sorry that's not it. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70900#70900 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG crash on startup
What can happen is that if you are not careful you can end up using an incompatible mix of the following defines. _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED _OPENTHREADS_ATOMIC_USE_MUTEX Just make sure you are using the same OpenThreads/Config header in your code as was used to build OSG. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70898#70898 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawing large number of labels
Hi Robert, Thanks for the very detailed reply - I don't know where you find the time! I think you gave me some good ideas. For example, I only need to render numbers. I could render each digit and reuse the vertex arrays to compose the number. Thanks a bunch! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70628#70628 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawing large number of labels
Ok, will need to digest that. I am correct in assuming it will work on Windows. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70622#70622 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Drawing large number of labels
Hi, I am looking for suggestion on how to efficiently draw 'large' ( aka many thousands) numbers of 'labels' or 'string markers' Typically these are short numeric strings. Instancing a osgText object for each label is likely to be very inefficient Andrew Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70620#70620 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.4.0 exception in Drawable::flushAllDeletedDisplayLists on nVidia
When I delete a view that has a complex geometry ( many OSG objects) I am getting an exception inside the nVidia driver at the line glDeleteLists(ditr->second,1); - Less complex geometry does not show the issue. - I have installed the latest nVidia Quadro driver( Win 7, 64-bit) - It is 100% reproducible - When running on a different type of nVidia card (GeForce vs. Quadro) I do not see the problem. I have checked the s_deletedDisplayListCache data structure and I have about 3300 display lists in the data structure before the deletion starts. The display list id values look fine ( not garbage). I hate to blame the driver, but Was wondering if anyone had encountered a similar issue? Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70463#70463 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Minor issue with GraphicsWindowWin32.cpp and mouse capture in 3.4.0
Hi, Somewhere along the line since 3.0.1 the logic of 'mouse capture' changed to have the concept of it being possible to have multiple buttons 'captured' on button down. When the capture count goes to 0 on mouse up, the mouse is 'released'. Unfortunately, this seems to cause problems with , say, Win32 pop-up/context menus as OSG is not 'releasing' the mouse to the pop-up menu. The 'fix' ( for me) was to revert to 3.0.1 behavior so that the ::ReleaseCapture() is always called on 'button-up'. Just a heads up for others... Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70033#70033 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tearing hair out over simple GLSL instancing
Yup that's what I found I had to do . I created a fragment shader and did the basic lighting. I assume I could do that in the vertex shader as well. Thanks for confirming. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69809#69809 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tearing hair out over simple GLSL instancing
Hi guys, Can you help me out with this one more time:) As I said, I am now able to draw my geometry ( a simple square) using hardware instancing. It works perfectly with excellent performance for millions of squares- except for one thing. Now I want to light the squares. I have turned on lighting, assigned a normal array to the geometry being instanced and assigned material colors, but I get unlit 'black squares' while the rest of my scene is lit just fine. Clearly something to do with hardware instancing using the vertex shader. Do I need to add a fragment shader? I am a bit lost here. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69801#69801 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tearing hair out over simple GLSL instancing
Thanks for the help I got it working by adding this to the StateSet osg::VertexAttribDivisor *divisor = new osg::VertexAttribDivisor(1, 1); ss->setAttribute(divisor); And changing my loop to add one offset per primitive to my vertexArray And thanks again!! I would never have figured that one out! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69747#69747 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tearing hair out over simple GLSL instancing
On thinking about this issue, I see the problem. I really only have 4 vertices, so the value d in my vertex shader just is always pulled from locations 0-3 in my array. What I really need to do is access an array of offsets in my shader indexed by glInstanceID -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69744#69744 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Tearing hair out over simple GLSL instancing
OSG 3.4.0
I am trying to use "instancing" (starting from the example osgdrawinstanced) to
draw simple square geometry at multiple locations.
I am getting all of my instances sitting on top of each other at (0,0,0). That
is they are not offset to their expected locations.
I know my shader is working OK because if I add a hack to my shader to add in
an offset that depends on gl_InstanceID then the squares do get "offset" per
instance.
Step 1
Add "nInstances" of the square to my osg::Geometry
geom.addPrimitiveSet( new osg::DrawArrays( GL_QUADS, 0, 4, nInstances ) );
Step 2
Create a simple shader program that uses an attribute array of offsets ("d") to
offset the vertex locations
std::string vertexSource =
"#version 120\n"
"#extension GL_EXT_draw_instanced : enable\n"
"in vec3 d;\n"
"void main() \n"
"{ \n"
// Use the =coord to translate the position of the vertices.
"vec3 pos = vec3(gl_Vertex) + d;\n"
"vec4 finalPos = vec4(pos, 1.0);\n"
"gl_Position = gl_ModelViewProjectionMatrix *
finalPos;\n"
"} \n";
osg::ref_ptr< osg::Shader > vertexShader = new osg::Shader();
vertexShader->setType(osg::Shader::VERTEX);
vertexShader->setShaderSource(vertexSource);
osg::ref_ptr< osg::Program > program = new osg::Program();
program->addShader(vertexShader.get());
ss->setAttribute(program.get(),osg::StateAttribute::ON);
program->addBindAttribLocation("d", 1);
Step 3
Create an array of offsets 4 * nInstances that contain the offsets for
each vertex. Is this where I am going wrong??? I have checked that "d" is not
(0,0,0) and is varying for each instance. It seems to be that all the instances
are using the same offset.
osg::Vec3Array *attrib = new osg::Vec3Array;
size_t vecIndex = 0;
for (size_t i = 0; i < nInstances ; i++) {
osg::Vec3 d=GetOffSetForInstance(i);
attrib->push_back(d);
attrib->push_back(d);
attrib->push_back(d);
attrib->push_back(d);
}
geom->setVertexAttribArray(1, attrib);
geom->setVertexAttribBinding(1,
osg::Geometry::BIND_PER_VERTEX);
Andrew
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=69743#69743
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Proper CMAKE settings for ZLIB, bogus "optimized.lib" in link
Now if someone could explain how to get the OSG CMake configuration to understand that QT5WebKit and QT5WebKitWidgets has gone away in QT 5.7 and stop looking for it. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69209#69209 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Proper CMAKE settings for ZLIB, bogus "optimized.lib" in link
Yup that worked. Same issue with PNG and TIFF. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69208#69208 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] Proper CMAKE settings for ZLIB, bogus "optimized.lib" in link
Hi, I am trying to build OSG 3.4.0 on Windows/Visual Studio 2015 using CMake to generate the projects. Everything works pretty well except the confusing settings for ZLIB_LIBRARY, ZLIB_LIBRARY_DEBUG,ZLIB_LIBRARY_RELEASE. Why 3 settings ? I included paths to Debug and Release builds of ZLib, in the ZLIB_LIBRARY_DEBUG and ZLIB_LIBRARY_RELEASE respectively and left ZLIB_LIBRARY blank. Although the DEBUG build is ok , my RELEASE builds ended up with library references to non-existent "optimized.lib" and "debug.lib" as well as duplicating the debug and release versions of the zlib libraries. For example, this is pasted from the VS linker settings for and OSG project. - optimized.lib D:\OSG\3rdParty\build\lib\Release\zlib.lib debug.lib D:\OSG\3rdParty\build\lib\Debug\zlibd.lib Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69206#69206 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt3D 2.0 vs OSG
We are using Visual Studio 2013 but will be moving to Visual Studio 2015 for this project. QT3D 2.0 is a real scene graph now - it's only real advantage over OSG is that getting started with it is 'low friction' vs OSG which seems at first glance a bit overwhelming, including the whole build process, especially those pesky third-party libs. And the OSG/QT5 integration has not been always so perfect. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69167#69167 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Qt3D 2.0 vs OSG
Hi, We are having a bit of an internal argument about using OSG 3.4 as a scene graphs vs the scene graph in QT3D2.0 (QT 5.7) for a QT Windows/C++ widget app. We are already familiar with OSG 3.3 in a Windows/MFC application - that's obviously a reason to use OSG. But QT3D 2.0 seems quite easy to use as well. Maybe someone has more experiences with the Pros/Cons. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69158#69158 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setCullMask and computeBounds of nodes
OK, makes sense. Now I at least understand what is going on. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67067#67067 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setCullMask and computeBounds of nodes
Hi, I am using cull masks to hide objects in the scene graph. Works great. When working with some custom drawables I note that the computeBound() method of my 'hidden/culled' object is still being called. It seems the computeBound traversal ignores cullmasks. Is that as expected? (OSG 3.0.1) Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67064#67064 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.4.0/QT 5.5 Warning "QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined"
It quite possibly could be specific to my implementation. I took the code from the osg example , but had to massage it a bit. I might try QT 5.6 to see if it goes away as well. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66872#66872 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to integrate osg with QT5.6 on VS2015
Great tip! I had no idea about that one. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66733#66733 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.4.0/QT 5.5 Warning "QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined"
Hi, When using OSG 3.4.0 and QT 5.5 and on the firstviewer->frame() of an OSGWidget I am getting this warning from QOpenGLContext. Subsequent calls to frame() do not show this warning. Mr. Google suggests that a fix is to check the isExposed() flag on the underlying QWindow - if it were possible to get to the QWindow via a public API. Any suggestions? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66726#66726 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to integrate osg with QT5.6 on VS2015
Hi, Do you mean OSG 3.4.0? I had problems with OSG 3.4.0/QT5.5/VS2013 unless I made sure that QT5.5 was built with "-opengl desktop" -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66725#66725 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5
Ok, now I am having a new problem. I am now transitioning to QT 5.5 and Visual Studio 2015 Update 1 from QT 5.4 and VS 2010 ( using OSG 3.4.0) I rebuilt OSG for Visual Studio 2015 Update 1 I built QT5.5 for Visual Studio 2015 Update 1 The OSG examples all work fine, except OSGViewerQT When osgViewerQT starts up > osg130-osgd.dll!osg::State::initializeExtensionProcs() Line 959 C++ osg130-osgd.dll!osg::GraphicsContext::makeCurrent() Line 620C++ osg130-osgQtd.dll!osgQt::GraphicsWindowQt::realizeImplementation() Line 777 C++ osg130-osgd.dll!osg::GraphicsContext::realize() Line 511C++ osg130-osgViewerd.dll!osgViewer::CompositeViewer::realize() Line 612 C++ osg130-osgViewerd.dll!osgViewer::ViewerBase::frame(double simulationTime) Line 681 C++ osgviewerQtd.exe!ViewerWidget::paintEvent(QPaintEvent * event) Line 85 C++ const char* vendor = (const char*) glGetString( GL_VENDOR ); returns NULL, so of course nothing will work from now on. Digging through the code, I found that in QGLContext::makeCurrent > Qt5OpenGLd.dll!QGLContext::makeCurrent() Line 3578 C++ Qt5OpenGLd.dll!QGLWidget::makeCurrent() Line 4071 C++ osg130-osgQtd.dll!osgQt::GraphicsWindowQt::makeCurrentImplementation() Line 840 C++ osg130-osgd.dll!osg::GraphicsContext::makeCurrent() Line 611C++ osg130-osgQtd.dll!osgQt::GraphicsWindowQt::realizeImplementation() Line 777 C++ osg130-osgd.dll!osg::GraphicsContext::realize() Line 511C++ const char *renderer = reinterpret_cast(d->guiGlContext->functions()->glGetString(GL_RENDERER)); returns a valid string... Any ideas on this one? It looks like we do not have a valid GL context when OSG needs it. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65981#65981 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5
I see my error, I built QT 5.5 with OpenGL ES 2 support, not desktop OpenGL support. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65982#65982 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5
[quote="robertosfield"]Hi Andrew The reason why z buffer etc. Is off is the your setup hasn't set it up as there is no global stateset to the camera you are passing to the Viewer. I have discussed this topic quite a but since OSG-3.2. Please see the archives. Robert. [quote] OK thanks, but my forum searching did not turn up much on this topic. Wrong keywords I suppose. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65940#65940 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5
Hmm, I was able to fix it by adding the following to my root object state... state->setMode( GL_DEPTH_TEST, osg::StateAttribute::ON ); Not sure why this was needed in QT5/OSG as I thought it was the default... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65939#65939 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5
Hi, Although I now have rendering of my objects happening in my Qt5/OSG 3.4.0 widget I am having a issue with simple polygonal objects rendering "on top of each other" as if there is no depth (Z) buffer in operation. I am using fairly vanilla OSG code to set up the model and camera that worked as expected in a MFC/OSG 3.0.1 world. I am completely at a loss as to why a Z-buffer is not operating. GL_BLEND is definitively OFF. Any ideas? Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65937#65937 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5
I'm not 100% sure why the OSG example code stopped rendering correctly when embedded in my app as a test. I did get it working eventually. Anyway, the underlying issue when trying to adapt the new OSG3.4/QT5 approach into my code code was that I completely missed ( too much holiday cheer?) that the 'actual' widget being rendered is found in graphicsWindow_->getGLWidget(). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65932#65932 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5
loopy wrote: > Hi, > I am struggling mightily to get OSG 3.4.0 to work with QT 5.4.2 on Windows 7 > (64). > > - The sample application, OSGViewerQT works as expected with OSG_FILE_PATH > set. > > - However, when I ( as a quick test) embed the "ViewerWidget" from > OSGViewerQT inside a QHBoxLayout inside a MainWindow, the ViewerWidget does > not show any geometry ( e.g. the "cow.osgt" etc). Interestingly the > "popupWidget" that displays the "truck" geometry works as expected - > presumably as it is a separate Window. So there is some issue with embedding > the OSG Widget(s) inside other QWidgets? > > OK, I sorted this one out. It was confusion over 'old ways' to use OSG/QT and the new, improved ways to do this. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65929#65929 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5
Hi, I am struggling mightily to get OSG 3.4.0 to work with QT 5.4.2 on Windows 7 (64). - The sample application, OSGViewerQT works as expected with OSG_FILE_PATH set. - However, when I ( as a quick test) embed the "ViewerWidget" from OSGViewerQT inside a QHBoxLayout inside a MainWindow, the ViewerWidget does not show any geometry ( e.g. the "cow.osgt" etc). Interestingly the "popupWidget" that displays the "truck" geometry works as expected - presumably as it is a separate Window. So there is some issue with embedding the OSG Widget(s) inside other QWidgets? Any ideas??? Cheers, Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65928#65928 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Oldie, but goodie... Aero themes and OpenGL/MFC
Hi,
I created a new class that inherits from CSplitterWndEx ( I am using the MFC
feature pack, but it should apply to CSplitterWnd )
and added these methods
virtual void StartTracking(int ht);
virtual void StopTracking(BOOL bAccept);
virtual void OnInvertTracker(const CRect rect);
If enableTrackSplitter_=false, you will no longer get the nasty trails left
over the 3D window.
void CTransposableSplitterWnd::StartTracking(int ht)
{
CSplitterWndEx::StartTracking(ht);
}
void CTransposableSplitterWnd::StopTracking(BOOL bAccept)
{
CSplitterWndEx::StopTracking(bAccept);
}
void CTransposableSplitterWnd::OnInvertTracker(const CRect rect)
{
if(enableTrackSplitter_){
CSplitterWndEx::OnInvertTracker(rect);
}
}
Cheers,
Andrew
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64238#64238
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Oldie, but goodie... Aero themes and OpenGL/MFC
Hi, I finally got around to resolving these MFC/Aero issues using the following . For drawing the selection box over a complex scene... - Capture the 3D scene image as a texture map - Turn off the 3D scene - map the texture onto a 2D quad that will in the background filling the window - While interactively drawing the zoom/selection box draw a outlined QUAD into a HUD over the 2D texture mapped quad. MFC CSplitterWnd issues - Overridde CSplitterWnd::OnInvertTracker to be a no-op to prevent 'trails' being left on the 3D window while you drag the splitter. - Handle these Windows messages for the Frame containing the CSplitterWnd ON_WM_ENTERSIZEMOVE() ON_WM_EXITSIZEMOVE() In between these two calls, handle OnDraw in the 3D window by filling the Window with a solid color ( or whatever) using GDI, not by trying to render OpenGL/OSG. Hope someone finds this helpful Cheers, Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62278#62278 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Olide, but goodie... Aero themes and OpenGL/MFC
Hi, This is an old one, that seemingly no-one has a solution for I am having problems on W7/W8 when aero is active in our MFC/OGL(OSG) based CAE style application. 1) MFC CSplitterWnd resizing leaves 'window garbage' behind 2) How to draw an rubber-banding zoom box (using XOR operations) on the OpenGL window - we were using GDI, of course this is a no-no now. We have to advise the user to revert to Windows 7/8 basic theme. Of course they never read the release notes, so support gets the call I was wondering how to resolve 2) using OSG. I suppose it's a HUD type problem. I want to draw over the existing rendered scene without requiring the underlying scene to be re-rendered. It quite simple to do a XOR'd rectangle using gl* calls in screen coordinates, but I'm at a loss how to integrate that into an OSG scene. Thank you! Cheers, Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56471#56471 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Oldie, but goodie... Aero themes and OpenGL/MFC
I am using a double-buffered window as per the OSG MFC example. traits-doubleBuffer = true; The MFC example shows a nice overlay HUD of rendering statistics. This just seems such a typical 3D UI interaction - to show a rectangular area on the screen under mouse control for selection or zooming that it surprises me there is not a canned solution. I suppose I could grab the pixel buffer and make that a static background while I draw the rectangle. It is crucial the full 3D scene be not continuously redrawn while drawing this zoom box. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56474#56474 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG + Mesa3D
Hi Mike, I have put a zip of the complete build directory on DropBox. https://dl.dropbox.com/u/82874382/Mesa-7.8.2.zip Let me know when you get it. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51428#51428 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG + Mesa3D
Mike, I posted the DLL's on this forum as an attachment but the moderator bounced the message as they were 300KB Here are the dropbox links. https://dl.dropbox.com/u/82874382/MESA64.zip https://dl.dropbox.com/u/82874382/MESA32.zip If you are interested in the complete 7.8.2 folder with VC10 projects let me know. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51296#51296 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render a lot of labels
Hi, FTGL looks good, but since I was only interested in bitmap ANSI text labels (always facing screen, always the same size), a simple set of per-rendered letters as bitmaps was all I needed - wrapped in a custom drawable. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51297#51297 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG + Mesa3D
Hi, I have built MESA for Windows for exactly this reason. We have some users who absolutely need to use RDP, and the default MS implementation is very buggy. The latest version of MESA that will build on Windows and use a software renderer is MESA 7.8.2 which implements OpenGL 2.1. I can make Visual Studio 2010 projects available if you need them + prebuilt DLLs. I'll stick them on DropBox. ... Thank you! Cheers, Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51273#51273 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render a lot of labels
Hi, I render the letters of the alphabet into pre-built bitmaps at various points sizes. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51274#51274 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on scene structuring
In my case, I decided I will keep a parallel OSG node with real geometry that I can use for picking. Picking is not typically as performance sensitive as say, rotating the model in real-time. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48566#48566 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on scene structuring
Hi, I am also confronting the issue of needing to pick the individual objects rendered as draw instances. Any best practices that can be recommended for use in the OSG world... Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48546#48546 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.0.1 crash in glDrawElements() under Windows Remote Desktop
I have had success with using Mesa. The last Mesa version that apparently supports Windows GDI is 7.8. Later versions will build on Windows ,but crash at runtime. I was able to successfully build Mesa 7.8.2 using Visual Studio 2010. I ended up with a mesa based opengl32.dll that is drop-in replacement for the ancient MS supplied opengl32.dll and works fine for my needs . -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48000#48000 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.0.1 crash in glDrawElements() under Windows Remote Desktop
When running a Windows OSG 3.0.1 application under Windows Remote Desktop the OpenGL driver defaults to the (ancient) software MS OpenGL GDI renderer v1.1. Unfortunately, I need to make the basics of our app work under RDC. I am finding that glDrawElements ( called from void DrawElementsUInt::draw) crashes every time inside the MS OpenGL driver when given a geometry with say, 3000 elements. With smaller numbers of elements there are no problems. This is code that works perfectly when running under accelerated drivers such as nVidia/ATI etc. I experimented with breaking up the drawing of elements into blocks of size GL_MAX_ELEMENTS_INDICES_WIN with no luck. It seems that repeated calls to glDrawElements in a loop even with a small number of elements cause the same issue. This is almost certainly a bug in the driver, but I am wondering if anyone has a workaround that can be done at the OSG level. Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47976#47976 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.0.1 crash in glDrawElements() under Windows Remote Desktop
Ok, thanks for that idea. I will definitely look into using Mesa. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47985#47985 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image::readPixels (3.0.1)
Just imagine this scenario of a DrawCallBack
struct SnapImage : public osg::Camera::DrawCallback
{
SnapImage(unsigned int format):
_snapImage(false),_format(format)
{
_image = new osg::Image;
_image-setPacking(4);
}
~SnapImage(){};
virtual void operator () (osg::RenderInfo renderInfo) const
{
if (!_snapImage) return;
osg::notify(osg::NOTICE)Camera callbackstd::endl;
osg::Camera* camera = renderInfo.getCurrentCamera();
osg::Viewport* viewport = camera ? camera-getViewport() : 0;
if (viewport _image.valid())
{
_image-readPixels(int(viewport-x()),int(viewport-y()),int(viewport-width()),int(viewport-height()),
_format,
GL_UNSIGNED_BYTE);
osg::notify(osg::NOTICE)Taken screenshot.. std::endl;
}
_snapImage = false;
}
mutable bool_snapImage;
mutable unsigned int_format;
mutable osg::ref_ptrosg::Image_image;
};
This will likely crash when width is not a multiple of 4. I not calling
setPacking() after the image has been allocated.
I wanted a packing of 4 as this matches the packing of BMP
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46659#46659
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Image::readPixels (3.0.1)
I think there is an issue in Image::readPixels that I noted in 2.8.x
Assume you have set the Image packing is set to say 4 , via
image-setPacking(4) before this call.
glReadPixels might try and store 'too much' data into _data ( overwriting
memory) because glReadPixels will be expecting the pixel data is using a
packing of 4 but allocateImage was passed a packing of 1 via the default
parameter.
It certainly cause my code to crash depending on the variations of width and
height.
void Image::readPixels(int x,int y,int width,int height,
GLenum format,GLenum type)
{
allocateImage(width,height,1,format,type);
glPixelStorei(GL_PACK_ALIGNMENT,_packing);
glReadPixels(x,y,width,height,format,type,_data);
}
changing code to
allocateImage(width,height,1,format,type,_packing);
seems to fix the issue.
It's pretty subtle, and may only affect some people who need a particular
format for the image data, and maybe calling setPacking is an abuse of the API
so this can be seen as informational only rather than a 'bug' report.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46637#46637
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg 2.8.3 : applyAndIncrement of BIND_PER_VERTEX attributeMaps
Hi,
I am not sure if I am missing something obvious here , but in the 2.8.3
implementation of Geometry::drawImplementation
There is a loop over primitive types as abridged below
Code:
for(DrawElementsUInt::const_iterator primItr=drawElements-begin();
primItr!=drawElements-end();
++primCount,++primItr)
{
if ( extensions-isVertexProgramSupported() )
{
DrawVertexAttribList list =
drawVertexAttribMap[BIND_PER_VERTEX];
for( unsigned int i = 0; i list.size(); ++i )
{
list[i]-applyAndIncrement();
}
}
}
What this suggests to me ( and what I am seeing ) is that in the body of the
loop over primitives , then for each [BIND_PER_VERTEX] attribute list,
applyAndIncrement will be called - this increments the index_ member of the
DrawVertexAttribList .
BIND_PER_VERTEX attribute arrays will have a size to the number of vertices.
If the number of primitives is greater than the number of vertices, then a
vector[] out of bounds exception on the vertex attribute array will happen when
the primCount exceeds the vertex count.
Thank you!
Cheers,
Andrew
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44004#44004
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg 2.8.3 : applyAndIncrement of BIND_PER_VERTEX attributeMaps
Hmm, I think I can answer my own question. Code ended up in the drawImplementation slowpath which is not well supported. The workaround is to make sure it never ends there. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44006#44006 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDB ifstream / ofstream conflict
Hi Vincent, I have been using Visual Studio 2010 and fstreams and OSG DLLs with no issues at all. The only possibility is you are compiling with incompatible compiler options between OSG and your other library. All files must be compiled /MD(d) and of course compiled with Visual Studio 2010. Make sure to include fstream not fstream.h etc You have not found a bug in Visual Studio 2010, I can guarantee that. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39488#39488 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
robertosfield wrote: Hi Andrew, I wouldn't recommend creating a single osg::Geometry with millions of vertices/primitives, while in theory it should work, even if it does it's likely to perform poorly as the GL driver won't be able to just render the data directly - it'll need to stream it in chunks. Hi Robert, When trying to fix this, I modified OSG and chunked up the calls to glDrawElements inside PrimitiveSet.cpp to be GL_MAX_ELEMENTS_INDICES in size. Anything wrong with this approach? This would mean the OSG user need not be concerned about whether they are using 'too many' vertices/primitives. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35157#35157 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
Hi, I have a Quadro FX 1700 with the latest 64-bit Nvidia drivers on Windows XP/64. My app is a 64-bit Windows application. For testing I am creating a single osg::geometry with probably about 3.2 million QUAD primitives , using quadPrims_=new osg::DrawElementsUInt(osg::PrimitiveSet::QUADS); I am not using VBO's. Once the osg scene graph is created, and the render phase begins. I see the border of my screen flash black twice and then my application is in la-la land, with a blank 3D window and needs to be killed. The app is using about 2G of memory but I have 9G free. More info... - osg does not report any errors - if I turn off the nVidia driver and switch to the default software OpenGL driver, the geometry renders fine. - If I take a geometry of a similar size or even much bigger, but break it up into multiple geometries so that each DrawElementsUInt is smaller there are no problems. I am not aware of any specific limitations on glDrawElements that says the number of elements must be some number. The reference guide says there may be performance problems with numbers GL_MAX_ELEMENTS_VERTICES/INDICES but it is not a hard limit. Any one experienced similar problems? Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35136#35136 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
Hi All, I did some testing with gDebugger (now free!) and the its support for nVidia Expert - totally clean, no errors. No breakpoints. And when running under gDebugger there were no problems What did fix it was going to the nVidia Control Panel and changing the global application settings to 3D App - Visual Simulation. Go figure. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35144#35144 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VertexBufferObects causing crash/bad geometry [2.8.2]
Hi,
This is a Windows 32/64app, fully single threaded(app and OSG in one thread).
Quadro FX1800, latest drivers.
I am rendering basic polygonal geometry - and I have been experimenting with
turning on use of VBO's. I want to emphasize that the app shows zero issues
until I turn VBO's on for geometry with a PrimitiveSet such as
osg::DrawElementsUInt(osg::PrimitiveSet::TRIANGLES)
.e.g
if(osgGrid_-areFastPathsUsed()){
osgGrid_-setUseVertexBufferObjects(true);
}else{
osgGrid_-setUseDisplayList(true);
}
When I turn on VBO's , the normally reliable app starts reproducibly showing
essentially random geometry for the objects (only) where UseVertexBufferObjects
is true. Non-VBO objects render fine. And the VBO objects render fine when
useVBO is off.
Crashes sometimes result. The symptoms are similar to multithreading issues
where one thread is accessing stale data from another thread.
Are the calls to the underlying rendering of VBO's asynchronous? It's as if
the VBO calls are getting stale data or something. Problems seem to happen
particularly if I close a window then open another one, again as if the
rendering was continuing with 'old' data in the old window.
All sounds a bit vague, I know, but these types of things are a nightmare to
debug.
Andrew
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=32990#32990
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VertexBufferObects causing crash/bad geometry [2.8.2]
Hi Robert, Tried two XP machines ... identical behavior as long as H/W acceleration is on. Both graphics cards are nVidia, though. If I disable the drivers, there are no problems , but that is not surprising as OSG defaults to a non-VBO code path. I am using the OSG API in a very vanilla way, and both debug and release builds show the issue. If I was exceeding vector bounds or otherwise abusing the OSG API that should be caught in the debug build or by OSG_NOTIFY_LEVEL Quite the mystery, I can toggle my use of VBOs at runtime so may look into this with some memory checking tools. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33003#33003 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vectorbool performance issue
Robert, You are right, although vectorbool is slow, it is apparently not the bottleneck. In my case, the bottleneck was basically, a deep and complex hierarchy of osg::Switch groups. I did some frame rate testing, replace all the osg::Switch with osg::Group, then frame rate tested again. There was only a minor difference. The hierarchy is the issue, not the presence of the osg::Switch Still, this is a bit like the _SECURE_SCL=0/1 issue on Windows - a performance problem possibly waiting to bite someone. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31382#31382 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vectorbool performance issue
Just as background, the model is a CAD model of a fairly typical part. When broken down to the component CAD entities, there are a total of about 19,000 groups in a hierarchy about 4 levels deep. Of course the geometry could be coalesced to any level, but users expect visibility control and attribute control down to the individual entity level. The traversal of the scene graph is very significant portion of the time taken to refresh the scene. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31386#31386 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] std::vectorbool performance issue
Hi, I am looking at a performance slow-down introduced after using some osg::Switch groups. I did some performance benchmarking on std::vectorbool and I found push_backs are 10x slower than std::vectorint, and more importantly, the simple [] operator is about 20x slower(*). I am not sure it is the smoking gun yet, as I will need to back-track a lot of code, but it looks possible. This is because std::vectorbool is specialized in the STL to be a memory efficient packed vector. I am not so sure that the memory (bool vs say unsigned char ) saved is really worth the performance hit in the case of osg::Switch (* Win32, _SECURE_SCL=0, Studio 2008) Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31323#31323 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering each primitive set differently in one osg::Geometry?
Hi Robert, I thought that was probably the case I had QUADS/TRIS/LINES in one geometry to centralize some moderately painful picking by primitive index logic. Oh well, back to the picking drawing board... Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31242#31242 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering each primitive set differently in one osg::Geometry?
Hi, I am rendering three separate primitive sets of TRIS,QUADS and LINES in one osg::Geometry object. I am rendering them using BIND_PER_PRIMITIVE of the normals with lighting enabled. Lighting of lines is not really very useful and it would be better to render the lines only in solid color. Is there any straightforward way of rendering the LINES only without lighting or is the only way to move them to their own osg::Geometry object. Is their some way of using BIND_PER_PRIMITIVE_SET to achieve this? Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31231#31231 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible wrong rotation in osgSim::ScalarBar
I would concur. This looks like a bug to me. Also the line text-setAxisAlignment( (_orientation==HORIZONTAL) ? osgText::Text::XY_PLANE : osgText::Text::XZ_PLANE ); Seems to be a workaround to the problem created by the wrong axis of rotation. I can't imagine why you would want a horizontal scalar bar in XY plane, but a vertical one in the XZ. Even after these fixes, the labeling doesn't work too well in the vertical orientation so needs some work as well. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29939#29939 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector and containment
Hi Peter, Just I did notice that for long/skinny objects the bounding sphere is a very poor fit. One option for me is to dig down and get the boundingBox() of the drawable that lies as the basis of my geometry. In my experience, that can allow for a much tighter fit for this type of selection. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=28253#28253 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PolytopeIntersector and
Hi, I am using the PolytopeIntersector to select , using a mouse based screen rectangle, objects in my scene. Works great. However, when post-processing the intersections returned by the PolytopeIntersector I would like to check for certain nodes whether the (bounding box of the ) node is ENTIRELY within the screen rectangle (aka the PolyTope of the PolytopeIntersector ). This seems like it should be trivial, but I have gone round and round in circles after searching the mailing list and now am totally confused about the best way to do this. Thanks Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=28203#28203 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector and containment
Umm, I think I found my own answer. - Subclass PolytopeIntersector to get access to the _polyTope member - transform this PolyTope by the inverse camera projection matrix to put it into world coords - When processing the Node, get the Node's bounding sphere, and transform that by the Intersection matrix into world coordinates - use the containsAllOf() method of the Polytope Whew! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=28213#28213 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Possible issue in _computeCorrectBindingsAndArraySizes (2.8.2)
Hi,
There is some code in the _computeCorrectBindingsAndArraySizes (below) that
assumes it is impossible to have numElements==numVertices in the normal array
and , for example, be BIND_PER_PRIMITIVE. The code resets to BIND_PER_VERTEX.
Consider a series of triangle primitives making a strip that loops back on
itself, say 4 nodes on the top edge, and 4 on the bottom for a total of 8
vertices. Like , for example, the sides of a cube as tris.
The number of triangles to make this strip is actually 8. So in this case
numElements==numVertices and BIND_PER_PRIMITIVE is perfectly OK.
Code:
if (numElements==numVertices)
{
// correct the binding to per vertex.
if (arrayData.binding!=osg::Geometry::BIND_PER_VERTEX)
{
outWarning: in
osg::Geometry::computeCorrectBindingsAndArraySizes() std::endl
arrayName binding has been reset to
BIND_PER_VERTEXstd::endl;
arrayData.binding = osg::Geometry::BIND_PER_VERTEX;
}
return;
}
...
Andrew
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=28077#28077
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Limitation of NodeMask
Seems like at least I have started an interesting discussion here! Really, I only used PICKABLE and VISIBLE as an example-probably not the best because pickability and visibility are logically somewhat entwined. It would be better to see the mask as a set of (32) independent logical flags. The problem with the simple test which is (paraphrased) getTraversalMask() node.getNodeMask() !=0 Is that the node is traversed if ANY of the matching bits in the traversalmask and the nodemask are both 'ON'. Essentially it allows use of only one bit at one time to manage traversal. As suggested, perhaps instead of a comparison with 0, we could have a new member variable traversalMaskResult which is used for the comparison. Backward compatibility would be a bit tricky as we want a == with the traversalMaskResult. Need to do some bit-twiddling thinking! Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27662#27662 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Limitation of NodeMask
Hi, May I am not seeing something here, but using the NodeMask seems to be not able to handle 'multiple' states. For example, I am using a mask ,0x01 to control the 'visibility' of the nodes. This works great. I have another mask to control 'pickable' state of the node, say 0x02 when used with IntersectionVisitor. Obviously a node that is not visible is not pickable. That is (pickable !visible) should be culled during a IntersectionVisitor traversal Therein lies the problem that I see. A simple bitwise AND is performed between the traversal mask and the node mask and the result compared to 0. There is no mask that can be passed to IntersectionVisitor that will cull (pickable !visible). As long as the pickable bit is on, the node will always be traversed. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27588#27588 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking and clipping together
Hi, Did you ever resolve this? My only solution will be to postprocess the pick list to remove and hits outside the clipping planes. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27097#27097 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Tracking down 'invalid enumerant'
Hi, I have to make our Windows OSG app function in a reasonable manner under Microsoft Remote Desktop, which means OpenGL 1.1.0 In general it actually works pretty well but at each window refresh, I am getting a Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) What is the best way to track down why I am getting this error? Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24746#24746 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tracking down 'invalid enumerant'
Looks like GLIntercept should work... Thanks for the tip... Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24784#24784 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scientific Visualization classes?
Hi I already have the osgVTK kit as listed on http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits As far as what specific visualizations I am after... - Real contour plots - Isosurfaces + possibly many of the other types of sci-visualizations (streamlines etc) in the future. Seems like the VTK bridge is probably the way to go I suppose as it is unlikely anyone will develop all those algorithms all over again for OSG. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23626#23626 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] compiling osg with intel compiler, windows
Intel are looking at the bug. When using Visual Studio and Intel integration you can right-click/Properties on any .CPP file and change the compiler to the MS compiler. The Intel and MS compilers are 100% compatible at the link level. You can compile a project with any combination of the two compilers. I compiled OSG and OSGUtil using the Intel compiler - probably worthwhile given the number of vectorization optimizations reported. BTW, the biggest boost you can give to OSG on Windows is to set _SECURE_SCL to 0 for Release builds. This makes a huge difference to performance. This is one #define you must set for all your files, though, as it changes the size of some of the STL classes. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23551#23551 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Scientific Visualization classes?
I was looking for some SciVis classes for OSG, along the lines of VTK's very rich collection? It is possible to use use VTK as a visualization engine to prepare data for OSG (vtkActorToOSG), and I am prepared to go that way, but that is not particularly efficient in memory and speed as data has to be translated both ways. I evaluated using either VTK and OSG for a project , but found the VTK scene graph implementation is, in my experience, poorly implemented, and performance is not good once a scene graph gets more than a few levels deep. VTK's abstraction from the underlying graphics API also hurts performance. One of my test cases showed a 20x performance hit over OSG. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23553#23553 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::DrawPixels bounding box and picking (2.8.2)
Hi Robert, Thanks - confirms what I thought, better start digging through the examples... Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23001#23001 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vista/Windows 7 visual problems on resize
On Windows 7 setting the theme to Windows 7 Basic (disabling Aero) fixes all my visual problems on various Windows 7 machines ( not all nVidia). So I think we have to assume that mixing GDI and accelerated OpenGL graphics in the same window is a no-no on both W7 and Vista ( even if GDI is accelerated on W7) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23030#23030 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] compiling osg with intel compiler, windows
I submitted a bug report re this on Intel Premier support. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23031#23031 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::DrawPixels bounding box and picking (2.8.2)
Hi, - The boundingBox() method of the osg::DrawPixels is implemented, but a bit wacky as it is based purely on pixel dimensions and will in general be completely wrong. This throws off camera bounding box calculations badly. For example a 200x200 pixel image is given a BB of 200x200x200 units - Picking of a osg::DrawPixels() is not implemented. does anyone have a working implementation for these functions? Basically I am drawing small 2D images at points on my 3D model and need to be able to pick them. Thanks. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22960#22960 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Vista/Windows 7 visual problems on resize
When running on Windows 7/Vista using accelerated graphics, and when resizing a window, an MFC OSG window flashes a lot and phantom bits of the window frame are left behind while resizing. The same is seen when using an MFC CRectTracker and TrackRubberBand on the OSG 3D window, the old Rect is not properly erased and the tracks of the box are left behind. None of this is seen on XP/XP64 and is not specific to a particular graphics card vendor. If you log onto the Windows 7 machine via RDC ( which causes a default OpenGL software driver to be used) these issues are not visible. This is , I am sure , and old Vista issue , but in our field (CAE) not a single user 'upgraded' to Vista - they are upgrading to W7... Thanks for any ideas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22963#22963 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vista/Windows 7 visual problems on resize
I think this answers my question , at least regarding trying to use CRectTracker. From http://www.opengl.org/pipeline/article/vol003_7/ GDI is no longer hardware-accelerated, but instead rendered to system memory using the CPU. That rendering is later composed on a 3D surface in order to be shown on the desktop. The graphics hardware video driver is no longer involved in GDI rendering, which means that mixing GDI and accelerated 3D rendering in the same window is likely to produce corruption like stale or blanked 3D rendering, trails, etc. Using Microsoft's OpenGL software rendering (the first item in the four OpenGL implementations) will achieve GDI compatibility, but at the expense of rendering speed and lack of modern features. So no mixing of GDI and accelerated 3D into the same window... The problem with resizing is obviously related. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22965#22965 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vista/Windows 7 visual problems on resize
So this now begs the question.. how to draw a nice zoom box using 'pure' OpenGL/OSG since I can't use CRectTracker/GDI -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22966#22966 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
