Re: [osg-users] Adding threading to QOsgWidget
Hi, On Monday 15 January 2007 20:56, Ben Cain wrote: > Is there an example (or even hints) showing the proper way to add threading > to the QOsgWidget class developed by Gazihan Alankus? See the method > QOsgWidget::paintGL() and it’s calls to osgUtil methods: update(), cull(), > and draw(). > > > > I’d prefer to use QThreads if possible. > > > > I’ve looked through the Producer code and it’s usage of threads (e.g. > Camera, RenderSurface). But, QOsgWidget isn’t based upon Producer. Keep in mind that you can't use any QWidget (QOsgWidget : public QGLWidget : public QWidget) in an other thread than the main thread. That means especially the update and draw stuff. I have not yet tried that, but: The only thing I could think of haveing multithreaded rendering with qt is to open a new X11 window that could be embedded using QX11EmbedWindow et. al. into your qwidget hierarchy. Drawing into additional X11 connections without the knowledge of qt could then be done in seperate threads. The required communication between the qt based window and the opengl window about repaints, focus changes and so on is done by the X11 server and the XEmbed protocol. For win32 I have not yet thought about something similar ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Thread-safe reference counting viaatomicincrement/decrement
Hi, On Tuesday 16 January 2007 01:31, Mike Wittman wrote: > I don't have any experimental data on performance at this point, and I > don't know that this would be a significant bottleneck. I'm just > interested to see if anyone has previously considered this approach in > the event that it does become an issue for me. What I do know is that > during osg::Referenced creation the CRITICAL_SECTION structure requires > separate heap allocation of about 56 bytes of memory on 32 bit Windows > and about 80 bytes on 64 bit Windows, including an allocation of a > kernel handle, and requires deletion of the same at destruction. An > atomic count would incur no extra allocation or deletion. And at least on MSVC and gcc >= 4.1 there are compiler builtin functions to do atomic counts. With that knowledge the compiler can probably even optimize successive ref/unref pairs away under some circumstances ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Thread-safe reference counting viaatomicincrement/decrement
Hi Robert, On Tuesday 16 January 2007 13:48, Robert Osfield wrote: > On 1/16/07, Mathias Froehlich <[EMAIL PROTECTED]> wrote: > > And at least on MSVC and gcc >= 4.1 there are compiler builtin functions > > to do atomic counts. > > With that knowledge the compiler can probably even optimize successive > > ref/unref pairs away under some circumstances ... > > Do you have a links to information on this? Hmm, I have even beginnings of an implementation for osg on my local disc at home :) Also, one free implementation using that stuff is in SimGear - a base lib of flightgear - www.simgear.org, SGAtomic.*. There is an implementation that uses either those two builtins if available or a plain mutex otherwise. The functions in MSVC are InterlockedIncrement for example, you will find documentation in MSDN about that. The one gcc intrinsic is named __sync_add_and_fetch for example. Documented in the gcc info file. BTW the gcc intrinsics are derived from some functions originally defined for the ia64 abi. May be other compilers support them as well ... Well, I believe the easiest way would be for me to finish that implementation that I have already started ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: [osg-submissions] Draft atomic operations for reference counts
Hi, ... moved to osg users on Roberts request ... On Tuesday 23 January 2007 09:57, Robert Osfield wrote: > The OSG is very deliberately *not* meant to be thread safe in a > general purpose way, such safety adds huge overheads in desgin, > implementation and runtime performance. The OSG has gone the route of > light weight thread safety - you should just update the scene during > the single threaded read/write update phase, but can safely > multi-thread it during the read only rendering phase (cull & draw). Yep. > > Given that I can also think about putting addition of observers into the > > area of 'scenegraph modifications' that should be done under a general > > scenegraph mutex that lives in the scope of the application. > > That means: the user is responsible for that like the user is responsible > > for not modifying the sg while it is culled and drawn. > > The new osgViewer::Scene will have ReadWriteMutex to marshal the > different phases of modifying the scene graph. This means on top > level mutex per scene graph. Yep. > > Let's first decide that general question above ... > > General purpose global locks and bad thing, its only appropriate to > have global locks in very specific places where protection of global > data strucutres is required. The observer list is not a global data > structure so inapprorpiate for a use of a global mutex. I was talking about that single lock per scenegrahp you are talking about a few lines above. The question boils down if 'modifying an observer' should be treated as 'modifying the scenegraph' and thus should be guarded with the 'per scenegraph lock' from above? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] FlightGear rendering errors since 2007-01-21 18:25:00
On Tuesday 23 January 2007 18:44, Martin Spott wrote: > Martin Spott wrote: > > Currently I'm hunting severe rendering errors with FlightGear that were > > introduced with the changes at 2007-01-21 between 18:24:00 and 18:25:00 > > UTC, but I'll post this into a new thread, > > http://foxtrot.mgras.net/bitmap/FGFS/FGFS-OSG_2007-01-21_18:25:00.jpg > > Actually this screen should show a panel and a nice view out the > windshield, I am not sure about that but the triangles are drawn as such. But their appearence is broken. Somehow like a polygon fill pattern ... I am currently working with cvs from 2007-01-22 (I believe). That one that is snapshotted at ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/OpenSceneGraph-20070122. The snapshot is just past the checked in updates to the txf loader. I have to double check the exact date and revisions. But my c172 looks ok ... May by I can today evening try with current cvs ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] FlightGear rendering errors since 2007-01-21 18:25:00
Hi, On Wednesday 24 January 2007 10:32, Robert Osfield wrote: > One thing to look for is output of error messsages to the console - by > default the OSG checks once every frame for OpenGL errors and if finds > out it reports it, and ups the granularity that it checks for errors. > If the OSG is sending erroneous OpenGL data then typically you'll get > message printout out to the console. OpenGL does catch all problems > though so the OSG can still send invalid pointers etc, but in general > the OSG should play nice and send everything along safey. The OSG is > used by a great number of users so such problems tend to get spotted > and fixed pretty early on in a features life. ... you remember the line in renderer.cxx that I commented out on your sgi last christmas. Does that tell something? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Viewer design
Hi Robert, On Wednesday 24 January 2007 10:45, Robert Osfield wrote: > As Richard suggest what we really need is a FrameStamp with both a > "real time" ReferenceTime and the possibility of SimulationTime. I > suggested this in another thread during the last couple of weeks. Yep, something like that would also be helpful for flightgear ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] proposal: osg::ref_ptr + osg::observer_ptr+ osg::Referenced = libSmartPointer ?
Hi, On Thursday 25 January 2007 09:01, Ignacio García wrote: > I have been thinking the same, using ref_ptr in non-OSG code, with the same > drawbacks you are seeing. You say that ref_ptr depends on OpenThreads, and > Producer has a Producer::ref_ptr similar or equal to osg::ref_ptr. > > After all this, what about moving osg::Referenced, osg::ref_ptr and > osg::observer_ptr to OpenThreads? It wouldn't add an additional library to > OSG, Producer could reuse OpenThreads::ref_ptr instead of declaring its > own, and user code could use ref_ptr's just linking OpenThreads lib (what > must be done if you want to use ref_ptr). > > The main drawback is that I suppose it requires a lot of changes in OSG to > use OpenThreads::ref_ptr instead of ref_ptr (in the OSG namespace). > > Thoughts? Just my 2 cents: Implementing reference counting is *not* a compicated task. Also, there are many variants of implementing refcounts that fit different needs. I for myself would never accept having a virtual table for some applications of refcounting where for other applications of refcounting having a virtual destructor is desired. There is also an other interresting concept of weak pointers in the boost implementation (and probably the upcomming stdc++ standard) that I would miss here and that I would favour over the observer in *some* cases ... IMO: If you need refcounting, think about your needs and implement that variant that you need ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] FlightGear rendering errors since 2007-01-21 18:25:00
Hi, On Monday 29 January 2007 11:17, Martin Spott wrote: > Martin Spott wrote: > > http://foxtrot.mgras.net/bitmap/FGFS/FGFS-OSG_2007-01-21_18:25:00.jpg > > > > Actually this screen should show a panel and a nice view out the > > windshield, > > Finally, I herewith nominate Mathias for the accolade because he fixed > this in FlightGear, Yep, I memember, I was willing to post that here but forgot ... The problem was/is that I have a top level camera that only clears the color buffer. Then the sky (I call that the 'background scene') is rendered without depth test. The ordering is guaranteed using render bin numbers. The 'real scene' is placed below a seperate Camera that then clears the depth buffer. This depth buffer clear is not honoured and thus the z buffer was never cleared. Resulting in such nice patterns ... The fix is to place a ClearNode with the z-buffer clear above that Camera in question. BTW: I am not sure about how the Camera's clear mask is meant, but currently we have cases where this is ignored. Robert? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] FlightGear rendering errors since 2007-01-21 18:25:00
Hi, On Monday 29 January 2007 13:10, Robert Osfield wrote: > HI Mathias, > > On 1/29/07, Mathias Froehlich <[EMAIL PROTECTED]> wrote: > > BTW: I am not sure about how the Camera's clear mask is meant, but > > currently we have cases where this is ignored. > > Robert? > > If a Camera is nested in the scene graph then it effectively just > controls a nested RenderBin, and RenderBin's don't have a clear > operation associated with them, only RenderStage do, so the Camera's > clear options don't have anything to, so are ignored. Ok, then the ClearNode must be used here ... ... ok, or alternatively clear in the top level camera as usual and just switch off depth buffer writing and tests ... > With the new osgViewer library one can handle HUDs in other ways other > than just placed a HUD Camera within the scene graph. One can do it > via osgViewer::CompositeViewer with the HUD managed as a separate view > to a separate scene graph. Alteranitvely you can manage the HUD > Camera yourself and just associate it with the GraphicsWindow and let > the viewer wire up the rendering operations - this is how the stats > are done. If these case the Camera's clear setting should all map > just fine. That is interresting to know! Thanks! Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: [osg-submissions] Draft atomic operations for reference counts
Hi Robert, On Wednesday 24 January 2007 16:09, Robert Osfield wrote: > It has occurred to me that perhaps we could put the list of observers > in a singleton rather attached to each Referenced object. This > singleton would have a something like a map Observer*>> and a single mutex to protect this data structure. > > There are instances of smart pointers that have non instrusive ref > counters done in this way. The OSG could use this approach, but its > not a good for performance so I've avoided it. However, very few > objects have observers so its not a cost that you'll pay too often - > the only extra cost is the call to the singleton on deletion to tell > it that you are no longer around. The later could possible be avoid > via use of an atomic count of number of observers - if its non zero > then you call the singleton. > > Another variation on this would be for the singleton to simple be a > DeleteHandler (note that support already exists in Refernced for this) > and build in the observer support. I have that still on my radar, but currently no time left ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] svn simplification
On Monday 19 February 2007 23:16, Joakim Simonsson wrote: > I wasn't aware of that it is was version controlled. > > According to Jan's mail: It is possible to omit the externals when you are > checking out something with the svn:external property set. > > The svn:external property doesn't allow you to choose the destination > directory of the externals, does it? It does. You can pull specific svn revisions or just track a head/branch/tag version ... From my point of view. It makes sense to put the Make subdirectory beside the Open* sources and pull the Make subdirectory with such an svn:external property into them. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] float == 1.0f?
Hi,
On Monday 26 February 2007 09:23, Anders Backman wrote:
> I just got stuck on something I been worried about for quite some time
> regarding the Math library in osg:
>
> bool Matrix::isIdentity() const
> {
> return _mat[0][0]==1.0f && _mat[0][1]==0.0f &&
> _mat[0][2]==0.0f&& _mat[0][3]==
> 0.0f &&
>_mat[1][0]==0.0f && _mat[1][1]==1.0f &&
> _mat[1][2]==0.0f&& _mat[1][3]==
> 0.0f &&
>_mat[2][0]==0.0f && _mat[2][1]==0.0f &&
> _mat[2][2]==1.0f&& _mat[2][3]==
> 0.0f &&
>_mat[3][0]==0.0f && _mat[3][1]==0.0f &&
> _mat[3][2]==0.0f&& _mat[3][3]==
> 1.0f;
> }
>
> Is there a specific reason for not using epsilon tests for a float? I can
> think of quite a few situations when this would fail.
> I guess, there is only one situation when this would succeed for sure, and
> that is after a call to makeIdentity().
>
>
> This also goes for quite some of the Vec3, Vec4, Quat code too.
> All comparisons such as:
>
> inline bool operator == (const Vec3f& v) const { return _v[0]==v._v[0] &&
> _v[1]==v._v[1] && _v[2]==v._v[2]; }
>
> Would effectively fail in most situations, as comparing floats directly is
> something that is not recomended.
>
>
> Instead something like the following should be used:
>
>
> #define EPSILON 1E-16
> #define EQUAL(A,B) (abs((A)-(B)) < EPSILON)
>
> inline bool operator == (const Vec3f& v) const { return
> EQUAL(_v[0]-v._v[0]) && EQUAL(_v[1]-v._v[1]) && EQUAL(_v[2]-v._v[2]); }'
Well, that is wrong too.
In effect you are making fixed point arithmethic from floating point
arithmethic.
Somehow more correct would be:
#define EQUAL(A,B) (abs((A)-(B)) <=
std::numeric_limits::epsilon()*max(abs(a), abs(b)))
But even that is not the real trueth...
See Goldbergs excelent paper 'what every sceintist should know about floating
point arithmetics' (just google for that).
Doing that right is highly dependent on the application you need.
Due to error accumulation your proposed bound is too hard, since this test
only checks for roundoff in the representation, not roundoff that happens
when operating on such numbers.
I cannot speak for osg, but from my point of view the implemented method is
perfect. If you want to have an 'equal up to floating point precision' test I
would prefer having a new set of methods that do not test for exact equality.
From my experience with that kind of stuff, you should not hard code that
EPSILON here - may be provide a sensible default value but no hardcoding ...
Greetings
Mathias
--
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] math functions in global namespace
Hi, We have some problems with the osg/Math header on solaris. Depending on the order of inclusion we have a redefinition of some libm functions in math.h or sunmath.h that are already defined in osg/Math. Given that this is an osg header I would suggest that those functions are put in the osg namespace instead of the global namespace. If we can do so, I would provide a patch for that. Opinions? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] limit Camera display "framerate"
Hi Robert, On Friday 01 June 2007 18:05, Robert Osfield wrote: > On 6/1/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote: > > okay, and in this case, is it possible / tested to have multiple viewers > > on the same OpenGL Context ?... > > You can multiple views that share the same graphics context, but > you'll need to use a single CompositeViewer for it to ensure that the > threads are sycronized. > > You also need to realistic, frame rate is governed by the swap buffers > of a window, when you do swap buffers all cameras drawing to that > window have to redrawn, you can't selectively say I just want swap > buffers on one cameras viewport on that window. Well, I can see an application of a frame rate limit for specific contexts. I would like to make mpeg movies from a running simulation with an existing viewer with one or more windows. The idea is to attach an additional pbuffer slave camera with a post render callback that converts the resulting image to yuv and writes it into a pipe to an external encoder program. Using an additional camera will ensure that you are free to resize the window that is displayed and that you do not rely on other windows not being on top of the opengl window. Obviously it is a waste of cpu/gpu power if this is done with 60 hz. Rendering with 30 hz - that is omitting every second frame - for that kind of slave camera would be good. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] limit Camera display "framerate"
Hi Robert, On Monday 04 June 2007 10:33, Robert Osfield wrote: > As part of the core OSG's viewer library there is a limit on how much > flexibility we can provide without ending up with a really convoluted > API and implementation. Sure. Is there any callback in the camera that can disable rendering in that case? Something like a callback that can omit every second frame or a quick way to disable such a camera completely every second frame together with an apropriate update callback for example? Are the node masks of these 'toplevel cameras' honoured, so that I just switch off that camera by a 0 node mask every other frame? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] limit Camera display "framerate"
Hi Robert, On Monday 04 June 2007 11:09, Robert Osfield wrote: > The update callbacks on a camera won't be called (I think :-) if the > NodeMask is 0 so it wouldn't be suitable to doing the toggling. > > You could do the toggling the main loop though, i.e. Ok, I think I just need to play with that a bit ... Thanks! Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Introducing my assistant... Martin Lavery
On Monday 04 June 2007 13:09, Robert Osfield wrote: > Today Martin Lavery has begun work alongside me. Martin will be doing > pair wise programming with me sharing keyboard/mouse duties to help me > recover from the Repetitive Strain Injury (RSI). > > Martin is newbee to the OSG, as well as OpenGL and C++, so will also > provide a perspective that other new comers to real-time graphics > will have. > > Please wish him luck! Best whishes to you both! Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Compile Error: osgManipulator with SunStudio
Hi Robert, On Tuesday 05 June 2007 11:10, Robert Osfield wrote: > On 6/5/07, Mathias Froehlich <[EMAIL PROTECTED]> wrote: > > We had a great week and presented flightgear with a multi view setup that > > was possible due to osg. > > Good to hear things went well, and multi-view goodness is here to > stay. But I have to ask pictures, any picutres :-) Sorry, not at work :) I have to dig them out at home ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Compile Error: osgManipulator with SunStudio
Hi Robert, On Tuesday 05 June 2007 10:34, Robert Osfield wrote: > > I was unable to follow development closely for more than one > > week (we were exhibiting on LinuxTag) > > Hey, hey, hows about a little news report for us less lucky souls :-) We had a great week and presented flightgear with a multi view setup that was possible due to osg. Thanks for your hard work! Greetings Mathais -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Compilation on HP-UX
Hi Robert, On Wednesday 26 July 2006 16:10, Robert Osfield wrote: > HP-UX is a platform that is very rarely used by members of the OSG > community, so its no great suprise that their might be unresolved > issues. > > What version are your headers? > > If we need to find an alternative to the #ifndef > GL_ARB_vertex_buffer_object then we'll need to find one that is cross > platform, one has to assume that the code works elsewhere fine, so it > might just be a certain version of HP-UX OpenGL that headers we need > to test for. > > I don't have a HP-UX system so I'm afriad you'll need to do most of > the leg work on resolving it. If we can get it resolved we can > release it with 1.1.1. Ok, in the meantime I have started a request at HP's OpenGL group. They were aware of some of the problems and are now aware of the rest. Our contact person at HP appeares to be very cooperative. According to him, some of the problems will be fixed with PHSS_32969/PHSS_32968, while some of the required fixes, will appear with the next update. In this case I will not look for a workaround for GL_ARB_vertex_buffer_object and this specific patchlevel. We have here a small set of remaining patches for OSG that we need to make it compile with some not so common platforms like HP-UX, SunOS ... . You will get them as soon as possible to be included in 1.1.1 ... Thanks Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Matrix, Vector , Eigenvalue, Singular Value Dec. , ...
Hi, On Wednesday 06 September 2006 16:37, Adrian Egli wrote: > has somebody a opensource LGPL math (algebra) library? i am working on a > real math problem, i has > a matlab implementation (prototype runing) but i like to integrat it now. What do you need? What kind of algorithms do you need, which dimesions? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Matrix, Vector , Eigenvalue, Singular Value Dec. , ...
On Thursday 07 September 2006 11:57, Adrian Egli wrote: > i am working on a really big system, but mathematically nothing hard to > implement, > SVD, eig > 3D points (~250'000) for PCA => size(X) =[3 ,25 ] (~) > eig(XX') > > etc > > SVD(same size) Ok, for svd and eigenvalue problems I would still use LAPACK. That is a collection of fortran codes that still provide state of the art algorithms for linear algebra. BTW that is what MATHWORKS uses internally since a few releases. octave also uses LAPACK as a computation backend. Octave also offers a c++ library that might be useful for you. That one is GPL I believe. If that kind of license is not acceptable for your use, you might take a look at the implementation how they embed the fortran codes into c++. The gnu gsl provides eigenvalue algorithms only for symmetric matrices. But your X*X' is obviously symmetric. So this one might be sufficient too. Hope this helps. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] where's IRIX ?
Hi, On Thursday 19 October 2006 21:47, Don Burns wrote: > Something Freudian, something possibly evil, something I can file away as > sins of omission: I forgot to add IRIX, to the list of OS's to vote for on > the front page poll. After several of you listed IRIX in your "Other" > choices, I decided to fix the database and the poll. Yes, SGI may have > dumped IRIX, but obviously, not all of you have yet, so we'll recognize it > now for the time being. > > Actually, the piece that I was interested in seeing, was the fact that > there were more votes for Solaris than IRIX (12 to 8, in fact). very > interesting... and a bit sad. Well I was the second one with IRIX in the 'other' field. But we also expect IRIX to be dead. There are customers out there with IRIX machines. But as far as I can tell they do not buy new ones. But as long as those machines are still runnung we will ship our software also for IRIX ... ... so IRIX is history. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
On Monday 06 November 2006 10:46, Norman Vine wrote: > FYI > > http:/www.flightgear.org > > Norman Hehe :) True. Still working on getting everything up working again. There are still some problems/bugs in current flightgear cvs' version. I expect that this will settle down within the next weeks ... BTW: we need a fix to the RGB Loader that was posted to osg-submissions some weeks ago. ... patch ping :) ... an updated ac3d loader will follow. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi Robert, On Monday 06 November 2006 11:27, Robert Osfield wrote: > I just just checked through my osg-merged and osg-submissions folders > and can't find any subject line relating to the RGB plugin. Could you > point me at the patch? http://openscenegraph.net/pipermail/osg-submissions/2006-October/002334.html Thanks and Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi, On Monday 06 November 2006 12:29, Robert Osfield wrote: > I have just revied the fix and it looks like a work around for non > complient data rather than an actual bug fix. Why was this needed? > What was the source of the problem RGB files? That rgb files are in flightgear's data cvs. I do at the moment not remember which ones failed but I can double check that today evening. I do not know how the RGB file format that good to tell if those files are corrupt or not. But the observation is - That loading such an rgb file just crashes the applications due to the rgb loader writing beyond the bounds of an array. That changes makes sure that the loader stays in those bounds of the new'ed array - even if there is garbage in that file. - Those (possibly corrupt?) files are displayed well using other RGB loaders in ImageMagick, gimp and ac3d - these are the ones I have tried. With this change the resulting osg::Image looks like what is displayed with other tools. > It looks to me like the widths are specified inconsistently, is this so? Well, I must admit that I can't tell that. I have debuged that those array bounds are violated and have in a first step tried to make sure that the loader does no longer violate them. Luckily this solved all my problems ... ... with the RGB loader :-) Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi Robert, On Monday 06 November 2006 14:35, Robert Osfield wrote: > > I do at the moment not remember which ones failed but I can double check > > that today evening. > > Could you post the problem files. Ok, found one of them. The file is attached. > I'd suspect if there is bug in the RGB loader it'll be earlier in the > code where the sizes of the data are set up rather in the reading of > each line where you've implemented the workaround. It appears to me that the length of the run length encoding is wrong. That change limits that to the min of the value from the file and the remaining line length. May be this is suficient? > It'd also be interesting to load and save the problem RGB's via > ImageMagic/gimp and then see if the OSG copes fine with the newly > saved version. That works. If I do a convert sun.rgba SGI:othersun.rgba the loader does not bail out. Note that the resulting file is longer than the original one. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 sun.rgba Description: RGB image ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi Robert, On Monday 06 November 2006 18:10, Robert Osfield wrote: > > It appears to me that the length of the run length encoding is wrong. > > That change limits that to the min of the value from the file and the > > remaining line length. May be this is suficient? > > I have just added some debug output to you workaround and get the > following when reading the sun.rgba: > > > RawImageGetRow - > ok count - 44 > ok count - 40 > ok count - 44 > ok count - 0 > > RawImageGetRow - > ok count - 126 > ok count - 2 > Clamping count before - 3 > after - 0 > > RawImageGetRow - > ok count - 126 > ok count - 2 > Clamping count before - 3 > after - 0 > > Now the size of the image is 128x128x4(rgba) and its run length > encoded by why should there rows with extra pixels that run over the > end of the line? Not all lines are broken though, many add up to 128 > just fine. It would be interresting to see if lines beyond that line in question are shifted by some amount? I cannot see any problem with Flightgear but may be a 3 pixel shift in a huge texture is invisible for the first cut. Note that the 'after' printout is allways zero, may be we need to switch to the next line not only at a zero length but also if the line end is just reached? > I have run other .rgb files that I have with run length encoding and > they are fine, and always have a 0 at the end, which is what the OSG > reader looks for. > > It looks to me like the file is not created in a proper form and other > loaders are more easy going with it, checking for length of line. That was my impression too. > The code should possibly be changed to keep reading till the end of > the line or a zero delimiter. The check should probably be elsewhere > than you've added though, as if we are trying to catch dodgy files the > file should really stop at the last byte in the row. Ok. If you have an other fix for that. I would like to test that on our rgb files. When I tested the loaders with the Flightgear models I run a script doing a osgconv to ive on any 3d model I could find in the data directiory. Just to see that that it does not crash. If I remember well, this osgconv crashed on about 20% of the 3d models due to crashes in the rgb loader. So there are plenty of them out there. Past that change in my private tree the models are converted without crash. Not sure if they are also correct ... > > > It'd also be interesting to load and save the problem RGB's via > > > ImageMagic/gimp and then see if the OSG copes fine with the newly > > > saved version. > > > > That works. > > If I do a > > convert sun.rgba SGI:othersun.rgba > > the loader does not bail out. > > Note that the resulting file is longer than the original one. > > This is another sign that perhaps the file is 100% ok. > > The question is what to do about it. Do you know the history of this > file? Is there some export tool that is being used that is creating > doggy .rgbs? No I do not yet know the history. Currently asking the one who checked that in where it originates. From the checkin comment this is from a third person ... So finding out that may take some time. What I can say from the checkin log is that it is a relatively new checkin. So it cannot originate from an 'too old' tool. Well, I would like to have a rgb loader that does not bail out on files that are displayed well with other tools. How this is achieved does not matter ... Can you contact the one who wrote that loader? May be he knows what to do? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Robert, On Tuesday 07 November 2006 10:27, Robert Osfield wrote: > > Ok. If you have an other fix for that. I would like to test that on our > > rgb files. > > I have pondered on adding the a check later, but there is two seperate > loops later in the code, which would make it better to do the > check/modify above this - and right where you added your workaround. > > I now think the only problem with your workaround is the assumption of > 1 byte per colour channel. Ah, I see ... I did not think of that ... > > When I tested the loaders with the Flightgear models I run a script doing > > a osgconv to ive on any 3d model I could find in the data directiory. > > Just to see that that it does not crash. If I remember well, this osgconv > > crashed on about 20% of the 3d models due to crashes in the rgb loader. > > So there are plenty of them out there. > > Past that change in my private tree the models are converted without > > crash. Not sure if they are also correct ... > > I'm not against adding an extra check, similiar to your workaround, > but looking at the data in the file it looks very much like that the > files themselves are suspect. As told earlier, I don't know what is *right*. But others can read them. I also doubt that there is an official iso standard for RGB files, true? So, I can change the files in flightgear's cvs and convert them all. But OTOH I believe that it is an additional value for osg to be able to read files that are read correctly by others. That is the reason I posted that patch to osg-submissions ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi, On Tuesday 07 November 2006 13:06, Robert Osfield wrote: > I have just checked in your workaround with a tweak to support > multi-byte colour channels. I don't have any such files to test > against so I can only hope that its correct. I works fine for your > sun.rgba and fine for all the OSG's own .rgb's. A cvs update will get > this fix. > > Could you review the workaround to make sure that I haven't introduced > a problem unwittingly. ... I have compiled that during lunch break today on that computer here at work. For the first cut it appears to be good. Many Thanks! > Good luck with the rest of the port. Well I will keep you informed. There is much left to do. But I am on the way ... The next thing that needs to be done is an updated ac3d Loader. I will come back when it is ready for your comments : ). In summary we have many people reporting performance problems with osg compared to plib especially under win32. From my point of view I see an average improovement on my local machines. I expect that the update traversal is a cpu hog. I am working on a more inteligent update visitor for our needs. Also we have a visitor collecting scenery triangles around the aircraft that collects them using a TriangleFunctor to do some kind of collision detection with those few triangles. That TriangleFunctor has plenty of virtual calls in the innermost loop that I currently expect to hog cpu time. ... still investigating. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi, On Tuesday 07 November 2006 14:11, Robert Osfield wrote: > I'm not the expert on ac3d, so hopefully Geof Michel the author can > review and chip in. Is he still around here? > > In summary we have many people reporting performance problems with osg > > compared to plib especially under win32. > > It'd be worth doing profiling about what is the bottleneck, it is > likely that something is set or being used efficiently. Yep. Anyway, do you have any methods to do OpenGL profiling? Can I find out what parts of the scenegraph are more expensive than others? What are your methods to do do that? > During the update traversal the OSG only traverses subgraphs that > contain nodes that need updating, this means that update traversals > typically are less than a 1ms, if its substantially greater than it > suggests that their is bottleneck that your adding somewhere along the > line. Well, there are just many nodes where some updates must be done. So it has to traverse many nodes. And due to the structure of the visitor pattern you have to do many calls that cannot be inlined. I am thinking of collecting those update callbacks in one top level callback per toplevel aircraft model. That would - depending on the distance to the eyepoint - decide if the updates are executed or not. I could avoid traversing a huge count of subgraphs and avoid doing many callbacks as such if the aircraft that is animated using that update callbacks is too far away. > > Also we have a visitor collecting scenery triangles around the aircraft > > that collects them using a TriangleFunctor to do some kind of collision > > detection with those few triangles. That TriangleFunctor has plenty of > > virtual calls in the innermost loop that I currently expect to hog cpu > > time. ... still investigating. > > There shouldn't be an virtual calls within the inner loops, it should > be inline functions all the way, this is whole reason for the > existance of the TriangleIndexFunctor and TriangleFunctor templates. Nope. Devirtualization is an optimization that is very seldom implemented in compilers. Code analysis is most often not good enough to see that even if all required knowledge about the concrete types is available. Allmost allways the compiler does not even have enought information about the types in question without looking into other cpp files besides ... A method to avoid the vtbl calls would be the so called Barton-Nackman trick. In this case you do not have any virtual table that must be optimized away. Even if the compiler decides not to inline the function in question you will get a function that exactly fits the original problem without a vtbl. If you interrested I can provide an implementation of that. That would be anyway interresting since we do also need something similar than the TrinalgeFunctor for lines - at least with the current implementation. > If your primitive sets are very fine grained then this perhaps could > cause a lot of virtual method calling,so longer tri strips or lists of > triangles will be more efficient. How are you setting up the terrain? > How many triangles for tile? Are you testing about bounding > volumes? Yep, I do. > There are lots of ways to make collision detection efficient. What to > recommend will depend alot of the type of scene graph structure you > have and what ops you want to do on them. That code part is something that must change in the longer term. There must be some hierarchical bounding volume tree that fits better than the current scenegraph structure. But that is a far term project. Currently I am working on restoring all we had with the previous implementation. From my point of view I do not have the time to rewrite such parts from ground up. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi Robert, On Monday 06 November 2006 18:10, Robert Osfield wrote: > The question is what to do about it. Do you know the history of this > file? Is there some export tool that is being used that is creating > doggy .rgbs? He told me now that he used gimp(!) for that ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi Robert, On Tuesday 07 November 2006 16:22, Robert Osfield wrote: > Traversal is generally quick, I certainly wouldn't worry about cost of > the virtuals used during a traversal, the big hit you contend with is > memory bandwidth when doing a traversal. > > How many nodes are you updating? 10? 100? 1000? 10,000? If its under > 1000 then I wouldn't expect traversal to be a big issue. More likely > is the ops you are doing in the update traversal. In a standard scene at the default location with the default aircraft about 5000-1. Depending on the models in the scene even more. Think that every object that moves wrt its parent - including for example the ball in the artificial horizont - is updated using such an update callback. I have tried to replace the update callbacks that actually do anything with the plain osg::NodeCallback implementation that does nothing but return. This way we will have the same traversal node count but no meat in the callback. The update() time is roughtly (~95%) the same. That tells me that traversing is the cost not the callbacks itself. As told before this could be done more inteligent and I think we need to do so. > If there are performance issues its typically down the way the scene > graph is being used. This is possible too. What are the top 10 most often made mistakes you see in your consulting job? :) > I not expecting any clever compiler tricks. The TriangleIndexFunctor > doesn't rely upon virtual functions its a pure template class, there > isn't anything to "devirtualize". Oops, I have looked into that. I had in my head that the operator() that is called with the triangle corners is a virtual - but it is not. > > > If your primitive sets are very fine grained then this perhaps could > > > cause a lot of virtual method calling,so longer tri strips or lists of > > > triangles will be more efficient. How are you setting up the terrain? > > > How many triangles for tile? Are you testing about bounding > > > volumes? > > > > Yep, I do. > > Ok. Can I ask the above questions again, minus the one that your > answered... :-) Ok. That depends. The scenery tiles are relatively croase. Only about 1-20 triangles in a ball of about 20 meters around the aircraft. But thise triangles are organized in long tristrips that for example cover the whole runway or just bigger parts of the scene. So boundingbox tests are very croase. You need to enter many nodes that cover such strips to see that no triangles are in. OTOH there are some objects that are very fine. These are also in the scene and are sometimes masked out with the nodemask for the intersection test but sometimes need to be considered since people want to land their heilcopter on a roof of a building ... Some of these objects also move over time. We need to consider not only at discrete time snapshots but also at continous times in between. You would else see aircraft jumpig on a rolling carrier ... All in all I think that we need to seperate the intersection stuff from the scene stuff and place that in some bounding volume treethat can have movable nodes. Smaller objects could then be tested just with a croaser test geometry. Relevant parts can probably be simplified. > The OSG has an optimization pass that can create balanced quad trees > for you, if this is what you are after. See include/osgUtil/Optimizer That is interresting. Thanks! Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi Robert, On Wednesday 08 November 2006 10:23, Robert Osfield wrote: > There are lots of issues besides thse to be mindful when composing an > efficient scene graph. There are also lots of tips and tricks you can > deploy to help out. What is appropriate will depend on where you are > starting from and your current bottlenecks. Ok. Bought that. Return to my prevous question: how can I find out the bottlenecks? ... CPU profiling with whatever CPU profiler is out of question. Or other asked different: What tools do you use for that? > When you have a working port of FlightGear I'll download it and see if > I can get it running will give me a better insight. However, I am > really busy with work, so tinkering with other code no matter how > curious has to take a back seat to my core duties. Thanks for the offer. I will return to that. :) > Things I'd suggest are putting in update, cull and draw stats is also > very useful, if you can have these on screen then it'll help. Another > trick is to output the scene graph to a .osg file and just look > through it, looking for how balanced the scene graph is, and if > certainly nodes are being overused perhaps mis-used. I used osgedit for that so far. Other suggestions? > Are there developer docs on FlightGear? Mostly the source. :-/ There are some bits on www.flightgear.org. The wiki is growing and has partly interresting bits. BTW: you told me that there is a scenegraph balancer in the Optimizer? Which optimization flag is that? Greetings and thanks Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Good morning Robert, On Wednesday 08 November 2006 18:16, Robert Osfield wrote: > At a first pass I just watch the update, cull and draw and GPU stats > that osgProducer::Viewer provides. Then once this gives me an overall > picture I then look at the traversal that is giving the most problem. > Do this I just go in a add code like: > > osg::Timer_t startTick = osg::Timer::instance()->tick(); > ... do stuff... > osg::Timer_T endTick = osg::Timer::instance()->tick(); > double timeTaken = osg::Timer::instance()->delta_ms(startTick,endTick); > > And the output the results to the console or a file. > > Crude but effective. Thanks! That is that kind of information what I would like to hear :) > > BTW: you told me that there is a scenegraph balancer in the Optimizer? > > Which optimization flag is that? > > Ahh I think this would be a good exercise for the reader, have a look > at the options bit mask at the top of the include/osgUtil/Optimizer > header. The enum lists should give you an ideal of all the > optimization traversals available. See if you can spot the one that > balances a scene graph (creates a quad tree). Ok, found it :) I sucessfully use that otimizer and had a quick look into the flags and did not remeber something like 'balance' or 'quad tree' or whatever. As german - I expect you have already identified that - I had not connected spatialize with a quadtree ... Aehm, I came across something in osg::Material. The osg::Material::apply routine is the only place where glEnable is called outside the codepath used for the osg::StateSet::setMode(). I wonder if this is a source for inconsistencies in the osg::State in the sense that osg::State believes GL_COLOR_MATERIAL is not enabled but the osg::Material::apply just did enable that? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi Robert, On Thursday 09 November 2006 11:09, Robert Osfield wrote: > On 11/9/06, Mathias Froehlich <[EMAIL PROTECTED]> wrote: > > Good morning Robert, > > Good morning, yep we are both in Europe, so morning it is for both of us :) :) > osg::Material is a bit of an oddity in that its the only place, as > you've spotted, where it does its own mode setting. > > Ideally osg::Material should be split out into two classes, and the > mode setting removed from it. osg::Material is a very old class now, > predating most of the other osg::StateAttributes, its served us well > though - the mode oddity you've spotted is not something that users > ordinarily hit upon. Actually I think you are the first person to > spot this and mention it publically :-) Well, ok. I believe that we need to improove out local communications here. Daniel came in and told me that he also had asked that some time ago ... To be clear, I work on FlightGear in my spare time. But Daniel 4 other guys and I work with osg in our day job too. > The way to use osg::Material is just as a black box and leave it to > control GL_COLOR_MATERIAL, rather than doing the setMode's yourself. Thanks. May be we need to change that consistently in the plugins? ... just because I have the impression that I have problems with that ... ... not sure ... ... we also have plain opengl code that might disturb the state too ... :-/ Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Oct 30 - FlightGear cuts over to OpenSceneGraph in CVS HEAD.
Hi Robert, On Thursday 09 November 2006 14:26, Robert Osfield wrote: > > To be clear, I work on FlightGear in my spare time. But Daniel 4 other > > guys and I work with osg in our day job too. > > Now the question is... is this is a good thing or a bad thing :-) Good and bad - like everything in life :) > > > The way to use osg::Material is just as a black box and leave it to > > > control GL_COLOR_MATERIAL, rather than doing the setMode's yourself. > > > > Thanks. > > May be we need to change that consistently in the plugins? Ok. I have seen that you removed the mode usage of the material state attribute. Since GL_COLOR_MATERIAL appears nowhere else in the sources this must be consistent within osg now. Thanks! > If there are problems then just point them out/suggest fixes. The OSG > isn't this complete static entity, if there are problems we just get > out the tools and fix them. Thanks. I will do so. BTW: just to make sure that my current post to osg-submissions does not fall thour your mailbox like the prevous one: I have posted that ac3d updated readerwriter a few hours ago. > Intergrating OpenGL with the OSG isn't difficult, but the state does > require a little of handling to make sure that it doesn't bleed into > adjacent OpenGL or OSG drawing code. When you are ready to do this > just ping the list on this topic. I have already done so. ... mostly. But as you told it requires some changes and I need to make sure that I have found every state change in the opengl code. Currently there is just a glPushAttrib(ALL) around that code. Since this is only one such call per rendered frame, I think we can live with that for a while ... In the far term I think we want to make scenegraph object of that stuff anyway. I would like to make use of producers multithreading capabilities in the long term. So I expect that I need to put everything that is displayed on the opengl window in some drawable in the scenegraph. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Wiki page on binary file versioning
Hi Fred, On Friday 17 November 2006 00:22, Frederic Bouvier wrote: > The other thing I don't get yet, is how osgDB behaves when it wants to load > a plugin. Either the plugins are searched like usual. But that leaves the discussed binary compatibility problems. To avoid this you have to statically link in the plugins too. The dirty hack is to reference the plugin proxy installer symbol in the application. Then it get's linked in and works as usual. May be there is a better way for that dirty part, but that is what comes in mind to me. The downside is: you need to know which plugins will be ever needed... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Compile Error: osgManipulator with SunStudio
Hi, On Tuesday 05 June 2007 11:19, Norman Vine wrote: > Looks like you had way to much fun :-) > > http://sadr.dfn.de/~wirtz/_bilder_linuxtag_2007/Linuxtag/subalbum_1.html Now got an other link to pics - still not mine: http://www.oflebbe.de/FgShow2/ Have fun ... Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] How change colors of a geometry in a callback
Hi, On Tuesday 26 June 2007 12:01, Benjamin Cabut wrote: > Hello, > > I use the chessboard of the sample "osganimate". > And I would like to add a Callback that get some value in a LUA script > to change the color of the Chessboard. > > I get the geometry from the Drawable, then the colorArray. > I change the color ( (*colors)[0].set()) > But the color of the ChessBoard is not affected... > > I tried in a UpdateCallBack and in a DrawableUpdateCallback, with same > effect, and I noticed that I only go once in the DrawableUpdateCallBack > > Seems the color is memorized and I can't say the system it changed... > > Could you explain me why? and how should I do? Dirty the display list on update or switch it of completely. You get there only once when the display list is generated. What to do depends on how often the updates really happen. If you really have to update that color on every frame it is better to disable display lists. If you nedd to update only every now and then, it might be worth to generate the display list and use it for some frames. The functions osg::Drawable::dirtyDisplayList() and osg::Drawable::setUseDisplayList(bool) are your friend. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] /usr/lib64 in build?
On Tuesday 10 July 2007 15:33, Andy Skinner wrote: > We've got a similar situation on linux that we did on solaris-we're > building our product with a different compiler than the one installed as > the default for the computers. That's fine (but odd) for normal work, > where we build in a certain environment that sets up everything we need. > But 3rd party and test programs can be a pain to compile with the same > setup. > > > > I'm still working on getting our makefile to give CMake all it needs to > build everything correctly. My latest problem is on Linux with 64 bits. > Something is putting "-L /usr/lib64" into the makefiles. I don't see it > in CMakeCache.txt. Where does it come from? > > > > Is there a way to override it? We need to get libraries from elsewhere. That one seems to be hardcoded in cmake. I am currently doing the same on hp-ux for 64 bit builds. see that thread http://www.cmake.org/pipermail/cmake/2007-July/014983.html for help and a pending feature request. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] /usr/lib64 in build?
Hi, On Tuesday 10 July 2007 15:58, Andy Skinner wrote: > Thanks. Did setting CMAKE_LIBRARY_PATH help you? On hp-ux it helped me to find the pa20_64 libs. The downside is that I need to tell cmake all paths where it finds the libraries ... That variable appears to extend the FIND_LIBRARY cmake command. > It does not help me, > because although I set that, it still adds -L/usr/lib64 to the link > command, and seems to find that one and not the one I'm trying to get. (I > want libstdc++.so.6, but am getting libstdc++.so.5.) So you have a custom built new gcc on an old linux system? May be you need to find something to extend your linker flags with CMAKE. I don't know that by heart how this is called. May be something like LDFLAGS or LINK_FLAGS will help here ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] /usr/lib64 in build?
On Tuesday 10 July 2007 16:33, Robert Osfield wrote: > On 7/10/07, Andy Skinner <[EMAIL PROTECTED]> wrote: > > I am setting linker and compiler flags. I don't know anything about > > cmake commands, so I guess I'm going to have to learn more about cmake > > itself. > > You should be able to change the lib postfix by running ccmake . and > then pressing 't' to toggle on advanced options, the scroll down the > LIB_POSTFIX, this will probably say "64" on your 64 bit machine so > just set to to "" instead, then press 'c' to configure. then 'g' to > write out. > > Or on the command line doing something like: > > cmake . -DCMAKE_BUILD_TYPE=Release -DLIB_POSTFIX="" Well that changes the osg build system where osg wants to place the libraries. So far so good. But that one does not change the paths where FIND_LIBRARY looks for the existance of libraries and where the linker paths will point to... I am fileing that feature request from the given mail thread today ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osg::ClipNode
Hi Robert, On Wednesday 11 July 2007 18:30, Robert Osfield wrote: > We don't just support decoration of subgraphs to support clip planes > as its really useful to decouple the positioning of the clip planes > from the use of them. See the osgclip example for why this is useful. Yep, but it is also usefull to reuse the clip planes. You remember the problem with flightgears instrumens we discussed in Tübingen. > Given this functionality you then have to limit how far the scope of a > single clip plane goes, the OSG by default limits it to the current > render stage. You can do this programmatically by creating a > RenderStage in the cull traversal. Ok, so the cull callback should do so? Do you have an example for that? I remember you telling me adding a post render camera to get a new render stage, but having a clipped part of the normal scene drwawn in the post render stage has other drawbacks ... So it would defeinitely be useful to be able to reuse positional state attributes for different subtrees. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] trouble in having a PRECISE intersection point in ..
On Tuesday 06 June 2006 18:22, David Lascombe wrote: > Thanks but I am not sure to understand how and when to start the > traversal.. Actually the database is already earth centered, I am not > changing its coordinate system but I compute new coordinates for each > entity so that they are earth centered too. > > ... Well, the idea is that you have surface tiles below a transform node, where the transform node is just a translation from the earth centered coordinate frame to a tile centered coordinate frame. That transformation should be done with doubles. In this case you need to transform your intersection start point to that tile centered coordinate frame (still in double values). If you have reasonable tile sizes, you should be near enough to continue with floats. At this point you can take the intersect visitor and use its hit values. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Compilation on HP-UX
Hi, I have compilation problems with osg-1.0/1.1 on HP-UX, but I am not yet sure if this is an osg or HP-UX problem. One of the problems is the way OpenGL extension are handled. For example include/osg/BufferObject contains (more or less) the code #ifndef GL_ARB_vertex_buffer_object typedef long GLsizeiptrARB; typedef long GLintptrARB; #endif Now on HP-UX gl.h defines those two typedefs but it does not define GL_ARB_vertex_buffer_object. Obviously this leads to a duplicate typedef that falis to compile. Well, I know that I can expect that all of the ARB_vertex_buffer_object extension is available in the client library if the macro GL_ARB_vertex_buffer_object is defined. But it is not clear to me if I can invert that logic and expect that nothing of that extension is defined if that macro is not defined. Is this a problem with osg, that there is _NO_ 'if and only if' connection between the macro and the typedefs or should I bug HP because of nonstandard gl headers? Opinions, or better OpenGL Standard paragaphs to cite? :) Or is there any other way to to solve that problem in a generic way? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
