Re: [osg-users] [build] Postbuild error with ot11-OpenThreads??

[Frank Sullivan]

Hi,

Sorry to resurrect an old thread, but I am running into a very similar problem:


> 3>file INSTALL cannot find
> 3>
> "C:/Development/OpenSceneGraph-2.8.3/VS2010/bin/Release/../../bin/ot11-OpenThreads.dll".


The OP said that they could find this DLL (and others) in the specific 
directory. It seems that the OP's problem was that VS didn't have the right 
permissions to access the destination directory.

My problem is a bit different. I'm running VS2010 as Administrator, but it 
still doesn't work. When I look at the above folder path, all it has are PDBs. 
In my case, that is not the correct path. The correct path is:

 C:/Development/OpenSceneGraph-2.8.3/VS2010/bin/Release/

All of my DLLs, etc., are in that path. They are not in the folder that the 
cmake install step is looking in.

I don't know how to get them to build into the path that the cmake install step 
is looking for them in (aside from manually editing each project file by hand). 
Does anyone have any advice?

Thank you!

Cheers,
Frank[/quote]

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] How to set SWSCALE?

[Daryl Lee]

Well, that made a difference, mysteriously (since libswscale.a was already 
there for some reason).  osgversion and osgviewer work nicely, and I think I'm 
now ready for the QuickStart Guide again.

Thank you!

Cheers,
Daryl

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Graphics Context Question

[paul1492]

I need to call glXWaitVideoSyncSGI() between the update and cull traversals. As 
I understand it, this needs to be called with a valid graphics context so I do 
viewer.getCamera()->getGraphicsContext()->makeCurrent() and then call 
glXWaitVideoSyncSGI() and then call the viewer.renderingTraversals(). However, 
the glXWaitVideoSyncSGI call is only working when I use a SingleThreading 
model. 
Otherwise, glXWaitVideoSyncSGI is returning with an error about a Bad Context. 
What am I doing wrong?

Paul P.



  
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] BIND_PER_PRIMITIVE broken?

[Don Leich]

I confirmed that the bug persists in today's SVN trunk.  In the example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.

-Don

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] file name case changes

[Don Leich]

Hi all,

Now that I'm back after a short vacation I fully intend to see if the
BIND_PER_PRIMITIVE bug is in the SVN trunk.  As a sporatic user of SVN
I find that each time I try to use it is a challenge.  I've now come across
something odd that may well be a quirk of TortoiseSVN or might
be an indication on something funky with the SVN code base.  I found
that I had to change the case of several OSG files before I could
build.

The first indication was this error generating the cmake configuration...

 CMake Error in src/osg/CMakeLists.txt:
   Cannot find source file "GL".  Tried extensions .c .C .c++ .cc .cpp .cxx .m
   .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

After some trial and error I found that I could build if I changed
these files and the directory x11 to upper-case:

  src/include/gl
  src/include/glu
  src/include/lod
  src/osg/lod.cpp
  src/include/osgViewer/api/x11
  src/osgPlugins/ive/lod.cpp
  src/osgPlugins/ive/lod.h
  src/osgPlugins/bsp/bitset.cpp
  src/osgPlugins/bsp/bitset.h

-Don Leich


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] How to set SWSCALE?

[KSpam]

Daryl,

On Monday 20 September 2010 14:07:40 Daryl Lee wrote:
> I am just trying to get OSG installed on Mac OSX 10.6.4 for the first time,
> for evaluation and personal education, and I've run into a problem with
> the ffmpeg plugin.  I get an error with "img_convert" not being declared
> in scope.  I have tracked the problem down to the FFMPEG_LIBSWSCALE_FOUND
> parameter apparently not being set, but I can't discover how to set it.  I
> installed the ffmpeg library using the configure options
> "--enable-libmp3lame --enable-shared --disable-mmx --arch=x86_64", and I
> do see libswscale in the /usr/local/lib directory.
> 
> Other than just going into FFMpegDecoderVideo.hpp and cramming "#define
> USE_SWSCALE" at the top, how should I solve this problem?

ffmpeg does not build the swscale library by default.  If you want to build it, 
you need to configure ffmpeg with "--enable-swscale".

Hope This Helps,
Justin
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [osgPlugins] How to set SWSCALE?

[Daryl Lee]

I am just trying to get OSG installed on Mac OSX 10.6.4 for the first time, for 
evaluation and personal education, and I've run into a problem with the ffmpeg 
plugin.  I get an error with "img_convert" not being declared in scope.  I have 
tracked the problem down to the FFMPEG_LIBSWSCALE_FOUND parameter apparently 
not being set, but I can't discover how to set it.  I installed the ffmpeg 
library using the configure options "--enable-libmp3lame --enable-shared 
--disable-mmx --arch=x86_64", and I do see libswscale in the /usr/local/lib 
directory.

Other than just going into FFMpegDecoderVideo.hpp and cramming "#define 
USE_SWSCALE" at the top, how should I solve this problem?

Thank you!

Cheers,
Daryl

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] StateSet setAttribute(Material) question

[Tom Pearce]

Hi OSGers,

I'm using setAttribute(osg::Material* mat) on a matrix transform to control the 
color of an object (just a simple sphere for now, nothing fancy).  Just using 
task manager in windows to watch process memory usage, I noticed that upon 
adding an object to the scene, the memory usage would start to creep upward.  
Thinking this was a leak of some kind in my application I looked into it 
further and found that the creep (~20kB/sec) was dependent on calling 
getOrCreateStateSet()->setAttribute(Material) for the first time - If I never 
set a material, the memory usage stays constant.  When I wait for a key press 
and then set the material, the creep starts right away.  If I remove the node, 
the usage stops increasing but does not decrease.  Finally, if I just let it 
run, after a while (~500kB worth) the memory usage plateaus and is steady.

I'm wondering if this something I should be worried about or not moving 
forward, or if that just happens and it isn't really an issue... either way I 
wouldn't mind knowing what's going on.

Thank you!

Tom

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Trajce (Nick) Nikolov]

okay .. that explains things. Looks like as per the latest MSDN there are
changes. Main thing it works for you though ...

Cheers,

-Nick


On Tue, Sep 21, 2010 at 12:24 AM, Brad Huber  wrote:

>  Nick,
>
>
>
> Yes.
>
>
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Monday, September 20, 2010 2:23 PM
>
> *To:* OpenSceneGraph Users
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi Brad,
>
>
>
> VS 8.0. Is that 2005?
>
>
> -Nick
>
>  On Mon, Sep 20, 2010 at 11:52 PM, Brad Huber 
> wrote:
>
> Nick,
>
>
>
> Thanks for the extra input.  I’m using VC80.  I’ve previously hooked up
> Spy++ and noticed that my window does not receive either WM_CHAR or
> WM_GETDLGCODE.  In addition I tried something like what you’ve mentioned and
> it doesn’t ever get a WM_CHAR.  It does get WM_KEYDOWN and others.  Anyway
> I’ve also come across several posts online saying the CDialog is different
> wrt WM_CHAR.
>
>
>
> You’re example says differently and I haven’t tried a stripped down version
> like that.  I don’t want to belabor the point.  The issue is essentially
> fixed for me (regardless of which way we do translated / raw messages).
>
>
>
> I guess we’ll see which direction Robert would like to take it vis-à-vis
> translated/untranslated, dead keys, etc.
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Monday, September 20, 2010 12:15 PM
>
>
> *To:* OpenSceneGraph Users
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi again Brad,
>
>
>
> http://msdn.microsoft.com/en-us/library/619z63f5(VS.80).aspx
>
>
>
> note the Note. This makes me think you are using older MFC that is not
> doing that .
>
>
> -Nick
>
> On Mon, Sep 20, 2010 at 9:37 PM, Trajce (Nick) Nikolov <
> nikolov.tra...@gmail.com> wrote:
>
> Hi Brad,
>
>
>
> I hate arguing :) ... For me it works. I put a break point on the Sleep and
> I get there
>
>
>
> BOOL CDialogDlg::PreTranslateMessage( MSG *pMsg )
>
> {
>
> if (pMsg->message == WM_CHAR )
>
> {
>
> // will I get here
>
> Sleep(10);
>
> }
>
> return CDialog::PreTranslateMessage(pMsg);
>
> }
>
> -Nick
>
>
>
> On Mon, Sep 20, 2010 at 9:28 PM, Brad Huber  wrote:
>
> Nick,
>
>
>
> According to my understanding and experience,
> CDialog::PreTranslateMessage(MSG *msg) does not receive WM_CHAR messages so
> I cannot do anything about that.  In the MFC documentation there is a
> CWnd::GetDlgCode method which tells the framework which key messages (like
> WM_CHAR) your class would like to receive but again this does not work for
> CDialog classes.  GetDlgCode does not get called and PreTranslateMessage
> does not ever get WM_CHAR.  Therefore I cannot use any WM_CHAR based
> mechanism with my existing CDialog based app.  I can use a work around (ie
> don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead.  I could also
> investigate inserting a control on top of the dialog which would allow
> receipt of WM_CHAR messages.  Anyway there is apparently nothing I can do to
> force WM_CHAR to work with CDialog.
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Monday, September 20, 2010 11:06 AM
> *To:* OpenSceneGraph Users
>
>
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi Brad,
>
>
>
> Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
> cannot properly pass it on to the OSG window
>
>
>
> you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the
> same way is CView from the osgviewerMFC example
>
>
> -Nick
>
> On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber  wrote:
>
> Gentlemen,
>
>
>
> I apologize for being inactive on the thread these last few days.  I was on
> vacation at the Reno Air Races J.
>
>
>
> Trajce- to address your point about how to make MFC “work properly”.  The
> example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC
> app.  Dialogs in MFC do not capture/receive the WM_CHAR message and that is
> why I cannot properly pass it on to the OSG window.  Of course there are
> other work arounds that address my particular problem (I believe I’ve
> already fixed it), but I’m trying to bring up the point that this may be a
> fundamental issue in the key handling.
>
>
>
> Robert- One issue with including both the translated and untranslated keys
> in the event is that there is not a one to one mapping.  In windows
> sometimes 3 key presses will translate to one WM_CHAR (translated key)
> message and they don’t even need to be pressed at the same time (in the case
> of dead keys).  Whereas I believe there is a one-to-one between WM_KEYDOWN
> and key presses…
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:*

Re: [osg-users] Keypress broken since rev 11749

[Brad Huber]

Nick,

 

Yes.

 

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Monday, September 20, 2010 2:23 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Brad,

 

VS 8.0. Is that 2005? 


-Nick



On Mon, Sep 20, 2010 at 11:52 PM, Brad Huber  wrote:

Nick,

 

Thanks for the extra input.  I’m using VC80.  I’ve previously hooked up Spy++ 
and noticed that my window does not receive either WM_CHAR or WM_GETDLGCODE.  
In addition I tried something like what you’ve mentioned and it doesn’t ever 
get a WM_CHAR.  It does get WM_KEYDOWN and others.  Anyway I’ve also come 
across several posts online saying the CDialog is different wrt WM_CHAR.

 

You’re example says differently and I haven’t tried a stripped down version 
like that.  I don’t want to belabor the point.  The issue is essentially fixed 
for me (regardless of which way we do translated / raw messages).

 

I guess we’ll see which direction Robert would like to take it vis-à-vis 
translated/untranslated, dead keys, etc.

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Monday, September 20, 2010 12:15 PM


To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi again Brad,

 

http://msdn.microsoft.com/en-us/library/619z63f5(VS.80).aspx

 

note the Note. This makes me think you are using older MFC that is not doing 
that .


-Nick

On Mon, Sep 20, 2010 at 9:37 PM, Trajce (Nick) Nikolov 
 wrote:

Hi Brad,

 

I hate arguing :) ... For me it works. I put a break point on the Sleep and I 
get there

 

BOOL CDialogDlg::PreTranslateMessage( MSG *pMsg )

{

if (pMsg->message == WM_CHAR )

{

// will I get here

Sleep(10);

}

return CDialog::PreTranslateMessage(pMsg);

}

-Nick

 

On Mon, Sep 20, 2010 at 9:28 PM, Brad Huber  wrote:

Nick,

 

According to my understanding and experience, CDialog::PreTranslateMessage(MSG 
*msg) does not receive WM_CHAR messages so I cannot do anything about that.  In 
the MFC documentation there is a CWnd::GetDlgCode method which tells the 
framework which key messages (like WM_CHAR) your class would like to receive 
but again this does not work for CDialog classes.  GetDlgCode does not get 
called and PreTranslateMessage does not ever get WM_CHAR.  Therefore I cannot 
use any WM_CHAR based mechanism with my existing CDialog based app.  I can use 
a work around (ie don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead.  I 
could also investigate inserting a control on top of the dialog which would 
allow receipt of WM_CHAR messages.  Anyway there is apparently nothing I can do 
to force WM_CHAR to work with CDialog.

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Monday, September 20, 2010 11:06 AM
To: OpenSceneGraph Users


Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Brad,

 

Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I 
cannot properly pass it on to the OSG window

 

you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the same 
way is CView from the osgviewerMFC example


-Nick

On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber  wrote:

Gentlemen,

 

I apologize for being inactive on the thread these last few days.  I was on 
vacation at the Reno Air Races J.

 

Trajce- to address your point about how to make MFC “work properly”.  The 
example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC app.  
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I 
cannot properly pass it on to the OSG window.  Of course there are other work 
arounds that address my particular problem (I believe I’ve already fixed it), 
but I’m trying to bring up the point that this may be a fundamental issue in 
the key handling.

 

Robert- One issue with including both the translated and untranslated keys in 
the event is that there is not a one to one mapping.  In windows sometimes 3 
key presses will translate to one WM_CHAR (translated key) message and they 
don’t even need to be pressed at the same time (in the case of dead keys).  
Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses…

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Friday, September 17, 2010 10:57 AM


To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Robert,

 

I find some time to dig into this. And here are my observations ( I am working 
with Vivien's submission, with osgviewerMFC )

 

I put break points in GraphicsWindowWin32.cpp:

Line: 2476

case WM_KEYDOWN

Re: [osg-users] Keypress broken since rev 11749

[Trajce (Nick) Nikolov]

Hi Brad,

VS 8.0. Is that 2005?

-Nick


On Mon, Sep 20, 2010 at 11:52 PM, Brad Huber  wrote:

>  Nick,
>
>
>
> Thanks for the extra input.  I’m using VC80.  I’ve previously hooked up
> Spy++ and noticed that my window does not receive either WM_CHAR or
> WM_GETDLGCODE.  In addition I tried something like what you’ve mentioned and
> it doesn’t ever get a WM_CHAR.  It does get WM_KEYDOWN and others.  Anyway
> I’ve also come across several posts online saying the CDialog is different
> wrt WM_CHAR.
>
>
>
> You’re example says differently and I haven’t tried a stripped down version
> like that.  I don’t want to belabor the point.  The issue is essentially
> fixed for me (regardless of which way we do translated / raw messages).
>
>
>
> I guess we’ll see which direction Robert would like to take it vis-à-vis
> translated/untranslated, dead keys, etc.
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Monday, September 20, 2010 12:15 PM
>
> *To:* OpenSceneGraph Users
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi again Brad,
>
>
>
> http://msdn.microsoft.com/en-us/library/619z63f5(VS.80).aspx
>
>
>
> note the Note. This makes me think you are using older MFC that is not
> doing that .
>
>
> -Nick
>
>  On Mon, Sep 20, 2010 at 9:37 PM, Trajce (Nick) Nikolov <
> nikolov.tra...@gmail.com> wrote:
>
> Hi Brad,
>
>
>
> I hate arguing :) ... For me it works. I put a break point on the Sleep and
> I get there
>
>
>
> BOOL CDialogDlg::PreTranslateMessage( MSG *pMsg )
>
> {
>
> if (pMsg->message == WM_CHAR )
>
> {
>
> // will I get here
>
> Sleep(10);
>
> }
>
> return CDialog::PreTranslateMessage(pMsg);
>
> }
>
> -Nick
>
>
>
>  On Mon, Sep 20, 2010 at 9:28 PM, Brad Huber 
> wrote:
>
> Nick,
>
>
>
> According to my understanding and experience,
> CDialog::PreTranslateMessage(MSG *msg) does not receive WM_CHAR messages so
> I cannot do anything about that.  In the MFC documentation there is a
> CWnd::GetDlgCode method which tells the framework which key messages (like
> WM_CHAR) your class would like to receive but again this does not work for
> CDialog classes.  GetDlgCode does not get called and PreTranslateMessage
> does not ever get WM_CHAR.  Therefore I cannot use any WM_CHAR based
> mechanism with my existing CDialog based app.  I can use a work around (ie
> don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead.  I could also
> investigate inserting a control on top of the dialog which would allow
> receipt of WM_CHAR messages.  Anyway there is apparently nothing I can do to
> force WM_CHAR to work with CDialog.
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Monday, September 20, 2010 11:06 AM
> *To:* OpenSceneGraph Users
>
>
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi Brad,
>
>
>
> Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
> cannot properly pass it on to the OSG window
>
>
>
> you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the
> same way is CView from the osgviewerMFC example
>
>
> -Nick
>
> On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber  wrote:
>
> Gentlemen,
>
>
>
> I apologize for being inactive on the thread these last few days.  I was on
> vacation at the Reno Air Races J.
>
>
>
> Trajce- to address your point about how to make MFC “work properly”.  The
> example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC
> app.  Dialogs in MFC do not capture/receive the WM_CHAR message and that is
> why I cannot properly pass it on to the OSG window.  Of course there are
> other work arounds that address my particular problem (I believe I’ve
> already fixed it), but I’m trying to bring up the point that this may be a
> fundamental issue in the key handling.
>
>
>
> Robert- One issue with including both the translated and untranslated keys
> in the event is that there is not a one to one mapping.  In windows
> sometimes 3 key presses will translate to one WM_CHAR (translated key)
> message and they don’t even need to be pressed at the same time (in the case
> of dead keys).  Whereas I believe there is a one-to-one between WM_KEYDOWN
> and key presses…
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Friday, September 17, 2010 10:57 AM
>
>
> *To:* osg-users@lists.openscenegraph.org
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi Robert,
>
>
>
> I find some time to dig into this. And here are my observations ( I am
> working with Vivien's submission, with osgviewerMFC )
>
>
>
> I put break points in GraphicsWindowWin32.cpp:
>
> Line: 2476
>
> case WM_KEYDOWN

Re: [osg-users] Keypress broken since rev 11749

[Brad Huber]

Nick,

 

Thanks for the extra input.  I’m using VC80.  I’ve previously hooked up Spy++ 
and noticed that my window does not receive either WM_CHAR or WM_GETDLGCODE.  
In addition I tried something like what you’ve mentioned and it doesn’t ever 
get a WM_CHAR.  It does get WM_KEYDOWN and others.  Anyway I’ve also come 
across several posts online saying the CDialog is different wrt WM_CHAR.

 

You’re example says differently and I haven’t tried a stripped down version 
like that.  I don’t want to belabor the point.  The issue is essentially fixed 
for me (regardless of which way we do translated / raw messages).

 

I guess we’ll see which direction Robert would like to take it vis-à-vis 
translated/untranslated, dead keys, etc.

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Monday, September 20, 2010 12:15 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi again Brad,

 

http://msdn.microsoft.com/en-us/library/619z63f5(VS.80).aspx

 

note the Note. This makes me think you are using older MFC that is not doing 
that .


-Nick



On Mon, Sep 20, 2010 at 9:37 PM, Trajce (Nick) Nikolov 
 wrote:

Hi Brad,

 

I hate arguing :) ... For me it works. I put a break point on the Sleep and I 
get there

 

BOOL CDialogDlg::PreTranslateMessage( MSG *pMsg )

{

if (pMsg->message == WM_CHAR )

{

// will I get here

Sleep(10);

}

return CDialog::PreTranslateMessage(pMsg);

}

-Nick





On Mon, Sep 20, 2010 at 9:28 PM, Brad Huber  wrote:

Nick,

 

According to my understanding and experience, CDialog::PreTranslateMessage(MSG 
*msg) does not receive WM_CHAR messages so I cannot do anything about that.  In 
the MFC documentation there is a CWnd::GetDlgCode method which tells the 
framework which key messages (like WM_CHAR) your class would like to receive 
but again this does not work for CDialog classes.  GetDlgCode does not get 
called and PreTranslateMessage does not ever get WM_CHAR.  Therefore I cannot 
use any WM_CHAR based mechanism with my existing CDialog based app.  I can use 
a work around (ie don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead.  I 
could also investigate inserting a control on top of the dialog which would 
allow receipt of WM_CHAR messages.  Anyway there is apparently nothing I can do 
to force WM_CHAR to work with CDialog.

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Monday, September 20, 2010 11:06 AM
To: OpenSceneGraph Users


Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Brad,

 

Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I 
cannot properly pass it on to the OSG window

 

you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the same 
way is CView from the osgviewerMFC example


-Nick

On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber  wrote:

Gentlemen,

 

I apologize for being inactive on the thread these last few days.  I was on 
vacation at the Reno Air Races J.

 

Trajce- to address your point about how to make MFC “work properly”.  The 
example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC app.  
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I 
cannot properly pass it on to the OSG window.  Of course there are other work 
arounds that address my particular problem (I believe I’ve already fixed it), 
but I’m trying to bring up the point that this may be a fundamental issue in 
the key handling.

 

Robert- One issue with including both the translated and untranslated keys in 
the event is that there is not a one to one mapping.  In windows sometimes 3 
key presses will translate to one WM_CHAR (translated key) message and they 
don’t even need to be pressed at the same time (in the case of dead keys).  
Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses…

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Friday, September 17, 2010 10:57 AM


To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Robert,

 

I find some time to dig into this. And here are my observations ( I am working 
with Vivien's submission, with osgviewerMFC )

 

I put break points in GraphicsWindowWin32.cpp:

Line: 2476

case WM_KEYDOWN:

case WM_SYSKEYDOWN :



 

{

int keySymbol = 0;

 

Line: 2451

 /

case WM_CHAR :

/

{

// if event was not handled by WM_KEYDOWN then we take care of 
it here

// this method gives directly the utf16 char back so ju

Re: [osg-users] Running an OpenGL program with mesa instead of the platform's OpenGL driver?

[Jean-Sébastien Guay]

Hi Jordi,


Did you try LD_PRELOAD? Something like 'export
LD_PRELOAD=/usr/lib/mesa/libGL.so'
May be it can do the trick..


Seems like the MacOSX version of LD_PRELOAD is DYLD_INSERT_LIBRARIES. So 
having built a recent mesa now, I tried:


DYLD_INSERT_LIBRARIES=...path/to/libGL.dylib osgversion

and I get the same message:

dyld: Symbol not found: _gll_noop
  Referenced from: 
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL

  Expected in: /sw/lib/mesa/libGL.1.dylib
 in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
Trace/BPT trap

I can run with DYLD_PRINT_LIBRARIES=YES and I see each library that's 
loaded. The problem seems to come from the fact that the QuartzCore 
library (and others) depends on other libraries that are in the 
OpenGL.framework, so it loads that all the time, even if I want to use 
Mesa in its place.


Seems to me there's too much magic going on behind the scenes for Mesa 
to be usable under MacOS X. Other libraries (including the window 
system) depend on OpenGL and shared libraries are being loaded from 
other places on the system... Unless someone with more knowledge than me 
in this area could help, I'm stuck. :-(


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgParticle emitter and transforms

[Javier Taibo]

  Hi all,

  I am trying to make a directional emitter using osgParticle nodekit and
faced a problem.

  I am using a osgParticle::ModularEmitter and everything works fine except
for one thing: the emission direction. I configured an emission cone around
Z-axis using the osgParticle::RadialShooter and tried to orient it to the
desired direction by applying transformations above the emitter node in the
scene graph. The problem is that rotations above this node do not affect the
direction of emitted particles.

  Is this the expected behaviour? Is the problem between keyboard and chair?

  Any suggestion on how to solve it? Maybe creating a new shooter
(DirectionalShooter)?


  Best Regards
  Javier Taibo.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgParticle effects on a moving object...

[Maxim Gammer]

//see
//http://faculty.nps.edu/jasullivan/osgTutorials/osgParticleHelper.htm
//http://faculty.nps.edu/jasullivan/osgTutorials/Download/psHelper.cpp
//Author: jasulli...@nps.edu

#ifndef PARTICLEHELPER
#define PARTICLEHELPER

class psGeodeTransform : public osg::MatrixTransform
{
public:
   class psGeodeTransformCallback : public osg::NodeCallback
   {
  virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
  {
 if ( psGeodeTransform* ps = dynamic_cast( node ) )
 {
osg::NodePath& fullNodePath = nv->getNodePath();
fullNodePath.pop_back();

osg::Matrix localCoordMat = osg::computeLocalToWorld(
fullNodePath );
osg::Matrix inverseOfAccum = osg::Matrix::inverse( localCoordMat );

ps->setMatrix( inverseOfAccum );
 }
 traverse(node, nv);

  }
   };

   psGeodeTransform() {setUpdateCallback( new psGeodeTransformCallback() );}

};

class findGeodeVisitor : public osg::NodeVisitor
{
public:
   findGeodeVisitor() : osg::NodeVisitor(TRAVERSE_ALL_CHILDREN)
   {
  foundGeode = NULL;
   }
   virtual void apply(osg::Node &searchNode)
   {
  if (osg::Geode* g = dynamic_cast (&searchNode) )
 foundGeode = g;
  else
 traverse(searchNode);
   }
   osg::ref_ptr getGeode() {return foundGeode.get();}
protected:
   osg::ref_ptr foundGeode;
};

class particleSystemHelper : public osg::Group
{
public:
   particleSystemHelper(osg::Group* psGroup) : osg::Group(*psGroup)
   {
  osg::ref_ptr fg = new findGeodeVisitor();
  accept(*fg.get());
  osg::ref_ptr psGeode = fg->getGeode().get();
  psGeodeXForm = new psGeodeTransform();
  psGeodeXForm->addChild (psGeode.get());
  replaceChild(psGeode.get(),psGeodeXForm.get());
   }
   void addEffect(osg::Group* psGroup)
   {
  this->addChild(psGroup);
  osg::ref_ptr fg = new findGeodeVisitor();
  psGroup->accept(*fg.get());
  osg::ref_ptr psGeode = fg->getGeode().get();
  psGeodeXForm->addChild(psGeode.get());
  psGroup->removeChild( psGroup->getChildIndex(psGeode.get()) );
   }
protected:
   osg::ref_ptr psGeodeXForm;
};


#endif


//конструктор
BaseParticleObject::BaseParticleObject(std::string Name,
osg::ref_ptr _root)
{
//Запоминаем ссылку на root
root = _root;

//задаем имя
setName (Name);

//Particle
ptemplate = new osgParticle::Particle();
ptemplate->setLifeTime(3);// 3 seconds of life
ptemplate->setSizeRange(osgParticle::rangef(0.75f, 3.0f));
ptemplate->setAlphaRange(osgParticle::rangef(0.0f, 1.5f));
ptemplate->setColorRange(osgParticle::rangev4(
osg::Vec4(1, 0.5f, 0.3f, 1.5f),
osg::Vec4(0, 0.0f, 0.0f, 0.0f)));
// these are physical properties of the particle
ptemplate->setRadius(0.05f);// 5 cm wide particles
ptemplate->setMass(0.05f);// 50 g heavy

//ParticleSystem
ps = new osgParticle::ParticleSystem;
//ps->setFreezeOnCull(false);
ps->setDefaultAttributes("", false, false);
// assign the particle template to the system.
ps->setDefaultParticleTemplate(*ptemplate);

//emitter
emitter = new osgParticle::ModularEmitter;

//По замечаниям Ассель...
//Углы вылете частиц
//RadialShooter
shooter = new osgParticle::RadialShooter();
emitter->setShooter (shooter.get());
float k =64.0f;
float k2 =4.0f;
shooter->setPhiRange (-0.05f*k,0.05f*k);
shooter->setThetaRange (-0.05f*k2, 0.05f*k2);

//SectorPlacer
placer = new osgParticle::SectorPlacer();
placer->setRadiusRange (0.1f,0.2f);
emitter->setPlacer(placer.get());

emitter->setParticleSystem(ps.get());
rrc = static_cast(emitter->getCounter());
rrc->setRateRange(20, 30);// generate 20 to 30 particles per second
rrc->setClamp (true);

osg::ref_ptr  geode = new osg::Geode;
geode->addDrawable(ps.get());

//В этой матрице эмиттер (должен быть строго в Root)
otherMatrix  = new osg::MatrixTransform();
otherMatrix->setName (Name + "_emitter");
otherMatrix->addChild (geode);

psu = new osgParticle::ParticleSystemUpdater;
psu->addParticleSystem(ps.get());

root->addChild (otherMatrix);
addChild(psu.get());
addChild(emitter.get());

//созданные обертки (для возможности работать с текстом командами
типа RSetPosition..)
root->addChild(this);
}



2010/9/20 Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
:
> All,
>
>
>
> I have a need to attach osgParticle effects on a moving object (i.e smoke
> and fire trail from a moving missile). I've looked at the
> osgparticleeffects.cpp example in where they attach these effects based off
> a hit node from the pick event to see how I might do this. Unfortunately I
> need to invoke the effects from the mov

Re: [osg-users] GLSL 1.4(1.5) / "in" Storage Qualifier

[John Kush]

HOw get vertex coordinates?
Through variable gl_VertexID?

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Jean-Sébastien Guay]

Hi Brad,


JS- However I am wary of the issue where the WM_KEYDOWN is received and
WM_CHAR is not (as in my case).  In this case how do you handle what you
are proposing?


I didn't think at all of implementation issues, I was just thinking high 
level - modifying the existing events to try and make them flexible 
enough to express both user needs. I'll leave implementation issues to 
whoever implements it :-)



Another option would be to make separate keydown and char events (like
windows has).  It sounds like this would be a lot of work.  Also I’m not
sure how other OSs handle this…


I think Robert clearly stated he would like to avoid introducing a new 
event type for translated keys. Though if the arguments are good enough 
I'm sure he'd change his mind. :-)


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] GLSL 1.4(1.5) / "in" Storage Qualifier

[John Kush]

Hi,

How can I pass vertices in GLSL1.4 shaders 
 How can I pass values to "in vec4 vertex"

Code example.

Code:
#version 150

uniform mat4 projectionMatrix; //Specifies that the value is passed to the 
shader from the
application and is constant across a given primitive.
uniform mat4 modelViewMatrix;

in vec4 vertex;//Specifies that the variable is an input to the shader stage.
in vec3 normal;

out vec3 fragmentNormal;
out vec3 fragmentEye;//Specifies that the variable is an output from a shader 
stage.

void main(void)
{
fragmentNormal = (modelViewMatrix*vec4(normal, 0.0)).xyz;

fragmentEye = (modelViewMatrix*vertex).xyz;
fragmentEye = -normalize(fragmentEye);

gl_Position = projectionMatrix*modelViewMatrix*vertex;
}




Thank you!

Cheers,
John

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] problem using osg::GraphicsContext::setClearMask in quadBufferStereo to clear both buffers

[John Kelso]

Hi,

I have a window whose viewport doesn't fill it, and I want to set the area
outside the viewport to a specific color.

I'm using:
  _gc = osg::GraphicsContext::createGraphicsContext(_traits);
  _gc->setClearColor( osg::Vec4f(1.f, 0.f, 0.f, 1.0f) );
  _gc->setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );

This is osg 2.8.3 on Centos, Quadro FX 4600.

This works fine when traits->quadBufferStereo is false, but when it's true,
I only get one of the buffers cleared.

Any ideas?  I suspect the fix is easy but hard to find, at least for me.

Many thanks,

John


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] Implementing ReaderWriter in a class within application binary

[Thomas Dickerson]

That's good to know, I've registered for a wiki account and will do my best to 
post useful tips that I figure out. Most of the information I've seen on there 
up to this point seems to be related to developing around OSG rather than 
developing to extend it, which seems a little silly given how extensible and 
modular it has been designed to be.
~Thomas


Vermont Sustainable Heating Initiative (http://www.sustainableheatingvt.org) || 
Village2Village Project (http://www.village2villageproject.org)

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Trajce (Nick) Nikolov]

Hi again Brad,

http://msdn.microsoft.com/en-us/library/619z63f5(VS.80).aspx

note the Note.
This makes me think you are using older MFC that is not doing that .

-Nick


On Mon, Sep 20, 2010 at 9:37 PM, Trajce (Nick) Nikolov <
nikolov.tra...@gmail.com> wrote:

> Hi Brad,
>
> I hate arguing :) ... For me it works. I put a break point on the Sleep and
> I get there
>
> BOOL CDialogDlg::PreTranslateMessage( MSG *pMsg )
> {
>  if (pMsg->message == WM_CHAR )
> {
> // will I get here
>  Sleep(10);
> }
> return CDialog::PreTranslateMessage(pMsg);
> }
> -Nick
>
>
>
> On Mon, Sep 20, 2010 at 9:28 PM, Brad Huber  wrote:
>
>>  Nick,
>>
>>
>>
>> According to my understanding and experience,
>> CDialog::PreTranslateMessage(MSG *msg) does not receive WM_CHAR messages so
>> I cannot do anything about that.  In the MFC documentation there is a
>> CWnd::GetDlgCode method which tells the framework which key messages (like
>> WM_CHAR) your class would like to receive but again this does not work for
>> CDialog classes.  GetDlgCode does not get called and PreTranslateMessage
>> does not ever get WM_CHAR.  Therefore I cannot use any WM_CHAR based
>> mechanism with my existing CDialog based app.  I can use a work around (ie
>> don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead.  I could also
>> investigate inserting a control on top of the dialog which would allow
>> receipt of WM_CHAR messages.  Anyway there is apparently nothing I can do to
>> force WM_CHAR to work with CDialog.
>>
>>
>>
>> Thanks
>>
>> -Brad
>>
>>
>>
>> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
>> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
>> Nikolov
>> *Sent:* Monday, September 20, 2010 11:06 AM
>> *To:* OpenSceneGraph Users
>>
>> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>>
>>
>>
>> Hi Brad,
>>
>>
>>
>> Dialogs in MFC do not capture/receive the WM_CHAR message and that is why
>> I cannot properly pass it on to the OSG window
>>
>>
>>
>> you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the
>> same way is CView from the osgviewerMFC example
>>
>>
>> -Nick
>>
>>  On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber 
>> wrote:
>>
>> Gentlemen,
>>
>>
>>
>> I apologize for being inactive on the thread these last few days.  I was
>> on vacation at the Reno Air Races J.
>>
>>
>>
>> Trajce- to address your point about how to make MFC “work properly”.  The
>> example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC
>> app.  Dialogs in MFC do not capture/receive the WM_CHAR message and that is
>> why I cannot properly pass it on to the OSG window.  Of course there are
>> other work arounds that address my particular problem (I believe I’ve
>> already fixed it), but I’m trying to bring up the point that this may be a
>> fundamental issue in the key handling.
>>
>>
>>
>> Robert- One issue with including both the translated and untranslated keys
>> in the event is that there is not a one to one mapping.  In windows
>> sometimes 3 key presses will translate to one WM_CHAR (translated key)
>> message and they don’t even need to be pressed at the same time (in the case
>> of dead keys).  Whereas I believe there is a one-to-one between WM_KEYDOWN
>> and key presses…
>>
>>
>>
>> Thanks
>>
>> -Brad
>>
>>
>>
>> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
>> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
>> Nikolov
>> *Sent:* Friday, September 17, 2010 10:57 AM
>>
>>
>> *To:* osg-users@lists.openscenegraph.org
>> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>>
>>
>>
>> Hi Robert,
>>
>>
>>
>> I find some time to dig into this. And here are my observations ( I am
>> working with Vivien's submission, with osgviewerMFC )
>>
>>
>>
>> I put break points in GraphicsWindowWin32.cpp:
>>
>> Line: 2476
>>
>> case WM_KEYDOWN:
>>
>> case WM_SYSKEYDOWN :
>>
>> 
>>
>>
>>
>> {
>>
>> int keySymbol = 0;
>>
>>
>>
>> Line: 2451
>>
>>  /
>>
>> case WM_CHAR :
>>
>> /
>>
>> {
>>
>> // if event was not handled by WM_KEYDOWN then we take
>> care of it here
>>
>> // this method gives directly the utf16 char back so just
>> need to add it as it is
>>
>> if(!_keypresshandled)
>>
>> {
>>
>> // first check if key is already registered on the map
>>
>>
>>
>>
>>
>> case WM_KEYDOWN/WM_SYSKEYDOWN : get its chance to handle every single key
>> you press, even a dead key. So, for my czech character 'č', I have to press:
>> SHIFT, '+', and 'c', in this order, and for each of these three I get
>> WM_KEYDOWN. The only difference is that when I complete this sequence, on
>> top of all WM_KEYDOWNs, it gets to case WM_CHAR: with my 'č'. This is how
>> the system is managing thes

Re: [osg-users] GL_R32F (and others) float textures are being normalized

[Werner Modenbach]

Hi Juan,

I struggled on the same thing. But I found out that a regular GRBA-Texture (32 
Bit) comes out in the shaders with a range 0.0 to 1.0 on each channel.

Keeping this in mind it's very straight forward to use.

- Werner -

On Monday 20 September 2010 19:14:37 Juan Hernando wrote:
> Dear all,
> I'm writing some GLSL code that needs to access a 1D floating point
> texture as input in a vertex shader. My problem is that I'm getting
> clamped/normalized (not sure which one) values inside GLSL instead of
> the full range values.
> 
> For debug purposes I've setup a dummy texture like this:
>osg::Image *image = new osg::Image;
>float *tmp = new float;
>image->setImage(1, 1, 1, GL_R32F, GL_RED, GL_FLOAT,
>(unsigned char*)tmp, osg::Image::USE_NEW_DELETE);
>tmp[0] = 2
>osg::Texture1D *texture = new osg::Texture1D();
>texture->setFilter(osg::Texture::MIN_FILTER, osg::Texture::NEAREST);
>texture->setFilter(osg::Texture::MAG_FILTER, osg::Texture::NEAREST);
>texture->setImage(image);
> 
> In this case, the following GLSL expression:
>texture1D(the_texture, 0.0).r
> returns 1.
> 
> But if I change the image setup to:
>float *tmp = new float[4];
>image->setImage(1, 1, 1, GL_RGBA32F, GL_RGBA, GL_FLOAT,
>(unsigned char*)tmp, osg::Image::USE_NEW_DELETE);
> it works fine.
> 
> Looking at the source code from Texture.cpp I've found that
> Texture::computeInternalFormatType() does not deal with GL_R32F,
> GL_RG32F, GL_R32UI, ... they all fall into the default clause of the
> switch statement which assigns _internalFormatType to NORMALIZED. At the
> same time I've found no member function to change that attribute manually.
> Is that an omission or am I doing something wrong in the initialization?
> If that's an omission, is there an easy workaround that doesn't require
> recompiling the library?
> 
> Thanks and best regards,
> Juan
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
TEXION Software Solutions

TEXION GmbH -  Rotter Bruch 26a  -  D 52068 Aachen - HRB 14999 Aachen
Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu

Geschäftsführer/Managing Director: Werner Modenbach
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Trajce (Nick) Nikolov]

Hi Brad,

I hate arguing :) ... For me it works. I put a break point on the Sleep and
I get there

BOOL CDialogDlg::PreTranslateMessage( MSG *pMsg )
{
 if (pMsg->message == WM_CHAR )
{
// will I get here
 Sleep(10);
}
return CDialog::PreTranslateMessage(pMsg);
}
-Nick


On Mon, Sep 20, 2010 at 9:28 PM, Brad Huber  wrote:

>  Nick,
>
>
>
> According to my understanding and experience,
> CDialog::PreTranslateMessage(MSG *msg) does not receive WM_CHAR messages so
> I cannot do anything about that.  In the MFC documentation there is a
> CWnd::GetDlgCode method which tells the framework which key messages (like
> WM_CHAR) your class would like to receive but again this does not work for
> CDialog classes.  GetDlgCode does not get called and PreTranslateMessage
> does not ever get WM_CHAR.  Therefore I cannot use any WM_CHAR based
> mechanism with my existing CDialog based app.  I can use a work around (ie
> don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead.  I could also
> investigate inserting a control on top of the dialog which would allow
> receipt of WM_CHAR messages.  Anyway there is apparently nothing I can do to
> force WM_CHAR to work with CDialog.
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Monday, September 20, 2010 11:06 AM
> *To:* OpenSceneGraph Users
>
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi Brad,
>
>
>
> Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
> cannot properly pass it on to the OSG window
>
>
>
> you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the
> same way is CView from the osgviewerMFC example
>
>
> -Nick
>
>  On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber 
> wrote:
>
> Gentlemen,
>
>
>
> I apologize for being inactive on the thread these last few days.  I was on
> vacation at the Reno Air Races J.
>
>
>
> Trajce- to address your point about how to make MFC “work properly”.  The
> example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC
> app.  Dialogs in MFC do not capture/receive the WM_CHAR message and that is
> why I cannot properly pass it on to the OSG window.  Of course there are
> other work arounds that address my particular problem (I believe I’ve
> already fixed it), but I’m trying to bring up the point that this may be a
> fundamental issue in the key handling.
>
>
>
> Robert- One issue with including both the translated and untranslated keys
> in the event is that there is not a one to one mapping.  In windows
> sometimes 3 key presses will translate to one WM_CHAR (translated key)
> message and they don’t even need to be pressed at the same time (in the case
> of dead keys).  Whereas I believe there is a one-to-one between WM_KEYDOWN
> and key presses…
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Friday, September 17, 2010 10:57 AM
>
>
> *To:* osg-users@lists.openscenegraph.org
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi Robert,
>
>
>
> I find some time to dig into this. And here are my observations ( I am
> working with Vivien's submission, with osgviewerMFC )
>
>
>
> I put break points in GraphicsWindowWin32.cpp:
>
> Line: 2476
>
> case WM_KEYDOWN:
>
> case WM_SYSKEYDOWN :
>
> 
>
>
>
> {
>
> int keySymbol = 0;
>
>
>
> Line: 2451
>
>  /
>
> case WM_CHAR :
>
> /
>
> {
>
> // if event was not handled by WM_KEYDOWN then we take care
> of it here
>
> // this method gives directly the utf16 char back so just
> need to add it as it is
>
> if(!_keypresshandled)
>
> {
>
> // first check if key is already registered on the map
>
>
>
>
>
> case WM_KEYDOWN/WM_SYSKEYDOWN : get its chance to handle every single key
> you press, even a dead key. So, for my czech character 'č', I have to press:
> SHIFT, '+', and 'c', in this order, and for each of these three I get
> WM_KEYDOWN. The only difference is that when I complete this sequence, on
> top of all WM_KEYDOWNs, it gets to case WM_CHAR: with my 'č'. This is how
> the system is managing these events. To reflect this behavior into OSG, only
> one single line needs to be added, I think, and that will fix Brad's issue
> as well:
>
>
>
> else
>
> {
>
> // was no special key, let WM_CHAR handle it
>
> _keypresshandled = false;
>
> _lastkeysymbol = keySymbol;
>
> /* the new line
> */ getEventQueue()->keyPress(keySymbol, eventTime);
>
> }
>
>
>
> This was the key that was waste (being 'eate

Re: [osg-users] Keypress broken since rev 11749

[Brad Huber]

Nick,

 

According to my understanding and experience, CDialog::PreTranslateMessage(MSG 
*msg) does not receive WM_CHAR messages so I cannot do anything about that.  In 
the MFC documentation there is a CWnd::GetDlgCode method which tells the 
framework which key messages (like WM_CHAR) your class would like to receive 
but again this does not work for CDialog classes.  GetDlgCode does not get 
called and PreTranslateMessage does not ever get WM_CHAR.  Therefore I cannot 
use any WM_CHAR based mechanism with my existing CDialog based app.  I can use 
a work around (ie don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead.  I 
could also investigate inserting a control on top of the dialog which would 
allow receipt of WM_CHAR messages.  Anyway there is apparently nothing I can do 
to force WM_CHAR to work with CDialog.

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Monday, September 20, 2010 11:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Brad,

 

Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I 
cannot properly pass it on to the OSG window

 

you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the same 
way is CView from the osgviewerMFC example


-Nick



On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber  wrote:

Gentlemen,

 

I apologize for being inactive on the thread these last few days.  I was on 
vacation at the Reno Air Races J.

 

Trajce- to address your point about how to make MFC “work properly”.  The 
example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC app.  
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I 
cannot properly pass it on to the OSG window.  Of course there are other work 
arounds that address my particular problem (I believe I’ve already fixed it), 
but I’m trying to bring up the point that this may be a fundamental issue in 
the key handling.

 

Robert- One issue with including both the translated and untranslated keys in 
the event is that there is not a one to one mapping.  In windows sometimes 3 
key presses will translate to one WM_CHAR (translated key) message and they 
don’t even need to be pressed at the same time (in the case of dead keys).  
Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses…

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Friday, September 17, 2010 10:57 AM


To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Robert,

 

I find some time to dig into this. And here are my observations ( I am working 
with Vivien's submission, with osgviewerMFC )

 

I put break points in GraphicsWindowWin32.cpp:

Line: 2476

case WM_KEYDOWN:

case WM_SYSKEYDOWN :



 

{

int keySymbol = 0;

 

Line: 2451

 /

case WM_CHAR :

/

{

// if event was not handled by WM_KEYDOWN then we take care of 
it here

// this method gives directly the utf16 char back so just need 
to add it as it is

if(!_keypresshandled)

{

// first check if key is already registered on the map



 

case WM_KEYDOWN/WM_SYSKEYDOWN : get its chance to handle every single key you 
press, even a dead key. So, for my czech character 'č', I have to press: SHIFT, 
'+', and 'c', in this order, and for each of these three I get WM_KEYDOWN. The 
only difference is that when I complete this sequence, on top of all 
WM_KEYDOWNs, it gets to case WM_CHAR: with my 'č'. This is how the system is 
managing these events. To reflect this behavior into OSG, only one single line 
needs to be added, I think, and that will fix Brad's issue as well:

 

else

{

// was no special key, let WM_CHAR handle it

_keypresshandled = false;

_lastkeysymbol = keySymbol;

/* the new line */ 
getEventQueue()->keyPress(keySymbol, eventTime);

}

 

This was the key that was waste (being 'eaten' :) ..). 

 

So to me it sounds that, with Vivien's submission, only the dead key + 
'something' was not firing an event in osg - for the rest it should work as 
before, not  as Brad states above that the key events stopped work. I am very 
curious what he was actually doing.

 

Cheers,

-Nick

On Fri, Sep 17, 2010 at 8:04 PM, Vivien Delage  wrote:

Hi guys,

I understand you Robert. I have no problem with reverting the code for now if 
this causes issues for other people. I will go and experiment a bit more on how 
to fix the de

[osg-users] GL_R32F (and others) float textures are being normalized

[Juan Hernando]

Dear all,
I'm writing some GLSL code that needs to access a 1D floating point 
texture as input in a vertex shader. My problem is that I'm getting 
clamped/normalized (not sure which one) values inside GLSL instead of 
the full range values.


For debug purposes I've setup a dummy texture like this:
  osg::Image *image = new osg::Image;
  float *tmp = new float;
  image->setImage(1, 1, 1, GL_R32F, GL_RED, GL_FLOAT,
  (unsigned char*)tmp, osg::Image::USE_NEW_DELETE);
  tmp[0] = 2
  osg::Texture1D *texture = new osg::Texture1D();
  texture->setFilter(osg::Texture::MIN_FILTER, osg::Texture::NEAREST);
  texture->setFilter(osg::Texture::MAG_FILTER, osg::Texture::NEAREST);
  texture->setImage(image);

In this case, the following GLSL expression:
  texture1D(the_texture, 0.0).r
returns 1.

But if I change the image setup to:
  float *tmp = new float[4];
  image->setImage(1, 1, 1, GL_RGBA32F, GL_RGBA, GL_FLOAT,
  (unsigned char*)tmp, osg::Image::USE_NEW_DELETE);
it works fine.

Looking at the source code from Texture.cpp I've found that 
Texture::computeInternalFormatType() does not deal with GL_R32F, 
GL_RG32F, GL_R32UI, ... they all fall into the default clause of the 
switch statement which assigns _internalFormatType to NORMALIZED. At the 
same time I've found no member function to change that attribute manually.

Is that an omission or am I doing something wrong in the initialization?
If that's an omission, is there an easy workaround that doesn't require 
recompiling the library?


Thanks and best regards,
Juan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgParticle effects on a moving object...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

All,

 

I have a need to attach osgParticle effects on a moving object (i.e smoke
and fire trail from a moving missile). I've looked at the
osgparticleeffects.cpp example in where they attach these effects based off
a hit node from the pick event to see how I might do this. Unfortunately I
need to invoke the effects from the moving object's UpdateCallback event
rather than from a pick event. I have tried several things to get this to
work without success.

 

As anyone else been able to something similar to what I'm trying to
accomplish? I would appreciate any suggestions anyone might have on how to
get this to work.

 

Thanks,

-Shayne



smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Trajce (Nick) Nikolov]

Hi Brad,

Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
cannot properly pass it on to the OSG window

you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the
same way is CView from the osgviewerMFC example

-Nick


On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber  wrote:

>  Gentlemen,
>
>
>
> I apologize for being inactive on the thread these last few days.  I was on
> vacation at the Reno Air Races J.
>
>
>
> Trajce- to address your point about how to make MFC “work properly”.  The
> example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC
> app.  Dialogs in MFC do not capture/receive the WM_CHAR message and that is
> why I cannot properly pass it on to the OSG window.  Of course there are
> other work arounds that address my particular problem (I believe I’ve
> already fixed it), but I’m trying to bring up the point that this may be a
> fundamental issue in the key handling.
>
>
>
> Robert- One issue with including both the translated and untranslated keys
> in the event is that there is not a one to one mapping.  In windows
> sometimes 3 key presses will translate to one WM_CHAR (translated key)
> message and they don’t even need to be pressed at the same time (in the case
> of dead keys).  Whereas I believe there is a one-to-one between WM_KEYDOWN
> and key presses…
>
>
>
> Thanks
>
> -Brad
>
>
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Trajce (Nick)
> Nikolov
> *Sent:* Friday, September 17, 2010 10:57 AM
>
> *To:* osg-users@lists.openscenegraph.org
> *Subject:* Re: [osg-users] Keypress broken since rev 11749
>
>
>
> Hi Robert,
>
>
>
> I find some time to dig into this. And here are my observations ( I am
> working with Vivien's submission, with osgviewerMFC )
>
>
>
> I put break points in GraphicsWindowWin32.cpp:
>
> Line: 2476
>
> case WM_KEYDOWN:
>
> case WM_SYSKEYDOWN :
>
> 
>
>
>
> {
>
> int keySymbol = 0;
>
>
>
> Line: 2451
>
>  /
>
> case WM_CHAR :
>
> /
>
> {
>
> // if event was not handled by WM_KEYDOWN then we take care
> of it here
>
> // this method gives directly the utf16 char back so just
> need to add it as it is
>
> if(!_keypresshandled)
>
> {
>
> // first check if key is already registered on the map
>
>
>
>
>
> case WM_KEYDOWN/WM_SYSKEYDOWN : get its chance to handle every single key
> you press, even a dead key. So, for my czech character 'č', I have to press:
> SHIFT, '+', and 'c', in this order, and for each of these three I get
> WM_KEYDOWN. The only difference is that when I complete this sequence, on
> top of all WM_KEYDOWNs, it gets to case WM_CHAR: with my 'č'. This is how
> the system is managing these events. To reflect this behavior into OSG, only
> one single line needs to be added, I think, and that will fix Brad's issue
> as well:
>
>
>
> else
>
> {
>
> // was no special key, let WM_CHAR handle it
>
> _keypresshandled = false;
>
> _lastkeysymbol = keySymbol;
>
> /* the new line
> */ getEventQueue()->keyPress(keySymbol, eventTime);
>
> }
>
>
>
> This was the key that was waste (being 'eaten' :) ..).
>
>
>
> So to me it sounds that, with Vivien's submission, only the dead key +
> 'something' was not firing an event in osg - for the rest it should work as
> before, not  as Brad states above that the key events stopped work. I am
> very curious what he was actually doing.
>
>
>
> Cheers,
>
> -Nick
>
>  On Fri, Sep 17, 2010 at 8:04 PM, Vivien Delage  wrote:
>
> Hi guys,
>
> I understand you Robert. I have no problem with reverting the code for now
> if this causes issues for other people. I will go and experiment a bit more
> on how to fix the dead key problem. Maybe I can find a solution which is not
> using the WM_CHAR message. I will let you know how it goes on my side.
>
>
> Cheers,
>
> Vivien
>
> --
> Read this topic online here:
>
> http://forum.openscenegraph.org/viewtopic.php?p=31778#31778
>
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Brad Huber]

Nick,

 

I tried the change you proposed, thanks.  It is not sufficient because
keySymbol gets set to 0 in adaptKey.  Therefore a key press of 0 is inserted
into the event queue.

 

Something along these lines would work… but I don’t know if we want to
generate extra/indistinguishable keydowns in this manner.  I would advocate
what JS proposed instead.

 

For example the user hits ` then a.  I believe a fix along the lines of what
Nick proposed would generate 3 keydowns, one for ` one for a and one for à.
A fix along the lines of what JS proposed would generate 2 keydowns.  One
for ` with a translated code of 0.  One for a with a translated code of à.
This way the translated and untranslated codes are distinguishable.  

 

JS- However I am wary of the issue where the WM_KEYDOWN is received and
WM_CHAR is not (as in my case).  In this case how do you handle what you are
proposing?

 

Another option would be to make separate keydown and char events (like
windows has).  It sounds like this would be a lot of work.  Also I’m not
sure how other OSs handle this…

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce
(Nick) Nikolov
Sent: Monday, September 20, 2010 10:03 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Brad,

 

did you tried my change with adding the new extra line in
GraphicsWindowWin32.cpp ? I think it will fix it. This way the key that was
being translated to WM_CHAR will be passed as WM_KEYDOWN as well


-Nick



On Mon, Sep 20, 2010 at 5:51 PM, Jean-Sébastien Guay
 wrote:

Hi Brad,

 

Robert- One issue with including both the translated and untranslated
keys in the event is that there is not a one to one mapping.  In windows
sometimes 3 key presses will translate to one WM_CHAR (translated key)
message and they don’t even need to be pressed at the same time (in the
case of dead keys).  Whereas I believe there is a one-to-one between
WM_KEYDOWN and key presses…

 

I don't think that's a problem, in that case there will be 3 keydown events:

- the first two would have an untranslated key code but the translated code
would be invalid (say -1 so the app can recognize it and just do nothing if
it only wants translated codes)

- and the third event would have both a translated and untranslated codes
(both would be valid).

Thus apps that want raw keypresses could get them, and apps (or
osgWidget::Input) that need translated keys could just ignore keypresses
where the translated code is invalid.



J-S
-- 
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
  http://www.cm-labs.com/
   http://whitestar02.webhop.org/
___

osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Preparing for OpenSceneGraph-2.9.9 developer release, please test :-)

[Robert Osfield]

Hi All

I have merged Wang Rui's changes to osgParticle and other fixes that
have come in from the community so I'm ready to start looking at make
2.9.9 once more.  If testing goes OK I'll make the dev release
tomorrow.

Could members of the community check out svn/trunk and let me know how
things compile and run with the OSG examples and your own apps.

Thanks in advance for your help,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Trajce (Nick) Nikolov]

Hi Brad,

did you tried my change with adding the new extra line in
GraphicsWindowWin32.cpp ? I think it will fix it. This way the key that was
being translated to WM_CHAR will be passed as WM_KEYDOWN as well

-Nick


On Mon, Sep 20, 2010 at 5:51 PM, Jean-Sébastien Guay <
jean-sebastien.g...@cm-labs.com> wrote:

> Hi Brad,
>
>
>  Robert- One issue with including both the translated and untranslated
>> keys in the event is that there is not a one to one mapping.  In windows
>> sometimes 3 key presses will translate to one WM_CHAR (translated key)
>> message and they don’t even need to be pressed at the same time (in the
>> case of dead keys).  Whereas I believe there is a one-to-one between
>> WM_KEYDOWN and key presses…
>>
>
> I don't think that's a problem, in that case there will be 3 keydown
> events:
>
> - the first two would have an untranslated key code but the translated code
> would be invalid (say -1 so the app can recognize it and just do nothing if
> it only wants translated codes)
>
> - and the third event would have both a translated and untranslated codes
> (both would be valid).
>
> Thus apps that want raw keypresses could get them, and apps (or
> osgWidget::Input) that need translated keys could just ignore keypresses
> where the translated code is invalid.
>
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
>   http://www.cm-labs.com/
>http://whitestar02.webhop.org/
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Brad Huber]

JS- Great.  Sounds reasonable.

-Brad

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien 
Guay
Sent: Monday, September 20, 2010 9:51 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749

Hi Brad,

> Robert- One issue with including both the translated and untranslated
> keys in the event is that there is not a one to one mapping.  In windows
> sometimes 3 key presses will translate to one WM_CHAR (translated key)
> message and they don’t even need to be pressed at the same time (in the
> case of dead keys).  Whereas I believe there is a one-to-one between
> WM_KEYDOWN and key presses…

I don't think that's a problem, in that case there will be 3 keydown events:

- the first two would have an untranslated key code but the translated 
code would be invalid (say -1 so the app can recognize it and just do 
nothing if it only wants translated codes)

- and the third event would have both a translated and untranslated 
codes (both would be valid).

Thus apps that want raw keypresses could get them, and apps (or 
osgWidget::Input) that need translated keys could just ignore keypresses 
where the translated code is invalid.

J-S
-- 
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
 http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] "Tiling" data

[Grahame Bowland]

Hi Robert

I've had a look at OSG's databases. I'm extracting 2D slices from a 3D
database. I can't change the data storage method used for the 3D data,
and I want to avoid any preparation stage that would require duplicating
all the data in another format.

Once I've extracted a 2D slice I need to store it in another internal
format so that it can be accessed by other programs.

For those reasons I don't think the OSG's databases will work for me.

>From what I understand any OpenGL texture has to be entirely within GPU
memory if it is accessed at all, so I think I can cut my usage of GPU
memory a lot by breaking up the textures - then occluded textures won't
be paged in. Do you know of any examples of how to do this within osg?

Thanks for your help.

Cheers
Grahame

On Mon, Sep 20, 2010 at 11:01:10AM +0100, Robert Osfield wrote:
> Hi Grahame,
> 
> Are you aware of VirtualPlanetBuilder and osgEarth?  They both provide
> support for taxing high res imagery and generating OSG databases from
> them.  VirtualPlanetBuilder is an offline too, while osgEarth can do
> it at runtime.
> 
> Robert.
> 
> On Mon, Sep 20, 2010 at 7:14 AM, Grahame Bowland
>  wrote:
> > Hi all
> >
> > I'm wondering if anyone could give me some advice - I'm working on a 3D
> > viewer application that makes use of OpenSceneGraph. At the moment I'm
> > loading large 2D slices of data into textures, and then using a fragment
> > shader to colourise them.
> >
> > The slices of data are big (up to 150MB), and consist of 32-bit floating
> > point data. I'd like to split the hunks of data up to reduce the amount
> > of data being paged into the video card when a frame is rendered. I'm
> > wondering what the best approach might be.
> >
> > At the moment I've got a single osg::Geometry created by
> > osg::createTexturedQuadGeometry(). I initially thought I could keep this
> > single geometry and just pass multiple textures through to my shader
> > program, but it seems that sampler2DArray isn't supported on all the
> > cards I need to support.
> >
> > I'm currently thinking of using multiple geometries for say 512x512
> > sized textures of my data, and overlapping them to avoid interpolation
> > issues on the boundaries. I'm worried about seams appearing and other
> > artifacts though, so I thought I'd ask the mailing list for advice
> > before writing too much code!
> >
> > Thanks for any help,
> >
> > Cheers
> > Grahame
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Jean-Sébastien Guay]

Hi Brad,


Robert- One issue with including both the translated and untranslated
keys in the event is that there is not a one to one mapping.  In windows
sometimes 3 key presses will translate to one WM_CHAR (translated key)
message and they don’t even need to be pressed at the same time (in the
case of dead keys).  Whereas I believe there is a one-to-one between
WM_KEYDOWN and key presses…


I don't think that's a problem, in that case there will be 3 keydown events:

- the first two would have an untranslated key code but the translated 
code would be invalid (say -1 so the app can recognize it and just do 
nothing if it only wants translated codes)


- and the third event would have both a translated and untranslated 
codes (both would be valid).


Thus apps that want raw keypresses could get them, and apps (or 
osgWidget::Input) that need translated keys could just ignore keypresses 
where the translated code is invalid.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Keypress broken since rev 11749

[Brad Huber]

Gentlemen,

 

I apologize for being inactive on the thread these last few days.  I was on 
vacation at the Reno Air Races J.

 

Trajce- to address your point about how to make MFC “work properly”.  The 
example code IS NOT a dialog based MFC app.  My app IS a dialog based MFC app.  
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I 
cannot properly pass it on to the OSG window.  Of course there are other work 
arounds that address my particular problem (I believe I’ve already fixed it), 
but I’m trying to bring up the point that this may be a fundamental issue in 
the key handling.

 

Robert- One issue with including both the translated and untranslated keys in 
the event is that there is not a one to one mapping.  In windows sometimes 3 
key presses will translate to one WM_CHAR (translated key) message and they 
don’t even need to be pressed at the same time (in the case of dead keys).  
Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses…

 

Thanks

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) 
Nikolov
Sent: Friday, September 17, 2010 10:57 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Keypress broken since rev 11749

 

Hi Robert,

 

I find some time to dig into this. And here are my observations ( I am working 
with Vivien's submission, with osgviewerMFC )

 

I put break points in GraphicsWindowWin32.cpp:

Line: 2476

case WM_KEYDOWN:

case WM_SYSKEYDOWN :



 

{

int keySymbol = 0;

 

Line: 2451

 /

case WM_CHAR :

/

{

// if event was not handled by WM_KEYDOWN then we take care of 
it here

// this method gives directly the utf16 char back so just need 
to add it as it is

if(!_keypresshandled)

{

// first check if key is already registered on the map



 

case WM_KEYDOWN/WM_SYSKEYDOWN : get its chance to handle every single key you 
press, even a dead key. So, for my czech character 'č', I have to press: SHIFT, 
'+', and 'c', in this order, and for each of these three I get WM_KEYDOWN. The 
only difference is that when I complete this sequence, on top of all 
WM_KEYDOWNs, it gets to case WM_CHAR: with my 'č'. This is how the system is 
managing these events. To reflect this behavior into OSG, only one single line 
needs to be added, I think, and that will fix Brad's issue as well:

 

else

{

// was no special key, let WM_CHAR handle it

_keypresshandled = false;

_lastkeysymbol = keySymbol;

/* the new line */ 
getEventQueue()->keyPress(keySymbol, eventTime);

}

 

This was the key that was waste (being 'eaten' :) ..). 

 

So to me it sounds that, with Vivien's submission, only the dead key + 
'something' was not firing an event in osg - for the rest it should work as 
before, not  as Brad states above that the key events stopped work. I am very 
curious what he was actually doing.

 

Cheers,

-Nick



On Fri, Sep 17, 2010 at 8:04 PM, Vivien Delage  wrote:

Hi guys,

I understand you Robert. I have no problem with reverting the code for now if 
this causes issues for other people. I will go and experiment a bit more on how 
to fix the dead key problem. Maybe I can find a solution which is not using the 
WM_CHAR message. I will let you know how it goes on my side.


Cheers,

Vivien

--
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=31778#31778






___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Running an OpenGL program with mesa instead of the platform's OpenGL driver?

[Jordi Torres]

Hi J-S,

Did you try LD_PRELOAD? Something like 'export
LD_PRELOAD=/usr/lib/mesa/libGL.so'
May be it can do the trick..

Cheers.

2010/9/20 Jean-Sébastien Guay 

> Hi Alberto,
>
>
>  I don't know why is it different on Mac, but on Linux just setting the
>> LD_LIBRARY_PATH as you did is the way to go, since both libraries must
>> have the same ABI. For example, when one installs the nVidia libraries
>> on Linux, the installer just substitutes the old ones (e.g. Mesa) by the
>> new accelerated .so's.
>>
>
> Interesting, good to know. It seemed to work except for the missing symbol,
> so I'm now just trying to compile a more recent Mesa myself to see if that
> will work. I will rebuild OSG with the platform-default OpenGL and try
> changing the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH to use Mesa since that's
> supposed to work.
>
> Thanks for the pointers.
>
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
>   http://www.cm-labs.com/
>http://whitestar02.webhop.org/
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Running an OpenGL program with mesa instead of the platform's OpenGL driver?

[Jean-Sébastien Guay]

Hi Alberto,


I don't know why is it different on Mac, but on Linux just setting the
LD_LIBRARY_PATH as you did is the way to go, since both libraries must
have the same ABI. For example, when one installs the nVidia libraries
on Linux, the installer just substitutes the old ones (e.g. Mesa) by the
new accelerated .so's.


Interesting, good to know. It seemed to work except for the missing 
symbol, so I'm now just trying to compile a more recent Mesa myself to 
see if that will work. I will rebuild OSG with the platform-default 
OpenGL and try changing the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH to use 
Mesa since that's supposed to work.


Thanks for the pointers.

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Preparing for OpenSceneGraph-2.9.9 developer release, please test :-)

[Wang Rui]

Hi Robert,

2010/9/18 Robert Osfield 

> I've just been doing some testing and run osgparticleeffects and found
> that the particle systems it's generating are all over the place, so
> clearly there has been a serious regression in osgParticle.  The two
> likely culprits are Wang Rui's changes or my changes in support of
> GLES/GL3.
>
>
This happens because of my submission of avoiding float error when updating
time stamp of particle system updater and processors. I've no idea of  the
underlying causes but can fix it by roll back only related changes. I've
sent a private mail to you including the fixed code.

Cheers,

Wang Rui
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DatabasePager and CompileContext

[Guy Volckaert]

Yes. Everything works when I don't use the compile context (i.e the scene is 
rendered correctly), except that I still detect a problem with the number of 
texture objects when using the database pager.

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX and osgversion

[Daryl Lee]

Thanks for the feedback.  I think I'll go ahead with the latest and do a full 
build from source.  I like XCode, but I feel more in control with a traditional 
makefile approach to developing.  I'm sure I'll be back with more questions as 
I stumble through this learning experience!

Cheers,
Daryl

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Running an OpenGL program with mesa instead of the platform's OpenGL driver?

[Alberto Luaces]

Jean-Sébastien Guay writes:

> A bit of a general question, does anyone know how to run an OpenGL
> program with mesa instead of the platform's OpenGL driver? Is it
> supposed to require a recompile?

Hi J-S,

I don't know why is it different on Mac, but on Linux just setting the
LD_LIBRARY_PATH as you did is the way to go, since both libraries must
have the same ABI. For example, when one installs the nVidia libraries
on Linux, the installer just substitutes the old ones (e.g. Mesa) by the
new accelerated .so's.

-- 
Alberto

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DatabasePager and TextureObjects

[Guy Volckaert]

Sorry for the confusion - I ment to say the SharedStateManager. 

I should have mentioned (in my original post) that I already merged the 
SharedStateManager from the trunk into v2.8.2. Fortunately, the changes were 
easy to merge but did not resolve the problem.

I'm trying to figure out a way to determine what's the difference between 
loading the FLT model myself using readNode() and loading it through the 
DatabasePager.  In both cases, I run the SharedStateManager process and the 
optimizer process (via the readNode callback).  

I will continue isolating the problem, but not sure how far I can go.

Regards,

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] Implementing ReaderWriter in a class within application binary

[Roland Smeenk]

Hi Thomas,

as far as I know there's no developer documentation that describes the steps 
for writing a new readerwriter plugin.  You are welcome to write down your 
experiences while developing your own readerwriter.

You will probably first need to create a new Wiki account. See
http://www.openscenegraph.org/projects/osg/wiki/About/WikiEditing for 
instructions.

kind regards,

Roland Smeenk

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] The problem of translucent dialog with MFC+OSG

[Hunjun Lu]

Hi,

 :x  , is there anybody to answer my question?

Thank you!

Cheers,
Hunjun

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DatabasePager and CompileContext

[Robert Osfield]

Hi Guy,

Does everything work fine if you don't use a compile context?

Robert.

On Mon, Sep 20, 2010 at 2:38 PM, Guy Volckaert
 wrote:
> Here is my system configuration:
>
> Laptop XPS M1730
> Windows 7
> 4 GB RAM
> NVidia 8800M GTX, 512 MB
> NVidia Driver v257.71
>
> I hope this help. I've spent all weekend trying to deciphere what's going on. 
> Still don't know why it's not working.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=31825#31825
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Composite Viewer in WxWidgets

[Jean-Sébastien Guay]

Hello Micha,


is there a way to integrate only one view of a CompositeViewer within the 
WxWidgets-Application (Canvas), but let the other views standalone? The thing 
is, that the other views should be fullscreen.


Yes, just create a standard graphics context (not GraphicsWindowEmbedded 
or setting inherited window on the traits) however you want (windowed, 
fullscreen, whatever) and set it to the camera of your additional views 
which you want standalone.


You can look at the code for osgViewer::View::setUpViewOnSingleScreen(), 
setUpViewAcrossAllScreens(), setUpViewInWindow() etc. for inspiration.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DatabasePager and CompileContext

[Guy Volckaert]

Here is my system configuration:

Laptop XPS M1730
Windows 7
4 GB RAM
NVidia 8800M GTX, 512 MB
NVidia Driver v257.71

I hope this help. I've spent all weekend trying to deciphere what's going on. 
Still don't know why it's not working.

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Composite Viewer in WxWidgets

[Micha Januar]

Hi,

is there a way to integrate only one view of a CompositeViewer within the 
WxWidgets-Application (Canvas), but let the other views standalone? The thing 
is, that the other views should be fullscreen.

Thank you!

Cheers,
Micha

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] Implementing ReaderWriter in a class within application binary

[Thomas Dickerson]

Tim Moore wrote:
> You don't need to do anything special for a ReaderWriter that you wish to 
> link into your application. You write the class in exactly the same way, 
> including the REGISTER_OSGPLUGIN macro. Your plugin will be registered early 
> and OSG will use your code to load that file extension without searching for 
> an external plugin.
> 
> 
> Depending on your platform, you might need to perform some additional magic 
> to ensure that your code is actually linked into the application. On Unix, 
> for example, if your plugin code is in a statically-linked library, the .o 
> file containing the REGISTER_OSGPLUGIN "call" won't be linked in unless you 
> create some external reference to code in that file.
> 
> ...
> 
> Not FILE_NOT_HANDLED, but NOT_IMPLEMENTED. Since the default virtual methods 
> return NOT_IMPLEMENTED, it's cleaner not to implement them yourself; you 
> might get the return result wrong :)
> 
> 
> Tim
> 

Ah, that is just exactly what I wanted to know. Many thanks. Are either of 
these clearly documented on the wiki somewhere that I should know about? Or 
would it perhaps be worth starting an entry on developing a new plugin?
Thomas

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Running an OpenGL program with mesa instead of the platform's OpenGL driver?

[Jean-Sébastien Guay]

Hi all,

A bit of a general question, does anyone know how to run an OpenGL 
program with mesa instead of the platform's OpenGL driver? Is it 
supposed to require a recompile?


I want to run osgviewer using mesa to compare this with my machine's 
OpenGL drivers. I'm doing this on MacOS X, BTW, compiled by configuring 
in CMake to build with makefiles.


I tried two things, without recompiling (i.e. compiling with the 
platform's OpenGL but using mesa at runtime) and recompiling (i.e. using 
mesa both at compilation and at runtime), and I'm getting the same 
results for both...


I set:

$LD_LIBRARY_PATH=(mesa lib path):$LD_LIBRARY_PATH
$DYLD_LIBRARY_PATH=(mesa lib path):$DYLD_LIBRARY_PATH

so that osgviewer finds the mesa .so's first before the 
platform-installed ones, but then I get this message:


$ osgversion
dyld: Symbol not found: _gll_noop
  Referenced from: 
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL

  Expected in: /sw/lib/mesa/libGL.1.dylib
 in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
Trace/BPT trap
$ osgviewer --window 50 50 800 600 cow.osg
dyld: Symbol not found: _gll_noop
  Referenced from: 
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL

  Expected in: /sw/lib/mesa/libGL.1.dylib
 in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
Trace/BPT trap

It looks like the binary is still looking for OpenGL in 
/System/Library/Frameworks/OpenGL.framework (in both cases), which I 
would have thought wouldn't happen if I compile with mesa... And it also 
looks like the mesa lib is missing a symbol...


In the CMake window, I can't see any reference to 
/System/Library/Frameworks/OpenGL.framework (I've replaced all of them 
with the equivalent mesa libs/include paths). I'm pretty novice at 
Linux/Unix development, I'm sure there's a way to check which shared 
libraries an executable will look for at runtime?


Another detail, the mesa I'm using was downloaded with fink, it's 
version 7.0.2-2. It's from November 2007. Perhaps I should uninstall 
that and build mesa 7.8.2 (June 2010) from source? I think I'll do this 
while I wait for a reply on this thread. Nov 2007 seems a really long 
time ago :-)


Has anyone done this? Could anyone offer some guidance?

Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get objects nodes in *.obj file

[Alberto Luaces]

"John Kush" writes:

> Hi,
>
> There are 3 objects  in *.obj file. Is it possible to get their nodes in OSG 
> in order to set different transformations?

Hi John,

yes, you can traverse through the node hierarchy you get when you load
the file. You can use osg::NodeVisitor for that.

-- 
Alberto

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] "Tiling" data

[Robert Osfield]

Hi Grahame,

Are you aware of VirtualPlanetBuilder and osgEarth?  They both provide
support for taxing high res imagery and generating OSG databases from
them.  VirtualPlanetBuilder is an offline too, while osgEarth can do
it at runtime.

Robert.

On Mon, Sep 20, 2010 at 7:14 AM, Grahame Bowland
 wrote:
> Hi all
>
> I'm wondering if anyone could give me some advice - I'm working on a 3D
> viewer application that makes use of OpenSceneGraph. At the moment I'm
> loading large 2D slices of data into textures, and then using a fragment
> shader to colourise them.
>
> The slices of data are big (up to 150MB), and consist of 32-bit floating
> point data. I'd like to split the hunks of data up to reduce the amount
> of data being paged into the video card when a frame is rendered. I'm
> wondering what the best approach might be.
>
> At the moment I've got a single osg::Geometry created by
> osg::createTexturedQuadGeometry(). I initially thought I could keep this
> single geometry and just pass multiple textures through to my shader
> program, but it seems that sampler2DArray isn't supported on all the
> cards I need to support.
>
> I'm currently thinking of using multiple geometries for say 512x512
> sized textures of my data, and overlapping them to avoid interpolation
> issues on the boundaries. I'm worried about seams appearing and other
> artifacts though, so I thought I'd ask the mailing list for advice
> before writing too much code!
>
> Thanks for any help,
>
> Cheers
> Grahame
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] No dynamic Model load

[Robert Osfield]

Hi Theo,

It sounds like the compilation of display lists, VBO's and texture
objects is the cause of the frame stalls.  Caching the models in
memory will not help in this case, which you need to do is compile the
display list, VBO's and texture objects.  There are a number of tools
in the OSG to aid this work by either compiling all objects up front
or compiling them incrementally so that you don't end up with many GL
objects being compiled at one time.

I would recommend using 2.9.8 or svn/trunk as this offers the most
options w.r.t compilation as it provides the new
osgUtil::IncrementCompileOperation.  There is also the
osgUtil::GLObjectVisitor available all the way back to 2.0, and
perhaps even before.  The later has to be called from a graphics
thread.  The DatabasePager also has support for incremental
compilation built into it, so if you page your database in they you
could get this support for free.

Have a search through the archives on references of the above classes
to see more info on how to use them.

Robert.

On Sun, Sep 19, 2010 at 6:18 PM, Theo Diefenthal
 wrote:
> Hi,
>
> we made a little driving simulator with different levels and we have a 
> problem with dynamic loaded models from the ReaderWriter.
>
> We'd like to load all models when the level is changed and the scenegraph is 
> created. After loading the models into the scenegraph, the simulation should 
> start.
>
> When we just create the root node and attach it to our camera, the simulation 
> starts and updates a few frames while the models still are loading.
> Models which are not in the camera's field of vision when the level starts, 
> are loaded, when tey are in the field of vision for the first time. This 
> makes our simulation have a litte framerate per second for a moment
>
> We tried to enable CACHING_ALL as ReaderWriter options and disabled the 
> Optimizer for the graph, but it still doesn't work.
>
>
> So do you have any suggestions how can we load all objects at the point the 
> scenegraph is created? Do we have to set any property to the viewer/camera?
>
> We are using osg 2.8.3.
>
> Thank you!
>
> Cheers,
> Theo
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=31805#31805
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DatabasePager and TextureObjects

[Robert Osfield]

HI Guy,

On Sun, Sep 19, 2010 at 6:35 PM, Guy Volckaert
 wrote:
> I noticed a huge discrepency between loading an FLT with and without the 
> DatabasePager.
>
> Before loading any database model, the number of TextureObject created is 16.
>
> When I load a model via readNode(), the number of TextureObjects created 
> increases to 112 (for 96 textures objects for the model itself).
>
> However, when I load the same model from within the DatabasePager thread, 
> then I get 173 TexureObjects created (157 TextureObjects for the model 
> itself).
>
> Essentially, I noticed that loading tiles from within the DatabasePager 
> requires lots more texture memory (confirmed by using glDebugger).
>
> Note: The StateSetManager is used the in the same manner for both cases.

Do you mean the SharedStateManager?

In svn/trunk there has been a bug fix relating to the
SharedStateManager/DatabasePager so perhaps this might help.  Could
you try it?

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DatabasePager and CompileContext

[Robert Osfield]

Hi Guy,

The use of compile contexts looks to be very dependant on OS and
OpenGL driver.  What OS/hardware and drivers are you using?  Have you
tried any other platforms.  It'd be useful to see if there is a
pattern.

Robert.

On Sun, Sep 19, 2010 at 6:14 PM, Guy Volckaert
 wrote:
> Hi,
>
> I think there are a few problems with compiling GL objects with the 
> DatabasePager (in OSG 2.8.2). The following topic sums it up pretty well:
>
>
> http://forum.openscenegraph.org/viewtopic.php?t=1032&start=0&postdays=0&postorder=asc&highlight=compilecontext
>
> So far, I was able to compile all the GL object from a compile context (by 
> calling DisplaySettings::setCompileContextsHint(true)). However, my scene 
> appears all white. It seems that the texture objects are not created, or are 
> created but invalid from the rendering context.
>
> Any ideas?
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=31804#31804
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX and osgversion

[Stephan Huber]

Hi,


Am 19.09.10 07:51, schrieb Daryl Lee:
> So are these three commands not implemented for the Mac?  If I rebuild a 
> current version from source, will they be there?  (I'm not afraid to do that 
> if it offers promise for benefit.)


Don't know why they are not part of the installer, on the other hand,
the installer seems really outdated, as the osg-2.8 branch is now at  2.8.3.

The source-distribution for OS X is the same as for all other platforms
(and includes all examples and applications), but as OS X offers some
more ways to build the core libs (as dylibs, as frameworks, as
embedabble frameworks / with makefiles, with xcode) there are chances
that the built applications don't run out of the box, because the
dependent libs are not in the right place.

Hope this helps,

Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] Implementing ReaderWriter in a class within application binary

[Tim Moore]

On Sun, Sep 19, 2010 at 7:06 PM, Thomas Dickerson  wrote:

> Hi Robert,
>
> Thank you for the time you take to make your response, and the level of
> information you included in it. Unfortunately I think you may have
> misunderstood my original question. I was not inquiring about the
> possibility of serializing my own classes into the native binary format, but
> rather I was wishing to know whether a class that implements the
> ReaderWriter functionality (i.e. the readNode and writeNode methods present
> in all osgDB plugins) for a new format must be compiled into an external
> plugin (.so), or whether it can be incorporated directly into my application
> code, and compiled as part of my application binary. The instructions I was
> able to find on the wiki regarding plugin implementation is a bit sketchy,
> and only covered the possibility of helping the osgDB locate ReaderWriter
> plugins that are actually stored as external plugins and not compiled into
> my application.
>
> You don't need to do anything special for a ReaderWriter that you wish to
link into your application. You write the class in exactly the same way,
including the REGISTER_OSGPLUGIN macro. Your plugin will be registered early
and OSG will use your code to load that file extension without searching for
an external plugin.

Depending on your platform, you might need to perform some additional magic
to ensure that your code is actually linked into the application. On Unix,
for example, if your plugin code is in a statically-linked library, the .o
file containing the REGISTER_OSGPLUGIN "call" won't be linked in unless you
create some external reference to code in that file.

Additionally I was wondering what "proper plugin etiquette" is for plugins
> that read a format, but do not also write to it. I noticed some plugins
> conditionally return a
> Code:
> WriteResult(WriteResult::FILE_NOT_HANDLED);
>
>
> My question on this second issue is whether it is "better manners" for my
> ReaderWriter class to implement a writeNode function that ALWAYS returns
> FILE_NOT_HANDLED, or whether it is best to just leave the function
> unimplemented.
>
Not FILE_NOT_HANDLED, but NOT_IMPLEMENTED. Since the default virtual methods
return NOT_IMPLEMENTED, it's cleaner not to implement them yourself; you
might get the return result wrong :)

Tim

>
> Thanks,
> Thomas
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=31803#31803
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org