Re: [osg-users] Control of animated object
Hi Carlos,
On Sun, Jul 12, 2009 at 7:58 PM, Carlos Sanchesces...@gmail.com wrote:
I see in .OSG file the animation path . I changed the loop to NO_LOOPING and
the object play onetime. very good too.But I still need to know the
animation time and later to check the current time.
Once you have the appropriate node you do something like:
osg::AnimationPathCallback* apc =
dynamic_castosg::AnimationPathCallback(node.getUpdateCallback());
if (apc)
{
// now we have the appropriate callback we can access the AnimationPath.
}
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text Problem
Hello Robert, The osgText example runs fine. I tested on two machines with different cards/drivers, the problem remains. I am using these modes : text-setCharacterSizeMode(osgText::Text::OBJECT_COORDS); text-setAxisAlignment(osgText::Text::SCREEN); I am using position values of the order of 1438137.375, and font size of 1.6. Could this be related to precision. Thanks and Regards Vaibhav Bansal -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Sunday, July 12, 2009 9:51 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Text Problem Hi Vaibahv, I've never seen a problem like this before. Exactly how are you setting your text? Do you see the problem across platforms and different hardware/drivers? What happens you run the osgtext example. Robert. On Sun, Jul 12, 2009 at 3:41 PM, Vaibhav Bansalvaib...@darshan3d.com wrote: Hello I was trying to place some osgText in my scene, the text seems to become distorted however. A picture of the distorted text is attached, please comment if any one has faced such problem before. I am using osg2.6.1. Thanks and Regards Vaibahv Bansal ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CullFace behaves differently under Linux and Win
Hi Robert, hi all, Thanks for the answer. Unfortunately, the only configs I got are XP + Geforce8 and Ubuntu + integrated graphics. I'll try to get another linux machine, but I think it won't be soon. Does anyone encountered this strange behaviour before? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sun, 12 Jul 2009 18:02:27 +0200, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, If you can try your app out on different hardware as well as different OS's as it's pretty likely that this issue is driver specific. Robert. On Thu, Jul 9, 2009 at 12:10 AM, Sukendersuky0...@free.fr wrote: Hi, I got a strange thing on a double sided model... Under Windows (XP), a line like: stateSet-setAttributeAndModes(new osg::CullFace(osg::CullFace::FRONT_AND_BACK), osg::StateAttribute::OFF); disables the face culling and my model is okay. Under Linux (Ubuntu 9.04), the *exact* same code makes all (front AND back) faces to be culled! Thus my model is invisible. Splitting this into 2 lines: stateSet-setAttributeAndModes(new osg::CullFace(osg::CullFace::FRONT), osg::StateAttribute::OFF); stateSet-setAttributeAndModes(new osg::CullFace(osg::CullFace::BACK), osg::StateAttribute::OFF); makes the model visible, with the expected behaviour. Am I wrong somewhere? May this be a driver issue? Is this *really* different from calling stateset-setMode(GL_CULL_FACE, osg::StateAttribute::OFF) for what I want? Any idea? Thanks! -- Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text Problem
HI Vailbhav, Try moving your text nearer to a local origin to see if the problem is a precision issue. A good technique to use when dealing with large model coordinates is to place a MatrixTransform above the local geometries to place them in world coords, and to enable the local geometries to have a local origin to maximize precision. Robert. On Mon, Jul 13, 2009 at 8:01 AM, Vaibhav Bansalvaib...@darshan3d.com wrote: Hello Robert, The osgText example runs fine. I tested on two machines with different cards/drivers, the problem remains. I am using these modes : text-setCharacterSizeMode(osgText::Text::OBJECT_COORDS); text-setAxisAlignment(osgText::Text::SCREEN); I am using position values of the order of 1438137.375, and font size of 1.6. Could this be related to precision. Thanks and Regards Vaibhav Bansal -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Sunday, July 12, 2009 9:51 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Text Problem Hi Vaibahv, I've never seen a problem like this before. Exactly how are you setting your text? Do you see the problem across platforms and different hardware/drivers? What happens you run the osgtext example. Robert. On Sun, Jul 12, 2009 at 3:41 PM, Vaibhav Bansalvaib...@darshan3d.com wrote: Hello I was trying to place some osgText in my scene, the text seems to become distorted however. A picture of the distorted text is attached, please comment if any one has faced such problem before. I am using osg2.6.1. Thanks and Regards Vaibahv Bansal ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada (dae) Reader/Writer issue....
Hi J-S, Thanks for getting back to me. I'll look to test this today. I suppose a related question would be whether the Collada reader/writer should be amended to make use of this explicitly itself? The issue being that given this is a graphics driver issue, and our software may be run on hundreds of machines, it would be a nice comfort factor to know that this particular problem isn't likely to arise. Many thanks for thoughts and help, Neil. Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Neil, I'm reordering your questions a bit to make the response more linear :-) Has anyone considered this already and come up with a really neat solution ? I recognise that coding around driver issues is not ideal, and may not be desireable. Yes, the osgUtil::Optimizer supports what you want. So you could use one of the osgUtil::Optimizer classes to the work for you (independently of whether your input model was COLLADA or any other format). Optionally you could just call osgconv with the appropriate OSG_OPTIMIZER environment variable on your model. Here are the relevant classes/environment options: One of the comments I read on the mail archive seemed to imply that in general to avoid these scaling problems, the model vertices should be scaled directly, and not via matrix operations. osgUtil::FlattenStaticTransformsVisitor FLATTEN_STATIC_TRANSFORMS I guess there are some complications here as if differing nodepaths to the same model produce differing scaling factors, the collada export is going to need to write geometry definitions for each of these nodepath scaled model instances. osgUtil::FlattenStaticTransformsDuplicatingSharedSubgraphsVisitor (wow what a mouthful :-) FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS I have never used those myself, but they should work. Let us know how you get on. The Optimizer also has a lot more things it can do to help you optimize your scene graph, so it's worth it to explore the options (osgconv --help-env) and the osgUtil/Optmizer header. 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] 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] Off on a weeks holiday!
Hi Robert, I've been running also not particularly this year, but last year I've run the Perpignan's marathon... It was to hot and I been really suffering... I wonder how Philippe Fuchs has run from Paris to Beijing... http://caor.ensmp.fr/~fuchs/parispekinfuchs.pdf Cheers, Pierre. 2009/7/12 Robert Osfield robert.osfi...@gmail.com: Hi All, Thanks for the well wishes, I'm now back home after a great week away. It was back to back sun shine for 2 days, and bit cloudy and windy for the others, but for the west coast of Scotland is actually really impressive, even the non sunny days we were up and about enjoying the stunning scenery and wildlife (seals, otters, golden eagles and much more :-) While away I turned 40, but rather than accept being over the hill lying down I got on my running shoes and ran over them and further than I have done in 15 years. A couple of months ago I took up running again and have slowly been getting back into my stride, I might not win any trophies like I did when I was kid but with age comes legs that can plod along happily for hours and a greater appreciation of all the great wildlife and scenery that goes by as you explore the moors, hills and coastlines. I wonder how many other runners out there in the community... it always surprised me just how many fellow hang glider and para-glider pilots turned up in the community, so perhaps cross runners/fell runners and marathon runners are here too... any ultra-marathon runners even? I'm certainly not on the later category, but find that runners that tackles these distances inspiring. Back to reality now though... got lots of email to trawl through, and thankfully not too much of a submissions backlog, hopefully I'll be able to zip through this tomorrow, right now I'll just take things easy. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ffmpeg stdint on Windows?
Hi Garrett, A bit OT, but which part of the C standard says that all uninitialized variables shall default to 0? The only zero initialization guarantee of the C standard I know of is related to static variables (which MSVC supports). If what you say about FFmpeg expected C behaviour is true, it sounds to me that FFmpeg is relying on a non-standard extensions of GCC. If you don't mind, I'll take your email as an opportunity to express my biggest complain about the FFmpeg project: its portability. On the current situation of FFmpeg on Windows, IMHO the FFmpeg dev team has abslolutely no valid reasons for not making FFmpeg portable. In fact, it looks like they took several decisions with the sole purpose of making FFmpeg a GCC-only / MSVC-incompatible product. Reading their rant about MSVC on the official website tends to confirm that some of their choices are mainly motivated by anti-microsoft political reasons rather than technical. - They've chosen to rely on the C99 standard, which is not as widely as supported as C89 and C++98. GCC is the only widely-used compiler that comes close to having a full C99 support (followed by the Intel compiler), but even GCC is still missing several features (http://gcc.gnu.org/c99status.html). MSVC and Borland have little C99 support. - They use the ATT assembly syntax for x86/x86-64 assembly code instead of using the Intel assembly syntax or Intel intrinsics. These two decisions alone mean that one would have to rewrite most of FFmpeg to get it compiling on any compiler that is not a GCC-clone. While there is nothing close to FFmpeg on the market (open or closed source), while I'm a huge supported of FFmpeg and related projects, such poor decisions are ridicule from a software engineering point of view and ultimately hurts FFmpeg. Tanguy From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Garrett Potts Sent: 11 July 2009 03:24 To: OpenSceneGraph Users Subject: Re: [osg-users] ffmpeg stdint on Windows? Hello All: The link below is the one I used before to add stdint.h and inttypes.h. I use it for the builds on windws. I have sucessfully used mingw then use Microsofts implib tool to create a import lib for the dll. Like they said below. ffmpeg will not build on MSVC and even if you can the ffmpeg dev team rely heavily on c standard that defines all uninitialized variables shall default to 0. MSVC does not put anything in an uninitialized variables and most of the variable definitions in ffmpeg core library are unnitialized. The only option is to use mingw to build a dll file and I use the implib to generate a import library for the dll. Take care all Garrett ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ffmpeg stdint on Windows?
Hello Tanguy: This probably isn't the place for the battle of ffmpeg. I have already had lengthy discussions on the ffmpeg chat list about it and variable initialization and they wouldn't accept my patches for it. Honestly I have not read up on the C standard and only took what they said as being true. They said they adhere to the C99 standard and they sent me a cut and past from the C99 standard that said variables are to be initialized to 0 but honestly can't remember if that is for static or non static or both. It is true that non gcc style compilers will probably not be able to build ffmpeg so for windows your only option I think will be a dll using mingw. I had no problems with this compiler and integrating into existing Microsoft builds but I turn off mmx and mmx2 which is mostly assembly and forces your builds to be GPL instead of LGPL when enabled. This is true also for the libswscale tha they now have you use. If it has assembly enabled then you are GPL else you can use it in an LGPL fashion. It is a tough library to build but if you can do it it is a very good library at supporting all the codecs. We are getting mpeg feeds with embedded geometries that have a codec that only ffmpeg has been able to read and non of the commercial vendors like Quicktime, Windows media player can read. Take care Garrett On Jul 13, 2009, at 7:24 AM, Tanguy Fautre wrote: Hi Garrett, A bit OT, but which part of the C standard says that all uninitialized variables shall default to 0? The only zero initialization guarantee of the C standard I know of is related to static variables (which MSVC supports). If what you say about FFmpeg expected C behaviour is true, it sounds to me that FFmpeg is relying on a non-standard extensions of GCC. If you don’t mind, I’ll take your email as an opportunity to express my biggest complain about the FFmpeg project: its portability. On the current situation of FFmpeg on Windows, IMHO the FFmpeg dev team has abslolutely no valid reasons for not making FFmpeg portable. In fact, it looks like they took several decisions with the sole purpose of making FFmpeg a GCC-only / MSVC-incompatible product. Reading their rant about MSVC on the official website tends to confirm that some of their choices are mainly motivated by anti- microsoft political reasons rather than technical. - They’ve chosen to rely on the C99 standard, which is not as widely as supported as C89 and C++98. GCC is the only widely-used compiler that comes close to having a full C99 support (followed by the Intel compiler), but even GCC is still missing several features (http://gcc.gnu.org/c99status.html ). MSVC and Borland have little C99 support. - They use the ATT assembly syntax for x86/x86-64 assembly code instead of using the Intel assembly syntax or Intel intrinsics. These two decisions alone mean that one would have to rewrite most of FFmpeg to get it compiling on any compiler that is not a GCC- clone. While there is nothing close to FFmpeg on the market (open or closed source), while I’m a huge supported of FFmpeg and related projects, such poor decisions are ridicule from a software engineering point of view and ultimately hurts FFmpeg. Tanguy From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org ] On Behalf Of Garrett Potts Sent: 11 July 2009 03:24 To: OpenSceneGraph Users Subject: Re: [osg-users] ffmpeg stdint on Windows? Hello All: The link below is the one I used before to add stdint.h and inttypes.h. I use it for the builds on windws. I have sucessfully used mingw then use Microsofts implib tool to create a import lib for the dll. Like they said below. ffmpeg will not build on MSVC and even if you can the ffmpeg dev team rely heavily on c standard that defines all uninitialized variables shall default to 0. MSVC does not put anything in an uninitialized variables and most of the variable definitions in ffmpeg core library are unnitialized. The only option is to use mingw to build a dll file and I use the implib to generate a import library for the dll. Take care all Garrett ___ 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] ffmpeg stdint on Windows?
Hi,
Tanguy Fautre wrote:
A bit OT, but which part of the C standard says that all uninitialized
variables shall default to 0? The only zero initialization guarantee
of the C standard I know of is related to static variables (which MSVC
supports).
I'm pretty sure even GCC doesn't zero-initialize variables by default, e.g.
13:31|p...@tabu:~/acgt/webservices-svn cat t.c
#include stdio.h
int main()
{
int i;
printf(%d\n, i);
}
13:38|p...@tabu:~/acgt/webservices-svn gcc -o t -std=c99 t.c
13:38|p...@tabu:~/acgt/webservices-svn ./t
134513588
If what you say about FFmpeg expected C behaviour is true, it sounds
to me that FFmpeg is relying on a non-standard extensions of GCC.
If you don’t mind, I’ll take your email as an opportunity to express
my biggest complain about the FFmpeg project: its portability.
On the current situation of FFmpeg on Windows, IMHO the FFmpeg dev
team has abslolutely no valid reasons for not making FFmpeg portable.
In fact, it looks like they took several decisions with the sole
purpose of making FFmpeg a GCC-only / MSVC-incompatible product.
Reading their rant about MSVC on the official website tends to confirm
that some of their choices are mainly motivated by anti-microsoft
political reasons rather than technical.
From the FFMPEG FAQ (http://ffmpeg.org/faq.html#SEC9)
4.3 Is Microsoft Visual C++ supported?
No. Microsoft Visual C++ is not compliant to the C99 standard and does
not - among other things - support the inline assembly used in FFmpeg.
If you wish to use MSVC++ for your project then you can link the MSVC++
code with libav* as long as you compile the latter with a working C
compiler. For more information, see the Microsoft Visual C++
compatibility section in the FFmpeg documentation.
There have been efforts to make FFmpeg compatible with MSVC++ in the
past. However, they have all been rejected as too intrusive, especially
since MinGW does the job adequately. None of the core developers work
with MSVC++ and thus this item is low priority. Should you find the
silver bullet that solves this problem, feel free to shoot it at us.
We strongly recommend you to move over from MSVC++ to MinGW tools.
The second paragraph is interesting, as it suggests that people have at
least tried in the past to get ffmpeg to be MSVC-compatible. But if they
made the decision to use C99 (which does have some nice additions
compared to the older C standards) then MSVC is indeed left in the rain :)
- They’ve chosen to rely on the C99 standard, which is not as widely
as supported as C89 and C++98. GCC is the only widely-used compiler
that comes close to having a full C99 support (followed by the Intel
compiler), but even GCC is still missing several features
(http://gcc.gnu.org/c99status.html). MSVC and Borland have little C99
support.
- They use the ATT assembly syntax for x86/x86-64 assembly code
instead of using the Intel assembly syntax or Intel intrinsics.
These two decisions alone mean that one would have to rewrite most of
FFmpeg to get it compiling on any compiler that is not a GCC-clone.
While there is nothing close to FFmpeg on the market (open or closed
source), while I’m a huge supported of FFmpeg and related projects,
such poor decisions are ridicule from a software engineering point of
view and ultimately hurts FFmpeg.
Bottom line: I think the ffmpeg devs only care about Linux (and other
unices). Windows folks are more used to having libraries available in
binary form so it takes just one guy to build FFMPEG using MinGW and
make it available for the rest to use.
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text Problem
Hello Robert, Thanks for the advice for placing geometries in local cords, it worked wonderfully. Regards Vaibhav Bansal -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, July 13, 2009 12:41 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Text Problem HI Vailbhav, Try moving your text nearer to a local origin to see if the problem is a precision issue. A good technique to use when dealing with large model coordinates is to place a MatrixTransform above the local geometries to place them in world coords, and to enable the local geometries to have a local origin to maximize precision. Robert. On Mon, Jul 13, 2009 at 8:01 AM, Vaibhav Bansalvaib...@darshan3d.com wrote: Hello Robert, The osgText example runs fine. I tested on two machines with different cards/drivers, the problem remains. I am using these modes : text-setCharacterSizeMode(osgText::Text::OBJECT_COORDS); text-setAxisAlignment(osgText::Text::SCREEN); I am using position values of the order of 1438137.375, and font size of 1.6. Could this be related to precision. Thanks and Regards Vaibhav Bansal -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Sunday, July 12, 2009 9:51 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Text Problem Hi Vaibahv, I've never seen a problem like this before. Exactly how are you setting your text? Do you see the problem across platforms and different hardware/drivers? What happens you run the osgtext example. Robert. On Sun, Jul 12, 2009 at 3:41 PM, Vaibhav Bansalvaib...@darshan3d.com wrote: Hello I was trying to place some osgText in my scene, the text seems to become distorted however. A picture of the distorted text is attached, please comment if any one has faced such problem before. I am using osg2.6.1. Thanks and Regards Vaibahv Bansal ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ffmpeg stdint on Windows?
Garrett Potts wrote: [...] Honestly I have not read up on the C standard and only took what they said as being true. They said they adhere to the C99 standard and they sent me a cut and past from the C99 standard that said variables are to be initialized to 0 but honestly can't remember if that is for static or non static or both. Looks like only static variables are zero-initialized: ISO/IEC 9899:TC2 draft, section 6.7.8, item 10: 10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then: — if it has pointer type, it is initialized to a null pointer; — if it has arithmetic type, it is initialized to (positive or unsigned) zero; — if it is an aggregate, every member is initialized (recursively) according to these rules; — if it is a union, the first named member is initialized (recursively) according to these rules. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada (dae) Reader/Writer issue....
Hi J-S, I've now had chance to have a look at your suggested optimisations, and I think they form the basis of a solution for me, so thanks for that. However there is one thing which troubles me a little, which is that the FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS optimisation, whilst flattening the static scalings, applies those scalings to the normals as well as the vertices. Whilst I can understand that this might be desirable for some strange effects, would you agree that the normals should at least be normalised after this process, else undesirable lighting anomalies can occur? Neil. Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Neil, I'm reordering your questions a bit to make the response more linear :-) Has anyone considered this already and come up with a really neat solution ? I recognise that coding around driver issues is not ideal, and may not be desireable. Yes, the osgUtil::Optimizer supports what you want. So you could use one of the osgUtil::Optimizer classes to the work for you (independently of whether your input model was COLLADA or any other format). Optionally you could just call osgconv with the appropriate OSG_OPTIMIZER environment variable on your model. Here are the relevant classes/environment options: One of the comments I read on the mail archive seemed to imply that in general to avoid these scaling problems, the model vertices should be scaled directly, and not via matrix operations. osgUtil::FlattenStaticTransformsVisitor FLATTEN_STATIC_TRANSFORMS I guess there are some complications here as if differing nodepaths to the same model produce differing scaling factors, the collada export is going to need to write geometry definitions for each of these nodepath scaled model instances. osgUtil::FlattenStaticTransformsDuplicatingSharedSubgraphsVisitor (wow what a mouthful :-) FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS I have never used those myself, but they should work. Let us know how you get on. The Optimizer also has a lot more things it can do to help you optimize your scene graph, so it's worth it to explore the options (osgconv --help-env) and the osgUtil/Optmizer header. 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] ffmpeg stdint on Windows?
This is similar to C++03, ISO/IEC 14882-2003 Section 8.5 Initializers ... if no initializer is specified for a nonstatic object, the object and its subobjects, if any, have an indeterminate initial value T -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Melis Sent: 13 July 2009 12:53 To: OpenSceneGraph Users Subject: Re: [osg-users] ffmpeg stdint on Windows? Garrett Potts wrote: [...] Honestly I have not read up on the C standard and only took what they said as being true. They said they adhere to the C99 standard and they sent me a cut and past from the C99 standard that said variables are to be initialized to 0 but honestly can't remember if that is for static or non static or both. Looks like only static variables are zero-initialized: ISO/IEC 9899:TC2 draft, section 6.7.8, item 10: 10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then: - if it has pointer type, it is initialized to a null pointer; - if it has arithmetic type, it is initialized to (positive or unsigned) zero; - if it is an aggregate, every member is initialized (recursively) according to these rules; - if it is a union, the first named member is initialized (recursively) according to these rules. Paul ___ 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
Re: [osg-users] ffmpeg stdint on Windows?
Hi Paul, The thing is that MSVC supports most of the C99 features indirectly, as they are backported from C++ (e.g. one-line comments, relaxed variable declaration requirements, etc). Most people have been using these on MSVC (and GCC) for C code well before the C99 standard was put in place. Other problem such as the missing stdint.h header can be easily worked around (cf. Previous discussions in this thread). I'd be very curious to know what are the C99 features that are essential to FFmpeg, not supported by MSVC and that cannot be easily worked around. Tanguy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Melis Sent: 13 July 2009 12:45 To: OpenSceneGraph Users Subject: Re: [osg-users] ffmpeg stdint on Windows? Hi, [...] The second paragraph is interesting, as it suggests that people have at least tried in the past to get ffmpeg to be MSVC-compatible. But if they made the decision to use C99 (which does have some nice additions compared to the older C standards) then MSVC is indeed left in the rain :) [...] Paul ___ 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
Hi Colin, 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). 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. 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] Build Error Windows : Application osgViewer
Hi Robert, welcome back from vacation :-) Sorry about this, it was an accidental check-in that looked to be checked in with some changes that were appropriate to check in. I've now reverted this change. Could you do an svn update and double check that svn/trunk is now working once more. osgviewer builds and runs fine now, thanks. Actually the whole OSG+applications+examples+plugins builds fine for me. Vista SP1, VC2005 SP1. 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] Collada (dae) Reader/Writer issue....
Hi Neil, Sorry this mail first went to you personally - I don't know why but the message I replied to defaulted to send to you personally instead of going back to the list, generally e-mails coming from the list go back to the list automatically when you reply to them... Weird. I've now had chance to have a look at your suggested optimisations, and I think they form the basis of a solution for me, so thanks for that. However there is one thing which troubles me a little, which is that the FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS optimisation, whilst flattening the static scalings, applies those scalings to the normals as well as the vertices. Whilst I can understand that this might be desirable for some strange effects, would you agree that the normals should at least be normalised after this process, else undesirable lighting anomalies can occur? Possibly - you could change it and submit the change to see what other people will have to say. I have never personally used these optimizer settings so it would be better if the actual users of it could comment as to whether this is desirable in the general case or whether it should be an option instead. I personally think normals should be normalized by default and the reverse case (not normalizing them) should be an option, but as I said I'm not one of the users of this visitor so the decision is not mine to make. As a workaround I think you could use the osgUtil::SmoothingVisitor (or using osgconv add the --smooth command line option), this give you unit-length normals but will also smooth them so it may not be exactly what you want. You could check the code of the SmoothingVisitor to make a similar one that does what you want. 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
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] frame rate faster than monitor vsync?
We're doing computations with the 3D engine, getting images, color histograms, etc. at different model parameter settings, 1 change for each frame, so the faster we can render the better. Can one change vsync dynamically, at any time, just by changing vsync setting in the traits? bob -Original Message- From: Paul Speed [mailto:psp...@progeeks.com] Sent: Saturday, July 11, 2009 9:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] frame rate faster than monitor vsync? I have to be pedantic here... the eye can most _certainly_ detect movement beyond 60 hz. But there is no point in displaying faster than that if your display can't render faster than 60 hz. There are good reasons to do so, though. For example, to test rendering speed to get good benchmarking for seeing how much CPU your rendering code is wasting. Alternately, there are certain situations where one may be driving sensing equipment that wants higher refresh. Of course, then the display is expecting that refresh or whatever is receiving the output... so we still come back to driving your display at what your display expects. Or benchmarking. -Paul Philip Taylor wrote: Wyatt, Out of very idle curiosity, why would you render at 2KHz when the eye can't really detect movement beyond 60Hz? Would it just be for rendering individual frames for a movie? PhilT -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org]on Behalf Of Wyatt Earp Sent: 11 July 2009 19:08 To: OpenSceneGraph Users Subject: Re: [osg-users] frame rate faster than monitor vsync? I have renderered in excess of 2 KHz on ocassion. Wyatt On 7/11/09, Ulrich Hertlein u.hertl...@sandbox.de wrote: Hi Bob, On 10/7/09 9:05 PM, Bob Youmans wrote: Hi, does anyone know if it's possible to run faster than the 60Hz vsync or 100Hz osg limit, if computational performance is the ultimate goal even at the expense of tearing. Can I get 600 fps by turning off vsync (or something else, it didn't work on my box)? Is the graphics card driver/model involved? How can you tell which ones will work without actually buying it? If you turn off vsync then OSG will render as fast as possible, without any artificial limitation. There's no 100 Hz OSG limit that I'm aware of except maybe in the DB pager. Sure you can get 600 fps if you're willing to accept tearing (or render offscreen), even my GeForce 8600M GT laptop gives me over 1000 fps for moderately complex models. And yes, the graphics card is obviously involved (the faster the better) and so is the driver. If you're not seeing more than vsync fps then the reason is most likely due to setup, e.g. a driver settings forcing vsync on or __GL_SYNC_TO_VBLANK being set on Linux. Cheers, /ulrich ___ ___ 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
Hi Colin, 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. But then it's changing states that was costly, not state sorting? I'm sure Robert's suggestion was accompanied with in your case, since your scene is ..., then using vertex attributes will probably be faster. Indeed, if you have a very large number of small geometries, and each one has a different value for the uniform, this may be the case. But as I said, the uniform changing for each and every object, and having lots and lots of objects, is rather a pathological case. Generally the uniform will have the same value for a batch of objects, and depending on the size of the objects (geometry etc.) changing the uniform will be insignificant compared to other things. 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. Of course, there are many ways to skin a cat. You have to remember too that you can have many more uniforms than attribute arrays, so depending on the number of values you need you may have no choice... Interesting discussion in any case, it's always good to know there are some other options available to do what you need to do. Thanks, 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] frame rate faster than monitor vsync?
Hi all, here's how I'm turning off vsync and it's not having any effect. Any ideas. This setup is based on one of the examples, C++ / Windows / Vista. I have dual monitors. Would that make any difference? Thanks, Bob // Local Variable to hold window size data RECT rect; // Create the viewer for this window m_pViewer = new CTOSOM_OSGViewer(this); // Add a Stats Handler to the viewer m_pViewer-addEventHandler(new osgViewer::StatsHandler); m_pViewer-addEventHandler(new TOSOM_OSGkeyboardEventHandler); // Get the current window size ::GetWindowRect(m_hWnd, rect); // Init the GraphicsContext Traits osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; // Init the Windata Variable that holds the handle for the Window to display OSG in. osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(m_hWnd); // Setup the traits parameters traits-x = 0; traits-y = 0; traits-width = rect.right - rect.left; traits-height = rect.bottom - rect.top; traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-inheritedWindowData = windata; traits-vsync = false; // Create the Graphics Context osg::GraphicsContext* gc = osg::GraphicsContext::createGraphicsContext(traits.get()); // Init a new Camera (Master for this View) osg::ref_ptrosg::Camera camera = new osg::Camera; // RLY set CullingMode camera-setCullingMode(osg::CullSettings::NO_CULLING); // Assign Graphics Context to the Camera camera-setGraphicsContext(gc); // Set the viewport for the Camera camera-setViewport(new osg::Viewport(traits-x, traits-y, traits-width, traits-height)); // RLY - set ortho projection camera-setProjectionMatrixAsOrtho(-5000, 5000, -5000, 5000, -5000, 5000); // Add the Camera to the Viewer m_pViewer-addSlave(camera.get()); // Add the Camera Manipulator to the Viewer m_pViewer-setCameraManipulator(m_pswitchManipulator.get()); // Set the Scene Data m_pViewer-setSceneData(m_pRoot.get()); // Realize the Viewer m_pViewer-realize(); } -Original Message- From: Ulrich Hertlein [mailto:u.hertl...@sandbox.de] Sent: Saturday, July 11, 2009 8:26 AM To: OpenSceneGraph Users Subject: Re: [osg-users] frame rate faster than monitor vsync? Hi Bob, On 10/7/09 9:05 PM, Bob Youmans wrote: Hi, does anyone know if it’s possible to run faster than the 60Hz vsync or 100Hz osg limit, if computational performance is the ultimate goal even at the expense of “tearing.” Can I get 600 fps by turning off vsync (or something else, it didn’t work on my box)? Is the graphics card driver/model involved? How can you tell which ones will work without actually buying it? If you turn off vsync then OSG will render as fast as possible, without any artificial limitation. There's no 100 Hz OSG limit that I'm aware of except maybe in the DB pager. Sure you can get 600 fps if you're willing to accept tearing (or render offscreen), even my GeForce 8600M GT laptop gives me over 1000 fps for moderately complex models. And yes, the graphics card is obviously involved (the faster the better) and so is the driver. If you're not seeing more than vsync fps then the reason is most likely due to setup, e.g. a driver settings forcing vsync on or __GL_SYNC_TO_VBLANK being set on Linux. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] vsync false doesn't change frame rate
Hi all, I'm trying to get frame rates above 60Hz, and when I set the traits-vsync = false it has no effect. I'm getting the default camera created by the View in the Viewer and re-setting its traits. Is that not the right approach? Thanks, Bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync false doesn't change frame rate
Hi Bob, Hi all, I’m trying to get frame rates above 60Hz, and when I set the traits-vsync = false it has no effect. I’m getting the default camera created by the View in the Viewer and re-setting its traits. Is that not the right approach? Check your display settings (in your OS - nvidia control panel or whatever), they might be forcing the vsync on. 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] vsync false doesn't change frame rate
On 13/7/09 4:42 PM, Jean-Sébastien Guay wrote: Hi Bob, Hi all, I’m trying to get frame rates above 60Hz, and when I set the traits-vsync = false it has no effect. I’m getting the default camera created by the View in the Viewer and re-setting its traits. Is that not the right approach? Check your display settings (in your OS - nvidia control panel or whatever), they might be forcing the vsync on. This reminds me of something that I asked a while ago: as far as I can tell there is no way in OSG to modify vsync after the context has been established. At least the OS X code only checks the vsync trait on setup. I have a preliminary patch that adds this on OS X (key binding 'v' and code to toggle vsync at runtime) but it's a bit raw. Is it worth polishing this for submission? Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering Performance and Proper Way to have millions of moveable objects
Sounds like a CAD application. Look into occlusion culling and imposters. Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: osg-users@lists.openscenegraph.org From: Andrew Burnett-Thompson aburnettthomp...@googlemail.com Sent by: osg-users-boun...@lists.openscenegraph.org Date: 07/12/2009 05:12PM Subject: [osg-users] Rendering Performance and Proper Way to have millions of moveable objects Hi Robert, Thanks for your reply. Yes I did guess that I'm using the scene graph wrong. Fortunately with regard to our scene, while we have a lot of objects, the detail is not significant. The application allows users to simulate certain conditions that would occur in an industrial plant. So long as the model is a crude reflection of the plant it works, so we are already significantly optimising geometry. Rendering is only required as the user moves around the plant, or if an object is manipulated. During render we are currently hiding the smallest 50% of objects, which works remarkably well to improve usability (A full re-draw is performed when the user stops moving), but still the frame rate drops below interactive levels depending on how many objects remain. With regard to flattening of static transforms - how exactly would we do this? I was thinking to put a PAT as parent of a geode only while the user is picking/manipulating it, then remove it after, somehow matrix-multiplying the transform with vertices to get the new position. Is this possible? With regard to LOD's - sounds like a good plan but I think this may end up using more memory (which is an issue) even though it improves rendering performance. Paging does interest me though. I already set the cull settings to ENABLE_ALL_CULLING. I noticed that shadow occlusion (which I believe means when a large object occludes the camera, objects behind it are culled?) seems to have no effect. Is this due to my flat scene graph? View frustrum culling seems to have the largest effect. With regard to efficiently managing the scene graph (having a balanced tree), thanks for confirming that. I did have a hunch that would be the case but its nice to know. With regard to state sharing - is it possible to have one state object on multiple geodes? Or did you mean have multiple statesets with similar states? Cheers for the feedback much appreciated, Andrew ___ 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] [osgPlugins] Plugin Logo bug
Hi Alexandre, I believe your changes suggest a deeper problem with the design/implementation of the logo. The plugin is a very early hack that hasn't really been fully updated to take advantage of various modern OSG features, I don't have time right now for a full rewrite though. Is the problem you are seeing triggered by the logo being used when multiple graphics windows are used? It does look like code assumes a single view per graphics window, something that isn't always true with the OSG these days. In the Producer days when this plugin was written one couldn't easily have multiple views per window, but these days it's trivial and common place thing to do. If the logo was attached in a window with multiple views that all shared the same scene graph we'd end up with the viewport being updated multiple times, with the last view's viewport taking precedence. One possible solution would be to have the callback ignore the cull visitor's viewport and use the whole graphics windows dimensions, so the logo would be placed relative to the window rather than the last rendered viewport. All in all though, putting a logo in the scene graph is not the best way of tackling the task of adding logo's - it'd be much better to use a slave camera attached to the viewer/viewer. Thougts? Robert. On Mon, Jul 6, 2009 at 3:57 PM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi osg-users, I'm using osg svn version 2.9.5 and I've apparently found a bug in osgPlugin logo. When using more than one view logosCullCallback function is called without checking context ID from the cull visitor is equal to logo _contextID variable. It involves updating logo's viewport with different sizes. So I made a fix well working, at least the way I use the plugin. I'm not used to post fix so I attached the modified cpp files in current mail, hope it helps... Code I added is indicated with comment : // AA DD/MM/YY Fix Kind regards -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ 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] how to set per vertext attributes using osg
Jason Daly wrote on Friday, July 10, 2009 1:25 PM: Jean-Sébastien Guay wrote: OSG sorts by state to minimize state changes, but I'm not sure how it does the sort. I believe the state sort is done using the compare() method of StateAttribute. In the case of Uniforms, the comparison is pretty thorough (first data type, then number of elements, then actually comparing the data values of each element). The facility is there for comparing StateSets and StateAttributes, but is disabled (see osgUtil::RenderBin::sortByState()) for performance reasons. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering Performance and Proper Way to have millions of moveable objects
It is exactly that - like a CAD application. Today I had fun with osgUtil::Optimizer which reduced my vertex count by around 50% when applying MERGE_GEOMETRY. Yes I will take a look at occlusion culling. I enabled it but it made no difference. Possibly due to my flat scenegraph? Imposter's i've not heard of, thanks for the heads up :) Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync false doesn't change frame rate
You may also want to verify that the environment variable __GL_SYNC_TO_VBLANK is not set. For certain graphics cards/drivers, this variable allows you to control the frame rate. If this variable is set to any non-zero value, the application settings will be overridden, and the frame rate will be locked to the monitor refresh rate. http://http.download.nvidia.com/XFree86/Linux-x86/1.0-8174/README/32bit_html/appendix-e.html -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ulrich Hertlein Sent: Monday, July 13, 2009 11:02 AM To: OpenSceneGraph Users Subject: Re: [osg-users] vsync false doesn't change frame rate On 13/7/09 4:42 PM, Jean-Sébastien Guay wrote: Hi Bob, Hi all, I’m trying to get frame rates above 60Hz, and when I set the traits-vsync = false it has no effect. I’m getting the default camera created by the View in the Viewer and re-setting its traits. Is that not the right approach? Check your display settings (in your OS - nvidia control panel or whatever), they might be forcing the vsync on. This reminds me of something that I asked a while ago: as far as I can tell there is no way in OSG to modify vsync after the context has been established. At least the OS X code only checks the vsync trait on setup. I have a preliminary patch that adds this on OS X (key binding 'v' and code to toggle vsync at runtime) but it's a bit raw. Is it worth polishing this for submission? Cheers, /ulrich ___ 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 Texture - CEGUI Texture
The problem is that osgWidget doesn't offer a lot of functionality that one finds in a somewhat more mature toolkit (even CEGUI). For example: * common GUI widgets are already fully developed (eg progress bar, scroll bar, tables, close button, etc) * GUI elements (windows, buttons, etc) are easily skinnable * XML content specification with graphical layout editor * etc. For us the context/threading issues may not be too hard to swallow, so it seems like a pretty good fit. Anyway, I dont want to start a debate, just throwing in my two cents on why we've decided to go with CEGUI over osgWidget. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Sunday, July 12, 2009 10:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG Texture - CEGUI Texture Hi Brad, Could you just use osgWidget instead? I've played with CEGUI in the past and found it's design very poor for doing general purpose graphics application integration - it can't handle multiple graphics context nor multi-threading, I learnt enough about it's short coming in design and implementation to know that it wasn't worth investing more time into, there are far better ways to tackle this type of work. Robert. On Thu, Jul 9, 2009 at 4:15 PM, Brad Huberbr...@procerusuav.com wrote: Hello, Im currently using an RTT Camera within OSG and I would like to use the texture associated with it in CEGUI. This will give the ability to render a 3d scene within a CEGUI window. Im coming up short finding out how to do this. Has anyone done this previously and might have a code snippet? I did find this http://www.gamedboy.com/tiki-index.php?page=MiniMap%20CEGUI which shows Ogre-CEGUI but they use a magic function that converts between Ogre and CEGUI textures Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault in osgPlugins/vrml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Falko Kellner wrote: Hi Robert, Could you send the whole file you modified to osg-submission, I'll review it once it arrives. ok, should be sent. Hi Falko, Robert - see my comments on the patch in the submission list. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKW5FCn11XseNj94gRAv9zAKC1PCYeRl/ngkJiXodLR8rUDFqwoACgnGql xB/7phCLuRgbI+G2dl8cUcM= =ztSe -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
