I'd like to disable the usage of the FBO extension at runtime. I tried
setting the OSG_GL_EXTENSION_DISABLE env var, but it didn't work.
Looking into FrameBufferObject.cpp, it seems that it is directly
loading the required functions via setGLExtensionFuncPtr and only
consults the isGLExtensionSuppo
Hi Robert!
Another user reported this, but my nightly build also exhibits the same problem.
Details here: http://www.cdash.org/CDashPublic/viewBuildError.php?buildid=14829
As we don't really need wrappers, this is just for your information in
case you missed it.
--
Csaba
On Fri, Mar 13, 2009 at 11:16 AM, Robert Osfield
wrote:
> Hi Csaba,
>
> Thanks for the fix. This helps me understand the nature and location
> of the problem. Reviewing the changes and the original code I'm
> thinking it might be simpler to just refactor the code block so the
> division by wind_a
On Thu, Mar 12, 2009 at 6:03 PM, Robert Osfield
wrote:
> HI Csaba,
>
> I don't have any strong opinions on these issues, as I'm not very
> familiar with the code, and haven't seen problems first hand with the
> code segments your pointing out so don't have any extra insight to
> provide. I don't
On Thu, Mar 12, 2009 at 5:04 PM, Tomlinson, Gordon
wrote:
> Read this page
> http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol
Looks the same as last time :D
I haven't made a submission, because I was hoping for some discussion
and a more sophisticated fix than jus
On Thu, Mar 5, 2009 at 4:16 AM, Csaba Halász wrote:
> Hi!
>
> If wind_accel has zero length, then line 43
>
> double critical_dt2 = relative_wind.length2()/wind_accel.length2();
>
> will attempt a divide by zero. A simple fix would be to check for zero
> but th
On Mon, Mar 9, 2009 at 7:23 PM, Paul Shabash wrote:
> Hello,
>
> When I try to create text, I get the following error message:
>
> Warning: Could not find plugin to read objects from file
> "C:\Windows\Fonts\arial.ttf".
>
> Does anyone know which plugin that's referring to and why?
I believe you
Hi!
More division by zero trouble, this time in
include/osgDB/DatabasePager line 331:
double getAverageTimeToMergeTiles() const { return
_totalTimeToMergeTiles/static_cast(_numTilesMerges); }
Obviously divides by zero if _numTilesMerges is zero.
--
Csaba
Hi!
If wind_accel has zero length, then line 43
double critical_dt2 = relative_wind.length2()/wind_accel.length2();
will attempt a divide by zero. A simple fix would be to check for zero
but that would still leave the possibility of an overflow if the
divisor is small. So a more clever check wo
On Mon, Mar 2, 2009 at 6:33 PM, Kim C Bale wrote:
>
> Occasionally this will run, but the majority of the time it bombs.
> If one of you kind ladies or gentlemen could run it and tell me if you get
> the same error/crash I would most grateful. I'm afraid I don't have access to
> a different mach
On Tue, Feb 10, 2009 at 2:19 AM, Pecoraro, Alexander N
wrote:
>
> On the Enterprise Redhat Linux computer I have 4 64 bit dual core Xeon
> 3Ghz processors.
>
> On my Windows XP computer I have an Intel 64 bit Core2 DUO 2Ghz CPU.
>
> BTW, I found in the GCC documentation that if the gcc linker repo
On Fri, Feb 6, 2009 at 12:08 PM, Luigi Calori wrote:
>
> I do not know if is my way of build or if is the static build, but I get
> link error in tiff plugin if I do not link also with jpeg and zip lib.
Yes, that is normal with static tiff (even on linux). I have reported
it here and on the cmake
On Fri, Feb 6, 2009 at 2:49 PM, Jean-Sébastien Guay
wrote:
>
> From what I've seen in the past few days (since I started submitting builds
> myself) they're removed from the list every night automatically. As you can
> see Sukender's Experimental builds from yesterday are not there anymore and
> I
On Fri, Feb 6, 2009 at 1:18 PM, Robert Osfield wrote:
>
> Could you please try out the svn/trunk or OSG-2.8 branch to double
> check that the lwo plugin is now behaving itself.
Hi Robert,
Apparently both versions now load the model, thank you.
There is only the original issue with multitexturing
On Thu, Feb 5, 2009 at 10:16 PM, Csaba Halász wrote:
>
> Rev 9397 is the first non-working revision. Looks like a lot of
> int-long changes, which seems to agree with your 64 bit theory. Except
> it is broken on 32 bit too.
LOL, it is one for Sukender's list :)
for(
On Thu, Feb 5, 2009 at 5:57 PM, Csaba Halász wrote:
>
> Now I have to leave for a couple of hours, but I'll make a valgrind
> run and continue the bisecting later.
Rev 9397 is the first non-working revision. Looks like a lot of
int-long changes, which seems to agree with your
On Thu, Feb 5, 2009 at 6:11 PM, Robert Osfield wrote:
>
> BTW, what OS/g++ version are you working on?
debian, with a somewhat old g++ (GCC) 4.1.2 20061115 (prerelease)
(Debian 4.1.1-21)
The mingw build is on 32bit windows xp, g++.exe (GCC TDM-2 for MinGW) 4.3.0
--
Csaba
__
On Thu, Feb 5, 2009 at 5:44 PM, Csaba Halász wrote:
> Update on the build: 2.7.8 is broken, now building 2.7.7
2.7.7 is fine. So the trouble is somewhere between 2.7.7 and 2.7.8 .
Judging from the symptoms, It could be an unitialized variable.
Now I have to leave for a couple of hours, but I
On Thu, Feb 5, 2009 at 5:24 PM, Robert Osfield wrote:
>
> Are you working on a 32 or 64bit system?
I am on linux 64bit. Now I have verified with last night's 32 bit
mingw build too, it gives a somewhat different, but equally bad,
result (note, I didn't have the textures).
Update on the build: 2.7
On Thu, Feb 5, 2009 at 4:49 PM, Robert Osfield wrote:
>
> I've just grabbed the source for lwo from 2.7.1 and applied it to
> OSG-2.8 and I get a different result from doing a conv to .osg but I
> still don't get a valid model - the tex coords are now all inf, rather
> nan.
>
> If 2.7.4 works for
On Thu, Feb 5, 2009 at 4:34 PM, Robert Osfield wrote:
> HI Csaba,
>
> I've just looked at the files, and the .osg file has 0 0 0's for all
> the vertices, looking at your code segment from the crash it kinda
> looks like the tex coords are derived from the vertex positions, so
> all 0 0 0's for ve
Hi everybody.
I have gotten a report that the LWO loader doesn't seem to work.
Investigating, I grabbed the sample LWO file posted by Marco Jez back
in november last year (attached for convenience).
Loading into osgviewer, I get an empty view. Trying osgconv, I get an
osg file full of zeroes and n
On Mon, Dec 29, 2008 at 9:55 AM, Andreas Goebel wrote:
> Zhu liangxiong schrieb:
>>
>> hi
>> my project need osg, and we use eclipse+QT+mingw.
>> so i am not sure, whether i can compile the osg by mingw.
>> and you guys know, please tell me ,and also how to.
>> appreciate for any comment .
>
> You
On Thu, Nov 20, 2008 at 4:50 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 20, 2008 at 3:51 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>
>> I wonder if I can try to use software rendering to see if it makes a
>> difference.
>
> I have run it w
On Thu, Nov 20, 2008 at 8:12 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
>
> When it hung, I had just created a 4th view (=4th context).
> Uncoincidentally, there are 4 threads on GraphicsThread::run(), which calls
> GraphicsContext::makeCurrent(), which calls
> GraphicsWindowWin32::makeCurr
On Thu, Nov 20, 2008 at 3:51 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
> I wonder if I can try to use software rendering to see if it makes a
> difference.
I have run it with mesa in a nested x server, no hangs. After each
added view, however, I got a single "Warning: d
On Thu, Nov 20, 2008 at 2:34 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
>
> "sparky"
> Linux 2.4.21-102-smp x86_64 GNU/Linux
My crash seems to be of this type, although no problem with threading
model switching.
I wonder if I can try to use software rendering to see if it makes a differe
Hi people,
my call stacks show that all the waiting is going on because one of
the threads is stuck in makeCurrent:
#0 0x7f34b8b7a727 in sched_yield () from /lib/libc.so.6
#1 0x7f34b8385665 in ?? () from /usr/lib/libGLcore.so.1
#2 0x7f34b80a0d8a in ?? () from /usr/lib/libGLcore.so.
On Wed, Nov 19, 2008 at 10:42 PM, Don Leich <[EMAIL PROTECTED]> wrote:
>
> pthread_cond_wait, FP=7fbfffd5a0
> pthread_cond_wait, FP=7fbfffd5b0
> OpenThreads::Condition::wait, FP=7fbfffd610
> OpenThreads::BlockCount::block, FP=7fbfffd660
> osgViewer::ViewerBase::renderingTra
On Tue, Nov 11, 2008 at 7:01 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote:
>
> I probably won't be the only one to say it but...
>
> This is wicked awesome. :)
It is *wicked* all right ...
Notebook, Intel c2d 2.2Ghz, 3GB ram + 4GB swap, nVidia 8600M-GT 256MB,
driver 177.80
1) 103
2) 207
3) 154 sec
On Fri, Nov 7, 2008 at 10:55 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
>
> You can uploaded data to the server via WebDAV:
I wonder if there is public interest in having the automated nightly
builds available.
--
Csaba (aka. Jester on the dashboard)
__
On Thu, Nov 6, 2008 at 5:16 PM, Engvall Åsa <[EMAIL PROTECTED]> wrote:
>
> I want to render the scene to a texture and use the texture in a shader. The
> texture image is saved to file by a postdraw callback, so I can look at it.
> I'm doing something wrong because the texture becomes all gray.
I
On Thu, Nov 6, 2008 at 10:04 AM, Johannes Nilsson
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have had some problems with OSG freezing when running in
> ThreadPerCamera mode. My problems
> were resolved with two changes:
>
> The first one changes the order of the startRenderingBarrier and the
> reset of
On Mon, Nov 3, 2008 at 6:12 PM, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
> If this all fails then it looks like there is a bug in ReentrantMutex.
Hmm, looking at it, I wonder why the thread checking is disabled in
the unlock path? Is it for performance reasons? (couldn't find the
relevant svn c
On Mon, Nov 3, 2008 at 5:08 PM, Max Pfingsthorn
<[EMAIL PROTECTED]> wrote:
>
> I'm using the current trunk of OSG (updated 30 mins ago) on Ubuntu
> 8.04. The program hangs on the line with osgDB::readNodeFiles. I have
> no idea why.
>
> This is what GDB says:
> #6 0xb7ea30c1 in OpenThreads::Reentr
On Thu, Oct 30, 2008 at 9:38 AM, Alberto Luaces <[EMAIL PROTECTED]> wrote:
> Hi Csaba,
>
> Out of curiosity, are you "jester"?
Hi Alberto,
Yes that's me :)
> If that were your machine, how did you manage to install Dart with Mingw? I am
> be interested in doing the same with a Cygwin build.
I bu
Have run into another trouble, I had to add OSGSHADOW_EXPORT to each
of the embedded protected ViewData struct's in the osgShadow lib,
otherwise I get linking errors with the osgshadow example.
If it doesn't break other platforms, can they be added in svn?
--
Csaba
___
On Wed, Oct 29, 2008 at 11:15 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
> Yeah, that's what I figured too. So I guess I have to get the gcc
> builtins to work if possible.
Ok, you can strike this from the list.
I used -DCMAKE_CXX_FLAGS_RELEASE="-O2 -march=i686"
On Wed, Oct 29, 2008 at 9:05 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
> Hi Csaba,
>
>> 2) None of the OPENTHREADS_ATOMIC_USE flags work. I assume either gcc
>> or win32 interlocked would be the right choice. As I am using gcc, I
>> went for the GCC builtins first, but I get errors:
>
> Ma
Hi!
I encountered some problems while building OSG using mingw.
1) can't build osgwrappers. on 32 bit windows, ld goes up to about 2GB
mem usage and then aborts. Cross-compiling on 64 bit linux, it went up
to a whopping 5GB after 10 minutes, at which point I had to kill it as
I only have 3GB ram
On Mon, Oct 27, 2008 at 10:42 PM, John Cummings <[EMAIL PROTECTED]> wrote:
> FYI, here is the link to the discussion on the Ac3D forum:
>
> http://www.inivis.com/forum/showthread.php?t=5090
>
> It seems to be headed in the same direction as Robert's comments regarding
> keeping track of the UV rang
On Thu, Oct 23, 2008 at 12:25 PM, Torsten Dreyer <[EMAIL PROTECTED]> wrote:
>
> Sorry for the long posting
Apology accepted :)
Nice report, thanks for sharing.
Have you figured out what was wrong with the autopilot?
--
Csaba/Jester
___
osg-users maili
On Mon, Oct 20, 2008 at 8:50 AM, Mathias Fröhlich
<[EMAIL PROTECTED]> wrote:
>
> With the lack of an ac3d modeller here, can you tell me how it looks like in
> ac3d, when texrep is
> * omitted
> * set to 0 0
> Is there a way to get non repeating textures in ac3d?
I don't personally have ac3d eithe
On Mon, Oct 20, 2008 at 10:12 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> HI Csaba,
>
> Are you working on the SVN version of the OSG? As the new
> StatsHandler additions aren't thread safe yet - I've also seen crashes
> when bringing up the scene graph statistics, although not any OpenGL
> er
Hello,
In the osgcamera example I disable draw serialization like this:
Index: osgcamera.cpp
===
--- osgcamera.cpp (revision 9034)
+++ osgcamera.cpp (working copy)
@@ -204,6 +204,7 @@
while (arguments.read("-g")) {
v
On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> HI Csaba,
>
> I suspect the particular problem you are seeing is not directly driver
> related, but is an OSG bug, differences in drivers might change the
> timing slightly which leads to the problem not becoming visible,
Hi!
The texrep parsing change that went into the plugin about 2 weeks ago
is against the ac3d spec, that says:
*texrep %f %f
Optional - default 1.0,1.0 . The texture repeat values for the tiling
of a texture
on an object's surfaces."
(http://www.inivis.com/ac3d/man/ac3dfileformat.html)
I beli
On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
>
> CullThreadPerCameraDrawThreadPerContext is the most complex of all the
> osgViewer threading models, and with it the widest range of different
> thread/barrier combinations. It could be that you are using a
> combinatio
On Thu, Oct 16, 2008 at 10:43 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi Csaba,
>
> Given the provided details I don't have enough to provide an clues to
> what might be up.
>
> Try different threading models to see what results you get.
>
> Also try the standard OSG examples to see if any
On Thu, Oct 16, 2008 at 10:07 AM, Michal Turlik <[EMAIL PROTECTED]> wrote:
> Hi,
> I am trying to compile osg with mingw.
> After have compiled the cmake I obtein a message stating the M$ VS 6 is
> required.
Yes, I have it working. Not sure what message you get and where.
--
Csaba
__
On Thu, Oct 16, 2008 at 2:40 AM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
> Maybe I am missing something else that causes cmake to use the tcl
> submit (and that doesn't seem to support http)
/o\ so I don't even need the dart thing, ctest can do everything?
Where do I
On Thu, Oct 16, 2008 at 1:23 AM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
> I also tried a mingw build, that seems to work too but the submission doesn't:
Comparing with the linux makefile, I spotted this difference:
CMakeFiles/NightlySubmit:
/C/msys/home/hcs/tcl-ins
Hi,
I have set up a nightly 64 bit linux build (I guess you'll get more of
those) that seems to work fine.
Do we have fancy stuff like coverage, valgrind or tests? Also, I
wonder if you want a build from scratch? That took like 3 hrs :)
I also tried a mingw build, that seems to work too but the s
Hi again,
Now that I got threading running, I have run into this trouble:
draw() 0xee0b20
draw() got SceneView 0xf18a80
end draw() 0xee0b20
draw() 0xda1f80
cull()
cull() got SceneView 0xf03e90
end cull() 0xee0b20
cull()
cull() got SceneView 0xf7b020
_clampProjectionMatrix not applied, invalid dep
On Wed, Oct 15, 2008 at 8:44 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 8:28 PM, Robert Osfield
> <[EMAIL PROTECTED]> wrote:
>
>> This sounds like a bug in osgViewer, it shouldn't matter which order
>> your set the threading m
On Wed, Oct 15, 2008 at 8:28 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 6:45 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>> On Wed, Oct 15, 2008 at 7:23 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>>
>>> The threading is se
On Wed, Oct 15, 2008 at 7:23 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
> The threading is set like so:
> viewer = new osgViewer::Viewer;
> viewer->setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext);
And that's exactly the problem ...
On Wed, Oct 15, 2008 at 7:07 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 6:01 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>
>> Here is what stats I get: http://imagebin.ca/view/lDtnJ9ET.html
>> I have tried your debugging mods, wit
On Wed, Oct 15, 2008 at 6:47 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
>
> On Wed, Oct 15, 2008 at 5:30 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
>> As a related question, in the stats display if multiple cpus are used
>> properly, should that manifest itse
On Wed, Oct 15, 2008 at 6:15 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi Csaba,
>
> On Wed, Oct 15, 2008 at 5:07 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>> So all looks correct in terms of num of processors and cpu number
>>> assigned for a
On Wed, Oct 15, 2008 at 5:46 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
>
> numProcessors = 4
> cpunum=1
> cpunum=2
> cpunum=3
> cpunum=0
> running and setting thread 0x737238 for cpunum=3
> running and setting thread 0x737638 for cpunum=0
> running and setting thread 0x734bf8 for cpunum=1
> run
On Tue, Oct 7, 2008 at 11:04 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 7, 2008 at 10:58 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
>>
>> Well, going back to 169.12 does seem to make that problem go away
>
> Interesting, since I have the problem
On Tue, Oct 7, 2008 at 10:58 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
>
> Well, going back to 169.12 does seem to make that problem go away
Interesting, since I have the problem with the 169.12 driver.
Maybe I should upgrade to make it go away ;)
--
Csaba
___
On Tue, Oct 7, 2008 at 9:14 PM, Paul Melis <[EMAIL PROTECTED]> wrote:
> I seem to be getting some lock up when switching threading models in
> osgviewer (with the cow). However I also see these in 2.6.0 now that I
> test it (haven't been using 2.6 yet).
> What's more, switching of the threading
On Tue, Jun 3, 2008 at 10:20 PM, <[EMAIL PROTECTED]> wrote:
>
> Especially since after osg::Transform (the direct ancestor of
> osg::MatrixTransform) is constructed the _prvData member is a valid
> pointer, and immediately after osg::MatrixTransform's constructor executes
> the _prvData member is
On Tue, Jun 3, 2008 at 4:48 PM, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
> Could you do an svn update on the OSG and let know if things are no
> work fine at your end,
It works, thanks.
--
Csaba
___
osg-users mailing list
osg-users@lists.openscenegr
On Tue, May 27, 2008 at 12:08 PM, Tim Moore <[EMAIL PROTECTED]> wrote:
>
> Indeed. I've made the necessary changes to FlightGear, and it seems to
> be working fine.
Except for being a cpu hog.
Apparently, the pager thread is not blocked properly and continuously
spins. The fact that the queue is
67 matches
Mail list logo
