Re: [osg-users] a problem with computing near far

[rpingry]

Something that I have done (please let me know if this is not a good way to
do it or if there is a better way), is to break up my scene into parts.  I
have the large distant things in one part of my scene graph, and then
everything else in another part.  I then render them in separate render
bins, assuming that the large things will be drawn behind the smaller
things.  I also scale down the large objects and draw them closer to the
camera so they still look the same size.  I know this would throw off fog
calculations unless you adjusted for that, but I have found in my space
scenes that I can draw small ships right next to planets without having
near/far clipping problems, Z buffer fighting, or single point precision
errors.

-- Rick

On Mon, Jun 29, 2009 at 7:52 AM, Ren Liwei lw...@163.com wrote:

 Thank you Maria, your method should work well in most circumstance. But, my
 sky sphere whick has a very large radius would surely be cliped by the far
 plane in that, and that's not what i want to see. Any ideas to solve it?

 Thank you,
 RenLiwei

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





 ___
 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] a problem with computing near far

[rpingry]

Yes, two different groups in the scenegraph under the same camera, but I
cheat the large object part by scaling it and moving it closer to the
camera, so there is no risk of clipping due to the cull settings.

On Mon, Jun 29, 2009 at 7:39 PM, Ren Liwei lw...@163.com wrote:


 rpingry wrote:
  Something that I have done (please let me know if this is not a good way
 to do it or if there is a better way), is to break up my scene into parts.
 I have the large distant things in one part of my scene graph, and then
 everything else in another part.  I then render them in separate render
 bins, assuming that the large things will be drawn behind the smaller
 things.  I also scale down the large objects and draw them closer to the
 camera so they still look the same size.  I know this would throw off fog
 calculations unless you adjusted for that, but I have found in my space
 scenes that I can draw small ships right next to planets without having
 near/far clipping problems, Z buffer fighting, or single point precision
 errors.
 
  -- Rick
 


 I don't quite understand by breaking scene into two parts. If it means tow
 groups in the scenegraph under the same main camera, they will be cliped by
 the same cullsettings(the same near far clip planes), the problem is still
 here. Then can we render them with different cullsettings?

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





 ___
 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] Can I change the plugin directory structure?

[rpingry]

 So yes, either delete the old one and add the new one or rename the
directory and then checkin the updated plugin DLLs over the old ones...
That is unfortunate :(

 (which is not exactly the same thing, it preserves history, so SVN will
know they're actually the same files).
History is not all that helpful anyway since they are binaries.  The fact
remains that I need to remove directories and check in new directories each
time the plugin DLL version name changes, rather than simply doing a commit.


Oh, well.  I am still curious about the OSG_MSVC_VERSIONED_DLL thing.  What
is its expected functionality supposed to be?  I am sure it is not supposed
to just break the build paths of all of the applications.  My buddy James
was sure that at one time it added the actual plugin names to every plugin,
which causes many of the same problems we have now (or worse).  He is going
to do some tests himself and look closer at it.  I am thinking that perhaps
over time the OSG practice with the versions has evolved from being not
included, to being included in the name of each DLL, to being included only
in the plugin directory name.  James, perhaps a search through the archives
might help if no one pipes up here.


On Tue, Jun 2, 2009 at 5:41 AM, Jean-Sébastien Guay 
jean-sebastien.g...@cm-labs.com wrote:

 Hi Rick,

  Well, which Plugin directory am I supposed to add?  If I add a particular
 plugin directory with a given name, and then I do an update and the plugin
 version changes, then the folder name is not the same anymore.  Do I add the
 new plugin folder and delete the old one?  Perhaps use SVN to change the
 directory name (which essentially does the same thing)?


 The plugin directory name has to match the version of the OSG DLLs you have
 (you can check with the osgversion executable). So yes, either delete the
 old one and add the new one or rename the directory and then checkin the
 updated plugin DLLs over the old ones (which is not exactly the same thing,
 it preserves history, so SVN will know they're actually the same files).


 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

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

Re: [osg-users] Can I change the plugin directory structure?

[rpingry]

 With the command line SVN it's easy to script whatever you want. I really
 think you're making a mountain out of an ant hill. It's useful
 functionality, and all it takes on your side is a few more steps (not that
 often, unless you recompile OSG extremely often) or a little scripting.

 But as I said, if you want to have a different behavior (or disable that
 behavior as an option), code it up and submit it, and others will be able to
 comment on the change.




 I think it's to remove the osgXX- prefix on the main OSG DLLs. By default
 it's set to true so DLLs are named osg60-osg.dll, osg60-osgViewer.dll etc.
 Once again, it's there to help avoid picking up the wrong version of the
 DLLs.


Oh you are right, I can see all of those extensions now (sorry James, I did
not see those extensions when I was with you on the phone).
Unfortunately when you don't want that, and you try to turn it off,
side-effect of it breaking all of the paths of the Example projects and
other applications.

It seems like there is all this effort going towards just keeping people
from picking up the wrong version of the DLLs.  How often does that happen
anyway?  When somebody builds, don't they build everything they need all at
one time?  Why would anyone have the wrong version of DLL's floating around,
unless they had several versions of OSG on their path or something?I
have had far more difficulty tracking down problems from people in my
organization forgetting to do all the steps than I ever have because of
having the wrong version of the DLL.  If anything, I am far more likely to
get the wrong version of the DLL because I am still copying an antiquated
set of plugins because the old one with an old version number is still
sitting there, NOT being over-written.

Indeed, it is not a big issue for me to work around it, and I have so far.
It just seems to add several steps to my process, and I am not enough of an
SVN or CMAKE master to get around them.  I guess the root of the problem for
me is that I have to figure out out to use SVN or CMAKE in a special way I
am not used to to overcome a feature that I do not really understand the
usefulness of anyway, and that frustrates me a bit.

I know, this is open-source (that I am still very thankful for, even if I
just don't get the working process of the people who are masters of it), and
if I really don't want it I can weigh out how much it bugs me versus the
time taken to try to work out how to fix it to work for me.  There are
apparently lots of people who like this and it works for them.  I just don't
get it.  I can deal with it.  Thanks for trying to explain it to me.

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

Re: [osg-users] Can I change the plugin directory structure?

[rpingry]

I don't think I quite communicated what I meant to say in the end there.  I
am not super bothered by the whole naming thing, just a bit irritated and in
my organization I think it causes more problems that it is worth.  I was
hoping that perhaps with the power of CMake that someone had already
provided a way to disable this feature that works well for so many but not
for us.  Apparently that is not the case, and that is ok.  Perhaps we can
help to write it if we get a chance.

Thanks Again,
-- Rick

On Tue, Jun 2, 2009 at 2:05 PM, rpin...@gmail.com wrote:


 With the command line SVN it's easy to script whatever you want. I really
 think you're making a mountain out of an ant hill. It's useful
 functionality, and all it takes on your side is a few more steps (not that
 often, unless you recompile OSG extremely often) or a little scripting.

 But as I said, if you want to have a different behavior (or disable that
 behavior as an option), code it up and submit it, and others will be able to
 comment on the change.




 I think it's to remove the osgXX- prefix on the main OSG DLLs. By default
 it's set to true so DLLs are named osg60-osg.dll, osg60-osgViewer.dll etc.
 Once again, it's there to help avoid picking up the wrong version of the
 DLLs.


 Oh you are right, I can see all of those extensions now (sorry James, I did
 not see those extensions when I was with you on the phone).
 Unfortunately when you don't want that, and you try to turn it off,
 side-effect of it breaking all of the paths of the Example projects and
 other applications.

 It seems like there is all this effort going towards just keeping people
 from picking up the wrong version of the DLLs.  How often does that happen
 anyway?  When somebody builds, don't they build everything they need all at
 one time?  Why would anyone have the wrong version of DLL's floating around,
 unless they had several versions of OSG on their path or something?I
 have had far more difficulty tracking down problems from people in my
 organization forgetting to do all the steps than I ever have because of
 having the wrong version of the DLL.  If anything, I am far more likely to
 get the wrong version of the DLL because I am still copying an antiquated
 set of plugins because the old one with an old version number is still
 sitting there, NOT being over-written.

 Indeed, it is not a big issue for me to work around it, and I have so far.
 It just seems to add several steps to my process, and I am not enough of an
 SVN or CMAKE master to get around them.  I guess the root of the problem for
 me is that I have to figure out out to use SVN or CMAKE in a special way I
 am not used to to overcome a feature that I do not really understand the
 usefulness of anyway, and that frustrates me a bit.

 I know, this is open-source (that I am still very thankful for, even if I
 just don't get the working process of the people who are masters of it), and
 if I really don't want it I can weigh out how much it bugs me versus the
 time taken to try to work out how to fix it to work for me.  There are
 apparently lots of people who like this and it works for them.  I just don't
 get it.  I can deal with it.  Thanks for trying to explain it to me.

 -- Rick



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

Re: [osg-users] Can I change the plugin directory structure?

[rpingry]

If the switch were the default sure.  Right now there IS a switch with a
name that infers it would do what I want, but it just doesn't work and in
fact breaks other things.  That switch is off by default (or ON I should
say, adding versioning info to the DLL's).  It is even an advanced switch
that is buried away.  I can completely understand the dll hell you are
trying to avoid, and the people (presumably pretty new people) that have
mixed up versions because they have multiple versions in their path.  These
people would not even know about the switch (or maybe they would, and turn
it off because they think versioned dll's are weird, and then come whining
to you guys when there is a problem.  Robert is right to be concerned with
that ).  I do NOT have that problem.  I am very careful about keeping things
OUT of my path, and if things get wierd, I know how to run dependency walker
to check what DLL's are running before I ask the forums about it.

The fact is, in my personal situation, the version numbers on every dll and
folder name hinder rather than help.  I have a choice now.  I can rework my
project to do everything the OSG Way (singular bin folder with 'd'
post-fixes to every debug dll, every dll version named, etc.). Even if I DID
do that, I would have to deal with removing and adding dll's (if they were
all version named) and folders, which EVEN YOU said I would have to do.
That is more work than I have even now.  Right now I only have to look and
see if OSG snuck in a new plugin version folder on me and edit my bat files
to copy them from the right place.  I also have to deal with the broken
positions of the the example applications, but I can even fix that pretty
easily by copying some files around.  A slight annoyance that happens only
when we have to update OSG, which is not too often, but we like to be
somewhat up on things.  I waited too long to update from 1.2 and had a
painful growing curve to put away Producer::CameraGroups in favor of
osgViewer::Viewer and all the gui interaction that went with it.

Anyway, a slight annoyance and one I was hoping to overcome, but I would
much rather do that than add and remove stuff from my SVN every time the
plugin version number changes.  I was hoping that perhaps the fancy CMake
setup would already help me avoid even that annoyance, but it does not (and
I am ok with that, I certainly can't look this wonderful gift horse of OSG
in the mouth).  We might make it so that it works if we are bothered too
much by it, or we might not (the beauty of open source).  Once completed, we
might submit it, or not (if we felt like it was just a good enough hack to
get us by but not good enough to submit).  If we did submit, Robert could
accept it, or not, that is totally up to him and he should do what is best
for the community.  It's all good.

In the end, I might end up going the OSG way.  There might be deployment
issues we would have to deal with my way.  RIght now, I just think I would
be irritated by having to add and remove every versioned dll from my SVN
repository every time I update OSG, and that would be more annoying than
what I am doing now.  Perhaps you know a way to REALLY avoid that?

On Tue, Jun 2, 2009 at 5:12 PM, Jean-Sébastien Guay 
jean-sebastien.g...@cm-labs.com wrote:

 Hi Rick,

  I don't think I quite communicated what I meant to say in the end there.
  I am not super bothered by the whole naming thing, just a bit irritated and
 in my organization I think it causes more problems that it is worth.  I was
 hoping that perhaps with the power of CMake that someone had already
 provided a way to disable this feature that works well for so many but not
 for us.  Apparently that is not the case, and that is ok.  Perhaps we can
 help to write it if we get a chance.


 That would be great, but I think you don't consider the benefits of the
 current scheme compared to the numerous e-mails about mixed-up versions
 simply because you weren't there back then. It's very much a case where
 there was a problem reported by lots of users, a technological solution was
 put in place, and the problem is basically non-existent now that it has. So
 please consider that.

 I'm sure others would also benefit from you adding a switch to disable
 usage of the osgPlugins-x.y.z directory, but I don't know what Robert would
 think of that since it's pretty much transparent to end-users but cuts down
 significantly on support. But then again, there's precedent in the
 versioning of DLLs (osgXY-osg.dll) which can be disabled if you want, so
 perhaps that would be accepted too.

 I'm just an end-user like you in this regard, I don't have any say in what
 goes into OSG or not, but I think adding a switch to disable that would be a
 step backward.


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

Re: [osg-users] Can I change the plugin directory structure?

[rpingry]

 You say your examples are in bin\Release. This is not the case for me;
there
 is no bin\Release in my build dir. The release build of my osganimate.exe
 file is in my build dir\bin. Not sure why yours would be elsewhere,
but
 this appears to be the source of your problem. What CMake variables did
you
 change from their default?

AHA:  It was OSG_MSVC_VERSIONED_DLL  If you leave it in its default on
position, it makes the linker  General  Output File to something like:
\bin\Release\..\osghud.exe

Somewhere along the line, probably as I was kicking against the pricks
trying to avoid having to deal with versioned dlls, I turned
OSG_MSVC_VERSIONED_DLL off.  After doing that, it set linker  General 
Output File to something like:
\bin\Release\osghud.exe


So for the examples, is there any way to set the Working Directory for
debugging?  It is actually pretty easy to select all of the apps and
examples and then set properties for all configurations at one time, so that
is not such a big deal, but I was curious.

So, I am starting to get the idea of the version number on the folder.  In
our environment, we have separate folders for debug and release folders.  I
know that OSG puts them all in one folder.  Our bat files break out the OSG
files to go to our debug and release folders.  Is there an easy way to break
them up to separate debug and release folders rather than compiling to a
single folder?

Finally, we are moving these files to a stable bin folder, and then we are
checking them in to our own SVN repository.  Just copying the bin folder
with a versioned number plugin folder makes that really hard.  Any ideas?

Thanks
-- Rick


 brought up Properties and specified
 OSG_NOTIFY_LEVEL=DEBUG_FP in the environment, then I hit ctrl-f5 to run.
Wow, that is cool, how do you do that?  In the C++ Preprocessor Settings?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Can I change the plugin directory structure?

[rpingry]

 Why is it hard? Just svn add the whole directory, that should add all
contents and subdirectories by default... Unless I'm missing something?

Well, which Plugin directory am I supposed to add?  If I add a particular
plugin directory with a given name, and then I do an update and the plugin
version changes, then the folder name is not the same anymore.  Do I add the
new plugin folder and delete the old one?  Perhaps use SVN to change the
directory name (which essentially does the same thing)?



On Mon, Jun 1, 2009 at 8:40 PM, Jean-Sébastien Guay 
jean-sebastien.g...@cm-labs.com wrote:

 Hi Rick,

  So for the examples, is there any way to set the Working Directory for
 debugging?  It is actually pretty easy to select all of the apps and
 examples and then set properties for all configurations at one time, so that
 is not such a big deal, but I was curious.


 I don't know of any way to set it for all examples in one go, no. Sorry...

  So, I am starting to get the idea of the version number on the folder.  In
 our environment, we have separate folders for debug and release folders.  I
 know that OSG puts them all in one folder.  Our bat files break out the OSG
 files to go to our debug and release folders.  Is there an easy way to break
 them up to separate debug and release folders rather than compiling to a
 single folder?


 I'd like that too actually. Right now what I do is:
 1. Clean destination directory.
 2. Build INSTALL target in debug.
 3. Run script to copy debug binaries to somewhere.
 4. Clean destination directory.
 5. Build INSTALL target in release.
 6. Run script to copy release binaries to somewhere.

 It's kind of a pain, but we only update OSG on stable releases, so I don't
 have to do it too often. If your project lives on the bleeding edge I can
 see how that would be more painful, though again you could script all that
 with the devenv /build command line I gave you in the other message...

 But it would be nice of OSG's CMake scripts supported this in some way. It
 just doesn't bug me enough personally to take the time to implement it :-)

  Finally, we are moving these files to a stable bin folder, and then we are
 checking them in to our own SVN repository.  Just copying the bin folder
 with a versioned number plugin folder makes that really hard.  Any ideas?


 Why is it hard? Just svn add the whole directory, that should add all
 contents and subdirectories by default... Unless I'm missing something?


 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

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

Re: [osg-users] Can I change the plugin directory structure?

[rpingry]

Thanks for the help guys, and the reminder to check the previous posts and
the web-site.  UNFORTUNATELY:

 Being able to run an example directly from Visual Studio (using Set As
Active Project and pressing F5) is another issue. You need to first run at
least the ALL_BUILD target, so that all plugins will be built. That's
because none of the OSG DLLs or examples have the plugins as dependencies,
as it should be - the plugins are dynamically loaded, and as such no
executable can know /a/ /priori/ which plugins it will need, it all depends
on what is loaded either from the command line or the code.
 Once you've run the ALL_BUILD target (or INSTALL, which depends on
ALL_BUILD) then the examples will find the plugins just fine, you can run
them with F5 no problem.

I am not finding this to be the case.  When running with F5 or Ctrl-F5, VS
runs the example from where it compiled to, NOT where the INSTALL project
sends it.  In my case, bin\Release\.  I have built all the plugins, and
the go to bin\Release\..\osgPlugins-2.x.x\, which appears to be in the
wrong relative place (one directory too high) for osgDB to find it.  I am
not sure where the extra ..\ is coming from, does any one know?  Something
else that I thought would be nice is if the examples knew where the sample
data is.  That way it could set the working directory for debugging to where
the samples are, and it should just run when you hit F5 (or Ctrl-F5).

 Just set your CMAKE_INSTALL_PREFIX to some directory where you want the
latest OSG binaries+libs+headers to be placed ...

Unfortunately this does not do it either, it creates the osgPlugins-2.x.x
whether I want it or not.


 Then just copy the right version of the OSG DLLs into your app's bin
 directory (with its executable) and the osgPlugins-VERSION directory
 there too (with the plugins inside the directory).

 ...somepath/bin/myapp.exe
 ...somepath/bin/osg.dll
 ...somepath/bin/all other dlls you need
 ...somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll
 ...somepath/bin/osgPlugins-x.y.z/all other plugins you need

Well, there is the rub.  To keep from having to do all this manually, I
created a bat file to do the copying for me.  Whenever either one of us
upgrades OSG, we have to remember to go and change that bat file to include
the new version number.  Just one more thing to forget to do.

Thanks, and sorry for the whining.  I love OSG and all this community does.
If it is just a matter of changing something somewhere on my end, please let
me know.
-- Rick



On Fri, May 29, 2009 at 6:46 AM, James Killian james_kill...@hotmail.comwrote:


 Sorry about that... I did fix, and then I had to forward an email to Rick
 about the osgParticle (as I had to use html to preserve the diagram's
 spacing)  I have now switched it back to plain text.
 Thanks for letting me know. (there are too few of us in the dark side for
 microsoft to do something about it)  : (

 I have recopied email in plain text below:

 James Killian
 - Original Message - From: James Killian 
 james_kill...@hotmail.com
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Cc: Rick Pingry rpin...@gmail.com
 Sent: Thursday, May 28, 2009 10:25 PM

 Subject: Re: [osg-users] Can I change the plugin directory structure?


 
 Then just copy the right version of the OSG DLLs into your app's bin
 directory (with its executable) and the osgPlugins-VERSION directory
 there too (with the plugins inside the directory).

 .somepath/bin/myapp.exe
 .somepath/bin/osg.dll
 .somepath/bin/all other dlls you need
 .somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll
 .somepath/bin/osgPlugins-x.y.z/all other plugins you need
 

 I should review the code as I suspect it uses relative paths to retrieve
 the plugins.  If so, there should be a clause that client code must not
 dominate the CWD as ours currently does.  One thing I know for sure is that
 this path setup does not work right with our game in its current state.
  Thanks for taking the time out to explain.  Hopefully we may find a better
 solution.



 James Killian
  - Original Message -  From: Jean-Sébastien Guay
  To: OpenSceneGraph Users
  Sent: Thursday, May 28, 2009 8:07 PM
  Subject: Re: [osg-users] Can I change the plugin directory structure?


  Hello Rick,

   I have noticed that for the past little while the plugins are compiled
   to their own directory with the version number.  I am not quite sure why
   this is beneficial, it seems like you would always want the plugins
   compiled with the version of OSG you have compiled, and it seems that
   having them in the same folder with the other binaries ensures that the
   proper dll's will be found.

  Well, copying the plugins into the same directory as your application
  ensures that *some* *version* of the plugin will be found, not
  necessarily the right one (unless you're extra careful).

  There have been enough cases in the past of people only updating the
  main OSG DLLs, omitting to also update the plugins, 

[osg-users] Can I change the plugin directory structure?

[rpingry]

Hello All,

I have noticed that for the past little while the plugins are compiled to
their own directory with the version number.  I am not quite sure why this
is beneficial, it seems like you would always want the plugins compiled with
the version of OSG you have compiled, and it seems that having them in the
same folder with the other binaries ensures that the proper dll's will be
found.  I know when I try to run any of the example projects from Visual
Studio, that it always complains about the plugins not being there until I
copy them all over to the bin directory where the other binaries are.
Perhaps I am doing something wrong and I am missing some really cool feature
related to having them in their own version labeld directory?

I have several versions of OSG on my machine, for different projects, and I
want to avoid the DLL hell that might arise from having an environment
variable or whatever telling me where they go.  Right now I have a bat file
that copies all the files to the same directory as my project, and I have to
make sure I remember to change that whenever the plugin version number
changes.  Is there a way to tell CMake to just put all the binaries in the
same directory?

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

[osg-users] What is the best way to record a game scene?

[rpingry]

Hello all,

I am wondering about the best way to record some aspect of a scene that is
playing from a game.  Quite often in games when your character gets killed,
you want to see an instant replay of getting killed.  The camera motion in
these cases is probably overridden to show the reverse angle of the killing
character.  Being able to record and playback some aspect of the game has
lots of other uses as well.  There are times I might want to read in an
entire scene from a file, but there may be times as well that

So if you guys were to tackle this one, how would you do it?  The game is
obviously interactive, so it is not just a matter of having an AnimationPath
and writing out an .osg file of the scene (or perhaps I could, and there is
just something I am not understanding).  Most of the objects in the scene
are read in from other files.  If I were to write things out to an osg file,
is there a way to do it in such a way that the file references are written
out rather than all of the geometry explicity?

In my primary example, the primary scene is already built, and I just need
to keep track of the motions of everything,  I should be able to do that
ok.  I was thinking of creating a seperate scene with new Transform nodes,
but the original geometry nodes, so I would not have to read them all in
again, but I could keep the structure of my primary game scene in tact and
just replace the scene nodes that my viewer is looking at.  Sound
reasonable?

Thanks for all your help and advice.
-- Rick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] What is the best way to record a game scene?

[rpingry]

Oh, I almost forgot the thorniest thing I am trying to understand ...

In the game I am using particle effects for things like vapor trails,
explosions, smoke, etc.  They seem to have their own relationship with time,
and I do not know that they are rewindable.  Lets say that I am in the
middle of an explosion and I want to replay that explosion, but not from the
very beginning, perhaps from somewhere in the middle.  Is there a way to
rewind the time and play the particle effect from a given time, or do I need
to somehow start a new effect over and fast-forward it to the appropriate
time?

Hope that makes some kind of sense,
-- Rick

On Mon, Dec 29, 2008 at 8:33 PM, rpin...@gmail.com wrote:

 Hello all,

 I am wondering about the best way to record some aspect of a scene that is
 playing from a game.  Quite often in games when your character gets killed,
 you want to see an instant replay of getting killed.  The camera motion in
 these cases is probably overridden to show the reverse angle of the killing
 character.  Being able to record and playback some aspect of the game has
 lots of other uses as well.  There are times I might want to read in an
 entire scene from a file, but there may be times as well that

 So if you guys were to tackle this one, how would you do it?  The game is
 obviously interactive, so it is not just a matter of having an AnimationPath
 and writing out an .osg file of the scene (or perhaps I could, and there is
 just something I am not understanding).  Most of the objects in the scene
 are read in from other files.  If I were to write things out to an osg file,
 is there a way to do it in such a way that the file references are written
 out rather than all of the geometry explicity?

 In my primary example, the primary scene is already built, and I just need
 to keep track of the motions of everything,  I should be able to do that
 ok.  I was thinking of creating a seperate scene with new Transform nodes,
 but the original geometry nodes, so I would not have to read them all in
 again, but I could keep the structure of my primary game scene in tact and
 just replace the scene nodes that my viewer is looking at.  Sound
 reasonable?

 Thanks for all your help and advice.
 -- Rick

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

[osg-users] Teaching an intro to graphics course

[rpingry]

Hello All,

I am going to be teaching my first semester as a part-time adjunct professor
at BYU-Idaho.  I am really EXCITED!  We will be teaching an intro. to
graphics course that has not been taught before at this school.  Our focus
will be on juniors and seniors wanting to get out in the industry and do
something.

Our thought is to take a direction slightly different from the traditional
graphics course that works students through writing their own low level
graphics operations through writing their own phong shader and rudimentary
ray-tracer.  We know we need to teach the fundamentals with vector and
matrix math, etc. (a linear algebra class is already set as a
pre-requisite), but our thought was that we could focus on OpenGL and teach
how these concepts are important even while working on this relatively high
level API.

Once we have the fundamentals down and an idea of how OpenGL works, I wanted
to introduce the students to OSG and how a scene graph helps.  Another big
goal is to teach them how to participate in an Open Source community.
Ultimately I would like to have the students work on final projects that
they might be able to submit to the cause.  There are SOOO many great things
they could learn from this effort.  I hope we are not trying to shove too
much into a 3 credit hour class, but I am excited to see how it goes.

So, we have a few ideas about the things I think we should cover, but I
would love to get some feedback from this great community about things that
you would teach in this kind of course.  I know I want to introduce them to
the coding standards and the submission guidelines you have on the website.
Are there other things we should consider on that front?  (should we
pre-screen the submissions before we send them off to you?).  What kinds of
projects would you recommend the students might be able to work on?  The LWO
and LWS readers are near and dear to my heart, so I was going to have them
work on features there, but I am certainly open to suggestions.

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

Re: [osg-users] Teaching an intro to graphics course

[rpingry]

Thanks Simon,

A CSG library would be a great idea to work on.  I needed one of those for
some work I did with Northrop Grumman.  The generalized extrusion function
is cool too, maybe for a single student or as a feature of the CSG library.
I didn't look too deeply, but does the gts library work with OSG?

-- Rick


For me Geometry handling and generators.

I've spent part of today writing a generalised extrusion function but I'd be
highly
surprised if this hasn't been done 10,000 times already.

I couldn't find such a function in osg.

If it is there, then maybe you could get your students to help with
the documentation in the code and on the website. ;)

Also a high level CSG library would be fantastic.
I'm doing CAD stuff and it would be so much faster if I could just specify
things like 'intersect a cylinder with this box'

This might be relatively straight forward, if the CSG library generates
meshes to feed to:

http://gts.sourceforge.net/

On Fri, Nov 7, 2008 at 12:26 PM, [EMAIL PROTECTED] wrote:

 Hello All,

 I am going to be teaching my first semester as a part-time adjunct
 professor at BYU-Idaho.  I am really EXCITED!  We will be teaching an intro.
 to graphics course that has not been taught before at this school.  Our
 focus will be on juniors and seniors wanting to get out in the industry and
 do something.

 Our thought is to take a direction slightly different from the traditional
 graphics course that works students through writing their own low level
 graphics operations through writing their own phong shader and rudimentary
 ray-tracer.  We know we need to teach the fundamentals with vector and
 matrix math, etc. (a linear algebra class is already set as a
 pre-requisite), but our thought was that we could focus on OpenGL and teach
 how these concepts are important even while working on this relatively high
 level API.

 Once we have the fundamentals down and an idea of how OpenGL works, I
 wanted to introduce the students to OSG and how a scene graph helps.
 Another big goal is to teach them how to participate in an Open Source
 community.  Ultimately I would like to have the students work on final
 projects that they might be able to submit to the cause.  There are SOOO
 many great things they could learn from this effort.  I hope we are not
 trying to shove too much into a 3 credit hour class, but I am excited to see
 how it goes.

 So, we have a few ideas about the things I think we should cover, but I
 would love to get some feedback from this great community about things that
 you would teach in this kind of course.  I know I want to introduce them to
 the coding standards and the submission guidelines you have on the website.
 Are there other things we should consider on that front?  (should we
 pre-screen the submissions before we send them off to you?).  What kinds of
 projects would you recommend the students might be able to work on?  The LWO
 and LWS readers are near and dear to my heart, so I was going to have them
 work on features there, but I am certainly open to suggestions.

 Thanks,
 -- Rick

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

Re: [osg-users] Teaching an intro to graphics course

[rpingry]

Thanks Paul,

Lots of great project ideas.
We are looking for text book kinds of materials.  Do you have
recommendations in that regard, perhaps something you and Bob have already
written?  Like I mentioned, I would really like to start off with OpenGL and
then show how OSG helps.

-- Rick




Hi Rick -- Congrats, this sounds like a great undertaking.

I have somewhat similar plans you might be interested in. My intent is to
set up an internship program with CU Boulder and take in two interns
starting in January. While I will expect real work out of them (to be open
sourced, either as an OSG contribution or a standalone project), I also
intend to teach them 3D graphics. Like you, I'll focus on using the
higher-level API, and only teach the low-level stuff as a means to
understanding the end.

Like you, I'm also afraid that this will be like drinking from a fire hose
-- way too much material for a semester-long internship. Hopefully, if the
interns do well through the January-April semester, I can convince them to
stay on over the summer and really put to use what they've learned for solid
code production.

Between the curriculum Bob Kuehne and I have developed for out OSG courses,
and the material I intend to create for this internship program, I hope to
finally have enough material to create the long-awaited OSG Programming
Guide book.

On the subject of final projects suitable for a semester course...
 * A set of replacements for the ShapeDrawables that use Geometry as their
base class. The benefit would be that code could easily access and modify
the vertices, they could be exported to FLT, etc.
 * A new polygon decimator that can remove boundary vertices (a limitation
of the existing osgUtil::Simplifier).
 * I've always thought it would be useful to write an export osgPlugin that
dumps out an HTML document per node, with the document displaying info about
that node and containing links to parent/children/siblings. This would be a
great analysis tool for any OSG developer.
 * Finally, there are always several new OpenGL extensions that could be
implemented in OSG... How about a Drawable that supports ARB_draw_instanced,
for example?

Let's keep in touch as our two programs progress.

On Fri, Nov 7, 2008 at 4:37 PM, [EMAIL PROTECTED] wrote:

 Thanks Simon,

 A CSG library would be a great idea to work on.  I needed one of those for
 some work I did with Northrop Grumman.  The generalized extrusion function
 is cool too, maybe for a single student or as a feature of the CSG library.
 I didn't look too deeply, but does the gts library work with OSG?

 -- Rick


 For me Geometry handling and generators.

 I've spent part of today writing a generalised extrusion function but I'd
 be
 highly
 surprised if this hasn't been done 10,000 times already.

 I couldn't find such a function in osg.

 If it is there, then maybe you could get your students to help with
 the documentation in the code and on the website. ;)

 Also a high level CSG library would be fantastic.
 I'm doing CAD stuff and it would be so much faster if I could just specify
 things like 'intersect a cylinder with this box'

 This might be relatively straight forward, if the CSG library generates
 meshes to feed to:

 http://gts.sourceforge.net/


 On Fri, Nov 7, 2008 at 12:26 PM, [EMAIL PROTECTED] wrote:

 Hello All,

 I am going to be teaching my first semester as a part-time adjunct
 professor at BYU-Idaho.  I am really EXCITED!  We will be teaching an intro.
 to graphics course that has not been taught before at this school.  Our
 focus will be on juniors and seniors wanting to get out in the industry and
 do something.

 Our thought is to take a direction slightly different from the traditional
 graphics course that works students through writing their own low level
 graphics operations through writing their own phong shader and rudimentary
 ray-tracer.  We know we need to teach the fundamentals with vector and
 matrix math, etc. (a linear algebra class is already set as a
 pre-requisite), but our thought was that we could focus on OpenGL and teach
 how these concepts are important even while working on this relatively high
 level API.

 Once we have the fundamentals down and an idea of how OpenGL works, I
 wanted to introduce the students to OSG and how a scene graph helps.
 Another big goal is to teach them how to participate in an Open Source
 community.  Ultimately I would like to have the students work on final
 projects that they might be able to submit to the cause.  There are SOOO
 many great things they could learn from this effort.  I hope we are not
 trying to shove too much into a 3 credit hour class, but I am excited to see
 how it goes.

 So, we have a few ideas about the things I think we should cover, but I
 would love to get some feedback from this great community about things that
 you would teach in this kind of course.  I know I want to introduce them to
 the coding standards and the submission guidelines you have on the 

Re: [osg-users] KD-Tree Performance Challenge....

[rpingry]

Wow, that sounds pretty fantastic.  How do you integrate Adrian Egli's K-D
tree implementation into an application that uses OSG?

I appreciate all the hard work everyone does.  I appreciate it to the tune
of $25.  (actually, I appreciate it much much more than that, but it is
about all I can affor right now.  I know its not very much, but its a
start.  I also will go ahead and donate $25 to the OSG in general.  Heaven
knows Robert has done so much for every project I have worked on that uses
OSG.)  Maybe someone else can add to the pot?

Are you manning this competition Adrian?  What are the other rules?  I just
want to make sure that I (as an OSG noviciate), and everyone else in the
community, can use these great optimizations.

-- Rick

On Mon, Jul 14, 2008 at 7:57 AM, Adrian Egli OpenSceneGraph (3D) 
[EMAIL PROTECTED] wrote:

 Hi all,

  KD-Tree Performance Challenge 

 The latest version of OpenSceneGraph (SVN) supports a KD-Tree data
 structure. So we can start a challenge:

 Who can bit my kd-Tree implementation?

 Rule: Everyone who has a faster implementation can send a email with
 containing source code. It has to be based one the OSG KDTree
 implementation.

 Prize:
 Is out there someone can offering a prize?

 Help:
 I can not offer any price for the winning code, but i will offer my source
 code as starting point.
 My source code should only help to understand who fast we can trace a ray
 through a scene. it's not yet the fastet know implementation have a look at:
 http://homepages.paradise.net.nz/nickamy/benchmark.html

 Source:
 http://webaddon3d.assoftware.ch/AE/RayTracer.zip

 Scene to test:
 http://webaddon3d.assoftware.ch/AE/bunny.zip

 Results:
 *** Adrian Egli's KD-Tree  ***
 fraction_hit:10493:0.10493
 time:108.256ms
 923.74K rays/sec:

 *** OpenSceneGraph's KD-Tree (SVN) 
 fraction_hit:10495:0.10495
 time:258.756ms
 386.464K rays/sec:

 *** OpenSceneGraph without any KD-Tree  
 fraction_hit:10495:0.10495
 time:77564.2ms
 1.28925K rays/sec:

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




-- 
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] KD-Tree Performance Challenge....

[rpingry]

OK, I could not figure out how to donate to OSG (I looked for a link on the
OSG site and did a search for 'donate' with no joy).

-- Rick

On Mon, Jul 14, 2008 at 12:43 PM, [EMAIL PROTECTED] wrote:

 Wow, that sounds pretty fantastic.  How do you integrate Adrian Egli's K-D
 tree implementation into an application that uses OSG?

 I appreciate all the hard work everyone does.  I appreciate it to the tune
 of $25.  (actually, I appreciate it much much more than that, but it is
 about all I can affor right now.  I know its not very much, but its a
 start.  I also will go ahead and donate $25 to the OSG in general.  Heaven
 knows Robert has done so much for every project I have worked on that uses
 OSG.)  Maybe someone else can add to the pot?

 Are you manning this competition Adrian?  What are the other rules?  I just
 want to make sure that I (as an OSG noviciate), and everyone else in the
 community, can use these great optimizations.

 -- Rick

   On Mon, Jul 14, 2008 at 7:57 AM, Adrian Egli OpenSceneGraph (3D) 
 [EMAIL PROTECTED] wrote:

  Hi all,

  KD-Tree Performance Challenge 

 The latest version of OpenSceneGraph (SVN) supports a KD-Tree data
 structure. So we can start a challenge:

 Who can bit my kd-Tree implementation?

 Rule: Everyone who has a faster implementation can send a email with
 containing source code. It has to be based one the OSG KDTree
 implementation.

 Prize:
 Is out there someone can offering a prize?

 Help:
 I can not offer any price for the winning code, but i will offer my source
 code as starting point.
 My source code should only help to understand who fast we can trace a ray
 through a scene. it's not yet the fastet know implementation have a look at:
 http://homepages.paradise.net.nz/nickamy/benchmark.html

 Source:
 http://webaddon3d.assoftware.ch/AE/RayTracer.zip

 Scene to test:
 http://webaddon3d.assoftware.ch/AE/bunny.zip

 Results:
 *** Adrian Egli's KD-Tree  ***
 fraction_hit:10493:0.10493
 time:108.256ms
 923.74K rays/sec:

 *** OpenSceneGraph's KD-Tree (SVN) 
 fraction_hit:10495:0.10495
 time:258.756ms
 386.464K rays/sec:

 *** OpenSceneGraph without any KD-Tree  
 fraction_hit:10495:0.10495
 time:77564.2ms
 1.28925K rays/sec:

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




 --
  Rick
 Check us out at http://fringe-online.com/




-- 
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Using image maps with materials

[rpingry]

Hello All,

Is there a way to use image maps with some of the other material properties,
like emission or specular or diffuse?  I am working on adding some
functionality to the LWO reader.  We have been able to get the transparancy
working along with how LightWave does it, by taking the transparency mapped
defined in lightwave and copying that into the alpha channel of the color
map.  I can see there are lots of examples about how to use a reflection
map, so I think I am ok there.  Any way to use a map to define the emission,
specularity, and diffuse amounts across a surface?

-- Thanks
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test SVN of OpenSceneGraph

[rpingry]

I have build 8572 running using Visual Studio 7.1 and linking with my
project just fine.  Win XP, CMake 2.4
-- Rick

On Sat, Jul 12, 2008 at 1:18 PM, Mike Weiblen [EMAIL PROTECTED]
wrote:

 I'll verify and send details later this afternoon
 -- mew


 On Sat, Jul 12, 2008 at 11:59 AM, Robert Osfield
 [EMAIL PROTECTED] wrote:
   Hi Mike,
 
  On Sat, Jul 12, 2008 at 5:18 PM, Mike Weiblen [EMAIL PROTECTED]
 wrote:
  core built ok w/ winxp, vs8sp1, cmake2.4.8, but there was an error in
  wrappers (not at that machine to provide details)
 
  I've have just re-run genwrappers and nothing got updated, and snv
  diff suggests that everything is checked in.  I've also done a build
  of the wrappers under Linux and this went fine.
 
  So... there must be something like a missing export of something
  similar.The KdTree::BuildOptions didn't have an OSG_EXPORT so
  perhaps it was this, I've gone ahead and add this export and checked
  it in.   Fingers crossed this was the only one... as I want to go get
  on with tagging the release :-)
 
  Robert.
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 



 --
 Mike Weiblen -- Austin Texas USA -- http://mew.cx/
 ___
  osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test SVN of OpenSceneGraph

[rpingry]

Sorry, I only have the core, plugins, and apps compiling.  I am not building
the wrappers or examples.
-- Rick

On Sat, Jul 12, 2008 at 3:27 PM, [EMAIL PROTECTED] wrote:

 I have build 8572 running using Visual Studio 7.1 and linking with my
 project just fine.  Win XP, CMake 2.4
 -- Rick

   On Sat, Jul 12, 2008 at 1:18 PM, Mike Weiblen [EMAIL PROTECTED]
 wrote:

 I'll verify and send details later this afternoon
 -- mew


 On Sat, Jul 12, 2008 at 11:59 AM, Robert Osfield
 [EMAIL PROTECTED] wrote:
   Hi Mike,
 
  On Sat, Jul 12, 2008 at 5:18 PM, Mike Weiblen [EMAIL PROTECTED]
 wrote:
  core built ok w/ winxp, vs8sp1, cmake2.4.8, but there was an error in
  wrappers (not at that machine to provide details)
 
  I've have just re-run genwrappers and nothing got updated, and snv
  diff suggests that everything is checked in.  I've also done a build
  of the wrappers under Linux and this went fine.
 
  So... there must be something like a missing export of something
  similar.The KdTree::BuildOptions didn't have an OSG_EXPORT so
  perhaps it was this, I've gone ahead and add this export and checked
  it in.   Fingers crossed this was the only one... as I want to go get
  on with tagging the release :-)
 
  Robert.
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 



 --
 Mike Weiblen -- Austin Texas USA -- http://mew.cx/
 ___
  osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




  --
  Rick
 Check us out at http://fringe-online.com/




-- 
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] KdTree support now checked in

[rpingry]

Hi J-S, et. al.

When you mention caching the intersect visitors, when should you use reset()
and when are setStart()/setEnd() used?

In my game, I keep simplified, bounding box representations of the ships in
the scene and then do line segment intersections.  When I do the
calculations, I start at the smaller ships, which have several intersection
points.  For each point, I create a line segment for the global position of
where the point was last frame and where it is this frame.  I then bounce
that against each ship in the scene that is larger.  I also translate the
last position for the intersection point based on how the bigger ship has
moved.  I do all of this to make sure I catch ships flying right through
each other, because they are going fast.  This has all worked out really
well, but I am of course looking for any speed improvements I can get.

So my first question is about how I should try to cache the intersect
visitors?  Should I keep one around for each large ship (node passed in to
the getIntersections() function), or should I just make a single one that is
used over and over?

Next, how often should I call reset()?  Once for each big ship, or once for
each intersection check?  I do not see any setStart()/setEnd() functions.
Please forgive my ognorance, but where are they and what do they do?

Finally, I am doing a few checks before I try the line segments to see if
they are even close to the node I am checking.  Is this worth the check or
does the intersectVisitor do that all for me anyway?

Thanks,
-- Rick

On Fri, Jul 11, 2008 at 8:09 PM, Jean-Sébastien Guay 
[EMAIL PROTECTED] wrote:

 Hi Robert,

 To wrap, all these changes on now in SVN trunk and will be part of
 2.5.4 and hence the up coming 2.6.  If you enable the build of
 automatic KdTrees of load and use
 IntersectionVisitor/LineSegmentIntersector then you'll be able to go
 straight ahead of use KdTree intersections without lifting a further
 finger ;-)


 This is all very cool! I'll definitely be testing this out in the next few
 days to try it out with my Masters project (which was very
 intersection-heavy). I'll be setting up a little competition between your
 KdTree and Adrian Egli's... Just kidding!

 I think I may be able to help a bit regarding the higher-level setup and
 bookkeeping changes needed to speed things up on that regard. One thing I
 noticed before is that creating a new Intersector and IntersectionVisitor
 each time is costly, and instead keeping static or cached instances and
 using the reset() and setStart()/setEnd() methods is faster. There may be
 some other similar things that can be done too, we'll see what I can dig up.

 Thanks a lot for this work, it's a great addition, and I expect that it
 will be useful in lots of different applications.

 J-S
 --
 __
 Jean-Sebastien Guay[EMAIL PROTECTED]
   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




-- 
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] When optimizing with LOD changes, should I change UV map resolutions?

[rpingry]

Hello All,

I have been trying to get my scenes to run faster, balancing my scene graphs
using LOD.  I use quite a bit of UV mapping in my models, and they can be
fairly high res because I want them to look good up close.  There are
usually several instances of the same model in the scene, all pointing to
the same scene graph.  I was wondering about the best way to create LOD
changes for them.  I was going to cut out some polygons, but I was also
thinking of cutting the resolution back on the UV maps.  Is this valuable?
On first assessment, it seems it would be, but then I realize that it might
cause MORE of a memory usage, and the graphics card (or OSG) might be doing
this kind of optimization anyway (dropping image map resolutions based on
pixel size or whatever).  What are your recommendations?

-- Thanks for everything
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] The growing draw bar in the stats handler

[rpingry]

It seems that getting a driver update did the trick.  I have a pretty new
setup, so I was surprised there would be new drivers out there, but indeed
there were.

Now I do not have the growing Draw callback, but everything still shows the
orange bar across the entire screen.  I am getting 60 fps ok, so I don't get
the bar.  I am sure it is probably still a driver issue somewhere.  I still
also have these long orange bars and big spaces in my stats display I do not
understand, but atleast the performance does not degrade.

Thanks
-- Rick

On Thu, Jul 10, 2008 at 7:34 AM, Martin Naylor [EMAIL PROTECTED]
wrote:

  Hello,

 Been a while since I have posted and am just trying to catch up and rebuild
 OSG so I could be way off ;-).

 Are you running any kind of power saving options, such as cool and quiet?

 I seem to remember this happened to me when you had power saving options
 enabled and the model displaying was using particles or something like that?

 Of course that's on Windows J

 Cheers



 Martin Naylor.





 *From:* [EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED] *On Behalf Of *
 [EMAIL PROTECTED]
 *Sent:* 10 July 2008 03:43
 *To:* OpenSceneGraph Users
 *Subject:* Re: [osg-users] The growing draw bar in the stats handler



 Some more information:



 I have noticed that this strange behavior only seems to happen on certain
 models.  In others, the orange bar fills all along the lower bar.  I
 included a picture.  Somthing I see there is that the other bars take up
 very little of the space.  I am only getting 15 fps, but most of the bar is
 empty.



 -- Rick

 On Wed, Jul 9, 2008 at 10:14 PM, [EMAIL PROTECTED] wrote:

 Something else I noticed that I thought was strange was that the orange GPU
 bar has 8 short blocks all drawn in the first frame.  I have included an
 image to show.  What does this mean?  When I look at a smaller model, the
 Orange block fills alll along the lower bar.







 On Wed, Jul 9, 2008 at 9:46 PM, [EMAIL PROTECTED] wrote:

 Hello all,



 I recently added a stats handler to our game viewer.  Something I noticed
 is that if you have the stats window open, showing the bars, that the draw
 bar grows and grows.  The framerate starts dropping and gets slower.  If I
 turn the bars off, the framerate returns to 60.  When I turn the bars back
 on, the draw bar is suddenly back where it was when I turned it off, and
 starts growing again.



 I noticed this does not happen if I have a fairly trivial model, and it
 does not happen in osgviewer at all (as far as I can tell), using the same
 model I had in my game viewer.  What could I be doing wrong?



 Thanks

 -- Rick



 --
  Rick
 Check us out at http://fringe-online.com/




 --
  Rick
 Check us out at http://fringe-online.com/

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




-- 
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] The growing draw bar in the stats handler

[rpingry]

Hello all,

I recently added a stats handler to our game viewer.  Something I noticed is
that if you have the stats window open, showing the bars, that the draw bar
grows and grows.  The framerate starts dropping and gets slower.  If I turn
the bars off, the framerate returns to 60.  When I turn the bars back on,
the draw bar is suddenly back where it was when I turned it off, and starts
growing again.

I noticed this does not happen if I have a fairly trivial model, and it does
not happen in osgviewer at all (as far as I can tell), using the same model
I had in my game viewer.  What could I be doing wrong?

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

Re: [osg-users] The growing draw bar in the stats handler

[rpingry]

Something else I noticed that I thought was strange was that the orange GPU
bar has 8 short blocks all drawn in the first frame.  I have included an
image to show.  What does this mean?  When I look at a smaller model, the
Orange block fills alll along the lower bar.




On Wed, Jul 9, 2008 at 9:46 PM, [EMAIL PROTECTED] wrote:

 Hello all,

 I recently added a stats handler to our game viewer.  Something I noticed
 is that if you have the stats window open, showing the bars, that the draw
 bar grows and grows.  The framerate starts dropping and gets slower.  If I
 turn the bars off, the framerate returns to 60.  When I turn the bars back
 on, the draw bar is suddenly back where it was when I turned it off, and
 starts growing again.

 I noticed this does not happen if I have a fairly trivial model, and it
 does not happen in osgviewer at all (as far as I can tell), using the same
 model I had in my game viewer.  What could I be doing wrong?

 Thanks
 -- Rick




-- 
 Rick
Check us out at http://fringe-online.com/
attachment: Growing Draw Stats Viewer.jpg___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG thread profiling results are in!!

[rpingry]

Hi Robert,

I got the stats handler working on our scene and displaying.  I am not sure
I understand what the different numbers mean and how I might work with
them.  I can see the optimization effort is a big deal.  I know it is beyond
the scope of this group.  Are there any resources out there to look at?

I have finished the work you had already mentioned, like using png rather
than bmp everywhere.  We are also working on making sure our images are as
small as possible.  We are also going to work on using LOD.  Since we are in
space and most ships are far away, we are sure we can make a big jump
there.  I used osgUtil::Optimizer and that game me a few more frames.

What are some other suggestions?

We are using some particle effects pretty heavily, and we noticed (using
filemon) that the smoke image file is being read over and over again, many
times (perhaps once per frame).  Is this possible?  We are going to look
into that next.  Maybe we can cache the single image (state set)?

Thanks
-- Rick

On Sat, Jun 28, 2008 at 11:55 AM, Robert Osfield [EMAIL PROTECTED]
wrote:

 On Sat, Jun 28, 2008 at 4:35 PM, James Killian
 [EMAIL PROTECTED] wrote:
  The thread profiler does provide detailed information of every threaded
  activity at any given time.  I just wish there was some way to present
 the
  information given that would be more meaningful to the group.
 
  What would be great is to have a big balanced scene that can put OSG
 Viewer
  to the test in a way where it puts equal intense stress on update,
 culling,
  and draw dispatch.  What I'd hope to see is the draw dispatch be on a
  separate thread, where that thread showed mostly I/O activity, and the
 cpu
  activity on other threads.

 The osgViewer::StatsHandler will display update, event, cull, draw
 dispatch on all systems and draw GPU stats.  The GPU stats require an
 OpenGL extension that I've only seen Nvidia implement so far, so you
 won't see this stats printed out on all systems.

 Also record a camera path/game sequence that you can use for
 benchmarking so that every run the app does the same thing, then
 you'll be able to study the effects that changes you make have on
 final performance.  You'll also be able to study the above stats to
 where the problems occur in your scene.

 As a small note, the OSG in CullDrawThreadPerContext,
 DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext run
 graphics in a separate thread.

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




-- 
 Rick
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG thread profiling results are in!!

[rpingry]

Thanks Robert,

(James and I are working on this together.  He has decided to focus his
attentions on understanding OpenSceneGraph and optimizing where he can,
where most of the client game code dealing with the scene graph is mine). I
was planning on asking some of these questions eventually anyway, but now
seems like a good time ;)

I think a huge part of what we are seeing is that we are relying very
heavily on image maps for everything, and that most graphics cards have to
swap memory.  That said, I know that I need to work on my dependence on
these image maps and look harder at resizing them where possible.  Are there
any other recommendations out there for more effective image map
utilization?  One thing I know I want to apply is LOD, which I have not done
yet.  In looking over the example code, the LOD is pretty straight forward.

All our ships use UV mapping, and I was trying to make it so that the image
was only loaded once for the ship type, rather than for each instance.  It
did not seem that this made much of a difference, however.  I have started
to look at the osgImposter example for help in how I might better handle
this.  AM I going in the right direction?

I have lots more questions, but I figure I will ask them as I get to them
and I am able to dig in myself.
Thanks again for all the great support,
-- Rick

On Sat, Jun 28, 2008 at 5:22 AM, Robert Osfield [EMAIL PROTECTED]
wrote:

 Hi James,

 I've read your emails but I'm afraid the stats mean absolutely nothing
 do me.  One will really need to be find out what parts of the OSG i.e.
 what function calls are the current bottleneck.

 As general note, performance optimization with scene graphs as almost
 always an issue of improving the balance of the scene graph, be it
 update, cull, draw dispatch or draw GPU, it's almost always a poor
 scene graph that is at fault.  You can often improve performance by
 10x and more by simply fixing the scene graph.  Doing low level code
 optimization will rarely get you anything like the performance
 improvement that you'd get by just fixing the scene graph.

 Given this, diving into low level profiling could well be a case of
 not seeing the wood from the trees.   So I'd recommend if you want
 your app to go faster start with the basics, are your CPU or GPU
 limited.  Then are you update, cull or draw dispatch limited?  Then
 depending upon what results you get consider why the scene graph
 itself is making things so slow.  This process will typically lead you
 to things you can do to your scene graph to fix the performance
 bottleneck, and all this without touching the actual code.
 Performance optimization is huge topic, but hopefully I'll have given
 you a little pointer to priorities I'd apply.

 Robert.

 On Sat, Jun 28, 2008 at 4:12 AM, James Killian
 [EMAIL PROTECTED] wrote:
 
  Here are some interesting profile results from the threaded profiler.
  First here is the ground work:
  OSG SVN 8482 using VS 7.1 with threading enabled (interlocked config).
  The
  actual client code tested that pushes some stress on osg is our game
 which
  anyone can download here http://www.fringe-online.com/.So I run this
 and
  measure the thread performance using Intel's thread compiler.  So far,
 our
  client code main loop is very similar to how it is in the osg viewer (no
  fancy optimizations).
 
  There are 2 machines I have tested now... I'll post a copy of a different
  message I sent a few days ago here (to keep all info in this thread)
 
  ---snip
  Robert,
  This proposal you mention for 2.6 will it help balance the cpu workload
  against the  gpu I/O bottleneck?
 
  I've been doing some osg performance benchmark research on thread
  synchronization using the Intel Threaded compiler, and so far the results
  are looking really good except for a 26% over-utilization due to
 sleeping. I
  do want to say awesome job to those responsible for threading, the amount
 of
  critical section use looked very good!  All the worker threads also had
 good
  profiling results.
 
  The ultimate test I want to try today deals with an intentional GPU
  bottleneck... where I have a quadcore that pipes graphics out a PCI
 graphics
  card.  If anyone is interested I'll post these test results.  I know now
  that using a quad core there is lack of parallelization (e.g. 25% 85% 15%
  15%), but that is a different battle for a different time.
 
  I do want to get to the bottom of the profiling and determine how well
 the
  workload is balanced against the gpu i/o, and see if there is some
  opportunity for optimization here.
  -snip
 
  Today I have the numbers from the souped up machine with a poor poor pci
  graphics card.  The first thing to note is that the game never exceeded
 18%
  cpu usage!!  When I profiled 65% of the main thread was devoted to
 serial
  time and the bulk of the cpu time was on *this thread* and
  PrintSchedulingInfo [20] thread.  

Re: [osg-users] osgNETDemo

[rpingry]

Thanks,

I had done that originally, but I would get the crash if I was linking to
release OSG from either the debug or release versions of my app.  For the
time being, I link to the debug versions OSG from both my debug and release
versions of my app, which seems to work.  I would of course like to get it
worked out.

So I am not thinking it is a mixture of debug/release, but rather that I am
not linking to some other runtime library properly, like msvcrt*.dll or
whatever.  As I have been porting Managed C++ projects from VS2003 to VS2005
I have been running into issues like this, so I think they might be
related.  We are using this example because we were having some problems
getting osgDotNet to work.  It would have these random memory corruption
kinds of errors.  osgDotNet only links to the release versions of OSG 2.0.
I hope it is not something deeper with the release versions of OSG, but I
imagine more people would have seen it if that were the issue.

-- Rick

On Wed, Mar 19, 2008 at 3:34 AM, Ralph Kern [EMAIL PROTECTED] wrote:

 I guess you have a mixture of debug/release C Runtimes. malloc() and
 free() have very different implementations in debug and release runtime,
 so this would explain why in your stack trace the size=1 from operator
 new() didn't get right through to malloc.

 Always link your debug version against debug OSG and release against OSG
 release libraries.

 regards Ralph

 [EMAIL PROTECTED] schrieb:
  AHA!!!
 
  I found out that the problems I was having are only on the RELEASE
  versions.  When I link to the debug versions of the OSG libraries, all
  seems to work well.  Anyone know why?
 
  -- Rick
 
 
  On 3/18/08, [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]*
  [EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED] wrote:
 
  I just used the latest stable build, OSG 2.2.0, and I got a crash at
  precisely the same point.  I do not think it is a versioning
  problem.  Looking at the call stack, I wonder if there is something
  I am doing wrong with setting up memory, either in the OSG build, or
  in the managed code that uses the unmanaged code.  I am new to
  VS2005 (have been using VS2003 for a long time), but I just followed
  the existing instructions, and everything compiles.
 
  The call stack seems to have a problem with a dynamic cast:
 
kernel32.dll!7c812a5b()
[Frames below may be incorrect and/or missing, no symbols loaded
  for kernel32.dll]
kernel32.dll!7c812a5b()
ntdll.dll!7c9106eb()
msvcr80.dll!malloc(unsigned int size=3765269347)  Line 163 + 0x63
  bytes C
msvcr80.dll!_CxxThrowException(void * pExceptionObject=0x0012ea24,
  const _s__ThrowInfo * pThrowInfo=0x781b55e0)  Line 161 C++
msvcr80.dll!__RTDynamicCast(void * inptr=0xcd010001, long
  VfDelta=0, void * SrcType=0x005cb25c, void * TargetType=0x005cc438,
  int isReference=0)  Line 315 C++
osg25-osgViewer.dll!005a1516()
osg25-osgViewer.dll!005a1a69()
msvcr80.dll!operator new(unsigned int size=1)  Line 59 + 0x8 bytes
 C++
osg25-osgViewer.dll!005aa741()
osg25-osgViewer.dll!005a1bfd()
osg25-osg.dll!1007d866()
[Managed to Native Transition]
osgNETDemo.exe!osgNETDemo::osgNETDemoForm::InitOSG() Line 65 +
  0x18 bytes C++
osgNETDemo.exe!osgNETDemo::osgNETDemoForm::osgNETDemoForm_Load
 (System::Object^
  sender = 0x0012ec40, System::EventArgs^ e = 0x0012ec4c) Line 330 C++
 

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




-- 
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgNETDemo

[rpingry]

One other thing,

When I downloaded the osgNetDemo (It was EXTREMELY helpful, thanks to you
hesicong2005, is that you Ralph?), it was not fully set up in release mode.
It was hooked up to the debug libraries in debug mode, but not hooked up in
release mode at all.  I get the impression that it was not tested against
the release versions of OSG.  Could someone please give it a try and see if
they have the same problems I am seeing in release mode?  Doing so would
either confirm there might be a problem in the release versions of the
libraries, or maybe point me in the direction I am going wrong with a
project configuration file.  We could also provide an update to the
osgCppCLIDemo.rarhttp://www.openscenegraph.org/projects/osg/attachment/wiki/Community/LanguageWrappers/osgCppCLIDemo.rar
file
on the website.

Thanks Again,
-- Rick

On Wed, Mar 19, 2008 at 8:26 AM, [EMAIL PROTECTED] wrote:

 Thanks,

 I had done that originally, but I would get the crash if I was linking to
 release OSG from either the debug or release versions of my app.  For the
 time being, I link to the debug versions OSG from both my debug and release
 versions of my app, which seems to work.  I would of course like to get it
 worked out.

 So I am not thinking it is a mixture of debug/release, but rather that I
 am not linking to some other runtime library properly, like msvcrt*.dll or
 whatever.  As I have been porting Managed C++ projects from VS2003 to VS2005
 I have been running into issues like this, so I think they might be
 related.  We are using this example because we were having some problems
 getting osgDotNet to work.  It would have these random memory corruption
 kinds of errors.  osgDotNet only links to the release versions of OSG 2.0.
 I hope it is not something deeper with the release versions of OSG, but I
 imagine more people would have seen it if that were the issue.

 -- Rick

   On Wed, Mar 19, 2008 at 3:34 AM, Ralph Kern [EMAIL PROTECTED] wrote:

  I guess you have a mixture of debug/release C Runtimes. malloc() and
  free() have very different implementations in debug and release runtime,
  so this would explain why in your stack trace the size=1 from operator
  new() didn't get right through to malloc.
 
  Always link your debug version against debug OSG and release against OSG
  release libraries.
 
  regards Ralph
 
  [EMAIL PROTECTED] schrieb:
   AHA!!!
  
   I found out that the problems I was having are only on the RELEASE
   versions.  When I link to the debug versions of the OSG libraries, all
   seems to work well.  Anyone know why?
  
   -- Rick
  
  
   On 3/18/08, [EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED]*
   [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
  
   I just used the latest stable build, OSG 2.2.0, and I got a crash
  at
   precisely the same point.  I do not think it is a versioning
   problem.  Looking at the call stack, I wonder if there is
  something
   I am doing wrong with setting up memory, either in the OSG build,
  or
   in the managed code that uses the unmanaged code.  I am new to
   VS2005 (have been using VS2003 for a long time), but I just
  followed
   the existing instructions, and everything compiles.
  
   The call stack seems to have a problem with a dynamic cast:
  
 kernel32.dll!7c812a5b()
 [Frames below may be incorrect and/or missing, no symbols loaded
   for kernel32.dll]
 kernel32.dll!7c812a5b()
 ntdll.dll!7c9106eb()
 msvcr80.dll!malloc(unsigned int size=3765269347)  Line 163 +
  0x63
   bytes C
 msvcr80.dll!_CxxThrowException(void *
  pExceptionObject=0x0012ea24,
   const _s__ThrowInfo * pThrowInfo=0x781b55e0)  Line 161 C++
 msvcr80.dll!__RTDynamicCast(void * inptr=0xcd010001, long
   VfDelta=0, void * SrcType=0x005cb25c, void *
  TargetType=0x005cc438,
   int isReference=0)  Line 315 C++
 osg25-osgViewer.dll!005a1516()
 osg25-osgViewer.dll!005a1a69()
 msvcr80.dll!operator new(unsigned int size=1)  Line 59 + 0x8
  bytes C++
 osg25-osgViewer.dll!005aa741()
 osg25-osgViewer.dll!005a1bfd()
 osg25-osg.dll!1007d866()
 [Managed to Native Transition]
 osgNETDemo.exe!osgNETDemo::osgNETDemoForm::InitOSG() Line 65 +
   0x18 bytes C++
 osgNETDemo.exe!osgNETDemo::osgNETDemoForm::osgNETDemoForm_Load
  (System::Object^
   sender = 0x0012ec40, System::EventArgs^ e = 0x0012ec4c) Line 330
  C++
  
 
   ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 



  --
 Check us out at http://fringe-online.com/




-- 
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Out of Memory Error when resizing images

[rpingry]

Ah, yes. that would do it. I am not creating a graphics context at all, just
using the code I showed above.  I can do that (all though it seems
unfortunate.)  Is there a utility already in OSG that provides this
functionality?
Thanks,
-- Rick

On Wed, Mar 19, 2008 at 3:33 PM, Robert Osfield [EMAIL PROTECTED]
wrote:

 HI Rick,

 The scale image function uses glu which requires a valid graphics
 context to be current in the thread you are calling from.  Could this
 be the problem?

 Robert.

 On Wed, Mar 19, 2008 at 6:41 PM,  [EMAIL PROTECTED] wrote:
  Hello All,
 
  I wrote a little application that simply takes as a command line param
 the
  name of an image, a new res, and a new filename.  The program then reads
 in
  the image with osgDB, resizes it, then writes it back out with osgDB.
  (Now
  that I think of it, is there already a quick utility to do this?)
 
  Anyway, I keep getting and error from the resize that says out of
 memory.
  My original image is 2048^2.  The resized image is 1024^2.  The code
 (w/o
  error handling) looks like:
 
 
 
 
 
  osg::ref_ptrosg::Image image = osgDB::readImageFile(argv[1]);
 
  int newRes = atoi(argv[2]);
 
  image-scaleImage(newRes, newRes, image-r());
 
  osgDB::writeImageFile(*(image.get()), argv[3]);
 
 
 
 
 
  Am I doing something wrong?  Is there another utility to do this?
 
  Thanks
 
  --Rick
  ___
   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




-- 
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgNETDemo

[rpingry]

AHA!!!

I found out that the problems I was having are only on the RELEASE
versions.  When I link to the debug versions of the OSG libraries, all seems
to work well.  Anyone know why?

-- Rick


On 3/18/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 I just used the latest stable build, OSG 2.2.0, and I got a crash at
 precisely the same point.  I do not think it is a versioning problem.
 Looking at the call stack, I wonder if there is something I am doing wrong
 with setting up memory, either in the OSG build, or in the managed code that
 uses the unmanaged code.  I am new to VS2005 (have been using VS2003 for a
 long time), but I just followed the existing instructions, and everything
 compiles.

 The call stack seems to have a problem with a dynamic cast:

   kernel32.dll!7c812a5b()
   [Frames below may be incorrect and/or missing, no symbols loaded for
 kernel32.dll]
   kernel32.dll!7c812a5b()
   ntdll.dll!7c9106eb()
  msvcr80.dll!malloc(unsigned int size=3765269347)  Line 163 + 0x63
 bytes C
   msvcr80.dll!_CxxThrowException(void * pExceptionObject=0x0012ea24, const
 _s__ThrowInfo * pThrowInfo=0x781b55e0)  Line 161 C++
   msvcr80.dll!__RTDynamicCast(void * inptr=0xcd010001, long VfDelta=0,
 void * SrcType=0x005cb25c, void * TargetType=0x005cc438, int isReference=0)
 Line 315 C++
   osg25-osgViewer.dll!005a1516()
   osg25-osgViewer.dll!005a1a69()
   msvcr80.dll!operator new(unsigned int size=1)  Line 59 + 0x8 bytes C++
   osg25-osgViewer.dll!005aa741()
   osg25-osgViewer.dll!005a1bfd()
   osg25-osg.dll!1007d866()
   [Managed to Native Transition]
   osgNETDemo.exe!osgNETDemo::osgNETDemoForm::InitOSG() Line 65 + 0x18
 bytes C++
   
 osgNETDemo.exe!osgNETDemo::osgNETDemoForm::osgNETDemoForm_Load(System::Object^
 sender = 0x0012ec40, System::EventArgs^ e = 0x0012ec4c) Line 330 C++


 Thanks Again
 -- Rick


  On Tue, Mar 18, 2008 at 2:30 AM, hesicong2006 [EMAIL PROTECTED]
 wrote:

   I wrote the osgCppCLIDemo.rar. I use lastest OSG SVN version, you
  should try upgrade your OSG.
 
 
  [EMAIL PROTECTED] wrote:
 
  Hello All,
 
  I have been working with Phil Tessier on some work using OSG in a
  managed code environment.  We tried using OsgDotNet, but we had some
  problems with that, and others on this list recommended we use C++/CLI
  directly to wrap just what we need form OSG directly, and there is an
  example provided on the language wrappers page (osgCppCLIDemo.rar).  I
  was able to get that compiled, but it crashes with a __RTDynamicCast
  exception deep within osgViewer.dll.   The last thing I can see in the
  call stack is in the InitOSG() function, in the line that uses
  osg::GraphicsContext::createGraphicsContext(traits.get());
 
  The call stack looks funny to me, because it calls osg.dll, and then
  osgViewer.dll.  I am using OSG version 2.0 (because it is compatible
  with OsgDotNet) and Visual Studio 2005.  Perhaps I need to upgrade OSG?
 
  Thanks,
  -- Rick
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 


 --
 Check us out at http://fringe-online.com/




-- 
Check us out at http://fringe-online.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgNETDemo

[rpingry]

Hello All,

I have been working with Phil Tessier on some work using OSG in a managed
code environment.  We tried using OsgDotNet, but we had some problems with
that, and others on this list recommended we use C++/CLI directly to wrap
just what we need form OSG directly, and there is an example provided on the
language wrappers page (osgCppCLIDemo.rar).  I was able to get that
compiled, but it crashes with a __RTDynamicCast exception deep within
osgViewer.dll.   The last thing I can see in the call stack is in the
InitOSG() function, in the line that uses
osg::GraphicsContext::createGraphicsContext(traits.get());

The call stack looks funny to me, because it calls osg.dll, and then
osgViewer.dll.  I am using OSG version 2.0 (because it is compatible with
OsgDotNet) and Visual Studio 2005.  Perhaps I need to upgrade OSG?

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

[osg-users] OsgDotNet

[rpingry]

Hello All,

We are using OsgDotNet and noticed a couple of things we would like to ask
about.

1.  We noticed that the quat multiply is not exported in .NET.  We saw that
this was because of the OsgIntrospection not properly exporting some of the
overloaded operators, so there are probably other ones besides quat
multiply.  We were going to go ahead and implement it ourselves, but I
wanted to see if there was some standard way people were using to provide
for themselves these kinds of operators.

2.  We have some code that was written in straight C++ and OSG, building
some scene graphs we would like to include.  We WERE using Managed C++ and
our own OSG kinds of wrappers to make that interop work. Now we are moving
over to OsgDotNet and we were looking for a way to wrap stuff written in
C++.  Any way to do that?

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