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

[rpingry]

Oh, and about being apologetic;  I have seen posts on the forum where people
are grousing that make me feel that people are just not thankful for how
great this all is.  I never wanted anyone to think I am not grateful for OSG
(or your time for trying to explain it to me).  I can see that there most be
some kind of posting etiquette in an open source forum that would allow
people to express questions, ideas for improvement, and concerns without
seeming ungracious.


On Wed, Jun 3, 2009 at 10:09 AM,  wrote:

> > I even gave you a batch file that would do some of that automatically,
> and it's easy to supplement that with a couple more commands that will do it
> all automatically (see below).
>
> You did?  Maybe I missed it.  Could you please send it again?  This does
> not look nearly as hard as I had imagined.  Perhaps I was making my
> ignorance of how to do it this way scare me away from trying it.  Thanks for
> being patient with my reticence.
>
>
> As a starting point, you could just do something like:
>
> :: remove all DLLs from SVN
> svn rm third-party/OSG/bin/*.dll
> :: remove osgPlugins-x.y.z directory from SVN
> svn rm third-party/OSG/bin/osgPlugins-*
> :: copy the new DLLs and osgPlugins-x.y.z directory
> xcopy osg-staging-area/bin/*.dll third-party/OSG/bin /s
> :: add new DLLs and osgPlugins-x.y.z directory to SVN
> svn add third-party/OSG/bin/*.dll
> svn add third-party/OSG/bin/osgPlugins-*
> :: commit (or do it from TortoiseSVN after running this batch file
> :: up to and including the previous two commands)
> svn ci -m "New version of OSG binaries" third-party/OSG/bin
>
>
>
>
___
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 even gave you a batch file that would do some of that automatically, and
it's easy to supplement that with a couple more commands that will do it all
automatically (see below).
You did?  Maybe I missed it.  Could you please send it again?  This does not
look nearly as hard as I had imagined.  Perhaps I was making my ignorance of
how to do it this way scare me away from trying it.  Thanks for being
patient with my reticence.


As a starting point, you could just do something like:

:: remove all DLLs from SVN
svn rm third-party/OSG/bin/*.dll
:: remove osgPlugins-x.y.z directory from SVN
svn rm third-party/OSG/bin/osgPlugins-*
:: copy the new DLLs and osgPlugins-x.y.z directory
xcopy osg-staging-area/bin/*.dll third-party/OSG/bin /s
:: add new DLLs and osgPlugins-x.y.z directory to SVN
svn add third-party/OSG/bin/*.dll
svn add third-party/OSG/bin/osgPlugins-*
:: commit (or do it from TortoiseSVN after running this batch file
:: up to and including the previous two commands)
svn ci -m "New version of OSG binaries" third-party/OSG/bin
___
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/
>  

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,  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]

> 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]

> 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]

> 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]

> 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 "\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]

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/
> ...somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll
> ...somepath/bin/osgPlugins-x.y.z/

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 wrote:

>
> 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" 
> Cc: "Rick Pingry" 
> 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/
> .somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll
> .somepath/bin/osgPlugins-x.y.z/
> "
>
> 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, and then running
>  into an application crash (because of ABI changes between 

[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

Re: [osg-users] Fw: [osg-submissions] [osgParticle]osgParticleParticleSystem andModularEmitterin differentcoordinate systems

[rpingry]

Hi Thomas,

We have been seeing some ghost particles here and there.  Since the
September updates, we have been seeing the particles offset in space as you
had described, so your notes have really helped.  To get my particle
"explosions" working, I followed the osgparticleeffects example.  These were
working well until the September update.  The osgparticleeffects example is
not showing the problem, but I am sure that is just because the particle
effects are just children of the root node, which is never moving.  This
example, and our code, uses osgParticle::ExplosionEffect, among other
things.

 So our scene graph looks something like this:

Group--+
  |
  +--MatrixTransform 1--+
  | |
  | +--Geode of main Body
  | |
  | +--osgParticle::ExplosionEffect
Emitter?)

  |
  +--Geode for particles--+
  |

+--osgParticle::ExplosionEffect.getParticleSystem()

So osgParticle::ExplosionEffect inherits from ParticleEffect which inherits
from Group.  It looks like ExplosionEffect has a ModularEmitter and a
FluidProgram as members.  I am just still learning, so I am not sure what a
Program does.

getParticleSystem() returns a ParticleSystem which inherits from Drawable.
I am not sure where the ParticleSystemUpdater you mentioned fits into this.


James has been tracking where exactly the change is.  We could just undo the
little change James found made locally and fix it for us, but we figure it
would be best to make it better for everyone, and work out how we can keep
the fixes in play.  I would not be surprised if there is something we were
doing wrong as well (wouldn't be the first time).

Thanks,
-- Rick



So the osgParticle::ExplosionEffect inherits from

On Fri, May 22, 2009 at 3:14 PM, James Killian wrote:

>
> - Original Message -
> From: "Jolley, Thomas P" 
> To: "OpenSceneGraph Users" 
> Sent: Friday, May 22, 2009 3:45 PM
> Subject: Re: [osg-users] [osg-submissions]
> [osgParticle]osgParticleParticleSystem andModularEmitterin
> differentcoordinate systems
>
>
> Hi James,
>
> The ParticleSystem is derived from osg::Drawable and
> ParticleSystemUpdater is derived from osg::Node.
>
> How are you creating the graph with particles?  If you are using clone
> you may have trouble with ParticleSystemUpdater (see my recent
> submission).  Also, if you don't clone ParticleSystems and get the links
> between ModularEmitter, Geode, and ParticleSystemUpdater correct you may
> get "ghost" particles.
>
>
>
> 
>
> From: James Killian [mailto:james_kill...@hotmail.com]
>
>
>
>
> Sorry that we are so late to chime in on this thread, but I'd
> like to post a response to the content presented here in hopes to help
> others, and perhaps fix code as well.
> Rick is the original author of the client particle system code
> we use for our game.  I have passed this thread to him and here is his
> response:
>
> Rick:
> As for the particle system structure, mine is arranged like the
> last one on that email you showed me:
>
> Group--+
>   |
>   +--MatrixTransform 1--+
>   | |
>   | +--Geode of main Body
>
>   | |
>   | +--Modular Emitter
>   |
>   +--Geode for particles
>   |
>   +--ParticleSystemUpdater
>
>
>
>
> Except I think he had a typo.  The ParticleSystemUpdater, if I
> understand it correctly, is a Drawable, so it is actually a child of the
> Geode.  The one that I have is a ParticleSystem.  Perhaps I am wrong and
> the PartilceSystemUpdater is something else.  Anyway, mine looks like
> this right now:
>
> Group--+
>   |
>   +--MatrixTransform 1--+
>   | |
>   | +--Geode of main Body
>   | |
>   | +--ParticleEffect (Modular
> Emitter?)
>
>   |
>   +--Geode for particles--+
>   |
>   +--ParticleSystem
> (ParticleSystemUpdater?)
>
>
>
> So perhaps there is something else to look at here.  We could
> also just make the little fix you found for the time being and be done
> with it.  Perhaps we should shoot off an email in response and ask the
> question of the OSG community?
>
>
>
>
>
>
>
>
> 
> 
>
>
> > ___
> > 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] 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,  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] 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] 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

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

[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] 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

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] 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

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] 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

[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] 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] 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]

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/
<>___
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] 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 wa

[osg-users] Amount of texture memory used

[rpingry]

Hello All,

Is there a way to find out how much texture memory is being used?  We are
finding that keeping texture memory in check is critical to the performance
of our game, depending of course on how much memory the card has.

Thanks

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

[osg-users] OSG Training?

[rpingry]

Hello All,

We are looking for some opportunities to get some OSG training.  I saw that
Skew Matrix was doing a class in Paris, but we would like to stay state-side
if we could.  I have already attended an intermediate class from Andes
Engineering, but there are some more people in the group, and I could always
use a refresher and/or a chance to go deeper.  Perhaps there are some people
that could do some consulting with us on our site (San Antonio)?

Thanks
-- Rick
___
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_ptr 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

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

[rpingry]

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_ptr 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

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.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]
> > > *
> > > <[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/
>



-- 
Chec

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]
> > *
> > <[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]

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

Re: [osg-users] osgNETDemo

[rpingry]

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/
___
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