Re: [osg-users] Custom Drawing for Geode
On Thu, Sep 2, 2010 at 11:59 PM, Frank Sullivan knarf.navil...@gmail.comwrote: Hi, I am working on an ocean water effect that basically consists of a tessellated plane that undulates in a wave-like motion. It's just a flat plane, but it has a vertex shader that creates the wave motion by adding a few sine waves together. And this is working perfectly well, but my problem is that I want this ocean water surface to be about 2km^2, and I can't have that entire plane heavily-tessellated, or I'll run into trouble. =) Not to mention extending out to the horizon... So I need to make sure that only the parts of the water near the camera are heavily-tessellated, and that the parts of the water further away are less-heavily-tessellated. Pretty basic stuff for some of you pros, I'm sure. =) So what I've decided to do is divide the water surface up into a grid of cells, and give each cell a different tessellation level. A top-down view of it might look something like this: http://imgur.com/cVR5T.gif As you can see, the closer a grid cell is to the camera, the more heavily-tessellated it is. Also, note that if two cells of different tessellation levels are adjacent to one another, the cell with the lower-tessellation will have a special seam. Finally, the cells that are shaded in gray should not be drawn, because they are not in the viewing frustum. I don't want to totally re-compute the geometry for this each frame, so I've precomputed a set of 36 cell meshes, which covers 6 levels of tessellation, and 6 seam types for each level. Each of these pre-computed meshes is an osg::Geometry object. I've done this so that, each frame, all I have to do is decide which grid cells are in the frustum, and which of the precomputed meshes to draw at each visible grid cell location. I'm not quite sure how best to do this within the OSG paradigm, though. I thought about maybe creating an OceanGeode class that, during the cull traversal, wipes out its list of drawables, and then calculates how the grid should be laid-out, and then re-adds these Geometry objects back to its drawables list. However, I'm not sure if I can add the same Geometry object more than once, and even if I could, I'm not sure how I could instruct each drawable to draw in a different location, because if I recall correctly, drawables don't have their own transformation matrices. You can do this, but it involves some hairy interaction with OSG's draw code. You would first need to study the code for osgUtil::CullVisitor::apply(Geode) and understand it. At this level you can, in fact, specify a different matrix for each Geometry, and you can also choose which Geometry objects to add to the rendering list with addDrawableAndDepth(). You would need to make sure that OceanGeode does the right thing in calculating the bounding volume of the patch. To solve the last problem, I could pass down a grid coordinate to the shader and have the vertex shader transform it to the correct place. That is a possibility. Alternately, I could assign each pre-computed Geometry object to a separate Geode, and then give each of these Geodes 0 or more MatrixTransform parents. Then, each of those MatrixTransforms would share a single WaterNode parent that manages them all. I've taken a similar approach in the Seamless terrain engine I'm working on. There, my Patch node keeps an array of geodes and dispatches the cull traverse to the appropriate ones based on the LOD calculations. The whole Patch sits under a MatrixTransform instead of assigning a MatrixTransform to each Geode. Or perhaps I should make my own WaterDrawable! But that would require knowing a great deal more about the whole rendering process in OSG than what I currently know (but I'm willing to read up on it if it is documented somewhere). That is probably a waste of time for you at this point. Does anyone have any advice on this? Even if it's just to point me towards an example or tutorial, that would be a huge help. I checked the Instancing example, but in that example, the number of instances is decided at Geometry creation time, and the positions of each of the instances is determined from the InstanceID, which is not what I'm looking for. I looked at the Precipitation example, which seems to have a similar scheme involving drawing the same geometry over and over in different grid cells, but I found it a bit difficult to understand. You can look at my evolving source code for the Seamless engine at http://gitorious.org/seamless. And help would be greatly appreciated. Cheers, Frank Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] How to use COLLADA DOM parser on Ubuntu?
Hi, I am trying to use COLLADA DOM parser on Ubuntu using Opengl ES 2.0. So could someone help me on how to proceed with the same. We have a small sample application and a sample .dae collada file.So we want to load the sample collada file in our application using collada dom parser on Ubuntu.So what steps need to be followed on that. Thank you! Cheers, Parmar -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31292#31292 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compute Terrain Intersection for .flt databases [SEC=UNCLASSIFIED]
Hi Paul, osgUtil::IntersectVisitor is deprecated. osgUtil::IntersectionVisitor coupled with LineSegmentIntersector is more flexible and has the support for using KdTree to improve performance significantly - you'll need to enable the build of KdTree's in the DatabasePager to use them. This topic has been discussed several times so have a look through the archives. osgSim::HeightAboveTerrain provides a simpler interface ontop of IntersectionVisitor and also adds support for automatically loaded high levels of details. The loaded is done synchronously though so if the intersection traversal it does needs to load external tiles it will take significantly longer to do the query. There is a cache of tiles to help reduce this cost on subsequent queries. The osgintersection example provides code that illustrates the various intersection routines in action. Robert. On Fri, Sep 3, 2010 at 6:06 AM, Paul Pocock paul.poc...@dsto.defence.gov.au wrote: Hi - Whats the best way to get the z down intersect point onto a paged database. I'm getting what looks like loss of precision errors. I am not sure if it is because I am using osgUtil::IntersectVisitor (Which I believe is deprecated?) or my lack of knowledge of osgSim::HeightAboveTerrain. Is it my proper understanding that I provide two points x,y,z (beginning and end) for HAT? Even doing this gives some very strange results... Is there a very basic example out there to achieve this? Is it a trivial problem? Regards Paul IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hi Andrew, On Thu, Sep 2, 2010 at 8:31 PM, Andrew Lett andr...@yahoo.com wrote: export DYLD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib/osgPlugins-2.9.9 If you do need to add this line then you should point it to the parent directory to the osgPlugins-2.9.9 rather than the osgPlugins directory itself. The OSG appends the osgPlugins-2.9.9 by default when looking for plugins, and once a new release comes out it'll look for the appropriate plugin version i.e. osgPlugins-2.9.10. If you use your approach when you upgrade the OSG version it'll start trying to read the wrong plugins. The README.txt section 'Release notes on OSX build' is a little out of date, as the XCode support has been deprecated. I realize this is due to the fact that cmake on Mac now handles Frameworks and hence there is a single unified build after version 2.9.8. (At first I was trying to figure out where the XCode folder had gone...) The hand maintained XCode projects are deprecated and have now been annexed to deprecated section of the OSG svn repository. In svn/trunk there isn't the old XCode directory anymore, one needs to use CMake to build XCode projects. Up until now, I've been using the 2.8.2 and 2.8.3 with XCode, and the build here worked just fine. I couldn't get the 2.9.8 XCode project to compile (GCC_VERSION was set to 4.0) in either 10.5 or 10.6, but this point is moot, as the command line unified compile and frameworks support has taken care of this issue. Try svn/trunk. Also as Tat suggests the OSG builds both for both ppc and intel at the same time, but some 3rd party libs now just compile for intel. It might be for simplicity we just go with the slow and build for only for intel by default as well, and leave it to users to build for both (via the ccmake architecture option) if they want to retain portability to both architectures. Thoughts on this topic Mac dev? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] How to use COLLADA DOM parser on Ubuntu?
Hi Parmar, There are docs on the OSG wiki about using the COLLADA DOM, please go read them. If you have a problem then explain these and then people will be able to help you. The community aren't going to hand hold every step of the way, we all have jobs to do. You really needs to start making more of an effort to use the resources in front of you and use your own initiative, and when you get stuck explain where you are getting stuck. Robert. On Fri, Sep 3, 2010 at 8:25 AM, Rakesh Parmar rakes...@kpitcummins.com wrote: Hi, I am trying to use COLLADA DOM parser on Ubuntu using Opengl ES 2.0. So could someone help me on how to proceed with the same. We have a small sample application and a sample .dae collada file.So we want to load the sample collada file in our application using collada dom parser on Ubuntu.So what steps need to be followed on that. Thank you! Cheers, Parmar -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31292#31292 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hi Tat, Thanks for the tip, I recompiled for only target 'i386' and the compile link worked for Qt 4.6.3 now. I believe there are still some issues with the Qt examples, there are a number of warnings and errors in the terminal (osgQtBrowser, osgviewerQtContext, osgQtWidgets, osgviewerQtWidget). Sometimes osgQtWidgets crashes immediately on startup. Is there is mix of compile flags / OS X version / Qt version which is known to be stable? Comments? Cheers, - Steve [My latest test was with Qt4.6.3, Mac OS X 10.5.8, OSG 2.9.9 SVN] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
A couple more comments: It's probably a good idea to use 'i386' compiles from now on (perhaps this should be the default for all Intel architecture machines, as Apple has not sold PPC machines for over 4 years now). I've used Qt under Windows and it appears to be quite stable with the OSG environment; I'm concerned with Qt + OSG stability under Mac. Has anyone successfully used this combination out there? Cheers, - Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] How to use COLLADA DOM parser on Ubuntu?
Hi Robert, Thanks for your quick reply . I will read the docs for that. Cheers, Rakesh -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31298#31298 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Virtual reality application (head-tracking, stereo, immersive displays)
Hallo,
Have a look at osgUtils SceneView and search for this:
/** Callback for overidding the default method for compute the offset
projection and view matrices.*/
struct ComputeStereoMatricesCallback : public osg::Referenced
{
virtual osg::Matrixd computeLeftEyeProjection(const osg::Matrixd
projection) const = 0;
virtual osg::Matrixd computeLeftEyeView(const osg::Matrixd view)
const = 0;
virtual osg::Matrixd computeRightEyeProjection(const osg::Matrixd
projection) const = 0;
virtual osg::Matrixd computeRightEyeView(const osg::Matrixd view)
const = 0;
};
We subclassed from this and calculated all projections according to the
screen and headtracker informations, which worked fine independent of
the stereomode in use.
Hope this helps
Olaf Hasemann
Am Donnerstag, 2. September 2010 17:30 schrieb lucie lemonnier:
Hi,
I want to create a virtual reality application with OSG in an immersive
environment (workbench cf. attached file) with head-tracking and
stereoscopy, ... I want to implement the head-tracking with the
stereoscopy. I get the values of position and orientation of the
head-tracker with VRPN. How do I proceed to update the view? What should I
update for the camera (view matrix, projection matrix, etc.) according to
the data of the head-tracker? What should I change otherwise knowing that I
must take into account the stereoscopy?
Thank you!
Cheers,
lucie
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31278#31278
Attachments:
http://forum.openscenegraph.org//files/workbench_374.bmp
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Thanks J-S, Interesting. I will keep it mind. I remember that case I reported to NVidia was also doing good as long as light number was less than 4. I guess compiler was implicitly unrolling the loop, but when number got above 3, it could not unroll and the problem started to show. In the meantime I changed the code to use my own (non gl_) uniforms and this also seems to work. However, instead of array of LightStructs I rather use a set of arrays each containing single light attribute (for example diffuse) for all lights. I did it because it allows for better use of uniform memory. Cheers, Wojtek Lewandowski -- From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Sent: Thursday, September 02, 2010 4:27 PM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] latest NVIDIA drivers Hello Wojtek, I have noticed issues with Shader compilation on 256 (and above) series on Windows 7. Some fragment shaders using gl_LightSource fields were generating internal compiler errors. In fact I also posted a bug report to NVidia. These errors were normally reported by OSG with compilation log showing assembly cg output that was causing trouble for compiler. You don't see any compilation errors even with OSG_NOTIFY_LEVEL=DEBUG_INFO ? I have attached the bug report I posted to NVidia you can check if it could related. We have put back updating our simulators' drivers for this reason. Our lighting shaders did not compile with that same error (binding in multiple relative-addressedarrays). I looked it up last night to try and find a workaround, and found one. If you simply unroll the loop that iterates over lights, it compiles fine. So what you can do is: // Don't forget the backslash at the end of each line except // the last in the define... #define APPLY_LIGHT(i) \ // the code that you had in your loop before \ // that uses gl_LightSource[i]\ // for example: \ // ...\ ambient += attenuation * gl_LightSource[i].ambient; \ // ... APPLY_LIGHT(0) APPLY_LIGHT(1) APPLY_LIGHT(2) APPLY_LIGHT(3) // Up to however many lights you want to support Sure it's just a workaround, I think the behavior you reported to nVidia is still a bug they should fix, but at least this allows us to keep on working even if some clients or users update their drivers. I always hate telling people don't update your drivers to a version newer than x.y, because that shows some incompatibility in our own software and also I may forget to tell them that it's ok to update once the driver bug is fixed, and then they may run into other issues in the future because they have old drivers. Also, I don't have any other loops currently in my code, so I can't say if this same compiler error might affect looping over other variables. See this thread on OpenGL.org for some discussion of this issue. I got the inspiration for the #define above there. http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=281429 Someone mentioned in that thread: In the GLSL spec, if you use some of the built in array types (like gl_ClipDistance) you need to either declare the size of the array or make the source code so that the GLSL compiler can figure out the maximum index you access. It might be possible to remove the above workaround if we did what he suggests. But I haven't yet found out how to do that. What I've tried (uniform gl_LightSourceParameters gl_LightSource[gl_MaxLights]; or uniform gl_LightSourceParameters gl_LightSource[8]; at the top of the shader) didn't change anything. I really hope nVidia fixes the bug... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hi, Am 03.09.10 10:03, schrieb Robert Osfield: It might be for simplicity we just go with the slow and build for only for intel by default as well, and leave it to users to build for both (via the ccmake architecture option) if they want to retain portability to both architectures. Thoughts on this topic Mac dev? +1 from me. If anybody wants universal builds it's easy to configure via cmake / xcode. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3D envelopes
Hi Robert, Sorry my question was not complete. By envelope I mean convex hull. BB and BS are too simple to approximate any 3D model to my mind. The convex is not necessary, just a hull could be fine. I'll be interested in every code/idea/suggestion about that. Thanks a lot. Regards, Vincent. Le 02/09/2010 16:45, Robert Osfield a écrit : HI Vincent, What do you mean by 3D envelope, it's rather an open ended all by itself. Convex hull? Bounding box? Bounding sphere? A pre-paid A4 envelope perfect for sending large pictures through the post? Robert. On Thu, Sep 2, 2010 at 3:12 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, I am currently looking for a way to compute envelopes from 3D datas (Geometry, Groups, etc...) I saw that external lib could do it, but first of all I ask to all of you if someone did something for OSG that could help me. That would help me a lot in my work. Thanks for your help. Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hi Wojtek, In the meantime I changed the code to use my own (non gl_) uniforms and this also seems to work. However, instead of array of LightStructs I rather use a set of arrays each containing single light attribute (for example diffuse) for all lights. I did it because it allows for better use of uniform memory. Yes, that strategy was also suggested on one of the forum threads I read about the problem. http://www.gamedev.net/community/forums/topic.asp?topic_id=578784whichpage=1#3688129 Actually someone on that thread said that bugs in deprecated functionality were likely to appear often, which to me suggests that nVidia might never fix this bug because it relates to built-in uniforms which are deprecated, and just using your own uniforms instead of gl_LightSource[] works fine, so why should they fix a deprecated feature? I actually wonder how true that is, based on this text that can be found on nVidia's site (http://developer.nvidia.com/object/opengl_driver.html) : - 4) Is NVIDIA going to remove functionality from OpenGL in the future? NVIDIA has no interest in removing any feature from OpenGL that our ISVs rely on. NVIDIA believes in providing maximum functionality with minimal churn to developers. Hence, NVIDIA fully supports the ARB_compatibility extension and Compatibility profile, and is shipping OpenGL drivers without any functionality removed, including any functionality that is marked deprecated. 5) Will existing applications still work on current and future shipping hardware? NVIDIA has no plans for dropping support for any version of OpenGL on our existing and future shipping hardware. As a result, all currently shipping applications will continue to work on NVIDIA's existing and future hardware. - But then again, that text might just be PR speak and wishful thinking. If some feature is deprecated (OpenGL 2.x, built-in uniforms, etc.), and less developers are using it over time, how many resources are they likely to devote to fixing bugs that appear in that feature? Of course, from the version number jump, we might assume that nVidia did some big work on their drivers lately, maybe even a rewrite of some or all of them. If that's the case, then they might have had to rewrite the deprecated parts too, and since they most likely tested these parts less than the others, it could explain why we see some bugs in it at this point. This is all conjecture on my part of course, but this kind of thing happens pretty often in development projects... What do you think? I don't know what to think at this point, but since we have an acceptable workaround I'm not too concerned. I just hope the situation doesn't go downhill from here (at least not before OSG has a good transition path to OpenGL 3+ that we can use). In any case, let us know if you ever get news from the bug report you sent. In the past when I've reported bugs they've been rather quick to respond, but maybe that has changed too... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hi Andrew, I've used Qt under Windows and it appears to be quite stable with the OSG environment; I'm concerned with Qt + OSG stability under Mac. Has anyone successfully used this combination out there? I've been working on osgQtBrowser and osgQtWidgets (and the classes they demonstrate - QGraphicsViewAdapter, QWidgetImage and QWebViewImage) lately, but haven't used them on a Mac (or used a Mac at all, really :-) ). They're still work in progress even on Windows, so there may be stability issues I haven't found yet (and actually I've recently fixed a threading issue in their use that I'll submit back soon). So I'm afraid I can't help much. If you can build them in debug, and try running them in the debugger, you should be able to find the source of the crash pretty easily (crash bugs are generally easy to find and fix). Sorry I can't help more, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] Problems with resizing
Hi Ricardo, I have to shame that I still haven't officially tagged new osgppu version which supports resizing. All the changes are only in the svn. As to your suggestions, I think it should be set to user to change the aspect ratio. The reason is that the osgPPU does actually not know anything about projection matrix. osgPPU works purelly in 2D domain. Hence moving the work of updating projection matrix to osgPPU might be a wrong way to do it. I think it might make more sense to put that projection matrix update somewhere in to update routines of the camera or the viewer. cheers art Riccardo Corsi wrote: Hi there, I rise again this pretty old thread to add a detail: the aspect ratio of the camera is not automatically corrected when resizing the viewport. Is this operation left to users on purpose to be more generic? If you think it might be useful to integrate it in the resizeViewport method - maybe with an optional flag? - it is as simple as adding a call like: camera-setProjectionMatrixAsPerspective(fovy, ar, zNear, zFar); with the new AR, within the resizeViewport() method. I tested on my side and works as expected. Cheers, ricky On Tue, Apr 20, 2010 at 15:56, Art Tevs () wrote: Hi folks, so, I just realized that the solution I posted yesterday is the same as was proposed by Mick. I just implemented another solution for proper resizing. You can find it in the svn. With the current implementation resizing works like a charm with almost any example (motionblur still make some small issues). Take a look into the viewer or HDR or DoF example, all of them works. There were several issues, I had to correct. One of them was to force to call osg::Texture::dirtyTextureObject() after resizing. In osg code if you call setTextureSize, then nothing else happens :( With this change it works better. Additionaly I put the solution as proposed by Mick and changed the size of every texture of the camera. Just take a look into examples. I will go for a release of osgPPU v0.6 (for osg 2.8.3) in the next days, I think. I hope now, the problem can be seen as solved to 95% :) Cheers, Art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27014#27014 (http://forum.openscenegraph.org/viewtopic.php?p=27014#27014) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (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=31306#31306 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Virtual reality application (head-tracking, stereo, immersive displays)
Olaf Hasemann wrote:
Hallo,
Have a look at osgUtils SceneView and search for this:
/** Callback for overidding the default method for compute the offset
projection and view matrices.*/
struct ComputeStereoMatricesCallback : public osg::Referenced
{
virtual osg::Matrixd computeLeftEyeProjection(const osg::Matrixd
projection) const = 0;
virtual osg::Matrixd computeLeftEyeView(const osg::Matrixd view)
const = 0;
virtual osg::Matrixd computeRightEyeProjection(const osg::Matrixd
projection) const = 0;
virtual osg::Matrixd computeRightEyeView(const osg::Matrixd view)
const = 0;
};
We subclassed from this and calculated all projections according to the
screen and headtracker informations, which worked fine independent of
the stereomode in use.
Ah, didn't know about that particular callback. That would definitely
be the place to do it!
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgFX Outline Patch
All,
I made a couple of changes to the osgFX::Outline class (SVN patch
attached). I had a couple of issues with it that I was trying to resolve:
1. When an outline object was occluded by another object, the backfacing
wireframe was exposed. To fix that, I removed the disabling of
GL_DEPTH_TEST.
2. In some cases, the outline color was the same color as the geometry
being drawn instead of the specified color. I'm not sure I have
completely fixed this issue, but I did make some changes to match up to
how we do a scribe effect.
-Todd
Index: Outline.cpp
===
--- Outline.cpp (revision 11730)
+++ Outline.cpp (working copy)
@@ -71,8 +71,9 @@
_color = color;
if (_material.valid()) {
const osg::Material::Face face = osg::Material::FRONT_AND_BACK;
-_material-setAmbient(face, color);
-_material-setDiffuse(face, color);
+_material-setAmbient(face, osg::Vec4(0.0f, 0.0f, 0.0f, 1.0f));
+_material-setDiffuse(face, osg::Vec4(0.0f, 0.0f, 0.0f, 1.0f));
+_material-setSpecular(face, osg::Vec4(0.0f, 0.0f, 0.0f,
1.0f));
_material-setEmission(face, color);
}
}
@@ -135,13 +136,12 @@
// outline color/material
_material = new osg::Material;
-_material-setColorMode(osg::Material::AMBIENT_AND_DIFFUSE);
+_material-setColorMode(osg::Material::OFF);
setColor(_color);
state-setAttributeAndModes(_material.get(), Override_On);
// disable modes
state-setMode(GL_BLEND, Override_Off);
-state-setMode(GL_DEPTH_TEST, Override_Off);
state-setTextureMode(0, GL_TEXTURE_1D, Override_Off);
state-setTextureMode(0, GL_TEXTURE_2D, Override_Off);
state-setTextureMode(0, GL_TEXTURE_3D, Override_Off);
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Virtual reality application (head-tracking, stereo, immersive displays)
Hi, Thank you very much for your replies. I'll try to get along with your indications. Cheers, lucie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31309#31309 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Can update callback be a mutex?
Hello all, I'm working on project where a viewer is running in one thread, and user input/physics simulations/external devices/etc. are happening in one or more other threads, but need to modify the scene graph. Currently, we use mutexes which the other threads modify, and update callbacks access the appropriate mutex to find out if anything has changed. I was reading some older forum topics which said the OSG doesn't natively support asynchronous updating, so this seemed like a good way to accomplish our goal - right now it does everything we need it to. However, I was thinking it might be possible to eliminate the middle man by having my update callback itself derive from OpenThreads::Mutex, and creating two methods (one for updateData() and one called by operator()) which lock the mutex, act on the data, and unlock it. I'm wondering if anyone with more experience sees anything wrong with this approach, either conceptually or because of performance issues. Thanks for any input! Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31310#31310 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hi J-S, Responses below: [...] Actually someone on that thread said that bugs in deprecated functionality were likely to appear often, which to me suggests that nVidia might never fix this bug because it relates to built-in uniforms which are deprecated, and just using your own uniforms instead of gl_LightSource[] works fine, so why should they fix a deprecated feature? I think that breaking gl_LightSource usage in fragment shaders is actually a major problem. On this forum there are three of us who admitted it affected them. Probably few more did not mention it. How many OpenGL developers outside OSG community do pixel lighting ? I bet there thousands if not tens of thousands who were or can be affected in the future. Its not just a minor issue, so I guess NVidia will do something about this sooner or later. I hope they will, despite the fact, they did not respond to my bug report at all ;-(. I am telling myself they probalby did not, because they already knew about it. I actually wonder how true that is, based on this text that can be found on nVidia's site (http://developer.nvidia.com/object/opengl_driver.html) : - 4) Is NVIDIA going to remove functionality from OpenGL in the future? NVIDIA has no interest in removing any feature from OpenGL that our ISVs rely on. NVIDIA believes in providing maximum functionality with minimal churn to developers. Hence, NVIDIA fully supports the ARB_compatibility extension and Compatibility profile, and is shipping OpenGL drivers without any functionality removed, including any functionality that is marked deprecated. 5) Will existing applications still work on current and future shipping hardware? NVIDIA has no plans for dropping support for any version of OpenGL on our existing and future shipping hardware. As a result, all currently shipping applications will continue to work on NVIDIA's existing and future hardware. - Yeah, I thought about the same ;-). Are NVidia continued legacy OpenGL support statements still valid ? But then again, that text might just be PR speak and wishful thinking. If some feature is deprecated (OpenGL 2.x, built-in uniforms, etc.), and less developers are using it over time, how many resources are they likely to devote to fixing bugs that appear in that feature? Of course, from the version number jump, we might assume that nVidia did some big work on their drivers lately, maybe even a rewrite of some or all of them. If that's the case, then they might have had to rewrite the deprecated parts too, and since they most likely tested these parts less than the others, it could explain why we see some bugs in it at this point. This is all conjecture on my part of course, but this kind of thing happens pretty often in development projects... I think NVidia was adding support for OpenGL 4.0 4.1 for Fermi based GPUs and they screwed something in shader compilers. If this was a minor issue they could ignore it, but I think its huge problem for many developers and NVidia should be aware of its importance. So I really think they will fix it. If they are not and will continue such attitude, then one day ATI will start to have better quality drivers. And it won't happen because ATI drivers improved ;-) Btw, I would love ATI/AMD OpenGL drivers improve so we have a real competition in OpenGL. What do you think? I don't know what to think at this point, but since we have an acceptable workaround I'm not too concerned. I just hope the situation doesn't go downhill from here (at least not before OSG has a good transition path to OpenGL 3+ that we can use). Since, I said before I think they will fix it, I can now play a little devils advocate ;-). I actually think that such OpenGL legacy support policy prevents faster progress. I think that DirectX has now edge over OpenGL and now dictates the pace of 3D graphics. This success was partially achieved by Microsoft policy to do a revolution with every major DirectX release. They redefined whole API and removed all stuff that did not fit anymore. With such attitude developers were forced to adapt but they also gained a lot. With compatibility profiles OpenGL cannot progress that quick. And number of OpenGL new and older calls usage combinations certainly makes building fast well behaving drivers more difficult. So I would rather like to see some revolution is OpenGL and adapt my code to pure OpenGL 4.0 profiles than deal with unexpected driver errors. In any case, let us know if you ever get news from the bug report you sent. In the past when I've reported bugs they've been rather quick to respond, but maybe that has changed too... As I said I have not heard from them after bug report. But I hope its a good sign and it means they are working on the issue. Wojtek ___ osg-users mailing list
Re: [osg-users] latest NVIDIA drivers
Hi Wojtek, I think that breaking gl_LightSource usage in fragment shaders is actually a major problem. On this forum there are three of us who admitted it affected them. Probably few more did not mention it. How many OpenGL developers outside OSG community do pixel lighting ? I bet there thousands if not tens of thousands who were or can be affected in the future. I agree, and in fact in my case the error happened in a vertex shader when doing a loop over light sources to do per-vertex lighting, so it's not just limited to per-pixel lighting shaders. I bet any code that loops over gl_LightSource[] in any shader will cause this error. I also agree with your other points. Hopefully soon OSG will allow us to choose which path we use, OpenGL 2.x or OpenGL 3.x+/4.x, and will help ease our transition. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hi J-S, Thanks for the information, and your work is very much appreciated. The Qt integration with Delta3D 2.3.0 under Windows is incredibly stable, so perhaps this should be something to have a look at (I speak from experience on using this package with Qt). Delta3D uses OpenSceneGraph for its rendering (see the particle editor example). However, I don't want to use Delta3D anymore as it is much larger than OSG itself and it isn't support on Mac. Cheers, - Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Custom Drawing for Geode
That is some incredible information, thank you very much! =D -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31314#31314 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hello Andrew, The Qt integration with Delta3D 2.3.0 under Windows is incredibly stable, so perhaps this should be something to have a look at (I speak from experience on using this package with Qt). Delta3D uses OpenSceneGraph for its rendering (see the particle editor example). However, I don't want to use Delta3D anymore as it is much larger than OSG itself and it isn't support on Mac. Well, it depends on what you mean by Qt integration - there are two angles: 1. Integrate an OSG window in a Qt window (i.e. have an OSG window inside your widget, and let it do its thing) 2. Integrate Qt widgets inside an OSG window (i.e. have Qt widgets as part of your scene). The osgQtWidgets and osgQtBrowser examples (and their component classes) implement number 2, and the osgViewerQT* examples implement number 1. Last I checked, Delta3D only implemented number 1, but some users were trying to implement number 2. What I'm working to improve is performance. The way Delta3D does its window integration (number 1) makes Qt drive the OSG rendering, so you lose all parallelism between OSG and Qt. Note that the osgViewerQtContext and osgViewerQtWidget also have this problem - anytime you have a Qt widget's repaint or a Qt timer calling viewer.frame(), that's bad IMHO. And the way the user I saw on a forum was proposing to implement number 2 was along the same lines. I currently have an implementation of number 1 which lets OSG run loose (completely parallel to Qt) which I have yet to submit, and our implementation of number 2 also lets OSG and Qt run in parallel (minus some locking that needs to occur at the right times, and threading issues that we fix as we find them as I mentioned in my previous post). So I think the stability issues you mention are just part of the evolution of these classes, they need more users to look at them to help make them better. But their low-level approach is better than what I've seen in other places (including what I've seen in Delta3D, but that might have changed). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Creating and exporting OSG Switches from 3ds max
Hi, I was wondering if there was any tutorials that anyone knows of for the creation and exporting of OSG models with Switch nodes. I am working on a driving simulator that for the creation of objects such as traffic lights, the different colour lights must be created with OSG switches. Only I have never used these before. I have installed OSGexp for 3ds max 2010, and I know how to add an OSG_Switch to the scene, but there my knowledge ends. So if anyone knows of a noob or beginner tut for this, I would really apprecitate it. ... Thank you! Cheers, Luke -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31290#31290 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can update callback be a mutex?
Tom Pearce wrote: Hello all, I'm working on project where a viewer is running in one thread, and user input/physics simulations/external devices/etc. are happening in one or more other threads, but need to modify the scene graph. Currently, we use mutexes which the other threads modify, and update callbacks access the appropriate mutex to find out if anything has changed. I was reading some older forum topics which said the OSG doesn't natively support asynchronous updating, so this seemed like a good way to accomplish our goal - right now it does everything we need it to. However, I was thinking it might be possible to eliminate the middle man by having my update callback itself derive from OpenThreads::Mutex, and creating two methods (one for updateData() and one called by operator()) which lock the mutex, act on the data, and unlock it. I'm wondering if anyone with more experience sees anything wrong with this approach, either conceptually or because of performance issues. Thanks for any input! Cheers, Tom Seems possible, but I don't see that it would buy you anything with respect to efficiency. You might want to take a look at osgbullet.googlecode.com. It supports physics and rendering in separate threads using a triple buffer mechanism. The triple buffer mechanism allows the mutex to be held only as long as it takes to swap a pointer. Reading and writing of the data is then done asynchronously. There's never a need for one thread to wait for another thread to finish its IO operations. -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
nice reading ... :) .. I agree about the DirectX part .. Let start talking to Robert to make OSG DirectX compatible :) -Nick On Fri, Sep 3, 2010 at 7:29 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Wojtek, I think that breaking gl_LightSource usage in fragment shaders is actually a major problem. On this forum there are three of us who admitted it affected them. Probably few more did not mention it. How many OpenGL developers outside OSG community do pixel lighting ? I bet there thousands if not tens of thousands who were or can be affected in the future. I agree, and in fact in my case the error happened in a vertex shader when doing a loop over light sources to do per-vertex lighting, so it's not just limited to per-pixel lighting shaders. I bet any code that loops over gl_LightSource[] in any shader will cause this error. I also agree with your other points. Hopefully soon OSG will allow us to choose which path we use, OpenGL 2.x or OpenGL 3.x+/4.x, and will help ease our transition. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hi Nick, nice reading ... :) .. I agree about the DirectX part .. Let start talking to Robert to make OSG DirectX compatible :) -Nick Haven't you been here for a while now? You should know by now that's not going to happen :-) Search the archives if you're interested, this has been discussed in the past. But let's not let this thread go into API wars, please. We're using one API, and this thread just discussed bugs in parts of that API which are deprecated but should still be supported by the vendor in question. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
hi J-S, I was just kidding :) .. I think I know Robert's view on Microsoft. My opinion is, even the fact the DirectX is kind of further then OpenGL, what osg is on top of opengl is my favorite, and not only osg but all the rest of opensource projects around that are on top of it (vpb, osgEarth, osgOcean ... ) as well ... -Nick On Fri, Sep 3, 2010 at 10:23 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Nick, nice reading ... :) .. I agree about the DirectX part .. Let start talking to Robert to make OSG DirectX compatible :) -Nick Haven't you been here for a while now? You should know by now that's not going to happen :-) Search the archives if you're interested, this has been discussed in the past. But let's not let this thread go into API wars, please. We're using one API, and this thread just discussed bugs in parts of that API which are deprecated but should still be supported by the vendor in question. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating and exporting OSG Switches from 3ds max
Hi I think I have seen OpenFlight exporter for max. You can build your hierarchy with it including the switches ... -Nick On Fri, Sep 3, 2010 at 9:40 AM, Luke Daly melbdemon...@hotmail.com wrote: Hi, I was wondering if there was any tutorials that anyone knows of for the creation and exporting of OSG models with Switch nodes. I am working on a driving simulator that for the creation of objects such as traffic lights, the different colour lights must be created with OSG switches. Only I have never used these before. I have installed OSGexp for 3ds max 2010, and I know how to add an OSG_Switch to the scene, but there my knowledge ends. So if anyone knows of a noob or beginner tut for this, I would really apprecitate it. ... Thank you! Cheers, Luke -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31290#31290 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can update callback be a mutex?
Ooh, nice - thanks for pointing me that way. I'm going to implement a triple buffer of some sort in my project - if I use some of the techniques in osgBullet as a pattern but don't actually copy code, what's the best/proper way to give credit? Right now the project is totally internal for an academic research lab, but we may share it at some point. Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31321#31321 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can update callback be a mutex?
Tom Pearce wrote: Ooh, nice - thanks for pointing me that way. I'm going to implement a triple buffer of some sort in my project - if I use some of the techniques in osgBullet as a pattern but don't actually copy code, what's the best/proper way to give credit? Right now the project is totally internal for an academic research lab, but we may share it at some point. osgBullet is very liberal licensing, so go for it. When I borrow code, I usually add a comment at the top that says Derived from: (or something to that effect) and follow that with the original copyright notice. I always keep the original copyright intact. -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] std::vectorbool performance issue
Hi, I am looking at a performance slow-down introduced after using some osg::Switch groups. I did some performance benchmarking on std::vectorbool and I found push_backs are 10x slower than std::vectorint, and more importantly, the simple [] operator is about 20x slower(*). I am not sure it is the smoking gun yet, as I will need to back-track a lot of code, but it looks possible. This is because std::vectorbool is specialized in the STL to be a memory efficient packed vector. I am not so sure that the memory (bool vs say unsigned char ) saved is really worth the performance hit in the case of osg::Switch (* Win32, _SECURE_SCL=0, Studio 2008) Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31323#31323 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating and exporting OSG Switches from 3ds max
This is the only doc that I've seen: http://www.openscenegraph.org/projects/osg/wiki/Community/OSGExp/Documentation/OSGSwitch -mike On 10-09-03 1:40 AM, Luke Daly wrote: Hi, I was wondering if there was any tutorials that anyone knows of for the creation and exporting of OSG models with Switch nodes. I am working on a driving simulator that for the creation of objects such as traffic lights, the different colour lights must be created with OSG switches. Only I have never used these before. I have installed OSGexp for 3ds max 2010, and I know how to add an OSG_Switch to the scene, but there my knowledge ends. So if anyone knows of a noob or beginner tut for this, I would really apprecitate it. ... Thank you! Cheers, Luke -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31290#31290 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
