Re: [osg-users] Updating Rotation Matrix - Quaternion
> > > What I need to do is invert the rotation. > > I'm not aware of a invert functionality on Quat but you could > create a rotation matrix from the Quat, invert that, and get > a quaternion back. > All quaternions contains a vector ( x,y,z ) and a scalar (w ). For a rotation quaternion the vector is the axis multiplied by sin(a/2), where a is the angle of rotation. The scalar is cos(a/2). The reverse rotation is obtained by negating the vector part. For a Quat called rot like in your example, you can use the rot.conj() function to do this. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to set per vertext attributes using osg
> > > As well as hardware state > > changes he also talks about the CPU cost of doing the > sorting being an > > issue. That was what my suggestion will help with as it > means that OSG > > has less states to sort, as all objects of the same type > will have the > > same state as opposed to having state where the uniform changes. > > Of course state sorting has some CPU cost, however except in > pathological cases this should be minimal compared to other > things your app does on the CPU. Perhaps you were heavily CPU > limited (that is, a severe imbalance between CPU power and > GPU power, in favor of the GPU). For the delivery system I was dealing with that was the case, however on my dev systems which had modern fast CPUs I still was better off using this trick. > That shouldn't be the general case though, so you can't go > around recommending that everyone use vertex attributes > instead of uniforms in all cases - most of the time people > will want to use uniforms for things that can change per > object, and vertex attributes for things that can change per vertex. > If this isn't faster on other people's apps I'd like to know ( to improve my own knowledge if nothing else ). It was Robert who suggested that I use this technique and he said that Uniforms can be expensive and that State changes should be minimised. However using a Uniform per object is far easier, if it gives comparable performance it is certainly the better option. It's more a case of letting people know that there is a gotcha that comes with the heavy use of Uniforms and that there is a way around it using techniques in the osgexamples. Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to set per vertext attributes using osg
> > Attributes provide a faster way of changing vertex > properties even on > > a per object basis, as it means all of your objects can > share the same > > state. Changing the value of uniforms cause the creation of > a new state. > > Lots of state changes can be very expensive. > > Sure, but some types of state are less costly than others to > change. See > > http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Renderst > ate%20change%20costs]] > That link doesn't quite work for me, but I think I found the blog entry that you were trying to point me towards. As well as hardware state changes he also talks about the CPU cost of doing the sorting being an issue. That was what my suggestion will help with as it means that OSG has less states to sort, as all objects of the same type will have the same state as opposed to having state where the uniform changes. > > Based on my experience of OSG, the performance > recommendations I have > > to give is that uniforms are to be changed between > different classes > > of objects ( no more than a handful per frame ). Anything more > > frequent should probably be set as a vertex Attribute. > > Do you mean using vertex attributes in BIND_OVERALL mode? > Otherwise you'd be sending an array of n times the same value > for n vertices... So I'm sure that depends on the size of > your geometry and how often the same uniform value will be > reused between objects too. > Yes, kind of. I actually implemented it by inserting Vertex Attribute OpenGL calls in a draw callback, prior to the OpenGL rendering of the actual geometry node. Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to set per vertext attributes using osg
> > I think my data items are going to be per Geode (e.g., > thickness of a > > "part"), but I thought I still needed shader attributes instead of > > uniforms, because uniforms are per frame. Unless you're > thinking I'd > > make an array of them where the indexing is the Geodes? > > Nope, you can set uniforms in the state set of a > node/drawable. So each node/drawable can have a different > value for the same uniform (as long as you name all your > uniforms on each node with the same name). OSG will > automatically use the closest uniform in the current > Drawable's path up to the scene root as the current value of > the uniform with that name when rendering that drawable. > > Attributes are only useful if you need per-vertex data. > Anything coarser than that and you're better off with uniforms. > Attributes provide a faster way of changing vertex properties even on a per object basis, as it means all of your objects can share the same state. Changing the value of uniforms cause the creation of a new state. Lots of state changes can be very expensive. At least it did last time I tried it. Here is a reference from last year. http://groups.google.com/group/osg-users/browse_thread/thread/3973790d19 c85823/6ef53c1c510aa821 I was dealing with a number of water effects ( splashes, water trails, wakes ). For around 100 effects this change made a significant reduction in CPU draw time, which was the bottleneck for my app. I was dealing with a pretty low power CPU though. Based on my experience of OSG, the performance recommendations I have to give is that uniforms are to be changed between different classes of objects ( no more than a handful per frame ). Anything more frequent should probably be set as a vertex Attribute. See the osgforest example for code on how you could achieve this. I hope this is useful, Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openscenegraph.org stats
> > > ATI and Intel two special cases of poor OpenGL support? We'll that > > only leaves one mainstream vendor that provides acceptable OpenGL > > drives, and it make it the exception to the rule - so > surely NVidia is > > the special case here, not ATI and Intel. > > Please actually read my arguments instead of just focusing on > the wording. You can't refute the fact that Intel's hardware > is not really 3D "accelerators", rather "decelerators" and > that is in both Direct3D and OpenGL. So that dismisses one > case right there, we're left with NVidia and ATI. > I can refute the "fact" that Intel's hardware is not really 3D "accelerators". I'm currently developing an embedded product that uses OSG on an Intel 945 chipset. It is certainly not a decelerator. Sure its fill-rate isn't great ( but it is better than the CPU could do ) but it is adequate for my purposes. Other chipsets ( X3100 and later ) are even more capable. Interestingly the OpenGL driver for this chipset is far far better on Linux than on Windows. I suspect the Open Source driver is responsible for this. Interesting about the stats though. I'm one of those people who skews the statistics. I do 90% of development on Linux and 90% of browsing ( including openscenegraph.org a fair amount ) on Windows. Linux screen space is valuable... Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] higher level shader chaining support?
Hi Ferdi, I did make a first pass at this, at least in terms of reusing modules in different shaders. The glsl functionality has most the same tools as a C compiler. But is missing a few things. osg::Shader provides some the functionality C compiler and some functionality of the preprocessor ( #define etc ). It does not unfortunately support includes or the ability to set defines outside of source code ( that I've found anyway ) , however this can be worked around by prepending your #defines and the contents of your includes to the std::string contianing your source code before feeding it to the shader ( compilation ). Prepending unfortunately messes up the line numbers for debugging though. You can use setShaderSource to build your shaders from a std::string rather than loadShaderSourceFromFile in order to do this. Osg::Program provides the functionality of the linker, resulting in an executable. As such you can build up different osg::Shaders togather to make a complex system with plug in modules. You can have any number of Shaders in a Program, not just one of each type. Just make sure that you have only one main() in each stage ( Vertex, fragment, geometry ) of the Program. So you can have your lighting functions in one osg::Shader, your texture functions in another and then use them in different Programs. I think this saves memory on the graphics card too. Think of osg::Shaders as object files. As for combining algorithms, you just need to plan your interfaces to be general enough, just like when coding in C/C++. The functionality for this is already in OSG, it just isn't immediately obvious. OSG is pretty much a pass through of the OpenGL API, the only place it is less capable is that the OpenGL Shader can be created from multiple char* 'strings' to allow for 'includes', but osgShader can't. Admittedly I have never tried doing that in OpenGL, but the Orange book does mention it as the reasoning for multiple char*s. Colin. > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf > Of Ferdi Smit > Sent: 12 December 2008 13:39 > To: osg > Subject: [osg-users] higher level shader chaining support? > > Hello, > > Just a thought, have people looked at implementing some > higher level shader functionality in OSG? For example a type > of system that is described in GPU Gems 2 ( > http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter13.h tml ) or something similar to direct show (yikes) where shaders > and buffer resources have input and output pins that can be > dynamically connected. > On top of this a shader that mimics the fixed functionality > pipeline could be provided. In this way, various algorithms > requiring shader code can be implemented in a much more > general fashion. You simply connect to the pins you need > transparently. I find myself often writing algorithms using > shaders, and every single time I have to reinvent, program > and incorporate basic opengl lighting and texturing. Then > when you want to combine two of these algorithms everything > falls apart usually. > > -- > Regards, > > Ferdi Smit > INS3 Visualization and 3D Interfaces > CWI Amsterdam, The Netherlands > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Calculating the volume of a model through OSG
Another simple way of calculating the volume of a arbitary closed 3d mesh is Choose an arbitary point ( let's call it o ) For each triangle with vertices ( a,b,c ) Calculate the volume of the tetrahedron ( a,b,c,o ) using a scalar triple product ( ((b-a)x(c-a)).(o-a)/3 ). Add the volumes of all of the tetrahedrons together, some of these volume will be negative and some will be positive, depending on whether the triangle is facing the arbitary point or not. These negative volumes cancel out the positive ones, leaving only the enclosed area. This relies on the 2 assumptions:- 1) All of the triangles in the 3d object have the same winding order, otherwise the volumes' sign cannot be trusted. 2) The object has no holes. If the object has holes then the placing of the arbitary point will affect the volume of the object, a triangular hole will mean that the volume of a tetrahedron between the hole and the arbitary point will be missed in the calcalation. As a result of this placing it in the centroid of the 3d object is probably the best plan. I hope this helps. Colin. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Alberto Luaces > Sent: 27 November 2008 08:42 > To: OpenSceneGraph Users > Subject: Re: [osg-users] Calculating the volume of a model through OSG > > Hi, > > in addition to Janusz pointers, if you need also the rest of > the mass properties, you could take a look at this famous paper: > > http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html > > Alberto > > El Jueves 27 Noviembre 2008ES 09:09:34 [EMAIL PROTECTED] escribió: > > Dusten: > > > > You might find these two helpful: > > > > accurate: http://tetgen.berlios.de/ > > approximate & simple: > > http://www.gamedev.net/reference/articles/article2247.asp > > > > The second one could be easily added to osg I guess. > > Janusz > > > > Dnia Wed, 26 Nov 2008 23:47:57 -0600, Dusten Sobotta napisał(a): > > > Hello, > > > > > > Manually modifying various attributes of models is quite tedious, > > > and tends to set back the development of games. To work > around this > > > issue, I'd like to implement a feature to calculate the > volume of an > > > in-game model, so that given a surface attribute such as > 'wood' or > > > 'metal', (which have pre-defined density values), the mass of an > > > object can be computed and later exported. Might anyone have an > > > example for finding the approximate volume of an object > through OSG? > > > > > > > > > Thanks in advance, > > > > > > Dusten > > > ___ > > > osg-users mailing list > > > osg-users@lists.openscenegraph.org > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap > > > h.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-opensce > negraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader Uniform Performance Question(s)
Hi Paul, > > Maybe somebody on this list can save me from reinventing the wheel... > > I'm looking to get a better understanding of performance > issues related to uniforms. > > How much overhead is there in having a uniform? If there > only a performance hit if the uniform changes values or every > frame. What if I change the Uniform in OSG to exactly the > same value it already has, would there be a performance hit? > At an OpenGL level a uniform change will result in a state change, in the same way as changing the diffuse color or a texture parameter would. This can mean that the graphics hardware may need to wait whilst some currently executing commands are flushed. If you only change it once a frame and you have any objects with different state in your scene, it will not make any difference. The main cost of uniforms is when you have many objects with slightly difference uniform values in the same frame as this introduces state changes. Uniforms are part of the osg::StateSet, so you need to be careful about making too many different ones as too many can cause performance problems. > I have uniforms that might not change values very often. Some > are simply boolean flags. Can I have different shaders and > somehow switch between them? Can I "recompile" the shader > on-the-fly (i.e. defining these boolean using #define/#if-#endif)? Compiling the shader on the fly is certainly possible, how long it takes I'm not sure. I expect it is an expensive state change ( like a texture download ), rather than a cheapish sort ( such as a uniform ), so probably not good if you are doing it a lot. > In some cases, I have variables which can change within the > shader, but I know these values when I create the scene graph > so I currently use #define instead of passing them as > uniforms (which will ever only have one value). Does this > gain me much in performance? I assume that the #define values are in the shader. The only way I've found to use #defines is with a different shader program ( character array or string ). As such it will mean using a different osg::Shader object and therefore more gfx memory and a different shader handle. I expect the cost of switching shaders is the same or more than switching the value of Uniforms. > > Also, is there a difference in performance in using four > "float" uniforms versus setting a Vec4? > >From my understanding a Vec4 will be cheaper than a four float uniforms in >terms of state changing. Each uniform needs to be checked with the uniforms in >the shader by the OpenGL driver. This is some sort of string compare. Also >increasing the number of uniforms increases the length of the list in >osg::StateSet and therefore how long it takes to walk. It is also feasible that the hardware is faster at dealing with shaders with less uniforms, so that your shaders may run faster with a Vec4 rather than 4 floats. However this is entirely dependant on the hardware optimisations. I've not tested this. Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vpb: Spherical terrains?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Robert Osfield > > The pole looks weird. Is there any way to fix it? > > Poles are little bit awkward to fix with the simple quad tree > approach used by the OSG (and many other whole whole > techniques.) We could certainly do more to try and alleviate > this problem by better sampling around the poles when > building the terrain. Anisotropic filtering can help at runtime. > > Robert. The problem is that the projection is not even close to linear at the poles, meaning that the mipmapping hardware does the wrong thing, anisotropic filtering may help, but you'll still get the weirdness, it will just be reduced. This is a limitation in using lat/long style texture projections as it means the pole is represented by a line in texture space rather than a point. For the earth this is not normally a problem because few people go to the poles and they are usually covered in ice and snow ( so have a very dull and uniform appearance ). For other planetary bodies in the solar system, sometimes the poles are very interesting though. In the past I've has success using a Azimuthal Equidistant projection ( http://en.wikipedia.org/wiki/Azimuthal_equidistant_projection ) for each hemisphere to bypass this problem for rendering planetary bodies. The problem with this is that the projection becomes less linear the further away from the projection points ( east and west 'poles' in my case ). I also know that other people have had success with a polyhedron based projection. The simplest would be using a cubemap style projection. These have the advantage that they use a number of linear projections, so any distortion could be corrected by use of the 4th texture coordinate. Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shaders, osg::notify and IP
It seems that there isn't a good solution to prevent people seeing shader code then, I didn't think of the plugin thing. Even if OSG was made completely secure, it seems that you could get shader source code from OpenGL debuggers ( as Ralph Kern said earlier ). I guess it is just a matter of putting a few simple obstacles ( like not giving away obvious shader source code ) in people's way so that the casual hacker is disuaded. I suppose that all the source files should also have copyright notices for legal reasons too. Cheers, Colin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 24 September 2008 11:52 To: OpenSceneGraph Users Subject: Re: [osg-users] Shaders, osg::notify and IP Hi Colin, The initial value of NotifyLevel is set from the OSG_NOTIFY_LEVEL env var, which users can set themselves, but your application can set the value via: osg::setNotifyLevel(osg::ALWAYS); Which will make the OSG notification system always ignore all calls to osg::notify(..), this way you can prevent users from changing things. The only way to get round this would be for a user to write a plugin that they force your application to load, then they reset the notification level back to DEBUG and then go trawling. Statically linking would avoid this possibility, as would strictly managing what plugins are loaded and from where. But any of these changes protects a user from tweaking the OpenGL library itself to catch the token stream, OpenGL-ES does provide compiled shaders but OpenGL itself doesn't so it's hard to protect against a determined hacker. Then there is always the law itself, it's legal to reverse engineer in most countries, but there is copyright to protect against actually copy binaries, data and source code, so even if someone did snoop and then reuse your work they would be open to a lawsuit. Robert On Wed, Sep 24, 2008 at 10:46 AM, Middleton, Colin (GE EntSol, Intelligent Platforms) <[EMAIL PROTECTED]> wrote: > Hi all, > > My colleague was recently doing some debugging and found that when > OSG_NOTIFY_LEVEL is INFO or higher all of the shader code comes out as > debug. Luckily because of the way the osg::notify code is written we > can prevent any slightly osg savvy 3rd party getting hold of my > shaders by setting the notify level in the application as the API call > overrides the environment variable. However this prevents me from > using the notify level as a means of debug in the future. > > I know that many people consider shaders to be a important part of > their IP and so I was wondering what the community thought of this. > Should there be a way of preventing this debug being printed out as > part of the info? I wouldn't suggest removing it entirely as knowing > the shader source ( especially if you have constructed it in code ) > can be important to debugging. > > Cheers, > > Colin. > ___ > 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shaders, osg::notify and IP
Hi all, My colleague was recently doing some debugging and found that when OSG_NOTIFY_LEVEL is INFO or higher all of the shader code comes out as debug. Luckily because of the way the osg::notify code is written we can prevent any slightly osg savvy 3rd party getting hold of my shaders by setting the notify level in the application as the API call overrides the environment variable. However this prevents me from using the notify level as a means of debug in the future. I know that many people consider shaders to be a important part of their IP and so I was wondering what the community thought of this. Should there be a way of preventing this debug being printed out as part of the info? I wouldn't suggest removing it entirely as knowing the shader source ( especially if you have constructed it in code ) can be important to debugging. Cheers, Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confused about Uniforms and StateSets.
Hi Robert, Thanks for your quick reply. I found the appropriate class in osgforest ( ShaderGeometry ), which passes the scale and translation that the shader uses in the glColor call, prior to the geomtry draw function. It seems to be a good start for what I want to do, of course with some refactoring at my end. Would you get the same result using a DrawCallback? Cheers, Colin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 15 August 2008 09:43 To: OpenSceneGraph Users Subject: Re: [osg-users] Confused about Uniforms and StateSets. Hi Colin, As a general rule it's best to minimize the number of StateSet and associated StateAttribute/Uniform/Mode changes, both form the OSG's CPU cost, as well as the cost down on the GPU with stalling the graphics pipeline with state changes. Uniforms in particular can be a very expensive state change as some drivers treat uniforms as constants and recompile or relink the shader program. The way to avoid using lots of separate Uniforms is to move to using vertex attributes attached to an osg::Geometry. In the osgParticular::PrecipitationEffect I tackled this by sharing a single shared geometry and then having a custom drawable that uses this shared geometry to send down most of the data and then in addition sets the vertex attribute I wanted to vary. The osgforest example also does a similar trick in the GLSL path. Robert. On Fri, Aug 15, 2008 at 9:32 AM, Middleton, Colin (GE EntSol, Intelligent Platforms) <[EMAIL PROTECTED]> wrote: > Hello, > > I'm using a geometry shader to do particle animation for a splash > special effect. I am using a few uniforms, one of which is the time at > which the splash starts and others that contain values that are shared > among the different splashes. > I am applying the StateSet containing the osg::Uniforms and the > osg::Program to a group above the splash geometry, I do this everytime > I create a new splash, which is shallow copied from a file I load. > > Now this seems to cause a lot of CPU load when I have lots of splashes > active. I believe this is because each splash has a different > StateSet, with all the elements equal apart from the Uniform > representing the splash time. ( Profiling shows me that lots of CPU > time is used in osgUtil::SceneView::draw, which is mostly spent in > osgUtil::StateGraph::moveStateGraph and osg::State::apply ). > > If I reuse the same StateSet, I get good performance, but of course > only my first splash is visible as the start time. > > Is there better mechanism to get the splash start time into the shader? > Would having the start time on a different StateSet on a node below > the one with the common state help performance? > > I don't have a very good grasp of how the state sorting works in OSG > so any advice would help lots. > > Cheers, > > Colin. > ___ > 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Confused about Uniforms and StateSets.
Hello, I'm using a geometry shader to do particle animation for a splash special effect. I am using a few uniforms, one of which is the time at which the splash starts and others that contain values that are shared among the different splashes. I am applying the StateSet containing the osg::Uniforms and the osg::Program to a group above the splash geometry, I do this everytime I create a new splash, which is shallow copied from a file I load. Now this seems to cause a lot of CPU load when I have lots of splashes active. I believe this is because each splash has a different StateSet, with all the elements equal apart from the Uniform representing the splash time. ( Profiling shows me that lots of CPU time is used in osgUtil::SceneView::draw, which is mostly spent in osgUtil::StateGraph::moveStateGraph and osg::State::apply ). If I reuse the same StateSet, I get good performance, but of course only my first splash is visible as the start time. Is there better mechanism to get the splash start time into the shader? Would having the start time on a different StateSet on a node below the one with the common state help performance? I don't have a very good grasp of how the state sorting works in OSG so any advice would help lots. Cheers, Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
