Re: [osg-users] Picking based on Render order, not depth
Can't you attach user data element to your Geodes or Geometry objects that roughly correspond to render bins or rendering order? Then in the intersection code, get a list of all hits, and sort it by render order first, followed by depth. This of course means that you have to pretty tightly control the render order yourself. If you want to incorporate the Z buffer results in your intersection tests, you need to render to an FBO with a Z buffer that is also readable as a texture. That allows you to extract the depth of each screen pixel and convert it to a linear distance from camera (or even a world space coordinate). Using this knowledge you can ignore intersection hits that are not anywhere close to the coordinate reported by the intersection visitor. Christian 2015-03-03 10:24 GMT+01:00 Robert Osfield robert.osfi...@gmail.com: Hi John-Luke, The osgUtil::IntersectionVisitor/LineSegmentIntersector is based of pure geometry calculations, there isn't any reference to rendering elements so has no knowledge of what may or may not have been rendered. If you want to have picking based on rendering results you'll need to implement your own scheme based on OpenGL rendering of the scene. There are a range of ways to tackle it's quite a bit more complicated than just using the OSG's standard intersection classes. Robert. On 2 March 2015 at 21:46, John-Luke Laue jlguitar...@gmail.com wrote: Hi all, Hopefully this isn't too newbie a question. Let's say I have a camera at the origin, looking down +x axis. I have a cube at position (1,0,0) and a sphere at position (5,0,0). If I render my scene normally, I will see (from the camera) the cube, but not the sphere because it is occluded by the cube. When I use the osg picker to pick with my mouse, it will pick the cube first, then the sphere. Next, I disable depth testing and give the sphere a higher render order than the cube. When I render my scene again, now I see the sphere and not the cube. However, if I use my picker again, the picker still picks the cube first, and then the sphere. I want the opposite. Which leads me to my question: Can the osg picker order the picking based on render order or is it always by depth only? Thank you for your time! Cheers, John-Luke -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62916#62916 ___ 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] Writing osg::Group to osg and osgt : Two different results
Hi,
using 3.0.1 I created the following test code:
Code:
osg::ref_ptrosg::Group group = new osg::Group();
group-setName( dummy group );
auto path = destDir_ + /group.osg;
osgDB::writeNodeFile( *group, path );
osgDB::writeNodeFile( *group, path+t );
The resulting group however is entirely different when comparing the osg file
to the osgt file:
osg file:
Group {
name dummy group
nodeMask 0x
cullingActive TRUE
}
osgt file:
#Ascii Scene
#Version 80
#Generator OpenSceneGraph 3.0.1
osg::Group {
UniqueID 1
}
They do not contain the same information. The name I've set for instance is
lost, when storing to osgt. While I am aware that default values can be skipped
during osgt serialization I doubt that the name string should be skipped at all.
How can this behaviour be explained?
Thank you!
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62929#62929
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Serialization always says: Unsupported associated class osg::Object
Hi,
using OSG 3.0.1 I've implemented a custom class deriving from osg::Object that
should support serialization:
The register object wrapper looks like this:
Code:
REGISTER_OBJECT_WRAPPER( MyLights,
new dx::MyLights,
dx::MyLights,
osg::Object dx::MyLights )
{
ADD_USER_SERIALIZER( VisionLight );
}
While the serialization to osgt works perfectly I still get msgs during
serialization:
OutputStream::writeObject(): Unsupported associated class osg::Object
InputStream::readObject(): Unsupported associated class osg::Object
Why is that happening? I know this occurs because my inheritance says
osg::Object dx::MyLights but I've searched through the osg source for classes
deriving from osg::Object and they all do the same inheritance, first
osg::Object then their own one
Example:
Code:
REGISTER_OBJECT_WRAPPER( AutoTransform,
new osg::AutoTransform,
osg::AutoTransform,
osg::Object osg::Node osg::Group osg::Transform
osg::AutoTransform )
How can I properly solve this? Leaving osg::Object simply out? Or do all those
classes generate serialization messages?
Thanks
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62924#62924
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Writing osg::Group to osg and osgt : Two different results
Hi John,
Could you post the .osg file that is revealing this problem? I can run an
osgconv on my system and see if the problem exists in OSG-3.2.x or
svn/trunk.
It does sounds like a bug. This is OSG-3.0.1 which was the first stable
release that had the new serializers. A great deal of improvements to the
serializers has happened since then a range of problems have been resolved.
There have also been lots of other bug fixes and other improvements to the
OSG since 3.0.1, there are lots of reasons to update.
Robert.
On 3 March 2015 at 12:42, John Pasnom stupid_sys...@dontsendmespam.de
wrote:
Hi,
using 3.0.1 I created the following test code:
Code:
osg::ref_ptrosg::Group group = new osg::Group();
group-setName( dummy group );
auto path = destDir_ + /group.osg;
osgDB::writeNodeFile( *group, path );
osgDB::writeNodeFile( *group, path+t );
The resulting group however is entirely different when comparing the osg
file to the osgt file:
osg file:
Group {
name dummy group
nodeMask 0x
cullingActive TRUE
}
osgt file:
#Ascii Scene
#Version 80
#Generator OpenSceneGraph 3.0.1
osg::Group {
UniqueID 1
}
They do not contain the same information. The name I've set for instance
is lost, when storing to osgt. While I am aware that default values can be
skipped during osgt serialization I doubt that the name string should be
skipped at all.
How can this behaviour be explained?
Thank you!
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62929#62929
___
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] Serialization always says: Unsupported associated class osg::Object
Hi John,
In principle the code snippets you have provided look OK.
Like in my previous email, it could well be a bug that has long been fixed
- OSG-3.0.1 was released along time ago. Without specific code to test
against there isn't any way to know the answer.
Robert.
On 3 March 2015 at 12:25, John Pasnom stupid_sys...@dontsendmespam.de
wrote:
Hi,
using OSG 3.0.1 I've implemented a custom class deriving from osg::Object
that should support serialization:
The register object wrapper looks like this:
Code:
REGISTER_OBJECT_WRAPPER( MyLights,
new dx::MyLights,
dx::MyLights,
osg::Object dx::MyLights )
{
ADD_USER_SERIALIZER( VisionLight );
}
While the serialization to osgt works perfectly I still get msgs during
serialization:
OutputStream::writeObject(): Unsupported associated class osg::Object
InputStream::readObject(): Unsupported associated class osg::Object
Why is that happening? I know this occurs because my inheritance says
osg::Object dx::MyLights but I've searched through the osg source for
classes deriving from osg::Object and they all do the same inheritance,
first osg::Object then their own one
Example:
Code:
REGISTER_OBJECT_WRAPPER( AutoTransform,
new osg::AutoTransform,
osg::AutoTransform,
osg::Object osg::Node osg::Group osg::Transform
osg::AutoTransform )
How can I properly solve this? Leaving osg::Object simply out? Or do all
those classes generate serialization messages?
Thanks
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62924#62924
___
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] Writing osg::Group to osg and osgt : Two different results
Hi, Robert, I've attached both files (or I've tried, looks like it ignores the second attachment...) Another interesting part is, as far as I can see, the UserData should be serialized as well. The patch posted http://forum.openscenegraph.org/viewtopic.php?t=5561 seems to be already in 3.0.1 but it looks like my custom user data (derived from object and extended by wrapper) is ignored here. Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62932#62932 group.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.3 developer release
Hi Stephan, I have return to the issue of the visualization problems with the database you provided. Eventually was able to isolate the problem to the binary parsing of the ClusterCullingCallback which in the end was fixable by just adding a osg::Callback entry into the ClusterCullingCallback serializers associates list, as this is now required as the NodeCallback no longer takes responsibility for the NestedCallback serialization, this is now move to osg::Callback. The Warning: CollectLowestTransformsVisitor::removeTransforms() error, encountered a NULL Transform pointer looks to be an erroneous error, as the case it occurs perfectly benign - so I've addressed it by removing this reporting code. Could you please update to svn/trunk and let me know if these problem have been resolved. I will now wrap up the next dev release (3.3.4) in prep for 3.4 stable release. Testing is really important now as we are just weeks away from a stable release. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenScenGraph-3.3.5 dev release tagged
Hi All, From the http://www.openscenegraph.org/index.php/download-section/developer-releases page: *O**pen**SceneGraph-3.3.5, **released on 3rd March **2015*, key deliverables in this dev release are: - No new features this dev release as we are now focusing on refining the software for the up coming OSG-3.4 stable release - Bug and build fixes *source package :* OpenSceneGraph-3.3.5.zip http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.3.5.zip *svn tag:* svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.3.5 OpenSceneGraph I have a few more items to tidy up before I make the OSG-3.4 branch, these aren't big changes though so 3.3.5 is getting pretty close to what will make into OSG-3.4. As we are so close to stable release please test svn/trunk or the OSG-3.3.4 dev release on as many patforms and applications as you can. Cheers Robert. ChangeLog since 3.3.4 -- 2015-03-03 14:59 robert * src/osgWrappers/serializers/osg/ClusterCullingCallback.cpp: Fixed ClusterCullingCallback parser problem due to osg::Callback not being included in inheritance list 2015-03-03 12:56 robert * src/osgUtil/Optimizer.cpp: Restructed the checks in the CollectLowestTransformsVisitor::removeTransforms() to avoid benign case being flagged as warning. 2015-03-03 12:03 robert * include/osgDB/ObjectWrapper, include/osgDB/Serializer, src/osgWrappers/serializers/osg/Camera.cpp, src/osgWrappers/serializers/osg/ClearNode.cpp, src/osgWrappers/serializers/osgText/TextBase.cpp: From Miha Ravselj, Regarding previous submission it was only partial solution. After further testing I found similar bug also in ClearNode serializer. //GLbitfield mask = GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT; This line was problematic since it produced incorrect result when let's say COLOR flag is serialized it should be null as in Camera serializer or in a proposed BitFlagsSerializer This line of code caused that whenever only GL_COLOR_BUFFER_BIT bit was written and on value read GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT was restored instead of GL_COLOR_BUFFER_BIT only. //GLbitfield mask = 0; //this resolves the issue same as in camera Also same bit-wise comparison bug was also present in write method. - As you can see there are total 3 bit mask serializers in OSG and all 3 had bugs so I decided to add ADD_BITFLAGS_SERIALIZER and replace USER serializers in osg::Camera, osg::ClearNode and osgText::TextBase. I have made sure that bitflags serializer does not break backwards-compatibility since it uses same code as user serializer does in all 3 cases. (see tester.cpp on how compatibility test was performed) 2015-03-03 12:00 robert * src/osg/PolygonMode.cpp: Re-organized the #ifdef's to avoid usage of glPolyginMode under GLES 2015-03-02 14:38 robert * CMakeLists.txt: Updated SO_VERSION to take account of API changes in osgDB 2015-03-02 12:11 robert * include/osgDB/ConvertBase64, src/osgDB/CMakeLists.txt, src/osgDB/ConvertBase64.cpp, src/osgDB/InputStream.cpp, src/osgDB/OutputStream.cpp: From Johannes Scholz, Attached you find a patch for osgDB::OutputStream and osgDB::InputStream to include osg::Image::data() using Base64 encoding inside the ASCII OSGT, if WriteImageHint=IncludeData is set, only. 2015-03-02 12:09 robert * examples/osgtessellationshaders/osgtessellationshaders.cpp, include/osg/GLDefines: From Michael McDonnel, The tessellation shader example has a small bug.The middle of the geometry is clipped as soon as it is tessellated. The clipping is probably caused by rounding errors because it is only in one spot. The clipping disappears when the camera is moved, and reappears when it is moved back. Expanding the the bounding box fixed the clipping bug. Tweaked by Robert Osfield to expand it to a -1 to 1 unit box. Actual clipping bug is not due to rounding errors but the shaders creating vertices outside the bounding box of the original input vertices 2015-03-01 15:20 robert * examples/osgshadercomposition/osgshadercomposition.cpp: Fixed StateSet::Define names to match OpenSceneGraph-Data/shaders. 2015-03-01 11:08 robert * src/osgGA/OrbitManipulator.cpp, src/osgGA/StandardManipulator.cpp: From Jannik Heller, I noticed the rotation in the OrbitManipulator depends on the framerate. To reproduce this issue, start the osganimate example, rotate the model with the left mouse button, then let go of the mouse button while still moving. You will notice that with V-Sync enabled, the model rotates slower.
Re: [osg-users] Compute shaders halt
Hi Steven, I never came across that compute shader execution stopped , but in som cases I experienced some flickering that could somehow depend on culling, but I did not find the reason for this. You could try to track if glDispatchCompute() in Program.cpp is called properly and at the right time on your system. In osgcomputeshaders example, i remember, there was an issue that it only worked for me if this axes.osgt model was added to the scene (Line 66). Could you describe your scene a little bit more? What is somehow special with the geometry that will stop your computeshader ? regards, Markus Den 02.03.2015 18:14, skrev Steven Powers: Hi, I'm using the compute SSBO technique to handle a particle system. I have everything working but in some cases the compute shader stops functioning and the particle system freezes. This seems to happen when a particular geometry in the scene is drawn. If the geometry is culled the particle system works just fine. The scene graph looks like this: -Group +computeNode (with the SSBO and compute shader attached) - Group + rendering particle system with geom/vert/frag shaders attached + test geometry (readNodeFile(test.osg)) If the test geometry is off screen the computeNode functions fine. If it is on screen the computeNode no longer runs the compute shader. Also, if I attach a static geometry (read from a file) to the computeNode this problem no longer occurs. Even if that geometry is loaded from the same file as the test geometry. When it works the scene graph looks like this: -Group +computeNode (with the SSBO and compute shader attached) - Group + rendering particle system with geom/vert/frag shaders attached - test geometry (readNodeFile(test.osg)) + test geometry (readNodeFile(test.osg)) Thank you! Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62913#62913 ___ 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 of a fbx 3D model
Hi, ... I just buy some fbx 3D model with some animation,each 3D model have one main part .fbx file and some separate animation .fbx file. main part .fbx dose not has animation effect if not loading other animation .fbx file . The problem is,when loaded a main part .fbx with osgviewer ,I found the update frame is extremely higher than a normal 3D model which without animation.Like pitcure below: [img]http://bbs.osgchina.org/forum.php?mod=attachmentaid=NjE2NHw4OTNhYTA4M3wxNDI1Mz [/img] the update frame is 6.8 . If I convert main part .fbx to main part .ive ,the update frame is 0.0~0.01 more than 100 main part .fbx will drop performance of our app significantly. I think a fbx file may attach some bone updatecallback even it does not run a animation , so the question is ,may i close the updatecallback of a fbx file when i do not need the animation ,or other way just improve the performance of a fbx 3D model? Thank you! Cheers, Lv -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62939#62939 Attachments: http://forum.openscenegraph.org//files/1_688.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Writing osg::Group to osg and osgt : Two different results
Hi John,
I have ran osgconv on the file:
osgconv group.osg out.osgt
And the resulting files looks like:
#Ascii Scene
#Version 117
#Generator OpenSceneGraph 3.3.5
osg::Group {
UniqueID 1
Name dummy group
}
Which is correct. So svn/trunk works correctly w.r.t Name. I expect
OSG-3.2.x will also work as well.
I can't provide free support for OSG-3.0.x so if you want to resolve this
problem I'd suggest updating to OSG-3.2.1 or svn.trunk (which is very close
to up coming stable release 3.4.)
Robert.
Robert.
On 3 March 2015 at 13:04, John Pasnom stupid_sys...@dontsendmespam.de
wrote:
Hi,
Robert, I've attached both files (or I've tried, looks like it ignores the
second attachment...)
Another interesting part is, as far as I can see, the UserData should be
serialized as well. The patch posted
http://forum.openscenegraph.org/viewtopic.php?t=5561 seems to be already
in 3.0.1 but it looks like my custom user data (derived from object and
extended by wrapper) is ignored here.
Thank you!
Cheers,
John
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62932#62932
___
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] OpenSceneGraph-3.3.3 developer release
Hi Robert, Hi Stephan, You don't seem to like my name ;-) I have return to the issue of the visualization problems with the database you provided. Eventually was able to isolate the problem to the binary parsing of the ClusterCullingCallback which in the end was fixable by just adding a osg::Callback entry into the ClusterCullingCallback serializers associates list, as this is now required as the NodeCallback no longer takes responsibility for the NestedCallback serialization, this is now move to osg::Callback. The Warning: CollectLowestTransformsVisitor::removeTransforms() error, encountered a NULL Transform pointer looks to be an erroneous error, as the case it occurs perfectly benign - so I've addressed it by removing this reporting code. Could you please update to svn/trunk and let me know if these problem have been resolved. I will now wrap up the next dev release (3.3.4) in prep for 3.4 stable release. Testing is really important now as we are just weeks away from a stable release. The fix works great! All older VPB-databases are running smoothly again, saving us weeks of compilation. Where can I donate? :-) Robert. Cheers Sebastian ___ 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] Questions about CompositeViewer views created/udpated/run in multiple threads
I'm using a CompositeViewer (viewer) to have multiple cameras with their own graphics contexts imaging a single scene. I've wrapped all this up in function calls that I expose to a separate UI, and so far I have the capability to change scene configuration on the fly and take simultaneous snapshots with viewer-frame(). That's really all I need, but I can only verify the scene contents by reviewing the stills from the snapshots. To get live imagery and use manipulators effectively, I figure I need to use viewer-run() or something equivalent. My first thought was to create a graphics context, apply to a view, and run() this in a separate thread. So, my questions: I'd have to call viewer-run() or equivalent, right? While the viewer is running in its thread, can a user still call my functions to take snapshots? Are these going to trigger traversals that could interfere with the running thread? What if the viewer is running and the user calls a function that adds a new node to the scene graph? What if the viewer is running and the user calls a function to add a second live view? How much trouble am I asking for here? What should the threading model be for the viewer, or does that even matter in this sense? Is there anything inherently problematic about this approach? Any part of the approach. Many thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62937#62937 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Remote Deskstop Display issue
Hi, Recently, I found a display problem with using remote desktop connection. If I used RDC connected to remote machine and then start the an application with embed osg viewer, the viewer cannot display volume image probably (empty image). If the application is already started at remote machine before RDC connection, the volume image can display probably and everything working fine. I think the problem may relate to opengl32 library. If the application is started after RDC connection, then osg will load opengl32 library which is based on RDC generic display driver. That driver cannot osg volume image. I also tested with the machine which has nvidia quadro installed. The problem is gone even before or after RDC connection to start the application. Does anyone have a solution to solve this problem? Is possible to force osg is not using generic display driver? Thanks. Regards, Clement ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.3 developer release
HI Sebastian, On 3 March 2015 at 17:09, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Hi Robert, Hi Stephan, You don't seem to like my name ;-) Sorry about that, too many hours coding of late. The fix works great! All older VPB-databases are running smoothly again, saving us weeks of compilation. Where can I donate? :-) Blood or organ donation? ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Android not building. Can someone have a look...
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
Re: [osg-users] Android not building. Can someone have a look...
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
Re: [osg-users] Compute shaders halt
Hi Stephan, This type of issue isn't something that others can really help with, there are simply too many unknowns. It could be a driver bug, a problem with your shaders, a hardware problem, an OS problem, a problem in the OSG, a problem in your application. Even if you have everything in front of you and able to re-produce it's still hard. The best we can do is make suggestions on possible things you can look at to diagnose what might be amiss. First thing I'd do is see if there are any GL debugging tools available on your platform. Second thing would be to simplify your application, data and shaders to see when things break. Third, try different hardware, drivers, OS etc. Robert. On 2 March 2015 at 17:14, Steven Powers stevenapow...@gmail.com wrote: Hi, I'm using the compute SSBO technique to handle a particle system. I have everything working but in some cases the compute shader stops functioning and the particle system freezes. This seems to happen when a particular geometry in the scene is drawn. If the geometry is culled the particle system works just fine. The scene graph looks like this: -Group +computeNode (with the SSBO and compute shader attached) - Group + rendering particle system with geom/vert/frag shaders attached + test geometry (readNodeFile(test.osg)) If the test geometry is off screen the computeNode functions fine. If it is on screen the computeNode no longer runs the compute shader. Also, if I attach a static geometry (read from a file) to the computeNode this problem no longer occurs. Even if that geometry is loaded from the same file as the test geometry. When it works the scene graph looks like this: -Group +computeNode (with the SSBO and compute shader attached) - Group + rendering particle system with geom/vert/frag shaders attached - test geometry (readNodeFile(test.osg)) + test geometry (readNodeFile(test.osg)) Thank you! Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62913#62913 ___ 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] writeNodeFile question
Hi Clement, Yesterday I merged a submission to OSG svn/trunk that added read/write support for inlined image data within .osgt and .osgx ascii files. To tell the .osgt, .osgx writer to inline the data you should use the OptionsString WriteImageHint=IncludeData. Robert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fwd: Last update in the osgAnimation::Animation ONCE mode bug fix
Hi Konstantin,
Thanks for the full name.
I haven't decided how best to tackle this submission yet. As is it would
cause a performance hit as Pjotr explained. I'm open to suggestions of how
best to resolve this issue whilst addressing the bug your change sought to
address.
Cheers
Robert.
On 28 February 2015 at 23:34, Matveyev Konstantin lalakos...@gmail.com
wrote:
Konstantin Matveyev
On Nov 20, 2014, at 12:46 PM, Robert Osfield wrote:
Hi KOS,
I have just got to reviewing your proposed change to Animation.cpp. What
name would you like me to use when attributing this fix when I check it in?
Cheers,
Robert.
On 27 August 2014 13:03, Konstantin lalakos...@gmail.com wrote:
-- Forwarded message --
From: Konstantin lalakos...@gmail.com
Date: 2014-08-26 18:27 GMT+04:00
Subject: Last update in the osgAnimation::Animation ONCE mode bug fix
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org,
osg-submissi...@lists.openscenegraph.org
Hello everybody!
*osgAnimation/Animation.cpp**bool Animation::update (double time, int
priority)*
*OpenSceneGraph 3.2.1*:
case ONCE:
if (t _originalDuration)
return false;
*Should be:*
case ONCE:
if (t _originalDuration)
{
*for (ChannelList::const_iterator chan = _channels.begin();
chan != _channels.end(); ++chan)
(*chan)-update(_originalDuration, _weight, priority);*
return false;
}
*maybe :)*
KOS
___
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking based on Render order, not depth
Hi John-Luke, The osgUtil::IntersectionVisitor/LineSegmentIntersector is based of pure geometry calculations, there isn't any reference to rendering elements so has no knowledge of what may or may not have been rendered. If you want to have picking based on rendering results you'll need to implement your own scheme based on OpenGL rendering of the scene. There are a range of ways to tackle it's quite a bit more complicated than just using the OSG's standard intersection classes. Robert. On 2 March 2015 at 21:46, John-Luke Laue jlguitar...@gmail.com wrote: Hi all, Hopefully this isn't too newbie a question. Let's say I have a camera at the origin, looking down +x axis. I have a cube at position (1,0,0) and a sphere at position (5,0,0). If I render my scene normally, I will see (from the camera) the cube, but not the sphere because it is occluded by the cube. When I use the osg picker to pick with my mouse, it will pick the cube first, then the sphere. Next, I disable depth testing and give the sphere a higher render order than the cube. When I render my scene again, now I see the sphere and not the cube. However, if I use my picker again, the picker still picks the cube first, and then the sphere. I want the opposite. Which leads me to my question: Can the osg picker order the picking based on render order or is it always by depth only? Thank you for your time! Cheers, John-Luke -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62916#62916 ___ 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] [vpb] osgdem Colormap gets flipped
Thanks a lot for your efforts! Yes, for the former version exporting as .osgb and .ive works fine and also by passing -O ddsNoAutoFlipWrite to osgdem I can export in .osg without problems. After pulling your changes I can confirm that no workaround is needed any more. Superb! Happy Michi -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62934#62934 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
