[osg-users] Application crash on XP

Hello, I have one OSG based application that uses osgAudio with OpenAL-soft. It works fine in Windows 7, but it crashes on exiting in XP. I have read this issue: http://code.google.com/p/osgaudio/issues/detail?id=9 and I can see that

Re: [osg-users] Application crash

Hi Werner, additionally to the solutions to your rendering purpose, you can pimp up 32bit windows to support 3GB Adressspace per process ( in reality it is alittle bit less) via the /3GB switch in the boot.ini: http://msdn.microsoft.com/en-us/library/bb613473%28VS.85%29.aspx Cheers, Torben --

Re: [osg-users] Application crash

Hi Tim and Robert, I just want to give you a feedback. I AM VERY, VERY LUCKY You took me on the right path. Thanks for your great support. - Werner - Am Mittwoch, 24. November 2010, 17:13:09 schrieb Robert Osfield: > Hi Werner, > > On Wed, Nov 24, 2010 at 3:02 PM, Werner Modenbach > > w

Re: [osg-users] Application crash

Hi Werner, On Wed, Nov 24, 2010 at 3:02 PM, Werner Modenbach wrote: > I was told using indexes is leaving fast path rendering. Isn't that the case? > I would be very, very lucky!!! Use vertex/colour/normal/etc index arrays in osg::Geometry will force the OSG to dispatch data to OpenGL using Open

Re: [osg-users] Application crash

On Wed, Nov 24, 2010 at 4:02 PM, Werner Modenbach < werner.modenb...@texion.eu> wrote: > Am Mittwoch, 24. November 2010, 15:31:48 schrieb Tim Moore: > > On Wed, Nov 24, 2010 at 2:52 PM, Werner Modenbach < > > > > > > > You can calculate the binormal from the normal and tangent vector in a > > shad

Re: [osg-users] Application crash

Am Mittwoch, 24. November 2010, 15:31:48 schrieb Tim Moore: > On Wed, Nov 24, 2010 at 2:52 PM, Werner Modenbach < > > > You can calculate the binormal from the normal and tangent vector in a > shader, for some savings. OK, I'll think about it. > > > Each yarn ist defined by a polygon along its

Re: [osg-users] Application crash

On Wed, Nov 24, 2010 at 2:52 PM, Werner Modenbach < werner.modenb...@texion.eu> wrote: > Hi Robert, > > my application is in the context of technical research. So it is not just > for creating a "good look". > > Imagine you need to calculate the flow of a filter textile. In this case > you have t

Re: [osg-users] Application crash

Hi Robert, my application is in the context of technical research. So it is not just for creating a "good look". Imagine you need to calculate the flow of a filter textile. In this case you have to know exact thread geometries. My geometry has the following vectors: osg::ref_ptr osgVertices;

Re: [osg-users] Application crash

Hi Werner, On Wed, Nov 24, 2010 at 10:53 AM, Werner Modenbach wrote: > Yes, I absolutely agree and this is actually similar to my first approach. > Unfortunately I ran out of address space on 32 bit Windows machines. The > available address space is about 1.4 GB and Windows garbage collection is

Re: [osg-users] Application crash

Yes, I absolutely agree and this is actually similar to my first approach. Unfortunately I ran out of address space on 32 bit Windows machines. The available address space is about 1.4 GB and Windows garbage collection is horrible! That's why I replace the geode in use by the new one immediately

Re: [osg-users] Application crash

On Wed, Nov 24, 2010 at 11:25 AM, Werner Modenbach < werner.modenb...@texion.eu> wrote: > Hi Tim, > > The new data arrives asynchronously out of threads. So I have no chance to > relate the updates in any way to the timing of frame() calls. > I didn't understand that you were updating the vertex

Re: [osg-users] Application crash

Hi Werner, If you have a multi-threaded rendering and physics calculations then I'd recommend use of double buffering of the data, and then having the physics thread write to the buffer, and the rendering thread read from this. You could implement the buffer simply as two sets of osg::Array's and

Re: [osg-users] Application crash

Hi Tim, The new data arrives asynchronously out of threads. So I have no chance to relate the updates in any way to the timing of frame() calls. Unfortunately I cannot believe it doesn't matter to osg replacing arrays out of threads eventually while frame() is active. BTW using VBOs results in t

Re: [osg-users] Application crash

You don't need to generate new vertex arrays each frame, and you don't need the mutex either, at least not for OSG. Disable display lists, enable VBOs, set the data variance of the vertex arrays to Object::DYNAMIC. During each frame update the existing arrays and call their dirty() method. Tim On

[osg-users] Application crash

Dear all, I'm using osg in an application running on Linux and Windows using Qt and adapter widget. I'm showing the relaxation process in a textile fabric and the number of vertices can reach huge numbers. The scene (Geodes representing one yarn thread each) has to be updated after each relaxat