Re: [osg-users] Incorrect zfar/znear when scene rendered under a PRE_RENDER camera
Thanks Farshid, that explains it all. Farshid Lashkari wrote: Hi Fred, OSG does compute the correct near/far values for pre-render cameras, assuming it is enabled for it. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54463#54463 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PatchParameter incorrect during rendering
Hi, I have two different programs, the first one of which uses GL_PATCHES primitives and has program-setPatchParameter(GL_PATCH_VERTICES) set to 1. The second program does not specify a value as it does not use GL_PATCHES. I see PatchParameter called at link time with a value of 1 for the first program, but then again with a value of 3 for the second one. Never set back to 1 when the first program is used afterwards during draw, resulting in incorrect rendering. Any idea? Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54464#54464 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compute near far and multiple cameras
Hi Sebastian and aperuggi, I too am tempted to revive this old thread. My observation regarding the Z near/far values for a PRE_RENDER camera is that they are always inherited from the master camera. Like you, I have the following scene graph: MainCamera | +--PreRenderCamera - RELATIVE_RF .| .+-- PreRenderSceneGraph (child of PreRenderCamera) | +--MainSceneGraph Both cameras are configured so that near/far are calculated using bounding volumes (COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES). According to my tests, it appears that the Z near/far values for 'MainCamera' are calculated by the OSG using the bounds of 'MainSceneGraph'. The *same* values are used for PreRenderCamera, that is, PreRenderCamera does not calculate its own Z near/far values based on its own underlying scene graph, 'PreRenderSceneGraph'. Does this match your experience too? Any insight would be greatly appreciated! Regards Fred Sebastian Messerschmidt wrote: Hi, I want to revive this relatively old thread. Can someone help me with the problem? I wasn't able to solve it. Setting the projection matrix of the PreRender2-pass in a cull callback doesn't help really. The problem behind this, is simply the fact, that the PreRender2-pass has a different scene(or at least a different cullmask) and will compute the incorrect near/far values. So I really need the near/far computation to be done by the first pass and used by the second pass. cheers Sebastian Hi folks, In my deferred setup I have multiple cameras rendering different subgraphs of the scene. Setup is more or less like this: MainCamera | PreRender1 - RELATIVE_RF(Gbuffer) | PreRender2- RELATIVE_RF(Transparent objects) | PreRender3 - ABSOLUTE_RF (SSAO) | ... | OutCamera - ABSOLUTE_RF (FullScreen Quad) The cameras are all rendering to framebuffer rendertargets and setup their render order as in the diagram above. This works really fine as long as I use setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); If I switch to any other mode in the PreRender1 the other cameras seem to use their original near/far. I already tried to set the projection matrix of the other cameras in a cull-callback (on the main and on the PreRender1) but it seems after the cullvisitor has traversed the projection-Matrix of the camera still shows the same near far planes. Also I tried to install a ClampProjectionMatrixCallback to the MainCamera. This worked, but unfortunally with the same result. The projection is indeed clamped, but it is not applied to the other relative cameras. The last hours I tried to play around with the inheritance masks of the cameras but this didn't help in any way. Any Idea what I'm doing wrong here? Also could someone explain to me what the difference between the PreRender and the NestedRender are in this setup? cheers Sebastian ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54394#54394 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Incorrect zfar/znear when scene rendered under a PRE_RENDER camera
Robert, Sorry to further fill in this thread with a question - but couldn't it be that the OSG indeed correctly calculates the near/far values for my pre_render camera, and that I simply just do not know (yet) a proper way to correctly retrieve the projection matrix? I see the CullVisitor calculates the near/far values, maybe I should hook into this and grab the values from there? Any hint is appreciated really, and again sorry for the verbose thread. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54407#54407 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Incorrect zfar/znear when scene rendered under a PRE_RENDER camera
Hi, I can render my scene graph fine when declared under the master camera in my viewer. What I am focused on is the Z far and near values, I must ensure they're good - I can inspect the view and projection matrix, render the viewing frustrum (as lines for instance), and observe that the Z far and near values are correctly set to enclose all objects in my scene. All good. I then create a PRE_RENDER, RELATIVE_RF, FBO-bound slave camera, and move over my whole scene graph to a child of this slave camera. The master camera just has the slave camera as a child now, which itself references my original scene graph. Finally I render the whole scene (viewer-frame()) and capture the contents of my framebuffer to an image file (using shaders) : it works fine. However, I can't get to display the viewing frustrum as I did before. The slave's camera view/proj matrices have been set to identity in my setup, so my expectation is that the slave camera retains the same view and projection as the master camera, right? Here, the projection part is okay, but not the depth range. The Z far and near values are way outplaced, very far away from the viewpoint (crazy values like 1.0 to 1.0 in my situation). How can I get the frustrum's properties correctly? Thank you! Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54358#54358 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Incorrect zfar/znear when scene rendered under a PRE_RENDER camera
Hi Robert, Both my master and slave cameras have matching cull settings, set to COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES. Somehow though, this doesn't work when my scene is under the slave camera. My bounding box is defined as a callback on the unique leaf drawable node I have in my graph. Z near/far calculations work fine when used with the master camera. I can't understand why I cannot retrieve a correct frustrum. Is there anything else I need to do? Cheers, Fred robertosfield wrote: Hi Fred, The OSG by default automatically computes the near/far values during the cull traversal so you don't normally need to worry about the specific settings of near/far. The 1.0 and 1.0 are simply default values and are of no particular note. The osg::Camera inherits from osg::CullSettings so have a look at CullSettings if you want to look at the various settings that you can control, in particular the near/far computation. Robert. On 31 May 2013 21:54, Fred Smith wrote: Hi, I can render my scene graph fine when declared under the master camera in my viewer. What I am focused on is the Z far and near values, I must ensure they're good - I can inspect the view and projection matrix, render the viewing frustrum (as lines for instance), and observe that the Z far and near values are correctly set to enclose all objects in my scene. All good. I then create a PRE_RENDER, RELATIVE_RF, FBO-bound slave camera, and move over my whole scene graph to a child of this slave camera. The master camera just has the slave camera as a child now, which itself references my original scene graph. Finally I render the whole scene (viewer-frame()) and capture the contents of my framebuffer to an image file (using shaders) : it works fine. However, I can't get to display the viewing frustrum as I did before. The slave's camera view/proj matrices have been set to identity in my setup, so my expectation is that the slave camera retains the same view and projection as the master camera, right? Here, the projection part is okay, but not the depth range. The Z far and near values are way outplaced, very far away from the viewpoint (crazy values like 1.0 to 1.0 in my situation). How can I get the frustrum's properties correctly? Thank you! Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54358#54358 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54360#54360 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Incorrect zfar/znear when scene rendered under a PRE_RENDER camera
There might be one wrong thing. When creating the slave camera, I set it up as a child of my master camera. Should I used osg::View::addSlave(Camera) instead, and leave my master camera's scene graph empty? Sorry if this question has been answered before I am all mixed up with regards to the registration of slave cameras. Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54361#54361 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GL 4.3 compute shader integration
Hi, Anybody working on basic compute shader integration? Just the new shader type and a way to kick off the job using DispatchCompute would be awesome. Might look into this next month if nobody is up for it. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49611#49611 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RESOLVED Re: Repository broken with SVN =1.7.5?
Hi, I have problems accessing SVN repositories today using a 1.6.7 client (! maybe I should upgrade). On a side note, I can't access www.openscenegraph.org either. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49623#49623 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RESOLVED Re: Repository broken with SVN =1.7.5?
Thanks for the heads up. I have set up the git repository. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49636#49636 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple MatrixTransforms, single geometry
Thanks, I will just do this. I'm a bit fuzzy as to what is or isn't part of the state in OSG (osg::StateSet, things deriving from osg::StateAttribute, which buffer objects aren't). I guess the rule is that everything that IS part of the state in OpenGL also is part of the state in OSG. Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47797#47797 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multiple MatrixTransforms, single geometry
Hi, I have some geometry that is making use of a VBO. The VBO contains an extremely large number of vertices. Similarly, I have an element buffer (EBO) that contains a large amount of indices. I need to render some objects that reference selected vertices of the VBO and selected indices of the EBO, sequentially, but under different model-view transformations. Basically, what I am trying to achieve with OSG is the following OpenGL code: Code: glBindBuffer(my_huge_vbo) glBindBuffer(my_huge_ebo) glLoadMatrix(...); // transformation 1 glDrawElements(GL_TRIANGLES, 10, , offset_to_EBO_indices_for_object1); // draw the first object under transformation 1 glLoadMatrix(...); // transformation 2 glDrawElements(GL_TRIANGLES, 50, , offset_to_EBO_indices_for_object2); // draw the first object under transformation 2 glLoadMatrix(...); // transformation 3 glDrawElements(GL_TRIANGLES, 8, , offset_to_EBO_indices_for_object3); // draw the first object under transformation 3 and so on My problem is that if I have the following scene graph (see below), I will have many VBO/EBO buffer bindings, which is what I want to avoid. Code: - MatrixTransform - Geode - Geometry - MatrixTransform - Geode - Geometry - MatrixTransform - Geode - Geometry Is there a way to manually assign a VBO and an EBO to a geometry? If this is the case I could share these across different osg::Geometry object instances. Regards Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47788#47788 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple MatrixTransforms, single geometry
Hi David, Thanks for the quick reply! ledocc wrote: I already have to do this kind of optimization, I have used a NodeVisitor to traverse the graph and assign VBO and EBO to geometries. Sounds like you are reusing the same VBO/EBO for all geometries. Did you check that OSG is indeed not binding/unbinding the buffers every time? Sorry if I am asking this question again, but it is a central consideration for me. Again thanks for your reply, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47790#47790 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk before todays 2.9.15 dev release.
Hi, No problem building for me here on Windows 7, VS2010 SP1, 32-bit build, default CMake options + BUILD_OSG_EXAMPLES. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39936#39936 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
robertosfield wrote: Hi Fred, On Sat, May 28, 2011 at 1:18 PM, Fred Smith wrote: On Windows XP or 7, AMD or nvidia hardware, they *are* causing a huge leak. Ever head of driver problem??? Go try another OS, Go try another type of hardware, Go try another driver, Go try a memory tracking tool. Who are you going to convince this is a driver or OS problem here? Yourself? robertosfield wrote: As to how to do RTT I am basing my code off the very little example code there is in OSG and since comments in both source and the generated documentation are quite rare who knows if this is the most politically-correct way of doing it. There is lot of examples of RTT. Lots of dicussion on osg-users. Lots of mention that creating and destroying context and Camrea is not good, and to prefer using node masks. The fact you don't seem to be willing to help here is certainly another thing worth noticing. You seem to take this very personally. I am starting to wonder if you accept criticism, the tone of your message is aggressive. You might realise that others might get fed up with have to follow up on confused and poorly put together examples. I have lots of other work to, lots of other problems to resolve. Some users make the effort to make stuff easy to follow, it makes all the difference, go look at the problems I've helped resolve this week, look at the process. Robert. Some people leading OSS library projects take the time to explain why a particular thing doesn't work, avoid lecturing people posting to forums and generally transform constructive criticism - and to some extent here, offer to help on testing - into an opportunity to develop their project so that it can reach the next level, particularly when stability is a concern. Anyway this discussion probably lasted long enough. At least the end of it reveals a bit more about who's behind OSG - pardon me, the OSG - and starts to answer some of my questions regarding whether I want or not help solve issues I might find. As for the mess you were talking about, the few lines of superflous code I had in the repro were nothing compared to the mess you were trying - and eventually managed - to put in this discussion. That said let me wish you a good end of week end. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39902#39902 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
robertosfield wrote: ...both of which are attached, I run both tests : fbotest --testRTT And fbotest And both run without problems and without memory growth, there both seem fine, despite be pretty dire ways to drive the OSG, both seem to not cause any problems. But they do. They just do, for heaven's sake. On Windows XP or 7, AMD or nvidia hardware, they *are* causing a huge leak. With release 2.9.10 there is no leak on testRTTCamera(). The large code changes you made following this release, as the OP might have noticed, may be to be blamed. As to how to do RTT I am basing my code off the very little example code there is in OSG and since comments in both source and the generated documentation are quite rare who knows if this is the most politically-correct way of doing it. The fact you don't seem to be willing to help here is certainly another thing worth noticing. You seem to take this very personally. I am starting to wonder if you accept criticism, the tone of your message is aggressive. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39895#39895 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi, Will this issue likely be addressed in the near future? I guess only somebody relatively experienced with the OSG code base can dig into this. I can test the code quite extensively as I have routines that process a lot of data. Right now I'm stuck with release 2.9.10. Not absolutely sure there is no minor leak with that release either. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39844#39844 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
robertosfield wrote: Hi Fred, Please try the latest updates to svn/trunk, it may or may not address the issues you have seen. If it doesn't please put together a small example that reproduces the problem. Robert. robertosfield wrote: Hi Fred, On Fri, May 27, 2011 at 1:12 PM, Fred Smith wrote: Will this issue likely be addressed in the near future? I guess only somebody relatively experienced with the OSG code base can dig into this. I can test the code quite extensively as I have routines that process a lot of data. Right now I'm stuck with release 2.9.10. Not absolutely sure there is no minor leak with that release either. I really don't know what is amiss and your modified version osggeometry.cpp I find just plain confusing. I can't start testing something that I don't under is supposed to do in the first and why. What you've provide as a test case just doens't make sense to me, I can't work why you'd do what you are trying to do in this way. I can't dive in on topic that I have no grasp of. Run the modified osggeometry.cpp sample and look at the memory usage. There is, apparently, a big memory leak. Increase the number of times testRTTCamera() is called and you should see the leak even better. As to why I'm doing what I'm doing, this is to do RTT. I need to do offscreen rendering at some point in my application, and for this purpose I'm adding a slave camera to my existing viewer, then do my RTT rendering, then dispose of the aforementionned camera. It's either that, or I use a separate viewer and do the RTT rendering from there. In both cases I have a memory leak. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39848#39848 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Attached is a cleaned up, less messy version of the repro.
testRTTCamera() shows off the leak with offscreen rendering using a slave camera
testLeak() shows off the GraphicsContext leak.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39855#39855
/* OpenSceneGraph example, osggeometry.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgGA/TrackballManipulator
#include osgViewer/Viewer
#include osg/Math
#include iostream
// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent. This demo uses the OpenGL red book diagram of different
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives. The OpenSceneGraph
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls. Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!
// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in the scene. osg::Geometry contains all the vertex, normal
// color and texture coordinate arrays required to specify the coordinates of your objects, and the
// primitives join these coordinates together as the points, lines or surfaces that you will see
// rendered on your screen.
//
// This demo is split into two functions, the createScene() function which creates the scene graph
// with the various primitives in it, and the main() which sets up a basic viewer window and
// adds to the it the scene generated by createScene().
struct NormalPrint
{
void operator() (const osg::Vec3 v1,const osg::Vec3 v2,const osg::Vec3 v3, bool) const
{
osg::Vec3 normal = (v2-v1)^(v3-v2);
normal.normalize();
std::cout \t(v1) (v2) (v3) ) normal (normal)std::endl;
}
};
// decompose Drawable primitives into triangles, print out these triangles and computed normals.
void printTriangles(const std::string name, osg::Drawable drawable)
{
std::coutnamestd::endl;
osg::TriangleFunctorNormalPrint tf;
drawable.accept(tf);
std::coutstd::endl;
}
osg::Node* createScene()
{
// create the Geode (Geometry Node) to contain all our osg::Geometry objects.
osg::Geode* geode = new osg::Geode();
// following are separate blocks for creating POINTS, LINES, LINE_STRIP, LINE_LOOP, POLYGON, QUADS,
// QUAD_STRIP, TRIANGLES, TRIANGLE_STRIP and TRIANGLE_FAN primitives. An image of these primitives
// is provided in the distribution: OpenSceneGraph-Data/Images/primitives.gif.
// create POINTS
{
// create Geometry object to store all the vertices and points primitive.
osg::Geometry* pointsGeom = new osg::Geometry();
// create a Vec3Array and add to it all my coordinates.
// Like all the *Array variants (see include/osg/Array) , Vec3Array is derived from both osg::Array
// and std::vector. osg::Array's are reference counted and hence sharable,
// which std::vector provides all the convenience, flexibility and robustness
// of the most popular of all STL containers.
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-push_back(osg::Vec3(-1.02168, -2.15188e-09, 0.885735));
vertices-push_back(osg::Vec3(-0.976368, -2.15188e-09, 0.832179));
vertices-push_back(osg::Vec3(-0.873376, 9.18133e-09, 0.832179));
vertices-push_back(osg::Vec3(-0.836299, -2.15188e-09, 0.885735));
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi J.P., I'll try running osgmemorytest, but I don't have the problem with OSG 2.9.10. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39526#39526 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performace issue with nVidia 400 series
dglenn wrote: Jason Daly wrote: On 05/18/2011 05:14 AM, Fred Smith wrote: Hi, The only problem that I personally heard about is about the slow transfer speed to/from GPU memory on Fermi cards. DMA transfers are said to be slower than on GTX 2xx hardware. I haven't seen anything related to computing. I think it's specifically GPU-host memory transfers that are slow. The other direction is OK, as is the computation speed. The thread on the OpenGL forums has the details, and someone posted a small program that does timing tests and illustrates the issue pretty well. http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=284065page=1 --J I looked at the link you gave and downloaded the program that was the (the 4th revision of it) and tried on my GTX 460 and an old 8800 GT and compared it to the results that was posted and something does not add up with the test program! Most people there compare GTX2xx hardware and Fermi hardware. You are comparing G80 and Fermi hardware. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39527#39527 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi,
Here is a repro of the slave camera problem (the original problem, not the
bounding box stuff).
Increase the number of testRTTCamera() iterations to see the problem better.
It seems there is something wrong with respects to how GL objects are released,
as the program is stuck after a large number of iterations.
Cheers,
Fred
Attached file: modified osggeometry.cpp source code.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39493#39493
/* OpenSceneGraph example, osggeometry.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgGA/TrackballManipulator
#include osgViewer/Viewer
#include osg/Math
#include iostream
// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent. This demo uses the OpenGL red book diagram of different
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives. The OpenSceneGraph
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls. Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!
// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in the scene. osg::Geometry contains all the vertex, normal
// color and texture coordinate arrays required to specify the coordinates of your objects, and the
// primitives join these coordinates together as the points, lines or surfaces that you will see
// rendered on your screen.
//
// This demo is split into two functions, the createScene() function which creates the scene graph
// with the various primitives in it, and the main() which sets up a basic viewer window and
// adds to the it the scene generated by createScene().
struct NormalPrint
{
void operator() (const osg::Vec3 v1,const osg::Vec3 v2,const osg::Vec3 v3, bool) const
{
osg::Vec3 normal = (v2-v1)^(v3-v2);
normal.normalize();
std::cout \t(v1) (v2) (v3) ) normal (normal)std::endl;
}
};
// decompose Drawable primitives into triangles, print out these triangles and computed normals.
void printTriangles(const std::string name, osg::Drawable drawable)
{
std::coutnamestd::endl;
osg::TriangleFunctorNormalPrint tf;
drawable.accept(tf);
std::coutstd::endl;
}
class CBCallback : public osg::Drawable::ComputeBoundingBoxCallback
{
public:
CBCallback()
{
}
virtual osg::BoundingBox computeBound(const osg::Drawable drawable) const
{
return _boundingBox;
}
protected:
/*mutable*/ osg::BoundingBox _boundingBox;
};
osg::Node* createScene()
{
// create the Geode (Geometry Node) to contain all our osg::Geometry objects.
osg::Geode* geode = new osg::Geode();
// following are separate blocks for creating POINTS, LINES, LINE_STRIP, LINE_LOOP, POLYGON, QUADS,
// QUAD_STRIP, TRIANGLES, TRIANGLE_STRIP and TRIANGLE_FAN primitives. An image of these primitives
// is provided in the distribution: OpenSceneGraph-Data/Images/primitives.gif.
// create POINTS
{
// create Geometry object to store all the vertices and points primitive.
osg::Geometry* pointsGeom = new osg::Geometry();
// create a Vec3Array and add to it all my coordinates.
// Like all the *Array variants (see include/osg/Array) , Vec3Array is derived from both osg::Array
// and std::vector. osg::Array's are reference counted and hence sharable,
// which std::vector
Re: [osg-users] Performace issue with nVidia 400 series
Hi, The only problem that I personally heard about is about the slow transfer speed to/from GPU memory on Fermi cards. DMA transfers are said to be slower than on GTX 2xx hardware. I haven't seen anything related to computing. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39496#39496 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integer vertex attribute issue. Repro included.
robertosfield wrote: I didn't even realize there was a glVertexAttribIPointer... so yes this does sound like it will be the issue. Either osg::Geometry::drawImplementation or osg::State will need to be adapted to detect the use of the interger array and use the glVertexAttribIPointer. Feel free to dive into the code and add this handling. Thanks. I actually didn't know this either. OK I'm going to look at the code, I think I should be able to make this change. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39456#39456 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Robert,
I have a serious, massive memory leak in the trunk (updated this morning at
around 10am UK time). I haven't tried with previous releases yet.
The following code leaks memory in a very important manner. Put this code
within a while (true) { testLeak(); } block and you should see memory usage
climbing fast. I'm testing on a Windows XP 32-bit system. I tried multiple
Nvidia driver versions, just to be sure I had the same results.
Code:
void testLeak()
{
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer();
osg::ref_ptrosg::DisplaySettings ds = new osg::DisplaySettings();
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits(ds.get());
traits-width = 64;
traits-height = 64;
traits-pbuffer = true;
// This probably is the offending line
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
}
This problem is making my life difficult at the moment as I do not have a
reliable way of doing a large amount of RTT.
This method for doing RTT using a separate pbuffer context is subject to a
memory leak. The other method using an ASBOLUTE_RF slave camera is also causing
some troubles. I am working on a repro to illustrate the latter. I would
appreciate any feedback on the above mentioned issue.
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39457#39457
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Robert,
I am a bit puzzled as the second problem I am having at the moment yields a
very different behavior when isolated out in a small repro.
This time I get an assertion.
Attached is a modified osggeometry.cpp file that triggers the assertion I'm
talking about. The assertion is raised when addSlave() is called.
This issue might be by design, though. Not sure.
Code:
osg::Camera *createRTTCamera(osgViewer::Viewer viewer)
{
osg::ref_ptrosg::Camera slaveCamera = new osg::Camera();
slaveCamera-setClearColor(osg::Vec4(0, 0, 0, 1)); // initialize alpha
to 1
slaveCamera-setClearMask(GL_COLOR_BUFFER_BIT);
osg::Matrixd projMatrix;
projMatrix.makeOrtho(0.0, (double)1, 0.0, (double)1, -1.0, 1.0);
slaveCamera-setProjectionMatrix(projMatrix);
slaveCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
osg::ref_ptrosg::Viewport viewport = new osg::Viewport(0, 0, 64, 64);
slaveCamera-setViewport(viewport.get());
osg::Matrixd viewMatrix;
slaveCamera-setViewMatrix(viewMatrix);
slaveCamera-setRenderOrder(osg::Camera::PRE_RENDER);
slaveCamera-setAllowEventFocus(false);
slaveCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
slaveCamera-setCullingMode(osg::CullSettings::NO_CULLING);
osg::ref_ptrosg::Camera masterCamera = viewer.getCamera();
slaveCamera-setGraphicsContext(masterCamera-getGraphicsContext());
return slaveCamera;
}
void testRTTCamera(osgViewer::Viewer viewer)
{
int oldNodeMask = viewer.getCamera()-getNodeMask();
viewer.getCamera()-setNodeMask(0);
osg::ref_ptrosg::Camera camera = createRTTCamera(viewer);
viewer.addSlave(camera.get(), false);
viewer.frame();
viewer.removeSlave(0);
viewer.getCamera()-setNodeMask(oldNodeMask);
}
void main(void)
{
osgViewer::Viewer viewer;
viewer.setUpViewInWindow(10, 10, 640, 480);
viewer.setThreadingModel(osgViewer::ViewerBase::SingleThreaded);
// add model to viewer.
viewer.setSceneData( root );
viewer.realize();
// Call this method to test the problem mentioned in the current message,
i.e. the slave camera issue. An assertion is raised when addSlave() is called.
Why?
testRTTCamera(viewer);
// Use this code to test the problem mentioned in my previous thread, eg.
the pbuffer leak issue. Memory usage will skyrocket
//while (true)
// testLeak();
viewer.run();
}
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39460#39460
/* OpenSceneGraph example, osggeometry.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgGA/TrackballManipulator
#include osgViewer/Viewer
#include osg/Math
#include iostream
// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent. This demo uses the OpenGL red book diagram of different
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives. The OpenSceneGraph
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls. Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!
// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Same issues with OSG 2.9.10. Any idea about what's going on? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39466#39466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi, Thanks Stephan, you actually replied to my original message. I have since edited it and suggested to concentrate on the leak issue. The other issue I have is still under investigation and yes, the code I had originally posted (too fast) to illustrate the second issue was incorrect ;) Thank you! Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39469#39469 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi, The second issue I had was that by design OSG doesn't assume the bounding box of a drawable should be recalculated when setting a computeBoundingBoxCallback up on the object. In other words I was expecting Drawable::_boundingBoxComputed to be set back to false when setting the callback. Shouldn't this be done? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39472#39472 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integer vertex attribute issue. Repro included.
It looks like a problem with OSG to me. OSG should be using glVertexAttribIPointer instead of glVertexAttribPointer when dealing with integer attributes. See: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=296704#Post296704 Not sure this is the actual problem but it looks like it. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39414#39414 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Integer vertex attribute issue. Repro included.
Hi,
I can successfully bind a Vec3 attribute to my vertices. But somehow, calling
setVertexAttribArray with an IntArray doesn't work for me.
I have attached a modified osggeometryshaders.cpp file to illustrate my issue.
Summary of changes:
Code:
// all shader versions changed to #version 150
// Vertex shader changes
in int inIndex;\n // declare attribute
void main(void)\n
{\n
v_color = vec4(inIndex == 1234 ? 1.0 : 0.0, 0.0, 1.0, 1.0);\n // if the
attribute is the expected value, the color will be violet - blue otherwise
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n
}\n
// C++ code changes
// createShader() changes:
#ifdef ENABLE_GEOMETRY_SHADER
pgm-addShader( new osg::Shader( osg::Shader::GEOMETRY, geomSource ) );
pgm-setParameter( GL_GEOMETRY_VERTICES_OUT_EXT, 4 );
pgm-setParameter( GL_GEOMETRY_INPUT_TYPE_EXT, GL_POINTS );
pgm-setParameter( GL_GEOMETRY_OUTPUT_TYPE_EXT, GL_LINE_STRIP );
pgm-addBindAttribLocation(inIndex, 6); // bind vertex attribute
#endif
// SomePoints() changes at the end of the constructor:
osg::IntArray *intArray = new osg::IntArray();
intArray-push_back(1234);
intArray-push_back(1234);
intArray-push_back(1234);
intArray-push_back(1234);
intArray-push_back(1234);
intArray-push_back(1234);
intArray-push_back(1234);
intArray-push_back(1234);
intArray-setName(inIndex);
this-setVertexAttribArray(6, intArray);
this-setVertexAttribNormalize(6, false);
this-setVertexAttribBinding(6, osg::Geometry::BIND_PER_VERTEX);
I've looked at the GL trace and it seems correct. There must be something I'm
missing.
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39367#39367
/* OpenSceneGraph example, osgshaders2
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
/* file:examples/osgshaders2/osgshaders2.cpp
* author: Mike Weiblen 2008-01-03
* copyright: (C) 2008 Zebra Imaging
* license: OpenSceneGraph Public License (OSGPL)
*
* A demo of GLSL geometry shaders using OSG
* Tested on Dell Precision M4300 w/ NVIDIA Quadro FX 360M
*/
#include osg/Notify
#include osg/ref_ptr
#include osg/Geode
#include osg/Geometry
#include osg/Point
#include osg/Vec3
#include osg/Vec4
#include osg/Program
#include osg/Shader
#include osg/Uniform
#include osgViewer/Viewer
// play with these #defines to see their effect
#define ENABLE_GLSL
#define ENABLE_GEOMETRY_SHADER
///
#ifdef ENABLE_GLSL
class SineAnimation: public osg::Uniform::Callback
{
public:
SineAnimation( float rate = 1.0f, float scale = 1.0f, float offset = 0.0f ) :
_rate(rate), _scale(scale), _offset(offset)
{}
void operator()( osg::Uniform* uniform, osg::NodeVisitor* nv )
{
float angle = _rate * nv-getFrameStamp()-getSimulationTime();
float value = sinf( angle ) * _scale + _offset;
uniform-set( value );
}
private:
const float _rate;
const float _scale;
const float _offset;
};
///
static const char* vertSource = {
#version 150\n
#extension GL_EXT_geometry_shader4 : enable\n
uniform float u_anim1;\n
varying vec4 v_color;\n
in int inIndex;\n
void main(void)\n
{\n
v_color = vec4(inIndex == 1234 ? 1.0 : 0.0, 0.0, 1.0, 1.0);\n // gl_Vertex;
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n
}\n
};
static const char* geomSource = {
#version 150\n
#extension GL_EXT_geometry_shader4 : enable\n
uniform float u_anim1;\n
varying in vec4 v_color[];\n
varying out vec4 v_color_out;\n
void main(void)\n
{\n
vec4 v = gl_PositionIn[0];\n
v_color_out = v_color[0];\n
\n
gl_Position = v + vec4(u_anim1,0.,0.,0.); EmitVertex();\n
gl_Position = v - vec4(u_anim1,0.,0.,0.); EmitVertex();\n
EndPrimitive();\n
\n
Re: [osg-users] large VBOs for multiple Drawables
Paul Martz wrote: On 5/6/2011 4:05 AM, Fred Smith wrote: You usually want to create GL batches that are as large as possible. 10 draw calls of 100 elements will be slower than 1 draw call of 1000 elements. Something else I have noticed a little while ago was that the stateset processing engine of OSG might be slow. One thing I have been surprised with was the performance with a scene graph containing just empty statesets on drawables vs. no stateset at all. Just having empty statesets decreases perf quite a bit, eg. just by calling getOrCreateStateSet. osgWorks.google.com contains the CountStateSets visitor, which will remove empty StateSets, just for this reason. -Paul OSG is a great piece of code, don't get me wrong - but I see a weakness here. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39193#39193 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
It means that there seems to be a cost in doing state changes with OSG. GL state changes do not necessarily incur any cost - this is implementation specific anyway - whereas OSG state changes seem to always incur one, as even going through empty statesets does incur a cost. Is that clear enough for you? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39204#39204 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
Hi Robert, The stateset performance issue, if ever encountered, can easily be worked around with a draw callback using applyAttribute/applyTextureAttribute prior to rendering every drawable. This is a very slim point where there might be room for improvement, and what you said perfectly makes sense to me. OSG is a library that I like getting familiar with, kudos to you and the community for all the good work. Best, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39209#39209 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
You usually want to create GL batches that are as large as possible. 10 draw calls of 100 elements will be slower than 1 draw call of 1000 elements. Something else I have noticed a little while ago was that the stateset processing engine of OSG might be slow. One thing I have been surprised with was the performance with a scene graph containing just empty statesets on drawables vs. no stateset at all. Just having empty statesets decreases perf quite a bit, eg. just by calling getOrCreateStateSet. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39084#39084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
robertosfield wrote: Please try the latest updates to svn/trunk, it may or may not address the issues you have seen. If it doesn't please put together a small example that reproduces the problem. I tried the trunk updated about an hour ago and I am still having problems. I see the memory usage climbing up, whereas with 2.9.10 things remain stable overall. I'll try to come up with a repro unfortunately right now I'm a bit swamped. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38727#38727 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi, I have an application using a single, unique viewer doing occasional RTT by the means of an ABSOLUTE_RF slave camera with a distinct scene graph. I had chosen a while ago to do my RTT this way and not use a separate context. I have a tool that pregenerates lots of textures, each texture generation going through a cycle of addSlave/removeSlave and distinct scene graoh disposal etc. Then, once all textures are generated, I get back to my main loop where viewer.frame() is called again. At this very moment, with release 2.9.12 - or actually a trunk snapshot somewhere inbetween releases 2.9.12 and 2.9.13 - I experience very weird issues where my application stalls quite badly for some unexplained reason. Again, this is once it gets past the texture generation and back into the main loop with viewer.frame(). I tried a release/debug build (VS2010) and noticed a couple of weird assertions with the debug build but only once or twice. Sometimes the computer freezes for a little while. When I saw these messages I decided to try with release 2.9.10. I don't seem to have the same problem with this release. These investigations are not exhaustive yet but I wanted to let you know. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38636#38636 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] gl_/osg_Vertex and gl_/osg_ModelViewProjectionMatrix difference?
Hi,
I must have been staying too long in front of my computer lately...
The following code works fine:
Code:
// GLSL
out vec4 out_color;
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
out_color = gl_Color;
}
// Trivial fragment shader code omitted here for clarity
The following code also works fine:
Code:
// C++
setUseModelViewAndProjectionUniforms(true);
setUseVertexAttributeAliasing(true);
// GLSL
uniform mat4 osg_ModelViewProjectionMatrix;
in vec4 osg_Vertex;
in vec4 osg_Color;
out vec4 out_color;
void main(void)
{
gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex;
out_color = osg_Color;
}
The following code does not work. Nothing is displayed on my screen:
Code:
// C++
setUseModelViewAndProjectionUniforms(true);
// GLSL
uniform mat4 osg_ModelViewProjectionMatrix;
out vec4 out_color;
void main(void)
{
gl_Position = osg_ModelViewProjectionMatrix * gl_Vertex;
out_color = gl_Color;
}
Why? Is there a difference between gl_Vertex/osg_Vertex and
gl_ModelViewProjectionMatrix/osg_ModelViewProjectionMatrix?
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38455#38455
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] State changes causing huge drop in framerate
hybr, I am not running a debug build. Just create a scene graph with 100 geometries, and attach a texture attribute to the stateset of each geometry. Now compare the framerate with the same scene graph, no stateset created, but a draw callback set up inside which you call renderInfo.getState()-applyTextureAttribute(0, texture). Making me believe the state 'diff' engine of OSG is very slow. I disable display lists and enable VBOs on each geometry otherwise drawImplementation or the draw callback is not called. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38299#38299 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ATI driver quality?
Hi, I'm working with both ATI/AMD and nVidia hardware, almost on a daily basis. I've had a lot of bugs with AMD drivers with regards to GLSL shader development, mainly in the compiler. It's been six months I am working with them to help them fix bugs, which they have done, but I still have a few serious issues that sometimes prevent me from doing any work on their hardware. This can be very frustrating. Dunno about OpenCL driver quality. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38246#38246 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sharing a VBO and EBO between multiple geodes
Hi, I'm trying to share a VBO and an EBO between multiple primitivesets of different geodes. My structure is the following (I always have only one primitiveset per geode, hence my question) + Geode --+ PrimitiveSet + Geode --+ PrimitiveSet + Geode --+ PrimitiveSet and so on I've tried to do it in 2 different ways: 1) By first creating one unique ElementBufferObject and one unique VertexBufferObject for the whole scene graph, but then creating individual, distinct vertex arrays for each primitivesets, eg: Code: int numberOfVertexArrays = 0; Geometry *geom = new Geometry(); // create my geometry Vec3Array *arr = new Vec3Array(); // 1 distinct vertex array for each geometry geom-setVertexArray(arr); numberOfVertexArrays++; arr-setVertexBufferObject(uniqueVbo); // use the unique VBO For the EBO, I use DrawElements::setBufferIndex(), my index being the index of the vertex array I'm adding to the EBO. Code: DrawElements *drawElements = [...]; geom-addPrimitiveSet(drawElements); drawElements-setBufferIndex(numberOfVertexArrays); 2) By creating one unique EBO and one unique VBO, and having only one unique vertex array, too. Everything's pretty much unique. In both cases, OSG keeps binding/unbinding Array and Element buffers inbetween glDrawElements calls. I mean, OSG even does this when VBO and EBO buffer ids don't change across glDrawElements calls. Isn't there a way to bind the VBO and EBO once for all at the beginning and then render everything? Or do I *have* to have everything declared in the same geometry? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38251#38251 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] State changes causing huge drop in framerate
Hi, I have a very large scene graph where I have many geodes. Each of this geode has a stateset with a GPU program defined on it, contianing a vertex and a fragment shader. The GPU program instance is unique for my whole application - I am not recreating the program over and over again for every geode. This would be an easy, silly mistake. I have done performance tests and having a StateSet assigned to each Geode causes a MASSIVE performance drop. For a given model, containing thousands of geodes, the framerate goes from 64 to 30 fps just when you call getOrCreateStateSet on every geode, causing state to be created on each individual geode. An OpenGL trace shows that OSG is clever enough to avoid calling glUseProgram(id) / glUseProgram(0) in between every geode being rendered. Declaring the GPU program once, on the topmost graph node, and not on every geode, results in the same GL trace, with no performance degradation. This suggests OSG is very heavily using the CPU to 'diff' the state changes across geodes. Is there a way, maybe by fiddling with OVERRIDE/PROTECTED flags, to improve the way OSG handles state changes, in order to keep good performance? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38256#38256 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] State changes causing huge drop in framerate
Hi JP, J.P. Delport wrote: Hi Fred, maybe have a look at this: http://www.bricoworks.com/articles/stateset/stateset.html I remember something like that state equality is only tested using pointers and not internal data. So, maybe you'll have to explicitly share state (that getOrCreate won't do). Sorry I can't actually answer from more experience. jp What about if I need to put a texture in my state? Often, each object has its own texture. Having distinct StateSet objects will be required, and I will be hit by the performance drop. What can I do in this case? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38258#38258 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
Things seem to be working today, although I need to double check everything to make sure I'm not dreaming. glUseProgram errors only happen on ATI hardware with Catalyst 11.2 drivers - I haven't tried 11.3 yet. My nvidia setup seems fine. As for the GL context version, source code modification isn't required, as it is possible to specify the version through osg::GraphicsContext::Traits. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38164#38164 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
hybr wrote: Hi Fred You can check if issue is somehow related to bounds calculation by using setCullingActive(false) on your node or geometry. Cheers, Sergey The issue is not related to bounds calculation. My bounding box is calculated correctly. Adding dummy geometries around my object has no effect. OSG refuses to handle my object with a NULL vertex array. Could it be a bug in the trunk? Nobody knows where the problem is here... Robert? Anybody using OSG using in a GL3 context which would implicitly require such a setup? Seems like the repro I've posted clearly shows the problem off, I'd be happy if somebody could give it a go. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37984#37984 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Juan Hernando wrote: I'll be very busy until next Friday so I can't answer to you properly. A quick answer is that I just replicated what I saw inside the OSG code for other textures. If you're sure that the binding is not needed, removte it. I'll try to come back to this issue later and check whether it works for me or not. Cheers, Juan No worries. Things work fine without the additional binding so far. I'm going to leave this commented out. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37985#37985 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
I can get my square if vertices reside in attribute slot number 0, not 6.
But in this case, my shader needs to be:
Code:
// vertex shader
#version 150
uniform mat4 osg_ModelViewProjectionMatrix;
in vec3 in_vertex;
void main(void)
{
gl_Position = osg_ModelViewProjectionMatrix * gl_Vertex; // gl_Vertex here,
not 'in_vertex'
}
My understanding is that gl_Vertex automatically maps to attribute index 0 with
GL 2.x. What I do not understand, however, is why replacing 'gl_Vertex' with
'in_vertex' does not work - it should do exactly the same.
My aim being to work with a GL3 context, I'm now going to test this code with
OSG_GL3_AVAILABLE. There, I should not be able to use gl_Vertex at all, so I
expect in_vertex to work. If it doesn't, I'll really, really be puzzled.
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=37994#37994
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
hybr wrote: As i understand you set your vertex array in osg to vertexattrib slot 0, setup vertexattrib binding for shader program to slot 0 for in_vertex. What result you have when use in_vertex in shader instead of gl_Vertex, exactly? Did you convert your in_vertex to vec4 with w=1.0 in shader? Shader compiler complains about something or it just dont draw anything? Yes, I do vec4(in_vertex, 1.0) otherwise the compiler would barf. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37997#37997 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
Things are extremely weird. Using in_vertex does actually work, I had misspecified the binding location. So the following line works // both gl_Vertex and vec4(in_vertex,1.0) work here gl_Position = osg_ModelViewProjectionMatrix * vec4(in_vertex,1.0); Actually this works even if I do NOT call program-addBindAttribLocation(std::string(in_vertex), 0); which is really puzzling me. Weird!?! I tried building OSG with OSG_GL3_AVAILABLE. Things build fine but I just can't get any rendering at all. First GL 3.x, isn't actually used under Windows, it is still a GL 1.x context that is created at runtime. You have to modify the source code to force the GL 3.x context creation (traits-glContextVersion = string(3.2)). The context is then created fine but after that nothing on the screen when running my modified sample. I always get an error when calling glUseProgram even though the program linked fine. Still blocked... any help appreciated... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38005#38005 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
There must be something I'm missing.
Below is a repro of my problem. This is a modification of the
osgvertexattributes sample, from the trunk.
Copy/paste the following code after createSimpleTestModel:
Code:
class MyCallback : public osg::Drawable::ComputeBoundingBoxCallback
{
public:
MyCallback() {}
virtual osg::BoundingBox computeBound(const osg::Drawable drawable) const
{
osg::BoundingBox box(0, 0, 0, 1, 0, 1);
return box;
}
};
osg::Node* createSimpleTestModelATTRIBS()
{
osg::Group* group = new osg::Group;
osg::Geode* geode = new osg::Geode;
group-addChild(geode);
osg::Geometry* geometry = new osg::Geometry;
geometry-setUseDisplayList(false);
geode-addDrawable(geometry);
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-setName(in_vertex);
vertices-push_back(osg::Vec3(0.0,0.0,0.0));
vertices-push_back(osg::Vec3(0.0,0.0,1.0));
vertices-push_back(osg::Vec3(1.0,0.0,0.0));
vertices-push_back(osg::Vec3(1.0,0.0,1.0));
//geometry-setVertexArray(vertices);
geometry-setVertexAttribArray(6, vertices);
geometry-setVertexAttribNormalize(6, false);
geometry-setVertexAttribBinding(6, osg::Geometry::BIND_PER_VERTEX);
geometry-setComputeBoundingBoxCallback(new MyCallback());
geometry-addPrimitiveSet(new osg::DrawArrays(GL_TRIANGLE_STRIP, 0, 4));
char vertexShaderSource[] =
#version 150\n
in vec3 in_vertex;\n
uniform mat4 osg_ModelViewProjectionMatrix;\n
void main(void)\n
{\n
gl_Position = osg_ModelViewProjectionMatrix * vec4(in_vertex,
1.0);\n
}\n;
char fragmentShaderSource[] =
#version 150\n
out vec4 out_fragcolor;\n
void main(void)\n
{\n
out_fragcolor = vec4(1.0, 1.0, 0.0, 1.0);\n
}\n;
osg::Program* program = new osg::Program;
program-addShader(new osg::Shader(osg::Shader::VERTEX,
vertexShaderSource));
program-addShader(new osg::Shader(osg::Shader::FRAGMENT,
fragmentShaderSource));
program-addBindAttribLocation(std::string(in_vertex), 6);
geometry-getOrCreateStateSet()-setAttribute(program);
return group;
}
Now modify main() so that it reads:
Code:
bool runConvertToVertexAttributes = true; // Note: true here
if (arguments.read(--simple) || arguments.read(--s))
{
loadedModel = createSimpleTestModelATTRIBS(); // change the function
name
}
// [...]
if (runConvertToVertexAttributes)
{
// switch on the uniforms that track the modelview and projection
matrices
osgViewer::Viewer::Windows windows;
viewer.getWindows(windows);
for(osgViewer::Viewer::Windows::iterator itr = windows.begin();
itr != windows.end();
++itr)
{
(*itr)-getState()-setUseModelViewAndProjectionUniforms(true);
// Comment out this line (I don't think I need, so I do not use it)
//(*itr)-getState()-setUseVertexAttributeAliasing(true);
}
}
Result: nothing shows up.
Expected: we should see a square.
Now uncomment the setVertexArray line when building the geometry. You will see
the square.
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=37903#37903
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
Peter Hrenka wrote: Do you set the initial Bounding Box? I think with generic Vertex Attributes OpenSceneGraph has no chance calculate the Bounding Box by itself. I calculate the bounding box myself and I set up a bounding box calculation callback for every geometry that I create through setComputeBoundingBoxCallback(). This should be enough, shouldn't it? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37875#37875 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
Things work if I call setVertexArray. I mean that I have to call setVertexArray, in addition to setVertexAttribArray, even though my shader is solely based on vertex attribute data and doesn't use GL2-style dedicated vertex coordinates data. Code: // This line should not be needed but seems required geom.setVertexArray(vertices); geom.setVertexAttribArray(verticesLoc, vertices); Is this expected? If I compile and use OSG with GL3 core profile support, will this still be required (again, it shouldn't)? On the GL trace side I don't see anything wrong when I don't call setVertexArray: glVertexAttribPointer(...); glDrawElements(...); When I also specify a vertex array the glVertexPointer call obviously seems superfluous: glVertexPointer(...); // pointless glVertexAttribPointer(...); // ok glDrawElements(...); Other custom vertex attributes that I tried to use to pass through color data behave fine. Vertex coordinates seem to be treated specially in OSG. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37879#37879 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
Peter Hrenka wrote: On the GL trace side I don't see anything wrong when I don't call setVertexArray: glVertexAttribPointer(...); glDrawElements(...); When I also specify a vertex array the glVertexPointer call obviously seems superfluous: glVertexPointer(...); // pointless glVertexAttribPointer(...); // ok glDrawElements(...); Can you compare the traces of the working and the non-working version? If so, can you spot differences in the values of osg_ModelViewProjectionMatrix? The values are the same for the working and non-working versions. My bounding box is correctly calculated. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37890#37890 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vertex Attributes
I don't believe my problem comes from the bounding box, but out of curiosity: the osgvertexattributes sample does not seem to specify a compute bounding box callback, so how come the camera is set up correctly? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37891#37891 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG_GL3_AVAILABLE, builds fine, runs weird
This is funny, I knew that I'd have to tweak my application but somehow expected OSG samples to work right out of the box, unmodified. Silly... Thanks for your reply. Even though I saw the osgvertexattributes samples I'm having problems switching to vertex attributes, that's probably worth another topic. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37863#37863 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using Vertex Attributes
Hi,
I can't get vertex attributes to work in my application.
Right now my aim is to display geometry with just any color, meaning I can have
very simple shaders, to start with.
I call setUseModelViewAndProjectionUniforms(true) on application startup to
make sure I can get the MVP matrix as a uniform. I am not calling
setUseVertexAttributeAliasing as I *think* I do not need it (I am not 100% sure
what this feature does, either).
My geometry creation code looks like the following:
Code:
int verticesLoc = 6;
geom.setUseDisplayList(false);
vertices.setName(in_vertex);
geom.setVertexAttribArray(verticesLoc, vertices);
geom.setVertexAttribNormalize(verticesLoc, false);
geom.setVertexAttribBinding(verticesLoc, BIND_PER_VERTEX);
Program *program = new Program();
program.addBindAttribLocation(in_vertex, verticesLoc);
geom.getOrCreateStateSet()-setAttributeAndModes(program, StateSet::ON);
My shaders are:
Code:
// vertex shader
#version 150
uniform mat4 osg_ModelViewProjectionMatrix;
in vec3 in_vertex;
in vec4 osg_Vertex;
void main(void)
{
gl_Position = osg_ModelViewProjectionMatrix * vec4(in_vertex, 1.0);
}
// fragment shader
#version 150
out vec4 out_fragcolor;
void main(void)
{
out_fragcolor = vec4(1.0, 0.0, 0.0, 1.0);
}
My window just remains blank. I was wondering whether the automatic setup of
the camera in the viewer would still work when vertices reside in vertex
attribute buffers.
Cheers,
Fred
NB: to refer to the previous, GL3-related topic I opened I am still using a
regular GL 1.x/2.x context here, but would like to transition to GL3 afterwards.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=37864#37864
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG_GL3_AVAILABLE, builds fine, runs weird
Hi, I'm trying to have OSG run inside a GL3 core profile context. I have downloaded gl3.h from opengl.org and followed the instruction on this thread to properly configure cmake: http://forum.openscenegraph.org/viewtopic.php?t=4224 That is: OSG_GLU_AVAILABLE OFF OSG_GL1_AVAILABLE OFF OSG_GL2_AVAILABLE OFF OSG_GL3_AVAILABLE ON OSG_GLES1_AVAILABLE OFF OSG_GLES2_AVAILABLE OFF OSG_GL_DISPLAYLISTS_AVAILABLE OFF OSG_GL_MATRICES_AVAILABLE OFF OSG_GL_VERTEX_FUNCS_AVAILABLE OFF OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE OFF OSG_GL_FIXED_FUNCTION_AVAILABLE OFF OSG builds fine, but the samples are non-functional. Things go quite wrong really. Is GL 3.x effectively supported? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37841#37841 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] View.obj : error LNK2001: unresolved external symbol public: virtual void __thiscall osg::View::Slave::updateSlaveImplementation(class osg::View ) (?updateSlaveImplementatio
robertosfield wrote: Hi Fred, This is likely to be down to the lack of an OSG_EXPORT in the declaration of View::Slave. Slave used to implemented entirely in the header, but now has methods implementated in the .cpp. I've just checked in the addition of an OSG_EXPORT, could you try this out? Robert. Hi Robert, Sorry it took me some time to reply. Things work fine now. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37674#37674 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Download details: Microsoft Visual Studio 2010 Service Pack 1 (Installer)
Hi Chris, Working with VC++ 2010 with no SP1 installed (yet) - I am not seeing any unusual behavior. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37675#37675 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] View.obj : error LNK2001: unresolved external symbol public: virtual void __thiscall osg::View::Slave::updateSlaveImplementation(class osg::View ) (?updateSlaveImplementation@Sl
Hi, Fresh SVN checkout, VC++ 2008 debug build - I get the following error when building my own application: View.obj : error LNK2001: unresolved external symbol public: virtual void __thiscall osg::View::Slave::updateSlaveImplementation(class osg::View ) (?updateSlaveImplementation@Slave@View@osg@@UAEXAAV23@@Z) This is weird, as I can see this function is actually implemented in View.cpp. Nevertheless, I can't build. Just as usually, I link to osgd.lib. Anyone knows what could be wrong? Recent changes that might affect my application? The problem doesn't happen when building OSG examples, for instance. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37618#37618 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] View.obj : error LNK2001: unresolved external symbol public: virtual void __thiscall osg::View::Slave::updateSlaveImplementation(class osg::View ) (?updateSlaveImplementatio
The problem seems to disappear when my application stops calling the following method: Code: osg::View::getSlave Any recent change in the source code that would cause this unexpected link problem? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37619#37619 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling OpenGL context binding/unbinding
Nobody here? I thought there was a way to remove the makeCurrent(context) / makeCurrent(null) calls inbetween the rendering of frames. I believe there was a message of Robert about this feature. Isn't it the case? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37239#37239 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling OpenGL context binding/unbinding
Sweet. This was the very method I had in mind but couldn't remember of the name of. Thank you ! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37241#37241 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Disabling OpenGL context binding/unbinding
Hi, If I recall correctly, there is a setting somewhere to set up an 'optimistic' rendering loop whereby OSG doesn't wrap rendering with makeCurrent(context id) / makeCurrent(null), always leaving the unique context active. Can't remember where this setting is. Could you refresh my memory? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36369#36369 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi Juan, I finally managed to make it work. Can't understand exactly what was wrong, I got mangled into several issues at the same time (signed/unsigned sampler1D vs buffer, ATI (bogus) compiler vs nvidia, texture originally too large, incorrect pixel formats...). I just ended up checking every line of code and things actually finally run fine. Your code is fine, thanks for submitting it here. I don't know if this is the best way to implement this, especially w.r.t the buffer object base classes in OSG (osg/BufferObject). Questions like that would be raised on submission for possible inclusion in the OSG code, I guess. Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35913#35913 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi, My simple fragment shader with textureSize() seem to work fine when dealing with a usampler1D uniform (the problem I had at one point was that I was giving a texture that was too big for the driver, hence the size ended up being actually 1, and my test was always failing). tex-setInternalFormat(GL_RGBA8); image-allocateImage((128*128), 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, 1); In my fragment shader: uniform usampler1D tex; My (textureSize(tex, 0) == 16384) test actually does work. When I change my code so that your TextureBuffer is used, somehow, things don't work. - I change the uniform type from UNSIGNED_INT_SAMPLER_1D to UNSIGNED_INT_SAMPLER_BUFFER. - usampler1D becomes usamplerBuffer, textureSize() becomes textureSizeBuffer(). - and of course I create a TextureBuffer and not a Texture1D object. In my GL tracer, I don't see any OpenGL error. I am trying hard to see what is wrong, but so far, I have no idea. And yet, things don't work. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35866#35866 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi Juan,
Thanks for your reply. I'm still having problems trying to make use of
texelFetchBuffer with your code.
Why texture pixel format are you using? I'm using an integer texture format.
Not sure if OSG's allocateImage method behaves ok in this case.
I am creating the texture the following way:
Code:
bbp::RTNeuron::TextureBuffer *tb = new bbp::RTNeuron::TextureBuffer();
tb-setInternalFormat(GL_RGBA8UI); // 4 bytes per pixel, R-G-B-A format as per
EXT_texture_integer formats specification
osg::Image *image = new osg::Image();
image-allocateImage(128*128, 1, 1, GL_RGBA_INTEGER, GL_UNSIGNED_BYTE, 1); //
note: width=(128*128), height=1
tb-setImage(0, image);
In my fragment shader, right now, here is what I'm doing for a quick test:
Code:
#version 150 compatibility
#extension GL_EXT_gpu_shader4 : enable
uniform samplerBuffer tex;
void main(void)
{
if (textureSizeBuffer(tex) == (128*128)) // size in pixels
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0); // red (as I am expecting)
else
gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0); // green
}
The result is always green here, not red as I am expecting.
Is there anything I am doing wrong with your code?
Regards
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35795#35795
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
fred_em wrote: Code: [...] tb-setInternalFormat(GL_RGBA8UI); // 4 bytes per pixel, R-G-B-A format as per EXT_texture_integer formats specification osg::Image *image = new osg::Image(); image-allocateImage(128*128, 1, 1, GL_RGBA_INTEGER, GL_UNSIGNED_BYTE, 1); // note: width=(128*128), height=1 tb-setImage(0, image); I am getting the same bogus result with the following standard pixel format (eg. not using EXT_texture_integer): Code: [...] tb-setInternalFormat(GL_RGBA8); // 4 bytes per pixel, regular RGBA normalized pixel format osg::Image *image = new osg::Image(); image-allocateImage(128*128, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, 1); tb-setImage(0, image); -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35798#35798 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi, When I compile your code I get the following errors: Code: error C2065: 'GL_TEXTURE_BUFFER_EXT' : undeclared identifier error C2039: 'Extensions' : is not a member of 'osg::BufferObject' error C2039: 'getExtensions' : is not a member of 'osg::BufferObject' [...] I don't see any osg::BufferObject::Extensions class in OSG's source code. Do you? Didn't you mean osg::Texture::Extensions instead? Regarding GL_TEXTURE_BUFFER_EXT, I'm usually working with and plan to include GLEW, so I should be fine. Regards Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35728#35728 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi,
OK, I temporarily replaced Extensions with GLEW, things moved forward, but I'm
stuck with the following compilation error now:
Code:
} else if (_image.valid() _image-data()) {
/* Temporary copy */
osg::ref_ptrosg::Image image = _image;
/* Creating the texture object */
_textureObjectBuffer[contextID] = to =
generateTextureObject(contextID,
GL_TEXTURE_BUFFER_EXT); // compilation error here:
error C2661: 'osg::Texture::generateTextureObject' : no overloaded function
takes 2 arguments
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35730#35730
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi Juan,
I managed to make some progress.
- I replaced osg::BufferObject::Extensions with GLEW
- I changed the other offending expression:
generateTextureObject(contextID, GL_TEXTURE_BUFFER_EXT);
to
generateTextureObject(this, contextID, GL_TEXTURE_BUFFER_EXT);
Things compile fine.
I have never used TBOs before. How do you use your new class?
Is the following correct?
Code:
// Creation
osg::TextureBuffer *tb = new osg::TextureBuffer();
// This will create a buffer of 300 * 4 bytes = 1200 bytes
osg::Image *image = new osg::Image();
image-allocateImage(300 /*width*/, 1 /*height is ALWAYS 1, right?*/, 1,
GL_RGBA, GL_FLOAT, 1); // GL_RGBA + GL_FLOAT = 4 floating point components for
my color
// here, feed buffer with data
tb-setImage(image);
Fragment shader:
Code:
#version 150 compatibility
#extension GL_EXT_gpu_shader4 : enable
uniform sampler1D tex; // shall I use sampler1D here, or sampler2D?
void main(void)
{
vec4 color = texelFetch(tex, 0); // I get a compile error here, texelFetch
is not a recognized function name (?!). I use a Fermi card with the latest
drivers. Confused with the different function names I found on the web
(texelFetch, texelFetch1D/2D, texelFetchBuffer which, I understand, are
deprecated).
[...]
}
Cheers,
Fred
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35742#35742
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
I figured out why texelFetch wasn't being compiled successfully. 1) I forgot the last argument 2) I last tried on AMD/ATI hardware, and the GLSL compiler on this platform doesn't seem to actually recognize 'texelFetch'... Now moving on with my tests. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35746#35746 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture Buffer Objects status?
Hi everyone, Are Texture Buffer Objects supported in OSG? From what I can see, I have to create and manage them myself. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35695#35695 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Juan Hernando wrote: Hi Fred, As far as I know, they are not planeed to be part of OSG's API for 3.0. I wrote a class for dealing with these textures based on the code for other texture objects. The implementation can be improved to resuse Texture::TextureObject instead or redeclaring its own TextureBuffer::TextureBufferObject class. Nevertheless it worked for me. I can contribute the code for others to use and review for future inclusion. Regards, Juan On 17/01/11 14:55, Fred Smith wrote: Hi everyone, Are Texture Buffer Objects supported in OSG? From what I can see, I have to create and manage them myself. Cheers, Fred Hi Juan, Sounds great. Your forum settings are not configured to accept private messages. I'm interested in your work, if you're willing to share some code with me drop me an email at fclXYZ.gvs at gmail.com (replace 'XYZ' with 'aux') Regards Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35697#35697 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confused with pixel buffer objects in OSG
Hi J.P., Let's say you have 1000 textures. You can't create 1000 PBOs as this would consume far too much memory. What you do is play with 2 PBOs. Have a look at the diagram here, in the figure called Streaming texture uploads with 2 PBOs: http://www.songho.ca/opengl/gl_pbo.html#unpack You load data into a first PBO with the CPU while the GPU loads texture data from another PBO. Now have a look at this thread: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=276595Searchpage=1Main=53356Words=orphanSearch=true#Post276595 This is the second method I mentionned above. It is called buffer orphaning by some people. People use this method to avoid fiddling with two PBOs. This method feels more natural to me. How can I implement this using multiple texture objects and only one osg::PixelBufferObject? Cheers, Fred NB: the songho.ca page uses buffer orphaning too - the thread on opengl.org is all about saying, providing you use orphaning, using only one PBO is sufficient -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34633#34633 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confused with pixel buffer objects in OSG
Hi Robert, Let's leave GPU - CPU transfers aside. I don't mind if they are slow. You usually have to use 2 PBOs. If I use a single PBO to upload texture data to the GPU, performance will be very low. It seems to me I have two ways to do CPU - GPU transfers efficiently. 1) Use 2 differents PBOs. Let glTexImage2D do its job with the first PBO, while I'm loading up new data into the second PBO with the CPU. 2) Use 1 PBO and the method below (feedback?) Code: // Bind PBO glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, pbo); Label1: // Request new buffer data (third parameter = NULL) // This call will return immediately. **The GPU will complete any transfer in progress with the previous buffer data**. // As far as the client side is concerned, the new buffer data is immediately available. glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, DATA_SIZE, NULL, GL_STREAM_DRAW_ARB); // Load up new pixels into the same pbo, but into its new buffer data (requested above), not the previous one glMapBuffer // returns immediately, because the GPU isn't doing anything with the new buffer updatePixels glUnmapBuffer // Issue asynchronous transfer to texture glTexImage2D(.., 0); goto Label1; This method above which should work (I think!) will most likely not be supported by OSG at all. I'll have to do things manually. However perhaps I can resort to method 1 and do something by fiddling with two osg::PixelBufferObject objects, two osg::Image objects, creating as many osg::Textures as I want, alternating osg::Texture::setImage(image1) and osg::Texture::setImage(image2), to be sure I am doing CPU and GPU work in parrallel. Thanks, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34554#34554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confused with pixel buffer objects in OSG
fred_em wrote: Hi, I am confused about how to use PBOs in OSG. I browsed the forum quite a bit but still can't make my code work. 1) GPU - CPU pixel transfers As I understand it, an osg::Image with an osg::PixelBufferObject cannot be used (yet) to read FBO contents. I have actually checked that and could see that glReadPixels() still uses a client-side memory pointer. I believe this scenario is not supported yet. Not a big deal. I understand it is possible to do this manually and follow for instance what is done in the osgscreencapture sample. This sample doesn't make use of osg::PixelBufferObject, and instead manually creates a GL PBO, manually calls glReadBuffer with a bound pixel buffer object. 2) CPU - GPU pixel transfers I gave this a go but cannot make it work yet. To see if the PBO is effectively used this time in my GL tracer I look at a current bound PBO and the last parameter of glTexImage2D, which would reflect an offset and not a client side pointer. My code to create my texture, image and PBO is the following: Code: Image *image = osgDB:readImageFile(filePath); // PBO image binding method 1 - this line has no effect for me PixelBufferObject *pbo = new PixelBufferObject(image); // PBO image binding method 2 - I get a crash in BufferObject::computeRequiredBufferSize here image-setPixelBufferObject(new PixelBufferObject()); Texture2D *texture = new Texture2D(image); geode-getOrCreateStateSet()-setTextureAttributeAndMode(0, texture, StateSet::ON); I don't see any PBO created in the GL trace, and glTexImage2D still reads image data off a client side pointer. What I am doing wrong? Cheers, Fred This looks like a bug to me. The following code works: Image *image = new Image(); image-allocate(256, 256, 1, GL_RGBA, GL_UNSIGNED_BYTE, 1); image-setPixelBufferObject(new PixelBufferObject(image)); Texture2D *texture = new Texture2D(); texture-setImage(image); The following doesn't work: Image *image = osgDB::readImageFile(...); image-setPixelBufferObject(new PixelBufferObject(image)); // I've tried image-dirty(); here, too Texture2D *texture = new Texture2D(); texture-setImage(image); In the second case, a GL tracer shows that glGenBuffers(1, ...); is called, but nothing is done beyond that. Long story short, if you create an Image with osgDB::readImageFile(), things don't work. Surprisingly enough, dirty() makes no difference. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34534#34534 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawable and OpenGL,
Hi, drawImplementation will be called once as display lists are used by default. Call Drawable::setUseDisplayList(false) to indicate you don't want a display list to be created, which will lead OSG to call drawImplementation every time your drawable needs to be rendered. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34535#34535 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Confused with pixel buffer objects in OSG
Hi, I am confused about how to use PBOs in OSG. I browsed the forum quite a bit but still can't make my code work. 1) GPU - CPU pixel transfers As I understand it, an osg::Image with an osg::PixelBufferObject cannot be used (yet) to read FBO contents. I have actually checked that and could see that glReadPixels() still uses a client-side memory pointer. I believe this scenario is not supported yet. Not a big deal. I understand it is possible to do this manually and follow for instance what is done in the osgscreencapture sample. This sample doesn't make use of osg::PixelBufferObject, and instead manually creates a GL PBO, manually calls glReadBuffer with a bound pixel buffer object. 2) CPU - GPU pixel transfers I gave this a go but cannot make it work yet. To see if the PBO is effectively used this time in my GL tracer I look at a current bound PBO and the last parameter of glTexImage2D, which would reflect an offset and not a client side pointer. My code to create my texture, image and PBO is the following: Code: Image *image = osgDB:readImageFile(filePath); // PBO image binding method 1 - this line has no effect for me PixelBufferObject *pbo = new PixelBufferObject(image); // PBO image binding method 2 - I get a crash in BufferObject::computeRequiredBufferSize here image-setPixelBufferObject(new PixelBufferObject()); Texture2D *texture = new Texture2D(image); geode-getOrCreateStateSet()-setTextureAttributeAndMode(0, texture, StateSet::ON); I don't see any PBO created in the GL trace, and glTexImage2D still reads image data off a client side pointer. What I am doing wrong? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34527#34527 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Hi, In a drawable cull callback, I have found that State::getModelViewMatrix() and State::getProjectionMatrix() are different from the matrices returned by Camera::getViewMatrix() and Camera::getProjectionMatrix(). I actually can't perform world to screen space coordinate conversion using matrices provided by the State, at least not using this kind of formula: screenSpacePoint = worldSpacePoint * view * proj * viewPortComputedWindowMatrix. The same calculation works with camera matrices. Am I missing something? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34388#34388 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Tim Moore wrote: On Thu, Dec 2, 2010 at 9:18 AM, Fred Smith () wrote: Hi, In a drawable cull callback, I have found that State::getModelViewMatrix() and State::getProjectionMatrix() are different from the matrices returned by Camera::getViewMatrix() and Camera::getProjectionMatrix(). Very few, if any, things in the State object are valid during the cull traversal. They could be changed asynchronously by the draw traversal in another thread, for example. You want the CullVisitor (actually, CullStack) methods getModelViewMatrix() and getProjectionMatrix(), which give you the concatenated matrices at that point in the scene graph. Also, as Fred said, the View matrix is not the same as the ModelView matrix. Thanks for your replies. ModelView is a bit misleading, but if you mean the difference between the drawable's model-space matrix and the view-space matrix, I follow you. Maybe I should put the question this way: in my cull callback, how can I access the View matrix, i.e. the view space - world space matrix? Anyway, I understand from your messages that one simple way to do it is the following: - cast NodeVisitor to CullVisitor (this was the bit I wasn't looking at. I am now assuming this is OK to do this, eg. this will always remain valid in future OSG versions) - call CullVisitor::getCurrentCamera() - use usual Camera methods. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34395#34395 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Geometry::setUseVertexObjects(true) doesn't enable use of ElementBufferObject?
Hi,
The way I should be using Element Buffer Objects is unclear to me.
If I use the following code:
Code:
osg::Geometry* polyGeom = new osg::Geometry();
polyGeom-setUseVertexBufferObjects(true);
osg::ref_ptrosg::DrawElementsUShort de = new
osg::DrawElementsUShort(osg::PrimitiveSet::TRIANGLE_STRIP,numIndices,myIndices);
polyGeom-addPrimitiveSet(de);
I expect the geometry to be using a VBO for vertex data *and* a VBO for index
data. However it seems only a VBO for vertex data is used, eg. the following GL
code is executed:
glBindBuffer(GL_ARRAY_BUFFER, bufferid);
glBufferData(GL_ARRAY_BUFFER, ...);
glVertexPointer(3, GL_FLOAT, 0, offset_to_VBO);
glDrawElements(GL_TRIANGLE_STRIP, 4, ..., pointer_to_local_index_array);
No EBO is created then used in the last parameter in glDrawElements().
I am surprised this block of code above doesn't work as expected, as the
Geometry.cpp file looks like this:
Code:
bool Geometry::addPrimitiveSet(PrimitiveSet* primitiveset)
{
if (primitiveset)
{
if (_useVertexBufferObjects)
addElementBufferObjectIfRequired(primitiveset);
[ ... ]
I also tried:
de-setElementBufferObject(new osg::ElementBufferObject());
but still no luck.
Furthermore, I checked the osgparametric sample and something else is
disturbing me.
In this sample, when useVBO = true, createModel() calls
geom-setUseVertexBufferObjects(true), but still manually sets up:
1) a VertexBufferObject, that it binds to the vertices
2) an ElementBufferObject, that it binds to the primitiveset
Isn't the call to geom-setUseVertexBufferObjects(true) sufficient? Isn't that
the whole purpose of setUseVertexBufferObjects()?
I'm kind of confused here. Could somebody shed some light on this.
Thanks,
-F
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=33987#33987
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry::setUseVertexObjects(true) doesn't enable use of ElementBufferObject?
robertosfield wrote: Hi Fred, You interpretation of what Geometry::setUseVertexBufferObjects(true) is correct, so what you are see looks to be a bug. Which version of the OSG are your using? A couple of weeks ago I was looking into VBO setup issues relating to the new serializers and tracked down the issues I was seeing to src/osg/Geometry.cpp, so I then tidied up the loopholes in the set up of the VBO's. The problems I saw was that is some usage models the VBO's were all setup correctly, but others it wasn't, so I closed these loopholes, these fixes are now checked into svn/trunk. There might still be some combinations of usage that I didn't spot, if svn/trunk has them then just point me in the right direction. Robert. I am working right off the trunk as I will most likely need to test recent/experimental features in the future. I was using a version from early October, IIRC. I have just updated and things work as expected now. One minor remark though. In my GL tracer, I can see the following warning: wglGetCurrentDC() wglGetExtensionsStringsARB(hex value) glGetString(...) glGetString(...) [...] glGetString(...) glGetQueryiv(GL_CURRENT_TIME_NV, GL_QUERY_COUNTER_BITS, hex value) OpenGL error GL_INVALID_ENUM detected I'm using a Radeon HD5000 graphics card, the call above is unsupported. Thanks, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33996#33996 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry::setUseVertexObjects(true) doesn't enable use of ElementBufferObject?
Robert, Out of curiosity, why does the osgparametric sample explicitly set a VBO and an EBO, in addition to calling setUseVertexObjects(true)? Thanks, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33997#33997 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Making sure I am completely freeing up OSG shader-related resources
I am not surprised this message has been left unanswered as it is not rocket science to release shader objects. It might be a bug, or at least a very unfortunate behavior, in the AMD Catalyst drivers, see: JVM won't die after shader compile http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=286315page=1 Long delay in wglDeleteContext on application exit http://forums.amd.com/devforum/messageview.cfm?catid=392threadid=141999enterthread=y Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33863#33863 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] integrating tessellation shaders into osg
I can't test your code right now because the code I am currently using in a geometry shader is compiled incorrectly on my machine and I can't make it work! I have reported a bug to AMD that they are currently investigating. I will test the code in the future, I just don't exactly know when. I'll let everybody know how things go. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33865#33865 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] New geometry object definition
Hi, I need to define an object that can be seen as a sphere - at least this is the most convenient analogy I can find right now. - it is defined by meta-properties, essentially, like by its radius and a center position. It does not contain actual geometry data per se. The actual rendered geometry is completely dynamic. - the object will need to use shaders in all cases. I might improve the implementation later so that it does not use shaders when they're not available, but shaders will be critical for a while. What can I do here? ShapeDrawable operates at the drawable level, and seems inappropriate for me as I want to enforce the use of shaders, which is a Node-level concept. I could derive from Geode, ignore all drawables underneath (not very elegant), but getStateSet/getOrCreateStateSet are not overridable, so I can't transparently add my shaders in there. Would somebody mind giving me a hint or two about the way to go? Surely there is a sample somewhere that does what I'm interested in. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33784#33784 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New geometry object definition
Paul Martz wrote: The Drawable level is entirely appropriate. Shaders can be attached per Drawable. Why not just use an empty Geometry, with appropriate shaders attached? -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum OK, I didn't see the stateset definition on the drawable. How can I set things up so that my shaders are always, transparently attached, without having to manually attach them, and regardless of how people fiddle with the stateset of the drawable once the scene graph has been built? My purpose is to write a clean, reusable class that is convenient to use for the end-user. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33788#33788 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] integrating tessellation shaders into osg
Hi Holger, I am too very interested in OSG support for OpenGL 4.x tesselation shaders. Maybe I can test your code, feel free to contact me in private. Not sure if your code already made it into the trunk (doesn't seem like it as far as I could see)? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33577#33577 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Making sure I am completely freeing up OSG shader-related resources
Hi, I'm in a situation in which my Win32 process takes a lot of time to exit, something like 15-20 seconds. This happens as soon as I attach shaders to my geode. Something I want to do first is to make sure I release OSG shader-related resources completely before exiting the application. Here is my code to use shaders then release them: Code: Geode *geode; Program *program = new Program(); Shader *vs = new Shader(...); Shader *fs = new Shader(...); program-addShader(vs); program-addShader(fs); geode-getOrCreateStateSet()-setAttributeAndMode(program, StateSet::ON); [...] // To free up resources I do: geode-setStateSet(new StateSet()); // obviously release all references to program, fs and vs here // I expect that, at this point, all shader-related stuff for OSG is gone Is this good enough? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33252#33252 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_POINTS primitiveset with only 1 point doesn't reach shaders
Thanks for your replies. I understand what's going on with osggeometryshaders with respects to the camera. I confirm turning culling off (I use osg::Node::setCullingActive(false) on my geode) makes it work. Thanks again. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33182#33182 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_POINTS primitiveset with only 1 point doesn't reach shaders
robertosfield wrote: This does suggest that small feature culling may well be the cause. I'm surprised my suggested change didn't work for you, perhaps something went amiss with the application of the change. Others in the past have come up across this issue and solved it roughly the way I've explain. Your tip *was* correct. I tried it first with osggeometryshaders and the screen actually remained empty. This wasn't because of culling this time, but because of how the camera was set up (bounding sphere reduced to a point maybe). Long story short - this was the culling. Disabling culling at camera or geode level is working for me either way. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33185#33185 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GL_POINTS primitiveset with only 1 point doesn't reach shaders
Hi, When I only have one point in a GL_POINTS DrawElements primitive, the shaders in my StateSet have no effect. It seems a primitiveset cannot contain use only one point, or the point does not reach the shaders for some reason. To reproduce the problem, change the osggeometryshaders sample so that only 1 (not 8) points are added to the vertex array. You should see 2 animated lines in this case - but nothing is displayed. A colleague of mine stumbled upon this behavior (bug?) a while ago. Is this a known bug? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33116#33116 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_POINTS primitiveset with only 1 point doesn't reach shaders
robertosfield wrote: Hi Fred, My guess is that small feature culling is culling the Geometry before it even gets into the draw traversal. You can switch off small feature culling by doing: viewer.getCamera()-setCullingMode(viewer.getCamera()-getCullingMode() ~osg::CullSettings::SMALL_FEATURE_CULLING); Robert. Hi Robert, Thanks for your reply, but that doesn't seem to work, the following code has no effect: Code: // osggeometryshaders.cpp, line 187 osgViewer::Viewer viewer; viewer.getCamera()-setCullingMode(viewer.getCamera()-getCullingMode() ~osg::CullSettings::SMALL_FEATURE_CULLING); viewer.setSceneData( root ); Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33121#33121 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stencil buffer and FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
Hi JP, As soon as I attach an image, OSG crashes on me. The problem arises in FrameBufferObject::Pimpl::Pimpl. Code: // This code crashes osg::Texture2D *texture = new osg::Texture2D(); texture-setTextureSize(1024, 1024); texture-setInternalFormat(GL_DEPTH24_STENCIL8_EXT); osg::Image *image = new osg::Image(); image-allocateImage(1024, 1024, 1, GL_DEPTH_STENCIL_EXT, GL_UNSIGNED_INT_24_8_EXT, 1); texture-setImage(image); rttCamera-attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, image); The following code works, but only if I modify Texture2D.cpp Code: osg::Texture2D *texture = new osg::Texture2D(); texture-setTextureSize(1024, 1024); texture-setInternalFormat(GL_DEPTH24_STENCIL8_EXT); rttCamera-attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, texture); Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32787#32787 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stencil buffer and FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
Frederic Bouvier wrote:
Maybe :
textureDepthStencil-setInternalFormat( GL_DEPTH_STENCIL_EXT );
...
camera-attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, textureDepthStencil);
Could work. As the depth and stencil buffer are packed, so should the texture.
(re)read http://www.opengl.org/registry/specs/EXT/packed_depth_stencil.txt
there is a paragraph that starts with :
In addition, a new base internal format, GL_DEPTH_STENCIL_EXT, can
be used by both texture images and renderbuffer storage. When an
image with a DEPTH_STENCIL_EXT internal format is attached to both
the depth and stencil attachment points of a framebuffer object (see
EXT_framebuffer_object), then it becomes both the depth and stencil
buffers of the framebuffer...
I modified the osgpackeddepthstencil sample the following way and it just
doesn't work.
Code:
if(usePDS)
{
osg::Texture2D *textureDS = new osg::Texture2D;
textureDS-setTextureSize(1024, 1024);
textureDS-setInternalFormat(GL_DEPTH_STENCIL_EXT);
rttCamera-attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, textureDS);
}
I'm using the latest nVidia drivers on Windows 7 x64 and OSG 2.8.
When looking things up with an OpenGL tracer (I used glslDevil here) the error
is generated upon the following call made by OSG:
Code:
glTexImage2D(GL_TEXTURE_2D, 0, 34041, 1024, 1024, 0, GL_DEPTH_STENCIL_NV,
GL_UNSIGNED_BYTE, )
OpenGL error GL_INVALID_ENUM detected
34041 = 0x84F9 = GL_DEPTH_STENCIL_NV according to GLew.h
Is this a bug, or am I doing something wrong?
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=32735#32735
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stencil buffer and FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
I've also tried with an image: Code: Image *pdsImage = new Image(); pdsImage-allocateImage(256, 256, 1, GL_DEPTH24_STENCIL8_EXT, GL_UNSIGNED_INT_24_8_EXT, 1); camera-attach(PACKED_DEPTH_STENCIL_BUFFER, pdsImage); This code results in the following error and then the application crashes. error type = 34042 Error: FrameBufferAttachment::FrameBufferAttachment(Camera::Attachment) passed an empty osg::Image, image must be allocated first. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32737#32737 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stencil buffer and FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
This looks like an OSG bug to me. The code is in osg\Texture2D.cpp, in Texture2D::apply. With PACKED_DEPTH_STENCIL_BUFFER, internalFormat should be GL_DEPTH24_STENCIL8_EXT, format should be GL_DEPTH_STENCIL_EXT and type GL_UNSIGNED_INT_24_8_EXT. The current OSG 2.8 code makes this GL_DEPTH_STENCIL_EXT, GL_DEPTH_STENCIL_EXT and GL_UNSIGNED_BYTE. This is incorrect, hence the driver returns GL_INVALID_ENUM. To make the osgpackeddepthstencil sample work as desired, with the code modification mentionned at the beginning of this thread, Texture2D.cpp can be modified this way: Code: if (_internalFormat == 6408) // GL_RGBA glTexImage2D( GL_TEXTURE_2D, 0, _internalFormat, _textureWidth, _textureHeight, _borderWidth, _sourceFormat ? _sourceFormat : _internalFormat, _sourceType ? _sourceType : GL_UNSIGNED_BYTE, 0); else glTexImage2D( GL_TEXTURE_2D, 0, 0x88F0, // GL_DEPTH24_STENCIL8_EXT, _textureWidth, _textureHeight, _borderWidth, 0x84F9, // GL_DEPTH_STENCIL_EXT, 0x84FA, // GL_UNSIGNED_INT_24_8_EXT, 0); Of course the code above is just a dirty modification just for testing purposes, but it does work. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32762#32762 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unexpected Scaling image from (320, 200) to (256, 256)
Vivien, Jordi, Thanks, it works fine. Somehow I missed this one. ARB_texture_non_power_of_two and co. Got it. Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32645#32645 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stencil buffer and FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
The following works fine: camera-attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, GL_DEPTH_STENCIL_EXT); Why doesn't it work if I create a texture? I need to create a texture and an image, as I want to retrieve stencil buffer data after frame() has been called. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32649#32649 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
