Bawenang Rukmoko | 1 Feb 2011 04:35
Picon

Re: [osgOcean] Greetings, and a few bug.

Hi,

Oops sorry, the if condition was my first attempt to check and fix the bug. It turns out that it was not working
and the bug was somewhere else. The whole method is this:

Code:

float FFTOceanSurface::getSurfaceHeightAt(float x, float y, osg::Vec3f* normal)
{
    if(_isDirty)
        build();

    // ocean surface coordinates
    float oceanX, oceanY;

    // translate x, y to oceanSurface origin coordinates
    oceanX = -_startPos.x() + x;
    oceanY =  _startPos.y() - y;

    // calculate the corresponding tile on the ocean surface
    unsigned int ix = oceanX/_tileResolution;
    unsigned int iy = oceanY/_tileResolution;

    unsigned int frame = _oldFrame;

    // Test if the tile is valid 
    if(ix < _numTiles && iy < _numTiles)
    {
		//++ BAWE-20101109: BUG FIX. 
		//NOTE: 20101112 - Not working but what the heck...
(Continue reading)

Bawenang Rukmoko | 1 Feb 2011 05:45
Picon

Re: [osgOcean] [ASK] Need help for a shader related issue

Hi,

Because I can post URLs now, I'll post the source of what I want to implement. http://http.developer.nvidia.com/GPUGems/gpugems_ch21.html

Thank you!

Cheers,
Bawenang

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=36212#36212

Alberto Luaces | 1 Feb 2011 09:12
Picon
Favicon

Re: Animate a human head

"Antonio Gal" writes:

> Hi guys,
> I am just beginning to get friendly with the osg api because i want to realize an application that animates a
loaded model of a human head. the head will copy the motion of a real person.
>
> well, my question is: can osg really help me ? i understand how to realize rotation, translation and scale,
but i'm not sure about how to simulate the mouth's motion for example. is that possible? where can i find
something that illuminate my mind? xD

You are looking for the osganimationmorph.cpp example.

Regards,

--

-- 
Alberto

Robert Osfield | 1 Feb 2011 09:58
Picon

Re: [vpb] vpbmaster build question...

Hi Shayne,

It sounds like VPB is black listing cores due to errors on the tasks
that ran on these cores, so it's limiting the build to just the ones
that are working.  VPB does this to handle outages on a network build
where problems on a single machine don't bring the whole build to a
halt.

If it is black listing that is limiting the cores that are available
then you'll need to look at the logs to see if there have been any
failures and any reports of blacklisting.  You will find a logs
directory in the directory that you ran the build from and within this
there will be lots of separate .log files that will provide the output
from each osgdem run, one per task.

If it isn't black listing then you'll need to try running vpbmaster in
a debugger and see what is going w.r.t threading.

Robert.

On Mon, Jan 31, 2011 at 11:43 PM, Shayne Tueller
<shayne.tueller@...> wrote:
> All,
>
> I fired off a VPB build using vpbmaster on a 16 processor machine running Linux Fedora core 13. The number of
tasks generated was 5314 for this build. As predicted, vpbmaster fired off 16 osgdem threads to work on the build.
>
> As the build went along I noticed that the number of osgdem threads running had slowly decreased until that
now there are only 0 to 2 threads running with about 2500 tasks remaining. I never see any more osgdem
threads than 2 being generated to work on the build. This seems a bit strange.
(Continue reading)

Antonio Gal | 1 Feb 2011 10:07
Picon
Favicon

Re: Animate a human head

Thank you!  is there a guide about osgAnimation library?

Antonio

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=36215#36215

Alberto Luaces | 1 Feb 2011 10:19
Picon
Favicon

Re: Animate a human head

"Antonio Gal" writes:

> Thank you!  is there a guide about osgAnimation library?

Unless others can point to more resources, I think the only available
documentation is the osganimation* examples themselves.

Regards,

--

-- 
Alberto

Sukender | 1 Feb 2011 11:39
Picon
Favicon
Gravatar

Re: Converting DrawArrays(TRIANGLE_STRIP) to DrawElements(TRIANGLES)

Hi Tim,

I'll try to send an exemple. Can I send it to your address direclty?
It's a very simple model with texture coordinates, created from the 3DS reader. I'll dump it as an OSG file beforehand.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/

----- "Tim Moore" <timoore33 <at> gmail.com> a écrit :

> Hi Sukender,
> I'm not sure what you mean; I need to see an example. The
> IndexMeshVisitor doesn't work with BIND_PER_PRIMITIVE attributes and
> bails if it finds any. If the number of vertex coordinates doesn't
> equal the number of texture coordinates, that's a big bug. Normally
> the number of indices in the DrawElements result will be different
> from the number of vertex coordinates, etc.
> 
> 
> Tim
> 
> 
> On Mon, Jan 31, 2011 at 5:05 PM, Sukender < suky0001 <at> free.fr > wrote:
> 
> 
> Hi Tim,
> 
> Sorry to jump into that conversation, but I also had a bug related to
> IndexMeshVisitor: the output geometries do NOT have "number of
> vertices == number of texcoords"... Did I miss something?
(Continue reading)

René Molenaar | 1 Feb 2011 11:42
Picon

PixelBufferWin32 memory leak and resize functionality

Hi osg-users,

In the application I'am working on we use PixelBufferWin32. I found there was a large memory leak and noticed incorrect shader result after destroying and creating a new pbuffer-enabled viewer.
( I adapted the pbuffertest code posted a while ago to create and destroy multiple pbuffers to see that this caused the leakage) :

traits->pbuffer = true     //leaks
v.s.
traits->pbuffer = false    //doesn't leak

After some experimenting I decided to reuse the existing pbuffer to solve the problems. However this did not work if the pbuffer needed a different size. So I created a resize function in the
PixelBufferWin32 class. This function does something like this (short version):

    //create new pbuffer
    newhwnd =wgle->wglCreatePbufferARB(_hdc, _format, width, height, &bAttribList[0]);
    newhdc = wgle->wglGetPbufferDCARB(newhwnd);
    newhglrc = wglCreateContext(newhdc);
    // delete the old context and pbuffer
    wglMakeCurrent(_hdc,0);
    if ( !wglDeleteContext(_hglrc) ) {}
    if ( !wgle->wglReleasePbufferDCARB(_hwnd, _hdc) ) {}
    if ( !wgle->wglDestroyPbufferARB(_hwnd) ) {}
    _hwnd = newhwnd;
    _hdc = newhdc;
    _hglrc = newhglrc;

This solved the problems, now I could reuse and resize pbuffers. The difference with this function and creating and destroying the entire PixelBufferWin32 is that there is no TempWindow involved.
It is the TempWindow class that was causing the memory leak. There is a comment in the code of this class:

PixelBufferWin32.cpp:

319:        // mew 2005-05-09 commented out due to crashes.
320:        // possible causes are unsafe destructor ordering, or context already
321:        // deleted by window deletion; see:
323:        //wglDeleteContext(_context);
324:        _context = 0;

after uncommenting the wglDeleteContext(_context) call the memory leak was gone.
I could not read the original post and now I am not sure how to procede. If we want a resize function in the PixelBufferWin32 class I can submit this? Can the wglDeleteContext(_context) 
be uncommented without causing the original crashes? Other suggestions?

Thanks!

René
<div>
<div>Hi osg-users,</div>
<div><br></div>
<div>In the application I'am working on we use PixelBufferWin32. I found there was a large memory leak and noticed incorrect shader result after destroying and creating a new pbuffer-enabled viewer.</div>
<div>( I adapted the pbuffertest code posted a while ago to create and destroy multiple pbuffers to see that this caused the leakage) :</div>
<div><br></div>
<div>traits-&gt;pbuffer = true &nbsp; &nbsp; //leaks</div>
<div>v.s.</div>
<div>
traits-&gt;pbuffer = false &nbsp; &nbsp;//doesn't leak</div>
<div><br></div>
<div>After some experimenting I decided to reuse the existing pbuffer to solve the problems. However this did not work if the pbuffer needed a different size. So I created a resize function in the</div>
<div>PixelBufferWin32 class. This function does something like this (short version):</div>
<div><br></div>
<div>&nbsp;&nbsp; &nbsp;//create new pbuffer</div>
<div>
<div>&nbsp;&nbsp; &nbsp;newhwnd =wgle-&gt;wglCreatePbufferARB(_hdc, _format, width, height, &amp;bAttribList[0]);</div>
<div>&nbsp;&nbsp; &nbsp;newhdc = wgle-&gt;wglGetPbufferDCARB(newhwnd);</div>
<div>&nbsp;&nbsp; &nbsp;newhglrc = wglCreateContext(newhdc);</div>
<div>&nbsp;&nbsp; &nbsp;// delete the old context and pbuffer<span class="Apple-tab-span">	</span>
</div>
<div>&nbsp;&nbsp; &nbsp;wglMakeCurrent(_hdc,0);</div>
<div>&nbsp;&nbsp; &nbsp;if ( !wglDeleteContext(_hglrc) ) {}</div>
<div>&nbsp;&nbsp; &nbsp;if ( !wgle-&gt;wglReleasePbufferDCARB(_hwnd, _hdc) )&nbsp;{}</div>
<div>&nbsp;&nbsp; &nbsp;if ( !wgle-&gt;wglDestroyPbufferARB(_hwnd) )&nbsp;{}</div>
<div>
&nbsp;&nbsp; &nbsp;_hwnd = newhwnd;</div>
<div>&nbsp;&nbsp; &nbsp;_hdc = newhdc;</div>
<div>&nbsp;&nbsp; &nbsp;_hglrc = newhglrc;</div>
</div>
<div><br></div>
<div>This solved the problems, now I could reuse and resize pbuffers. The difference with this function and creating and destroying the entire PixelBufferWin32 is that there is no TempWindow involved.</div>
<div>It is the TempWindow class that was causing the memory leak. There is a comment in the code of this class:</div>
<div><br></div>
<div>PixelBufferWin32.cpp:</div>
<div><br></div>
<div>
<div>319: &nbsp; &nbsp; &nbsp; &nbsp;// mew 2005-05-09 commented out due to crashes.</div>
<div>320: &nbsp; &nbsp; &nbsp; &nbsp;// possible causes are unsafe destructor ordering, or context already</div>
<div>321: &nbsp; &nbsp; &nbsp; &nbsp;// deleted by window deletion; see:</div>
<div>322:&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;// <a href="http://openscenegraph.org/pipermail/osg-users/2005-May/052753.html">http://openscenegraph.org/pipermail/osg-users/2005-May/052753.html</a>
</div>
<div>323:&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;//wglDeleteContext(_context);</div>
<div>324:&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;_context = 0;</div>
</div>
<div><br></div>
<div>after uncommenting the&nbsp;wglDeleteContext(_context) call the memory leak was gone.</div>
<div>I could not read the original post and now I am not sure how to procede. If we want a resize function in the PixelBufferWin32 class I can submit this? Can the&nbsp;wglDeleteContext(_context)&nbsp;</div>
<div>be uncommented without causing the original crashes? Other suggestions?</div>
<div><br></div>
<div>Thanks!</div>
<div><br></div>
<div>Ren&eacute;</div>
</div>
Anna Palazzolo | 1 Feb 2011 11:48

NodeTrackerManipulator validateNodePath method

Hi,

I was investigating about some problems I'm having using the NodeTrackerManipulator, and while
debugging the code I reached the call to the NodeTrackerManipulator validateNodePath method

bool NodeTrackerManipulator::validateNodePath() const
{
    for(ObserverNodePath::const_iterator itr = _trackNodePath.begin();
        itr != _trackNodePath.begin();
        ++itr)
    { .....

Maybe I'm missing something, but it seems to me that the for condition is never satisfied: itr=.begin;
itr!=.begin, ++itr , so the inner code is never executed.

Am I right?

Thank you!

Cheers,
Anna

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=36220#36220

Sukender | 1 Feb 2011 11:57
Picon
Favicon
Gravatar

Re: Generate mipmaps from arbitrary image

Hi Brad and Robert,

Any news about having a mipmap generation thing directly into OSG? I cannot include code of VPB (LGPL) in my
app (proprietary), and I do not think about linking to VPB just for mipmaps...

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/

----- "Sukender" <suky0001 <at> free.fr> a écrit :

> Hi Brad and Robert,
> 
> Well thanks for the answers. I don't know if I'll wait for Robert's
> implementation or use VPB. Is there a plan to move this code from VPB
> to OSG?
> 
> Sukender
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
> 
> ----- "Brad Christiansen" <brad.christiansen <at> thalesgroup.com.au> a
> écrit :
> 
> > Hi,
> >
> > The latest version of VPB has all the code you need to generate mip
> > maps for an osg::Image / Texture. This code also allows you to
> select
> > between NVTT (no context) or the current context based approach. The
> > code is in TextureUtils:
> >
> > void compress(State& state, Texture& texture,
> > Texture::InternalFormatMode compressedFormat, bool generateMipMap,
> > bool resizeToPowerOfTwo, CompressionMethod method);
> >
> > void generateMipMap(State& state, Texture& texture, bool
> > resizeToPowerOfTwo, CompressionMethod method);
> >
> > While this does have a cuple of VPB dependancies, these would be
> very
> > easy to remove.
> >
> >
> > Cheers,
> > Brad
> >
> > ------------------
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=33518#33518
> >
> >
> >
> >
> >
> > _______________________________________________
> > osg-users mailing list
> > osg-users <at> lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> _______________________________________________
> osg-users mailing list
> osg-users <at> lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users <at> lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Gmane