Re: [osg-users] Future of osgIntrospection + genwrapper
Hi Robert, Given the repeated problems I face, and the lack of active usage of osgIntrospection out in the community I am ready to move osgIntrospection out of the core. It has long been a real maintenance problem for me and I really know my own productivity will improve with moving osgIntrospection out of the core. I totally agree with this. If the wrappers were moved out of the core, it would bring two benefits: 1) changes to OSG will not cause a part of OSG that is not maintained and complicated to stop building. 2) it will be easier to give over the reins of maintaining the wrappers to someone else. Potentially they could say svn rev X of the wrappers build against svn rev Y of OSG, and then update them at their leisure as they need the wrappers to support more recent revisions of OSG. So I think it would be a good idea, and would also go toward the goal of lightening the load on your shoulders. Go for it :-) 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] Inline shaders in .osg files have extra newline in each quoted line
Hi Robert,
This fixes a small problem in .osg files, where inline shaders would
have an extra newline per line:
Shader {
type VERTEX
code {
#version 120
#extension GL_EXT_geometry_shader4 : enable
uniform mat4 osg_ViewMatrixInverse;
...
This is because the shader is being written directly from the string
(_shaderSource) to the .osg file, and that string contains newlines.
osgDB::Output::wrapString() is called from
src/osgWrappers/deprecated-dotosg/osg/Shader.cpp :
Shader_writeLocalData(). I made the change to
osgDB::Output::wrapString() because I think in no case would we want to
keep those newlines when writing a wrapped string, because the wrapping
itself adds a newline after each closing quote of each line anyways. So
the same shader above now looks like:
Shader {
type VERTEX
code {
#version 120
#extension GL_EXT_geometry_shader4 : enable
uniform mat4 osg_ViewMatrixInverse;
...
I also made the corresponding change for the new .osgt plugin.
AsciiOutputIterator::writeWrappedString() is called from
src/osgWrappers/serializers/osg/Shader.cpp : writeShaderSource(). Again
the change will take effect for any wrapped string. I have tested this
and it fixes it too.
The reading already adds a newline to each line of code read from the
.osg/.osgt file, so the shader code we read will be what we want. The
only thing that didn't work on reading was that empty lines were
discarded in the old deprecated .osg plugin. The change to
src/osgWrappers/deprecated-dotosg/osg/Shader.cpp fixes that.
So Output.cpp goes in src/osgDB, AsciiStreamOperator.h goes in
src/osgPlugins/osg, and Shader.cpp goes in
src/osgWrappers/deprecated-dotosg/osg/
By the way, is there a way of commenting out lines in the old or new
.osg/.osgt formats?
Thanks, and sorry for being verbose.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osgDB/Output
#include osgDB/Registry
#include osgDB/FileNameUtils
#include osg/Notify
#include sstream
#include stdio.h
#include string.h
using namespace std;
using namespace osgDB;
static osg::ApplicationUsageProxy
Output_e0(osg::ApplicationUsage::ENVIRONMENTAL_VARIABLE,OSG_WRITE_OUT_DEFAULT_VALUES,
ON | OFF);
Output::Output()
{
init();
}
Output::Output(const char* name) : osgDB::ofstream(name)
{
init();
_filename = name;
}
Output::~Output()
{
}
void Output::init()
{
_indent = 0;
_indentStep = 2;
_numIndicesPerLine = 10;
_pathNameHint = AS_IS;
_outputTextureFiles = false;
_textureFileNameNumber = 0;
_outputShaderFiles = false;
_shaderFileNameNumber = 0;
_writeOutDefaultValues = false;
const char* env = getenv(OSG_WRITE_OUT_DEFAULT_VALUES);
if (env)
{
_writeOutDefaultValues = strcmp(env,ON)==0;
}
}
void Output::setOptions(const Options* options)
{
_options = options;
}
void Output::open(const char *name)
{
init();
osgDB::ofstream::open(name);
_filename = name;
}
// Comment out to avoid compile errors under new compilers, the int mode
// is now a replaced by a class to wrap the mode.
// This method is not used right now to hopefully nobody will miss it...
// Jan 2002.
// void Output::open(const char *name,int mode)
// {
// init();
// ofstream::open(name,mode);
// _filename = name;
// }
Output Output::indent()
{
for(int i=0;i_indent;++i) *this' ';
return *this;
}
void Output::moveIn()
{
_indent += _indentStep;
}
void Output::moveOut()
{
_indent -= _indentStep;
if (_indent0) _indent=0;
}
std::string Output::wrapString(const char* str)
{
if (!str) return std::string(\\);
return wrapString(std::string(str));
}
std::string Output::wrapString(const std::string str)
{
std::string newstring;
newstring += '';
for(unsigned int i=0;istr.size();++i)
{
if (str[i]=='\\')
{
newstring += '\\';
newstring += '\\';
}
else if (str[i]=='')
{
newstring +=
Re: [osg-users] managing views in composite viewer...
Hi Shayne, My question is, is adding and removing the views during runtime the way to go or is there a more efficient/elegant way of turning my views on and off? Is there an equivalent of a switch node for managing views in a composite viewer? To add/remove views at runtime you have to stop threading in the viewer, which is a pretty major disruption. Instead, you can just set the view's camera's node mask to 0. view-getCamera()-setNodeMask(0) This means the camera won't be traversed and thus it won't draw anything, which is what you want. When you want to re-enable the view, set its node mask to 0x. view-getCamera()-setNodeMask(0x) Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ScreenShot File name
Hi Danny, I would like to do the following: 1) To disable static counter on the output file name and alway overwrite the last file. 2) Save this file in custom path on hard drive. How can set these option to ScreenCaptureHandler? If you look at the osgViewer/ViewerEventHandlers header, you'll see the ScreenCaptureHandler constructor takes an optional CaptureOperation: ScreenCaptureHandler(CaptureOperation* defaultOperation = 0, int numFrames = 1); You could implement your own CaptureOperation if you wanted, it's really simple, but the one concrete CaptureOperation that is provided should do what you need just by changing some default parameters. Check the ScreenCaptureHandler::WriteToFile class: WriteToFile(const std::string filename, const std::string extension, SavePolicy savePolicy = SEQUENTIAL_NUMBER); So you see, by constructing a WriteToFile with your desired filename (and path) and setting savePolicy to OVERWRITE instead of SEQUENTIAL_NUMBER, you'll get what you want. Then just pass this WriteToFile to the ScreenCaptureHandler constructor. I designed WriteToFile to cater to the most common needs, and your needs seem to fit these. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] using osg 2.9.7 and manipulators
Hi René, The re-factored manipulators do make the implementation simpler. I made some subclasses for customization ( and a more model/view like approach ). There are only a few small remarks regarding the manipulators. The line segment intersectors don't intersect with the cylinders when viewed from the side. I used a polytope intersector instead and had to reimplement the entire handle function in the subclass. Interesting how different people run into the same problems but find different solutions. We also wanted the rotation manipulators to be able to be picked from the side of the cylinders, and our solution was to make the derived class generate an invisible cylinder that had a larger thickness (just for picking). But this caused the problem that the rotation code assumes that the picking of the cylinder will happen from the top or bottom, and when it happens on the side sometimes the rotation becomes unpredictable (dragging the mouse by 1 pixel makes the object rotate more than 360 degrees sometimes). We worked around this by capping the maximum rotation speed, but it's not ideal. But then again, using a polytope intersector would likely be too slow for us. So I think we'll keep our present solution. My point is that our solution was probably also easier to adapt to the refactoring of the manipulators that Robert did. I just had to change 3 lines of code and we were up and running on 2.9.7. There are also a lot of notifications: osgManipulator::computeNodePathToRoot(,) taking first parent path, ignoring others. is this because the scene is visualized in multiple viewers? I think it's probably because of the way the old manipulator architecture had to have the Dragger (or is it Selection, it's been too long since I did this) as parent of the geometry you wanted to manipulate, and now it's not necessary. I'm not sure though. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and negative renderbin?
Hi all, I just wanted to mention for the sake of closing this thread, that the problem was caused by the shadows and the skydome both having a texgen state on the same texture unit. This caused two things I could observe: 1. No shadows at all when the skydome's renderbin was set to a negative number (I still don't understand that one) 2. When the skydome was in a positive-numbered renderbin, shadows were visible on some objects but not on others (so shadow application was wrong, which helped Wojtek to suggest a problem with possibly conflicting texgens. Apparently, it's been noted a long time ago that when two texgens are on the same texture unit, no matter the hierarchy, they will conflict (you might get the result of one when you expect to get the result of the other on your node). In my case, the texgen for the shadows is applied when traversing a node close to the top of the scene graph (the ShadowedScene), and the skydome is lower in the graph, but should never have shadows applied to it, so there is no conceptual conflict - they could share the same texture unit, if the lowest texgen (i.e. the last one traversed) took precedence. This is not the case. I could see a problem if some node needed a texgen PLUS shadows (i.e. two effects that both require a texgen), then obviously you need both and they can't share the same texture unit. But that's not my case. Is there any way to fix this so that the lowest texgen takes precedence? I realize TexGen is positional state, but there must be a way... 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] Shadows and negative renderbin?
Hi all, I was wondering if someone has had problems with objects which are in negative-numbered renderbins with shadows (in my case, osgShadow::LightSpacePerspectiveShadowMapVB). I had set up my skydome in renderbin -100 to make really sure it was rendered before other things, and set its node mask so it would not be included in shadow traversal - setNodeMask(getNodeMask() ~CAST_SHADOW ~RECEIVE_SHADOW) but for some reason it seems like it was still being used for the bounds of the shadow map, because shadows did not show up on near objects and were very aliased far out. I isolated the problem to the renderbin setting, and setting it to a positive value fixed the problem - the skydome is not considered at all for the shadows now. I'm surprised the renderbin would have any effect. I haven't delved into the code but if someone (Wojtek? :-) ) could explain this or provide some pointers I would appreciate... Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and negative renderbin?
Hi again, I was wondering if someone has had problems with objects which are in negative-numbered renderbins with shadows (in my case, osgShadow::LightSpacePerspectiveShadowMapVB). I should have mentioned that this is using the view dependent shadow classes from OSG 2.8.x backported to OSG 2.6.x, so perhaps I'm asking for trouble. Any semi-recent changes to the code aren't being used. I'll try compiling our sim using OSG SVN and see if it makes a difference. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and negative renderbin?
Hi Wojtek, MinimalShadowMap::ViewData::computeShadowReceiveingCoarseBounds() is good place to start looking. Check what are the dimension of returning volume. Good hunting ;-) Thanks for the hint. I'll look there. In the mean time I did more testing and found that even now that I've changed the renderbin to a non-negative number, the skydome (which I remind you is set to NOT cast NOR receive shadows) still interferes with shadows. From some angles, when the skydome is active, the shadows on the crane (our main object) turn all black. If I disable the skydome then the shadows are correct. The turning on and off of the skydome is just switching the node mask of its root node between 0 and ( ~CAST ~RECEIVE) which are single-bit masks. So I really think that there is somewhere that's traversing the skydome where it shouldn't, and setting the mask to 0 makes it really not traverse it... I'll check. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and negative renderbin?
Hi Wojtek, I don't think such backporting should be an issue. Practically recent fixes were cosmetics, improved precision in first iteration of shadow camera projection setup and better handling of spot lights. One more thing came to my mind: StandardShadowMap forces RenderBin override on all nodes rendered into shadow map. Maybe this somehow affects your case ? You may comment RenderBin override and see if it changes anything... I've tested with SVN OSG and it didn't change anything, and the forcing of renderbin in StandardShadowMap didn't change anything either. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and negative renderbin?
Hi Wojtek, Look inside the MinimalShadowMap::ViewData::computeShadowReceiveingCoarseBounds method. ComputeBoundingBox visitor has node mask set to cast shadow bitmask before visitor is run on ShadowedScene graph. I did not mean more than this. Hmmm, changing it to use the ReceivesShadow mask didn't improve my problem of the shadow changing when I enable/disable the skydome, it's still there. Plus, it made the shadow aliasing worse which is surely a problem of not setting the receives shadow flag to false everywhere we should... So in our case it also works by accident the way it is. ;-) If you decide to fix it let me know so I can fix our scenarios :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi all, Back from vacation, glad to see progress has been made on this thread. A few comments: o Porting the website for MediaWiki, are there any tools that might help this? This page on the official MediaWiki site has one pointer: http://www.mediawiki.org/wiki/Manual:Importing_external_content#Converting_TracWiki_format_to_MediaWiki_format Unfortunately the tool it lists requires one to go to each page on the Trac wiki, click Edit, copy-paste the text to a text file, run the script on that file to convert to MediaWiki syntax, and then make a page on the MediaWiki wiki with the output of the script. I'm pretty good with Perl scripts and WWW::Mechanize to automate such things so I could probably modify it to take in a list of pages (or read the list of pages from an All pages listing on the Trac wiki) and convert them all and post them to the MediaWiki wiki automatically under the same names. o No ones added there name to list of volunteers yet: http://www.openscenegraph.org/projects/osg/wiki/Community/Maintainers I've just done so, I had mentioned my willingness to be co-responsible for osgManipulator and possibly osgWidget in this thread but no one placed my name there (which is OK). BTW, the list of possible parts of the code base that others could take responsibility for was missing osgWidget, dunno if it was just an oversight or if there was a reason? Jeremy Moles seems to be keeping a low profile, and he mentioned he wanted to do a big redesign of osgWidget in the future, but I'm thinking if we have someone (me, someone else) to support and improve the current classes there's no reason why his new functionality couldn't coexist with it, and I rather like it how it is :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi Robert, all, OK, so I leave for the night and come back and there are tens of new messages in this thread, perhaps I should work in GMT hours so I'd be up during the same hours as many of you! :-) I think the discussion is rolling nicely, we've got a few good leads on what to improve. Here are my comments, I'll keep it brief. _Distributed version control:_ I'm not sure this is the silver bullet some of you make it to be, but it might improve the submission process, since it's a bit like giving everyone commit access but then letting Robert pick and choose what he wants to bring into the baseline. The learning curve might be steep, but I think we'll gain a lot in the long run. But I agree with Robert, even if Jose Luis can set this up quickly, we shouldn't make the move officially (if Robert decides he wants to) until the next stable release is out. An infrastructure change like this should not hold up the next stable release. It might be nice to make an unofficial import from svn to git (for example) so Robert and others can play with it before then, though, to get a feel for how it might work. _Responsibility for parts of the code base:_ In the interest of getting the ball rolling, I volunteer to take partial responsibility of osgManipulator (since we use it) and osgWidget (since I find it a really nice part of OSG). I say partial because I'd like to ask at least one other person to volunteer with me. Anyone, really. I just don't want to be the only choking point for this. For example, say I'm on vacation I don't want submissions to be held up while I am. (Concrete example: in case someone replies to this message tomorrow, I'll be on vacation starting tomorrow for a week, wednesday to wednesday, no access to my e-mails, so don't ask why I don't reply :-) ) _Server resources:_ I agree that Trac is more than we need, and seems heavy on the server too. I would vote for MediaWiki (so much more pleasant to work with, I use it for my own site) plus svn and Websvn (or some equivalent web interface for git/mercurial if we change). I think that will be easier to manage and will give us the services we need without the extra cruft we don't. Plus MediaWiki scales well to number of requests, and Websvn is very lightweight so I think it will too. But once again, let's wait till after the next stable release. _Automated testing:_ Would be nice, we already have some stuff in place for plugins though it's not really used in an automated fashion yet, and it would be nice to extend the idea to the examples. But nevertheless, direct testing (many eyeballs) will always be the best thing. _Direct e-mails:_ Just a note in passing, I think you could easily set up a rule in your gmail inbox that automatically replies to anyone not in your address book or sending to the mailing lists, telling them to post to the mailing list if it's an OSG-related question. That would free up some of your time from these time leeches that just want to get direct answers without bothering to subscribe... Here's to hoping we can get through this crisis stronger than ever, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi Mathieu, I'm testing svn import into github at the moment, it might take some time (if it succeeds) importing those 11000 revisions : http://github.com/mathieu/OpenSceneGraph Nice, I'll check it a few times to see if it finishes. Then, any suggestions of how to go about checking it out? Tutorials on the workflow, tools I should download (I'm on Windows), etc? I've tested also their wiki support for the main page. The result is that it is a poor wiki service, but maybe enough : http://wiki.github.com/mathieu/OpenSceneGraph/ I'll check it out a bit more later today. However, I wonder, is there a downside to putting all our stuff on github? I honestly don't know, I'm asking... I guess if we can host the whole project on some service that has some guaranteed availability, or at least is used by many other projects so has a high chance of being available all the time, it might reduce the amount of management we need to do. All we would need on the real openscenegraph.org would be a redirect to that wiki, and the files/downloads section (for releases and stuff). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi again Mathieu, I'm testing svn import into github at the moment, it might take some time (if it succeeds) importing those 11000 revisions : http://github.com/mathieu/OpenSceneGraph Nice, I'll check it a few times to see if it finishes. I just noticed the github pricing, this is what they say for Open Source projects: *Open Source* Free! Unlimited Public Repositories Unlimited Public Collaborators 300 MB Disk Space [1] [1] The 300MB is a soft limit setup to prevent abuse of the service. If your open source project needs more space, email us, we're happy to provide it. So I think that could work. I'm pretty sure the repo will bust the 300MB though, especially with all the history, and the OpenSceneGraph-Data, and everything... But as noted above that shouldn't be a problem. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-GPU on Windows 7, second window is black when the first window has focus?
Hi Raymond, I get a black window on my 2nd monitor when I use osgviewer without arguments (and other programs that I tried). The second window is rendered ok when the first window does not have focus, i.e. when another program is on top of it. I get the same on Windows 7 64 bit with nVidia 196.21 drivers. Not sure what causes this. I tried playing with the Multi-display performance mode setting in the nvidia control panel, but no setting made any difference. I hadn't noticed this because I always start up osgviewer fullscreen on my second monitor only, or in a window. So I'm not sure when that started. It would be interesting to backtrack in the drivers to see when it started, but I don't have time to do that today. It might also be a Windows 7-specific issue, because I remember it working fine on Vista on recent drivers and I just upgraded to 7 a week ago on my work machine. We also can't immediately rule out some problem with OSG causing this. Even if 2.8.x and 2.2.0 have the same behavior, perhaps it's something we've always been doing wrong but only recently have the drivers become sensitive to it. That's always a possibility. If anyone else has any feedback (confirmations on their system, or results with other versions of drivers) please post in this thread. Since we're ramping up towards a stable release it would be nice to find out whether this is caused by OSG or drivers or OS. I can also submit a bug report to nVidia, but I'd prefer doing a bit more exploration on our side first. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi Mathieu, Quick Start Guide :-) Yes, thanks! :-) If your the of TortoiseSVN sort I am :-) thanks. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-GPU on Windows 7, second window is black when the first window has focus?
Hi Raymond, I hadn't noticed this because I always start up osgviewer fullscreen on my second monitor only, or in a window. And about this, I think this new problem might be related to the weird behavior I and others have noticed with OSG apps before: - Start fullscreen on screen 0 : the app will show up, then the screen will turn black for a few seconds and then it will come back (annoying but it's ok after a few seconds). - Start fullscreen on screen 1 : the app shows up and stays that way (that's how we'd like it to behave every time!) - Start fullscreen on both screens : the app shows up on both screens, then the screen turns black for a few seconds, and the image comes back on the first screen but the second one stays black (that's the new problem, before the image came back on both screens after turning black). So I think I'll submit a bug to nVidia in any case. It would be nice to have them look at it and see if there's a problem in their drivers that's causing this. I haven't seen this behavior on other apps (games for example) but those are generally hard-coded to work on only one screen (the first)... If anyone with OpenGL knowledge would like to code up a quick straight OpenGL app that can start a graphics context in fullscreen and we can specify which screen or both, it would be interesting to see if this is reproducible then. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi Chris, I am very hesitant about changing our wiki and VC hosting. While what we have is not perfect, it works 99% of the time, and is mostly under our control. Changing to a new platform involves MORE work, not less, and we don't really know the reliability and performance of the new platform. This worries me greatly. We've had a lot of bad situations before and what we have now, while imperfect, is still closer to perfect than anything in the past, and I'd rather not risk going backwards. I'd normally agree with you wholeheartedly, but we've had more server problems in the last few months than in the year or two before, and that's what makes me think that the current platform might not be up to the task of supporting the amount of traffic we ask it to. Plus, control is good but an established service might have guarantees of reliability, redundant backups/load-sharing, etc. which would be too much to manage ourselves. I'm not saying we should go and change everything, just that we might want to investigate and that another solution might work just as well while offering some guarantees. We can investigate without committing ourselves to anything. We have some time anyways, if we want to wait until after the next stable release to decide and make any move we decide on... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.9.7 developer release tagged
Hi Robert, After a long slog tending to some very meaty submissions, and similarly taxing bug fixes/feature refinements, and can finally say that 2.9.7 is here. Yay! A bit late to the game this time, but I just wanted to tell you that I've compiled one of our simulators with OSG 2.9.7 and apart from the ObserverNodePath::empty() method and a few tiny problems with osgManipulator (we were still using 2.6.0 before your refactoring that removed the need for CommandManager) everything compiled and ran fine. I've also compiled our content creation application suite and that worked fine as well. We used a modified version of CompositeViewer which wasn't ifdeffed correctly, and that was all. Thanks again for all your hard work keeping the API stable while still getting issues resolved and adding new features, it really does make our lives easier and is really appreciated. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi Chris, I believe we could introduce a issue ticket tracker without cost to you. I'd be curious to hear input from other significant OSG developers about whether they use an issue tracker in their work, if they find it effective and useful, and if they believe it would be similarly useful to OSG. My opinion is that on a large project, bug tracking is only effective if you have a dedicated crew (one or more people) doing the bug triage and assignment. If we don't have that level of involvement from others to make sure duplicates are marked, invalid bugs are closed and priorities are assigned, then the workload on Robert will increase. Unless we have a few people who want to commit to doing that and stay in that post for a reasonable amount of time, a bug tracking tool will just become a dump of issues which will be impossible to sift through and make sense of. However, the flipside is that it can be really effective with the right bug wranglers. Once again I point out the Mozilla project as one great example, and there are many more. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multi-GPU on Windows 7, second window is black when the first window has focus?
Hi Raymond, Is there a way to let the osg open just 1 window that spans accross the 2 monitors? You can modify osgviewer to create the context in any way you like. By default when using run() it will call one of the setUpView*() methods, in this case setUpViewAcrossAllScreens(). You can check out that code to see. In your case you'd want to set the traits to have decorations off, origin at (0,0) and size = (w0+w1, h0) for example. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi Paul, I'm top-posting because I totally agree with all your points. You'll notice I replied to all suggestions, whether they involve changes in process or tools or infrastructure. Any of those might help, and the total gain we need might not come from any one solution but from a combination of solutions whose gain alone would have been less interesting. I think as a community we have enough people to be able to investigate many things at once. What we need to do is to investigate instead of *talking* about investigating... Because in many cases predicting the learning curve is very hard. And people need to be objective and see the downsides as well as the good points. J-S On 2/23/2010 3:45 PM, Paul Martz wrote: Jean-Sébastien Guay wrote: Hi Chris, I am very hesitant about changing our wiki and VC hosting. While what we have is not perfect, it works 99% of the time, and is mostly under our control. Changing to a new platform involves MORE work, not less, and we don't really know the reliability and performance of the new platform. This worries me greatly. We've had a lot of bad situations before and what we have now, while imperfect, is still closer to perfect than anything in the past, and I'd rather not risk going backwards. I'd normally agree with you wholeheartedly, but we've had more server problems in the last few months than in the year or two before, and that's what makes me think that the current platform might not be up to the task of supporting the amount of traffic we ask it to. Plus, control is good but an established service might have guarantees of reliability, redundant backups/load-sharing, etc. which would be too much to manage ourselves. I'm not saying we should go and change everything, just that we might want to investigate and that another solution might work just as well while offering some guarantees. We can investigate without committing ourselves to anything. We have some time anyways, if we want to wait until after the next stable release to decide and make any move we decide on... I'm in favor of investigation, especially if that investigation doesn't further tax Robert. But I do have concerns similar to Chris's. Back when MS came out with .NET, there was a well-circulated blog speculating that MS's strategy was to change the API every few years just to slow down all of its competition as they came up to speed on a new development environment. I don't know whether the blog was intended as humor or not, but new APIs and new tools do require spin up. There's a reason that all cars have steering wheels year after year after year, and no one ever replaces it with a joystick, for example. What we're discussing here is changing the VCS, changing the wiki, and setting up automated testing. How much work will all this actually take, including spin up time by those of us in the community already familiar with the existing tools? Will the new tools have a net reduction on our workload, or a net increase? Will these tools address the root cause of the issues we face? What _is_ the root cause of the issues we face? These are the core questions we need to examine while investigating these tools. What is really the most effective way for us to increase our productivity: new tools, like these? Or some other solution? What gets us the most bang for the buck? The OSG management issues we face are big. If we suspect the new tools will not have a sizable impact on these issues, then we should consider alternatives. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.9.7 developer release tagged
Hi Robert, After a long slog tending to some very meaty submissions, and similarly taxing bug fixes/feature refinements, and can finally say that 2.9.7 is here. Yay! Yes Yay! Congrats and thanks for all your hard work, hopefully this is the start of the steady ramp up to 2.10/3.0! J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn trunk build broke
Hi Robert, The fact is that right now, there's one person with commit access. Errr no. This is not fact. There are several developers with commit access to svn/trunk and svn/branches. In the case of svn/trunk those with commit access are for specific portions that they are the lead author to. You know full well I meant commit access to the core on svn trunk. That's the main point right now. I will state again. svn access does not scale like testing and debugging does. You can't scale up commit access and retain quality, consistency and productivity. Might I suggest reading a text like the Mythical Man Month will give you a few pointers about the delicate balance of development scaling. Believe it or not, I have read that and I agree with most of its points. BUT I didn't suggest scaling up to thousands of people. I suggested two or three more. And taking any point written in a book as an absolute is risky. You conveniently ignore my point about other open source projects. What did you understand that they all ignored? I guess I should just expect Boost, Blender, all those successful projects that have multiple people committing to their central svn to fail tomorrow, they can't possibly prosper a day more... (please take that as what it is, it's sarcasm designed to make you think about what other projects do, nothing more) One of the pioneering open source projects is Mozilla (once Netscape, then Mozilla, then Firefox and Thunderbird and others). I've had the chance to submit a few fixes to that project and see how they handled them. They have a group of reviewers, one of which gets assigned to your patch / bug report, depending on their area of expertise and the part of the code your patch touches. If the patch touches multiple areas, multiple reviewers get assigned. The reviewer(s) approve the patch (or it goes through a few iterations with the submitter before being approved), and then a second reviewer who doesn't know about the problem has to check it and approve it too, and finally the first reviewer can commit it. If a patch gets committed without this two-level review, then it gets backed out because it hasn't been approved correctly. I'm not suggesting we go to that level of organized process, I'm just saying that if that process has worked for them, then taking bits of it and adapting them could work for us. And saying that scaling up svn (revision control - they used CVS at the time) access doesn't work is just false. I have trouble believing you want to keep all that pressure on your shoulders. Believe it or not even you have broken the build and introduced bugs too. There must be one or two other people in whom you have some confidence, and that you could include and give some submissions to review... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] newbie texture question
Hi David, I will keep playing with it to see if it is dropping the u,v coords as you suspect. Worst case scenario I just remove the ability to apply a texture at run-time for a mesh and make them specify it in the mesh file. Or, just map a dummy white 1x1 texture by default, so that the obj loader thinks there's a texture and keeps the UVs (if that's indeed the problem). Applying a texture at run time is not a problem, it's getting the model loaded with the proper texture coordinates that is... After that it's just a matter of model-getOrCreateStateSet()-setTextureAttributeAndModes(0, my_new_texture.get(), osg::StateAttribute::ON); J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn trunk build broke
Hi Robert, You know full well I meant commit access to the core on svn trunk. That's the main point right now. No I didn't know you meant something other than what you said. You said something that wasn't true so I corrected it. Don't forgot that you're not the only one reading this thread. Geez, we're not brainless machines, we can reason from context can't we? If I have to re-state the whole context each time I say something we'll have many pages of text instead of a few paragraphs in each e-mail message. And I would be insulting your intelligence. As for the rest. As I said this isn't the thread to host such as discussion. You're the boss, boss. ;-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi Robert, Of course you had to know that I would be one of the first to reply :-) _My situation : just keeping up, but only by dedicating almost 100% of time to unpaid project work, which is not sustainable_ [...] Right now I am clearing the submissions backlog but slower than I'd like, and tackling some of the tasks I had planned, it's taking me near 100% of my time, which is fine for now, but there will come a time soon when I will need to back to earning a living once more, and will have to drop my unpaid efforts back down to less than 50% of my time. Not difficult to see crunch time is potentially looming. [...] Often I see posts from members of the community that site write access to subversion as a major bottleneck for the project, however, as I project lead this isn't what concerns me the most. I don't understand why you came to that conclusion while writing this message. Just writing it, it should have been obvious that processing submissions to the core is what's taking almost 100% of your time, and so that's what needs to be offloaded onto others. You speak of website maintenance, support on the mailing list, etc. All this is already as much off your shoulders as it could be. As soon as I and others see posts on the mailing list that talk about the server, we fire off a message to Jose Luis (we CC you so you're in the loop but not because we want you to take care of it!). And the community replies to most questions before you even get the chance to read them, I'm pretty sure. It's just the deeper questions about the render back-end or such things that most will have trouble answering, but some will still answer if you give them time. So if you want your support load to diminish I'd say don't check new messages as often, and most will take care of themselves! :-) What more would you want us to do in those areas? I'm not sure what we can do. So in effect by asking the question in this way you're constraining the solutions people can offer. You're not exposing a problem and letting people suggest solutions, you're offering a list of solutions and maybe none of those will solve the problem... I hope you'll consider *all* suggestions and not just the ones you ask for. If many people tell you that you need to bring more people into the loop for submissions to the core, perhaps you could consider that maybe they have a point... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn trunk build broke
Hi J.P., PS. I've come across this great lecture series (with videos) from Andrew Tridgell (of Samba fame). Lecture 7: FOSS Governance might be of interest (in the sense of being informative, not prescriptive). http://cs.anu.edu.au/students/comp8440/lectures.php Thanks for sharing this! I've just watched lecture 7 as you suggested and it is indeed good. I'll be watching the other ones, I'm sure the whole series is just as interesting! Thanks again, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.9.7 developer release tagged
Hi Robert, And updated the dev release page: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases But you didn't update the news on the front page... I'd offer to do it but no one other than you has access to that... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
Hi Torben, What is the issue with the server and repository? Our hosting is provided at AI2, Universidad Politecnica de Valencia, Spain by Jose Luis Hidalgo (see the footer on openscenegraph.org). In the last few months there have been various outages and server problems, some of which were database errors (the main site uses Trac), some of which were network problems (so they affected svn as well), etc. Can anyone estimte the monthly traffic and the required harddrive space? Depending of this values, I'll can see if I can offer a solution for free. At this point I don't think there's a clear understanding of the origin of the problems, so it would be premature to just move the software/content to another server and hope it fixes it... But it would be nice to find out what's happening. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] osgOcean with osgEarth
Hi Chris, I'll revisit this if anyone thinks of anything else to try, but for now I'm going to give up on osgEarth (since it seems osgOcean may be more valuable to us) and try VirtualPlanetBuilder to generate terrain that IS compatible with osgOcean. From your screenshots, I don't think it's osgEarth that's to blame. Anyways, from what I heard, osgEarth is pretty much the same as VPB except that it does the work at run time instead of as a pre-process. So just dropping osgEarth might not solve your problems if you're going to be generating the same type of Earth model with VPB... First thing is osgEarth by default probably works on the fixed pipeline, and you probably have not adapted your app's shaders to osgOcean's shaders. That's a pretty involved job, as you need to find out what your scene needs and duplicate those effects in shaders. Second, I have personally never tested osgOcean on a curved surface (round Earth), and I don't think Kim has either. I'm not sure it's supposed to work. Can you try with a flat Earth terrain model, even using osgEarth? Perhaps that would start eliminating variables. Someone has put those two together before, yes? :) Yes, I have used flat VPB-generated terrain models. I had to make shaders that knew about osgOcean and the effects I wanted on my terrain though. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn trunk build broke
Hi Robert, I am angry because of your attitude towards me, accusations of un-professionalism - something based on my inability to live up to your expectations on just how much work I can personally take on. These expectations *are* unreasonable, so I will never be able to live up to your expectations and I will always disappoint. I think this really underscores the submissions bottleneck for core OSG. I think if you had let someone (or a group of people) take on the less critical submissions, and had been able to totally devote yourself to the harder ones, you would be less exerted and this discussion might not have escalated to the point that it has. I'm not trying to put the blame on you at all, see my other posts where I question some things Paul did/said too... I'm just saying that one less straw might not have broken the camel's back, and suggesting what that straw might be. If we can improve in that area, perhaps things will go smoother in the future. I know it's been discussed in the past, but IMHO it's just one more item of proof that it's something that needs fixing... Maybe we can reopen the discussion with the aim of doing something about it. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn trunk build broke
I hate being the one to get between you two, but I think this is getting out of hand. As is often the case in these heated arguments, you're both right, and you're both wrong. Paul, finding which header is missing from the places where you get the errors would probably not be too hard. Robert, getting a header and trying a GL3 build would probably not be too hard. Paul, Robert has been troubleshooting lots of things today, most of which are threading problems which are notoriously hard to wrap your mind around, and so probably has lots on his mind right now (the mental call stack is getting deep ;-) ). Plus, it's around 9:45 where he is so he's had a long day behind him. Robert, Paul is trying to help in his own way and trying to help you help yourself by telling you that getting a GL3 build going is easy, which is something you might say to other people on the list if the places were reversed (Have you tried running in a debugger, we're not here to debug your code, etc.). Sorry but the last replies have not been constructive. I think the best thing to do is to drop the issue for now, go back to the technical issues, and remember that you're both working towards the same goal :-) And you have been for many years now... Longer than I've been here! I hope by telling you not to flame each other I won't get flamed myself :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn trunk build broke
Hi Paul, Paul, finding which header is missing from the places where you get the errors would probably not be too hard. I often do provide fixes, but I'm under the gun to get demos out the door in a few days. And Robert's under the gun (perhaps his own gun) to get a dev release out the door in a few days too. So suggesting he set up something new at this point in time was the same as him suggesting you fix the code yourself :-) Also, the general rule for most software development projects is: you break it, you fix it. I understand where you're coming from, but the fact is that when there are multiple code paths (and even more so when there are code paths determined at configure-time with #defines) it becomes hard and time-consuming to test each and every combination. I think it's reasonable for Robert to rely on the community for some of this, especially for configurations he doesn't use day to day. Just look at how many times I've submitted Windows build fixes in the past 3 years - I cut my teeth in OSG submissions on that stuff! For now, I see GL3 as the same thing - OSG's primary developer doesn't use the configuration (he could, I agree, but that's not the point), so it's up to others to test that it builds and runs for now. Although I also agree with your point that getting an automated build going for each configuration would be easy too, but crunch time was probably not the right time to suggest this... In effect, both of you were saying I can't fix this, I'm too busy with other things, you should fix it. And one of you had actually broken it, but the other had the errors right there in front of them. So you both could have fixed it. That's all I wanted to emphasize. Robert, keep in mind that words account for only a small percentage of communication, which makes it easy to read attitude into someone's text-only post, where none actually exists. That's so true. Most flame wars start because one poster reads more into the words than what was actually there, and then things escalate. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] linking two views to one camera manipulator
Hi David, In addition to what Paul said, I have this to add: ... I want them to be able to move together in sync like they where sharing the same camera manipulator. Your intuition here is good, you actually can give both views the same camera manipulator! Basically try out each solution and see what works best for you. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating a new AnimationPathManipulator.
Hi Nick, The reasoning behind this is that I want to capture flyover video and have reproducibility of my captures. Using the current APM, the captures would be dependent on the FPS performance of my machine and if it varies during capturing, my video will look off. If I interpolate based on frames, then regaurdless of the fps, all frames will be exactly the same and evenly spaced. Instead of doing this, you could just manipulate the Viewer's FrameStamp so that SimulationTime advances exactly say 16.6 ms each frame independently of the performance of your rendering. This would be less intrusive than changing the AnimationPathManipulator. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] png, tif 3ds files reading problem
Hi Akilan, Recently I installed osg2.8.2. I compiled the sources (from .svn) successfully. But viewer is saying couldn't find plugin to read .png, tif of 3ds files even if osgdb_freetype.dll is in path and created from compilation. What needs to be done? Why do you think osgdb_freetype.dll has anything to do with loading png, tif or 3ds files? You need osgdb_png.dll, osgdb_tif.dll and osgdb_3ds.dll. The first two depend on third party libraries (libpng and libtiff respectively) so you'll need to either download the 3rdParty package for your compiler from openscenegraph.org or compile them yourself. But the third doesn't need any dependencies and should have been compiled when you compiled OSG. Check if it was part of the sources and project file, and that it can be found when running osgviewer. If you want to debug plugin troubles you can set OSG_NOTIFY_LEVEL=DEBUG and you'll see messages on the console which will tell you which plugins osgviewer is looking for and where it's looking for them. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Survey: Is there interest for an OSG Users Group at ITEC or I/ITSEC?
Hi Brett, I know a lot of OSG users are building things in the ModSim space and I know that two of the bigger industry conferences are ITEC (Europe) and I/ITSEC (USA). I was wondering how many people from this list go to either of those and if there is any interest in a OSG Users Group meeting? I was thinking it would be a great opportunity to meet other OSG users. Perhaps everyone can speak a little about what they are building with OSG and share some of their experiences. So, the questions are: 1) Do you go to ITEC and/ or I/ITSEC? (Please specify which one) We'll be at both ITEC and I/ITSEC. Not me, but our VP of Business Development, Arnold Free, will be there. 2) Would you go to a OSG Users Group Meeting? Arnold would attend, sure, and he could talk about some of the things we've been working on. We're going to have a nice demo on the show floor as well if people would like to check it out. :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT --QOSGWidget cannot create context?
Hi Fausto, Sorry to bother again. I've got some improvement and in fact the problem was in the trails setup. But it's not perfect yet, and I was wondering if you could send your QOSGWidget code, at least the part concerning the context creation, just to see if there are other settings that I can try to get the new issues fixed. it would be helpful. I can have a look, but once again I'll reiterate what I said before, if you have such questions it's better to post to the mailing list / forum. I read the mailing list so if I can help I will, but in addition others can help too. And since in this case it's been a while since I've worked with Qt setup code, you would probably have more luck with other people on the list. So there's really no downside to posting to the list / forum! Many more eyeballs will see your code and be able to help. So send it to the list (reply to all will do that) please. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash reporting is incorrect
Hi Philip, Paul, Does this happen with anyone else's builds? I'm pretty sure it's a widespread issue, my builds seem to suffer from the same problems. WHITESTAR and both Skywalker builds on cdash.openscenegraph.org are mine. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange Visual Studio behaviour
Hi Andrea, I just wanted to share with everyone this experience... Yes, absolutely, thanks for sharing the resolution, it will probably help others in the future! Glad you found the reason, as I agree that it was quite a weird problem. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash reporting is incorrect
Hi Philip, (I'm consciously top-posting to keep the whole original message below) Jose Luis Hidalgo manages the current incarnation of openscenegraph.org and most of the related sites (except the forum, Art Tevs manages that). Jose Luis doesn't always read the list, so I added him as CC on this thread, perhaps he can look into it and see if he can spot something wrong. You might want to communicate with him off-list if you can help him diagnose the problem directly. In the past I've volunteered to help manage the sites, and the answer was that it would be difficult to convince the people at his school to let someone from outside their organization help manage one of their servers, but if we can help find problems faster I would think they'd be all for that... I hope we can get to the bottom of this, as CDash is only a useful service if it can give reliable results, obviously... J-S Philip Lowman wrote: On Sat, Feb 13, 2010 at 3:48 PM, Philip Lowman phi...@yhbt.com wrote: On Sat, Feb 13, 2010 at 1:11 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Philip, Paul, Does this happen with anyone else's builds? I'm pretty sure it's a widespread issue, my builds seem to suffer from the same problems. WHITESTAR and both Skywalker builds on cdash.openscenegraph.org are mine. Yeah I'm seeing this issue too. Guessing this is something messed up with the CDash install or database. Here's my output from the unsuccessful build and the XML submission files are attached which show the build warnings and errors. The dashboard claims everything was peachy: http://cdash.openscenegraph.org/buildSummary.php?buildid=1405 I think the CDash logs need to be examined for obvious signs of errors (corrupted database tables, file permission problems, etc.) Also someone might consider upgrading CDash to the latest version. -- Build files have been written to: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386 ^K Site: sisko Build name: Linux-gcc34-i386 Determine Nightly Start Time Specified time: 00:00:00 CET Create new tag: 20100212-2300 - Nightly Updating the repository Updating the repository: /usr/local/home/lowman/Dashboards/osg/trunk Use SVN repository type Old revision of repository is: 11057 Determine Nightly Start Time Specified time: 00:00:00 CET New revision of repository is: 11057 Gathering version information (one . per revision): Configure project Each . represents 1024 bytes of output . Size of output: 0K Build project Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. .*!... Size: 50K ..**.. Size: 100K ..***. Size: 150K . Size of output: 150K 4 Compiler errors 18 Compiler warnings Test project /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386 Performing coverage Error(s) when building project No tests were found!!! Cannot find any coverage files. Ignoring Coverage request. Create notes file Add file: /usr/local/home/lowman/Dashboards/Configs/osg/Linux-gcc34-i386.cmake Submit files (using http) Using HTTP submit method Drop site:http://cdash.openscenegraph.org/submit.php?project=OpenSceneGraph Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Build.xml Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Configure.xml Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Notes.xml Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Test.xml Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Update.xml Submission successful ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] website down
Hi all, hi Robert, It seems to me that the OSG site has not been very reliable in the past few months. We see these kinds of posts pretty often (maybe once every two weeks?) and the problem often lasts for a day or more, and is most of the time corroborated by multiple posters so it's probably not due to connection issues on the users' part. Nothing personal, it's great that Jose Luis volunteered to host the site at his university, but if it's not reliable (maybe it's even for reasons outside his control, but the result is the same) perhaps we should find another host? I think it looks bad for the project when the site is down a non-negligible portion of the time. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT --QOSGWidget cannot create context?
Hi Fausto, I've read your post regarding this problem, and I was wondering if you found the solution because I have the same problem when I try to embed osg into a Qt application. It works fine in simple tests, but when a more complex Qt windowing is concerned I receive the same error as yours. It's been a while since I've looked into this example. I guess it must have worked at some point because we're now using Qt in our application without any problems (and have been for over a year now), but I forgot to post the resolution. I would expect I changed something in the way Qt creates the widget that OSG will use to draw. The Traits you give to your OSG context and the way Qt created the widget in which it will be embedded must match. So check that, and if you still can't find the solution I'd advise you to post to the OSG list instead of sending mail directly to the poster :-) 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] This month in IEEE Computer Graphics and Applications
Hi all, I just wanted to mention that unless I'm mistaken, there's a pretty good OSG presence in the January/February issue of IEEE Computer Graphics and Applications. Two articles have been co-authored by members of this list: Dynamic Terrain for Multiuser Real-Time Environments Christopher Ellis, Pavel Babenko, Brian Goldiez, *Jason Daly* and Glenn A. Martin, University of Central Florida. We All Live in a Virtual Submarine Paul Chapman, Glasgow School of Art; *Kim Bale*, University of Hull; Pierre Drap, Laboratoire des Sciences de l'Information et des Systèmes, Marseille. Now, I'm not 100% sure that in the first one, the Jason Daly is the same as on this list (I think so but I may be wrong), but the second article talks about the VENUS project so I'm 100% sure Kim Bale is the same one :-) Congrats to Jason (if I'm not mistaken) and Kim, both are excellent articles. There's even a mention of OpenSceneGraph and some screenshots of osgOcean in there :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange Visual Studio behaviour
Hi Andrea, If I compile my application in Release build and launch it through VS2008 with the Start Debugging (Ctrl-F5) command, the performance is good and close to what I was expecting: ... If instead I launch the same application with the Start without Debugging (F5) command, the performance DROPS dramatically: In my case, Start Debugging is F5 and Start without Debugging is Ctrl-F5 (and these are the default key assignments). So could it be that you're mixing the two? Or is it just that you've customized the keyboard shortcuts? It should definitely be faster without debugging, and we've seen this in our apps. When both are Release builds, we don't see that dramatic a difference between the two though. But between Debug and Release builds the difference is large (and that's to be expected). 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] TexGen OBJECT_LINEAR in shaders
Hi all, I'm trying to replace the fixed function texgen for a given effect by a shader in order to remove the back projection problem. But I'm struggling a bit to even get the texgen to work with shaders (once that's done removing the back projection will be a cinch). The original (fixed pipeline) code does: _texGen= new osg::TexGen; _texGen-setMode( osg::TexGen::OBJECT_LINEAR ); osg::StateSet *ss = geode-getOrCreateStateSet(); ss-setTextureMode( _textureUnit, GL_TEXTURE_GEN_S, osg::StateAttribute::ON ); ss-setTextureMode( _textureUnit, GL_TEXTURE_GEN_T, osg::StateAttribute::ON ); ss-setTextureMode( _textureUnit, GL_TEXTURE_GEN_R, osg::StateAttribute::ON ); ss-setTextureMode( _textureUnit, GL_TEXTURE_GEN_Q, osg::StateAttribute::ON ); ss-setTextureAttributeAndModes( _textureUnit, _texGen.get(), osg::StateAttribute::ON ); And then later, in the cull traversal, it does: _texGen-setPlanesFromMatrix( someMatrix ); This works well on the fixed pipeline. Now my first question when replacing this by shaders is: I understand I need to replace the calculation by shader code like this in the vertex shader: gl_TexCoord[1].s = dot(gl_Vertex, gl_ObjectPlaneS[1]); gl_TexCoord[1].t = dot(gl_Vertex, gl_ObjectPlaneT[1]); gl_TexCoord[1].p = dot(gl_Vertex, gl_ObjectPlaneR[1]); gl_TexCoord[1].q = dot(gl_Vertex, gl_ObjectPlaneQ[1]); But does the setPlanesFromMatrix() fill in the gl_ObjectPlaneS/T/R/Q builtins, or should I remove the osg::TexGen stateAttribute completely and instead place that same matrix in some uniform and use that? i.e. in the cull traversal: geode-getOrCreateStateSet()-getOrCreateUniform( texGen, osg::Uniform::FLOAT_MAT4)-set(matrix); and then in my shader: uniform mat4 texGen; //... then in main() gl_TexCoord[1].s = dot(gl_Vertex, texGen[0]); gl_TexCoord[1].t = dot(gl_Vertex, texGen[1]); gl_TexCoord[1].p = dot(gl_Vertex, texGen[2]); gl_TexCoord[1].q = dot(gl_Vertex, texGen[3]); What is better? Next question, is there something special I need to do in the fragment shader to use these generated texture coordinates? Because I tried simply doing the obvious: vec4 col = texture2D( tex, gl_TexCoord[1].st ); and it doesn't work (I've tried using the vertex shader both ways above, and even without any vertex shader which should revert to fixed pipeline vertex stage...). So I guess my second question is more important, why does the texturing with OBJECT_LINEAR texGen not work when I just replace the fragment shader and use the fixed function vertex processing? I would think that would isolate the mistake to only the fragment shader... Do I need to do something else in the fragment shader? Maybe transform the generated texture coordinates somehow? What does the fixed pipeline do with generated texture coords? Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TexGen OBJECT_LINEAR in shaders
Hi Paul, Or better yet: gl_TexCoord[1] = texGen * gl_Vertex; There is a lot of overlap between the object plane equations and the texture matrix. Originally, the thinking behind the object plane equations was that you might only be concerned with s and t, so it was more efficient than using the texture matrix to do the transformation. But if you're going to transform all four elements, you may as well do a vector-matrix multiply. Ok, thanks for the clarification. I kind of lifted the code from the orange book without thinking too much :-) Interesting. You should try debugging it by temporarily changing your fragment shader to something like this: gl_FragColor = gl_TexCoord[1]; This will color your object using s for red, t for green, etc., which allows you to visually check to make sure the fragment shader is getting good texture coordinate inputs. If the inputs are good, then it might be an issue with texture binding. If the inputs are bad, then it could be something wrong in the vertex shader or some incorrect usage of predefined varyings. I tried that already and the result is the same with my vertex shader and with fixed-function vertex processing (and with your suggestion of gl_TexCoord[1] = texGen * gl_Vertex; too). My texture bindings are good too (I can use the sampler I want to use with gl_TexCoord[0] and see it). So you confirm that the fixed function fragment stage will not do anything special when texgen is active, i.e. that it will only do: vec4 col = texture2D( tex, gl_TexCoord[1].st ); ? Personally, I don't use predefined varyings anymore, as they're deprecated in v3.0 and not required in most of v2.x. Specifying my own varyings makes it easier to swap between 2.x and 3.x. Plus there are a zillion predefined varyings. I could never keep them straight, and it's actually easier to define my own varying than look up what is the correct one to use. Simply define this in both the vertex and fragment shader: varying vec4 tc; and use it instead of gl_TexCoord[1]. I'll have to start using my own varyings too eventually. I'm just used to using what's provided by whatever system I'm using before defining my own, so that's why I use the predefined names for now. Thanks for your help, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TexGen OBJECT_LINEAR in shaders
Hi Paul, I've found the problem. So you confirm that the fixed function fragment stage will not do anything special when texgen is active, i.e. that it will only do: vec4 col = texture2D( tex, gl_TexCoord[1].st ); ? Seems this was not correct, I had to do a transformation: vec3 texCoord = gl_TexCoord[1].xyz / gl_TexCoord[1].w; vec4 col = texture2D( tex, texCoord.st ); I guess this is because I'm doing projective texturing and not because of the texGen itself. I hadn't mentioned that fact. Oops... ;-) Thanks again for your help. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio 9 2008 3rd Party
Hi Adrian, does someone have for all existing openscenegraph plugin build the 3rd party library and is willing to share them. There is 3rdParty_Win32Binaries_vc90sp1.zip on this page: http://www.openscenegraph.org/projects/osg/wiki/Downloads/Dependencies Though it probably doesn't contain the dependencies for all existing plugins as you're asking... It's probably the dependencies for the most often used plugins. Maintaining a package with recent and known working dependencies for all plugins is probably more than anyone is willing to do, especially considering that some plugins are probably not used by many people... i thinks i would be greate having a full working OSG environments to test and play with. It's up to those who use plugins to test them... It's a case of those who have the itch will scratch it. Then again, you seem to want this, so why don't you take on the responsibility of making a package and maintaining it? i am aware of having some plugins with non LGPL dependencies, but no problem, we can nevertheless share them as long as we don't use them for commercial projects. In some cases, you can't redistribute binaries of dependencies (the QuickTime SDK comes to mind, each person (or company) needs to download it from Apple's site). Keep that in mind if you don't want to get unpleasant e-mails... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio 9 2008 3rd Party
Hi Luigi, What about having a repo of working recipes where people who have the itch and have successfully scratched can share the recipe in a somehow formalized way. In my previous mail, I' m suggesting use of Cmake external projects as a way to formalize download,unpack,patch,configure,make and install we could also think for simple plugins, some high level read-write testing based on osgconv. Yes, I agree with the principle of CMakePorts. It seemed promising about a year ago when it was announced, has any progress been made since then? Seems to me it has always built the same small list of dependencies, no more... Of course, if people don't get involved, it won't progress. So I would second your suggestion to Adrian that he somehow contribute to that instead of making / asking for binaries. It'll profit more people if he does that. What about automating the download+install process? would it be still illegal? You'd have to check the QuickTime SDK's licensing terms, but traditionally any large corporate entity (say Microsoft, Apple, etc.) who distributes an SDK will object if some other site hosts their binaries, but not if some other site simply automates the process. Of course, you then have the responsibility to make sure the download link you use stays valid / is updated when it changes on that entity's web site... And sometimes they may use devious tricks like scripts / cookies that will block automated downloading from a fixed link and will force a human user to manually download it. However those are the minority of dependencies... If one or two dependencies need the user to download something, but most others (say 10 or 20) can be downloaded automatically, then there's already a huge net gain in using your system. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] First attempt at OpenSceneGraph Programming.....
Hello Ernie,
Given your two symptoms, which are:
I place both: $(OSG_LIB_PATH) and $(OSG_INCLUDE_PATH) into the necessary fields
when i am configuring my project, like it says in the above tutorial, but i get
errors when i include them [...]
and
When i try to run the program by pressing F5 i get the following error:
Code:
The program cant start because osg55-osgd.dll is missing from your computer.
Try reinstalling the program to fix this problem
it seems to me that your Visual Studio is not picking up the environment
variables you have set. You could check this by making a simple C
program that would use getenv() to check the value of each environment
variable you have set and print it out to the console, for example
(untested):
#include stdio.h
int main(void)
{
char* path = getenv(PATH);
if (path != NULL)
printf(PATH = %s\n, path);
char* osg_inc_path = getenv(OSG_INCLUDE_PATH);
if (osg_inc_path != NULL)
printf(OSG_INCLUDE_PATH = %s\n, osg_inc_path);
char* osg_lib_path = getenv(OSG_LIB_PATH);
if (osg_lib_path != NULL)
printf(OSG_LIB_PATH = %s\n, osg_lib_path);
}
First possibility : did you restart Visual Studio after modifying your
environment variables? If you change system environment variables, any
command prompt or Visual Studio instance you were running will still be
using the old values. So close and restart it.
If that's not it, there may be another thing. I can't recall exactly
(installing and setting up Visual Studio is something you don't
necessarily do every day), but I think there's a setting that tells VS
not to pick up system environment variables. Perhaps that setting is set
that way for you - I think the default is that VS will pick up all
system environment variables. I think there's also a /useenv switch you
can pass to VS on startup that will do this. Google it.
In any case, there's no reason you couldn't get this working with the
environment variables as the tutorial says. In particular, I use this
same kind of setup with both VS 2005 and 2008 on multiple machines and
it works well for me.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nightly Windows builds?
Hi Paul, Interesting... I ran a nightly build on 5 Feb at 00:05 (5 minutes past midnight) CET, and that was Feb 4 16:05 local time. Immediately after the build completed, I saw the results posted to the dashboard. Then I took the evening off and went to sleep. This morning 15:45 CET (7:45 local time) they are no longer listed. What's up? Click the Previous link at the top of the page to see builds from the previous day. Your build was at 16:05 local, and then you checked again at 7:45 local, so it switched to another day... :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nightly Windows builds?
Hi Paul, Huh! Even though it's the _same_ day in CET... Yeah, well, it only knows about its own local timezone... Makes sense I think. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MatrixManipulator implementation
Hi Miguel, Is the feature I want is possible with the MatrixManipulator of OSG or should I implement my MatrixManipulator ? I think you should subclass osgGA::NodeTrackerManipulator or just modify it in OSG to add a new TrackerMode to it that would do that. It falls within its scope of functionality I think. Look at the code for NodeTrackerManipulator, you'll see that you just need to remove some calculations from getMatrix() and getInverseMatrix() to get what you want. So if you want your change to be useful to others, you could add a new TrackerMode to it, and if that's the active TrackerMode then you do the right thing. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dynamic_cast of referenced objects
Hi Kevin,
My project is throwing an occasional unhandled win32 exception error and I've been trying to figure out why. There is no consistency in the timing so I assume that I have a dangling pointer somewhere.
I doubt you're on the right track with changing standard pointers to
ref_ptrs in function arguments, but when unsure it's better to use
ref_ptrs everywhere.
The right way to debug your error would be to compile a debug version
and run your code in a debugger. Then the debugger would likely tell you
exactly which pointer was left dangling, you'd have a stack trace, and
it would be relatively easy to track down the cause. Just sprinkling
ref_ptrs everywhere in the hope that it'll fix it is not a solution, IMHO.
But to answer your more concrete question:
Is there an equivalant means of casting an osg::ref_ptrosg::node into an
osg::ref_ptrosg::MatrixTransform when using referenced object pointers? I'm trying
to do something like:
--- snip ---
void operator()( osg::ref_ptrosg::Node node, osg::ref_ptrosg::NodeVisitor
nv )
{
osg::ref_ptrosg::MatrixTransform MatrixXform =
dynamic_castosg::ref_ptrosg::MatrixTransform(node) ;
if ( MatrixXform )
--- snip ---
osg::ref_ptrosg::MatrixTransform MatrixXform =
dynamic_castosg::MatrixTransform*(node.get());
A ref_ptr is an object on the stack (not a pointer) that tracks a
pointer. And ref_ptr::get() returns a raw pointer to the underlying
object. So you can construct (or here, assign to) a ref_ptr from a raw
pointer.
So from right to left:
1. You extract the raw Node* pointer from a ref_ptrNode
2. You dynamic_cast that to a MatrixTransform*
3. You assign that to a ref_ptrMatrixTransform
4. Bob is your uncle.
Note that in the process, the ref count of node will be incremented if
it was really a MatrixTransform (i.e. if the assignment assigned
something other than NULL), so your function will have 2 refs (one in
the temporary ref_ptrNode, and one in the ref_ptrMatrixTransform).
This is unnecessary, as the temporary ref_ptrNode in the function
arguments guarantees that the object will not be deleted in the scope of
the function. So you could do this instead:
osg::MatrixTransform* MatrixXform =
dynamic_castosg::MatrixTransform*(node.get());
As I said, storing it in a raw pointer is safe at that point because of
the temporary ref_ptrNode in the function arguments which will be
destroyed when the function ends.
So you see, ref_ptrs require a bit of work wrapping your mind around
them, but it's not magic and it all works really well.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Problem building osgOcean in visual studio 9.0.
Hi Chris, In the osgOcean project settings, the additional include directories includes the osg header directories, including osgDB and osgText. These are put there by CMake, which demands those paths in order to generate the project files. osgText has its own String class based on std::string and osgDB has it's own fstream. Both are defined in headers with the same name as the standard library headers. So when osgOcean tries to include the standard varieties, it gets these overridden files. By removing those two directories from the additional includes, osgOcean builds correctly. Hm, interesting. CMake should be adding only osg root/include to the project's include paths, and not any of osg root/include/osg, osg root/include/osgText, osg root/include/osgDB or anything like that. If that were the case, the include lines in osgOcean (presumably #include string and #include fstream) would not find the osgText and osgDB versions, you would need to do #include osgText/String and #include osgDB/fstream specifically to get those, and all would be well in the world (and curse Windows' case-insensitive filesystem in the case of String vs string...). What version of CMake are you using? I'm pretty sure if CMake generated project files that way for you, it should have generated them that way for us too, unless there's a bug in the version of CMake you're using. The other possibility - did you manually specify the include directories? If that's the case, then you should have specified the same directory (osg root/include) for all *_INCLUDE_DIR settings. Doing that in the CMake GUI and then regenerating should fix the problem too, without needing to remove include paths manually from the project files. This should perhaps be better documented. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Problem building osgOcean in visual studio 9.0.
Hi Chris, By removing those two directories from the additional includes, osgOcean builds correctly. Oh, and I forgot to mention - great work tracking this down, it was certainly not obvious what the problem was when considering only the compiler errors you posted :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Quicktime plugin
Hi Kian, I am trying to use OSG to play a video but it keeps indicating to me that it can't find the plugin. I am trying to load the quicktime plugin in but is having some diffculties, I have downloaded the quicktime sdk but is not sure how to use the cmake to configure and generate, can someone guide me on this? I am hoping to load that plugin so that I can play videos using the osg libraries. If you're on Windows please see this page for general info about using CMake to generate Visual Studio build files from the OSG sources: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio and this page for specific info about the QuickTime plugin: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio/VisualStudioPlugins It's been a while since I've compiled the QuickTime plugin myself, these days I use the ffmpeg plugin as it's more recent, well-supported, cross-platform and freely licensed. You might want to try that yourself. Search the archives / forum for info about building the ffmpeg plugin, but it's basically the same process - get the ffmpeg includes/libs from the internet, configure CMake to find them, generate and build. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nightly Windows builds?
Hi Alberto, I found that the reports were likely bogus at least for me http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg34227.html so I stopped submitting my results for a while. I think that having bad information is worse that not having any at all. Yeah, you're right about that. I've cc'd Jose Luis on this, perhaps he can investigate. Jose Luis, please see the link above, it seems the CDash install on openscenegraph.org is reporting incorrect results. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nightly Windows builds?
Hi Chris, Do you guys have any special tips on setting up a nightly build environment? Or just -- go at it and see what happens. See the wiki page here: http://www.openscenegraph.org/projects/osg/wiki/Build/CDash If all you want is to build nightly (as opposed to publishing the build results on the dashboard) then you can build the INSTALL project in the Release and Debug configurations (or whatever you want) with that same procedure, just replace Nightly with INSTALL. You can obviously customize the batch file that's given on that page to do what you want. I personally do this: call %VS80COMNTOOLS%vsvars32.bat devenv %1% %2% %3% /project %4% so that I can call it with arguments like: OSG from SVN\build\OpenSceneGraph.sln /build Debug INSTALL OSG from some branch we're RCing\build\OpenSceneGraph.sln /rebuild Release Nightly or whatever combination I want. And I can even use it for other projects than OSG. Then I created a scheduled task that calls this batch file any number of times to build the configurations I want built (one task can run multiple commands in sequence, and I find this better for builds since it makes sure two builds don't run at the same time). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node following Camera Manipulator problem on Win32
Hello Ted, thanks very much for any insights, suggestions, help-- Sending the same message three times won't get answers quicker... I have never tried the code you're referring to, so other than suggest to trace into the code (or place breakpoints where the OSG view matrix is updated and in your update callback to make sure the sequence is correct) I can't really do much for you. But if you want a camera manipulator to track a node, why don't you use the osgGA::NodeTrackerManipulator? I've used that in the past, and it works well in my experience (though you must track something that has a valid bounding sphere - we tried using it to track DOF nodes without children and we had to set an initial bound on those or it wouldn't track them correctly, because of culling). Also it has the advantage of being part of the core OSG, so you can get support for it and if it doesn't work someone will fix it whereas I think the NPS tutorials are pretty old and don't necessarily represent recent changes to the API and services that OSG provides. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nightly Windows builds?
Hi Paul, Hi Chris -- I just set up a nightly OSG build (Vista/VS9) for the GL3 configuration. It wasn't difficult. ...and it just completed and published. The system name is UTAH. Perhaps you should change the name so it reflects it's a GL3 build (something like UTAH (GL3)). You can do that through the CMake GUI, in the advanced options change the SITE setting to whatever you want IIRC. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgGA::NodeTrackerManipulator
Hi Ted, Or, it is if the Camera keeps getting 'pushed' further away as the object is being displaced. I remember seeing this too. The trick is not to track the MatrixTransform itself, but to track its child (if there is no unique child, then reformat your graph by creating a single osg::Group below the MatrixTransform that contains the MatrixTransform's old children). For some reason when you setTrackNode(some MatrixTransform) the transform's matrix is applied twice which is what I think you're seeing. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgGA::NodeTrackerManipulator
Hi Ted,
I remember seeing this too. The trick is not to track the
MatrixTransform itself, but to track its child (if there is no unique
child, then reformat your graph by creating a single osg::Group below
the MatrixTransform that contains the MatrixTransform's old children).
For some reason when you setTrackNode(some MatrixTransform) the
transform's matrix is applied twice which is what I think you're seeing.
Actually I just realized that I had made a test case for this. It's
attached.
The program will show a simple scene where a blue sphere rotates around
the world origin, and a green sphere rotates around the blue sphere.
There are also a few stationary cubes just for reference (to see that
there is movement). The camera follows the green sphere with a
NodeTrackerManipulator (unless the --NoNodeTracker argument is given).
The source is commented to explain what is being demonstrated. Note that
the source comments talk about 2 bugs:
* Bug 1 is reproduced by the --TrackTransform argument. When you tell
the NodeTracker to track a transform instead of the child, the
transform's matrix seems to be applied twice, which is what I said
above. The simplest way to see this is to run with --TrackTransform, and
put your finger in the center of your screen. You'll see that the camera
is always centered at 2x the transform from the blue sphere to the green
one (the matrix, which is a translation, is applied with a factor of 2).
Without the --TrackTransform argument, you'll see that the green sphere
always stays right smack in the middle of the screen as it should.
* Bug 2 used to be reproduced by the --DoNotCreateGeometryUnderTransform
argument. When there was no geometry under the tracked node (i.e. the
tracked node has invalid bounds), then the NodeTracker seemed to revert
to looking at the world origin. This seems to have been fixed at some
point, because my test program can't reproduce it anymore.
The program has a few different command line options:
Running without --NoNodeTracker, --TrackTransform and
--DoNotCreateGeometryUnderTransform will lead to the green sphere being
tracked, and this shows normal behavior.
--MT, --PAT, --DOF : select the type of transform node used.
--NoNodeTracker : don't use a NodeTrackerManipulator - this allows you
to see what the scene looks like in general before using the other options.
--TrackTransform : reproduces bug 1 above.
--DoNotCreateGeometryUnderTransform : used to reproduce bug 2 above, but
doesn't anymore.
--AddBSphereCallback : used to be a possible workaround for bug 2...
I never went deep into the OSG code to find a real fix for these
problems, and always assumed that it was our usage of the
NodeTrackerManipulator that was wrong in these cases. I'm not so sure
anymore... Perhaps if you're inclined to debug the issue for bug 1, you
could look into it. We just found workarounds (track children of the
transform instead of the transform itself for bug 1, and the
BSphereCallback for bug 2) and used those instead.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commericial and non commericial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode
#include osg/Switch
#include osgText/Text
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/NodeTrackerManipulator
#include osgGA/StateSetManipulator
#include osg/MatrixTransform
#include osg/PositionAttitudeTransform
#include osgSim/DOFTransform
#include osg/ShapeDrawable
#include iostream
// This is a callback that will be attached to a transform which has no
// geometry under it, so that the transform itself has valid bounds (a
// small sphere at the position defined by the transform). Otherwise
// the NodeTrackerManipulator cannot follow the transform.
struct BSphereCallback : public osg::Node::ComputeBoundingSphereCallback
{
virtual osg::BoundingSphere computeBound(const osg::Node node) const
{
// If the node has no parents or if the parent is not a transform,
// return a bounding sphere that will place this node in world
// space / in the same coordinate space as the parent.
if (node.getNumParents() == 0 || node.getParent(0)-asTransform() ==
NULL)
return osg::BoundingSphere(osg::Vec3(0,0,0), .1);
Re: [osg-users] [osgOcean] Problem building osgOcean in visual studio 9.0.
Hi Chris, Here's hoping someone has figured out this problem in the last 6-7 months since this thread was active... Because I'm stuck. I've used VS2005SP1 to build osgOcean and have been doing so successfully since the start of the project... What version of OSG are you building osgOcean against? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Nightly Windows builds?
Hi Chris, Is anyone out there doing automated nightly builds on Windows? Yes, I am on both my home and work machines. You could see my work machine's submitted builds on this page if the openscenegraph.org site wasn't down/unbearably slow: http://cdash.openscenegraph.org/index.php?project=OpenSceneGraph My work machine is WHITESTAR. Hm, now that the site responded, I see that I'm the only builder still submitting build results? That seems strange, there were at least 10 nightly builds on various platforms by various people last time I checked (a few months ago). On my home machine I do nightly builds too but I don't submit build reports to CDash. I figure it's the same OS and compiler, so one is enough. One thing I don't do is distribute the build products. I don't have any interest in supporting these, plus OSG is pretty easy to build yourself these days (as opposed to a few years ago when building it on Windows was really painful). And apart from reporting build results which I hope can help Robert spot build issues on platforms he doesn't use himself (and a problem spotted early is often easier to fix), I mainly do nightly builds out of personal convenience. I like the idea of having the latest and greatest OSG version compiled and ready to go when I get to work in the morning (or when I get home at night for personal projects). :-) Why do you ask? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgmovie with ffmpeg plugin on Windows 7: runs fine in debug mode, crashes in release mode?!?
Hi Raymond, Did anyone succeed in this? I'm using VC2005SP1, and precompiled ffmpeg downloaded as ffmpeg-r15261.zip from somewhere (I can't remember where) and it works fine in both release and debug. There shouldn't be any problems about C++ runtime and using debug libs in release libs for the ffmpeg libs, because they're C only IIRC. Not sure what the problem might be in your case. Sorry. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgmovie with ffmpeg plugin on Windows 7: runs fine in debug mode, crashes in release mode?!?
Hi Raymond, I'm pretty sure that it crashes somewhere in the SDL Audio part... What version of SDL do you use? There's a difference between our use of osgmovie/ffmpeg plugin, I've never used it with audio. All I can say is try other versions, or compile SDL yourself? You might also be able to compile OSG and SDL in Release with Debug info, which might help trace the crash. Sorry I can't help more. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgmovie with ffmpeg plugin on Windows 7: runs fine in debug mode, crashes in release mode?!?
Hi Raymond, Hmm, that's interesting, never used that combination. Do you know how I enable Debug info for Release mode? When building OSG, after generating the project files with CMake, if you open the solution file you'll see RelWithDebInfo as one of the available configurations. For other projects, you can do it manually by enabling debug symbols in the C/C++ section of the project options, and enabling debugging in the Linker section, for a release build. I should note that you'll probably get weird results from breakpoints and checking the values of variables (because of compiler optimization in release mode). You can disable optimization but the crash might only happen when optimization is at a certain setting... So it's not perfect but might help you get closer to the bug. When something crashes in release but not in debug, it's often an uninitialized variable or something like that. Since the debug builds generally protect you more (initializing variables to known values for example) this sometimes hides bugs that only happen in release. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confirmed system configuration for osgShadow to work?
Hi Martin, I can afford buying a different graphics card and am flexible in regards to operating system, I would only like to have information on a confirmed working setup. So has anybody managed to get a good looking shadow, preferably PSSM, working? OSG's PSSM implementation has been finicky for a while - I haven't seen it work very well in the past year or so. No fixes have been made and I'm partially to blame for that, but LiSPSM works well for me so I haven't had the need to help fix PSSM. For me, ShadowMap, SoftShadowMap and LiSPSM (StandardShadowMap which is not view-dependent and is mostly equivalent to ShadowMap, as well as LightSpacePerspectiveShadowMapCB, VB and DB) work well across a large range of video cards (certainly all the nVidia cards from the 7xxx line forward, and some ATI models as well). You say you get mostly black objects. Is this in your own software that uses a shadow technique, or is it in the osgshadow example? If the osgshadow example works well, then you might have some fixes to make to the way you use the shadow technique - giving it the appropriate light source, fixing shaders, or appropriately setting the node masks, or something like that. Try: osgshadow --sm -3 osgshadow --ssm -3 osgshadow --lispsm -4 If those work, you can send the source of a small example of a program which exhibits the problems you see in your own code. We can probably help. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBX plugin issues...
Hello Bondy, I am trying to import a .fbx file(maya2010) into OSG2.9.6. I am facing some problems in installing the fbx plugin for OSG2.9.6. Here are the steps i followed. 1.I am using a Linux system and I downloaded the linux version of fbx sdk from autodesk website. 2. Unzipped the fbx20102_fbxfilesdk_linux.tat.gz fie and installed the SDK 3. I downloaded and installed OSG2.9.6 yesterday. But the fbx plugin is not installed in OpenSceneGraph-2.9.6/build/lib/osgPlugins-2.9.6 The fbx plugin is optional, and was not compiled and included as part of the binary packages. So if you need to use it, you'll need to download the OSG sources, configure with CMake to find your fbx sdk, and compile the plugin yourself. The binary packages are not a complete build of all plugins. They only include the most widely used plugins, and since in particular the fbx plugin depends on additional third-party libraries that most people won't have and won't need, it makes sense that it's not compiled by default. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgocean agressive memory leaks
Hi Nick,
when I add ocean to my scene, the mem goes up very agressively. and its
still increasing. Are you experiencing the same things ? I run the app
for 15 seconds and it crashes with FBO setup failure
I've modified the oceanExample so that it calls
OceanScene::setSunDirection(...) each frame. I've been running it for
over 5 minutes now and memory usage has not significantly increased in
that time (from the first rendered frame to 5 minutes later, it has
increased a few MB no more - so there may be a leak but it's small). And
it does not crash for me.
Here's my modified application.cpp, could you try this on your side. Run
it for a while and see how it goes. If it doesn't crash and memory usage
doesn't increase too much, we can assume the problem is not in osgOcean
itself.
Thanks,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/*
* This source file is part of the osgOcean library
*
* Copyright (C) 2009 Kim Bale
* Copyright (C) 2009 The University of Hull, UK
*
* This program is free software; you can redistribute it and/or modify it under
* the terms of the GNU Lesser General Public License as published by the Free
Software
* Foundation; either version 3 of the License, or (at your option) any later
* version.
* This program is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
* FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
details.
* http://www.gnu.org/copyleft/lesser.txt.
*/
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/FlightManipulator
#include osgGA/TrackballManipulator
#include osgGA/DriveManipulator
#include osgGA/StateSetManipulator
#include osgGA/GUIEventHandler
#include osg/Notify
#include osg/TextureCubeMap
#include osgDB/ReadFile
#include osg/Shape
#include osg/ShapeDrawable
#include osg/PositionAttitudeTransform
#include osg/Program
#include osgText/Text
#include osg/CullFace
#include osg/Fog
#include osgText/Font
#include osg/Switch
#include osg/Texture3D
#include string
#include vector
#include osgOcean/Version
#include osgOcean/OceanScene
#include osgOcean/FFTOceanSurface
#include osgOcean/SiltEffect
#include osgOcean/ShaderManager
#include SkyDome.h
#define USE_CUSTOM_SHADER
//
// Text HUD Class
//
class TextHUD : public osg::Referenced
{
private:
osg::ref_ptr osg::Camera _camera;
osg::ref_ptr osgText::Text _modeText;
osg::ref_ptr osgText::Text _cameraModeText;
public:
TextHUD( void ){
_camera = createCamera();
_camera-addChild( createText() );
}
osg::Camera* createCamera( void )
{
osg::Camera* camera=new osg::Camera;
camera-setViewport(0,0,1024,768);
camera-setReferenceFrame( osg::Transform::ABSOLUTE_RF );
camera-setProjectionMatrixAsOrtho2D(0,1024,0,768);
camera-setRenderOrder(osg::Camera::POST_RENDER);
camera-getOrCreateStateSet()-setMode( GL_LIGHTING,
osg::StateAttribute::OFF );
camera-setClearMask(GL_DEPTH_BUFFER_BIT);
return camera;
}
osg::Node* createText( void )
{
osg::Geode* textGeode = new osg::Geode;
osgText::Text* title = new osgText::Text;
title-setFont(fonts/arial.ttf);
title-setCharacterSize(14);
title-setLineSpacing(0.4f);
std::string versionText =
std::string(osgOcean ) +
std::string(osgOceanGetVersion()) +
std::string(\nPress 'h' for options);
title-setText(versionText);
textGeode-addDrawable( title );
_modeText = new osgText::Text;
_modeText-setFont(fonts/arial.ttf);
_modeText-setCharacterSize(14);
_modeText-setPosition( osg::Vec3f(0.f, -40.f, 0.f ) );
_modeText-setDataVariance(osg::Object::DYNAMIC);
textGeode-addDrawable( _modeText.get() );
_cameraModeText = new osgText::Text;
_cameraModeText-setFont(fonts/arial.ttf);
_cameraModeText-setCharacterSize(14);
_cameraModeText-setPosition( osg::Vec3f(0.f, -60.f, 0.f ) );
_cameraModeText-setDataVariance(osg::Object::DYNAMIC);
textGeode-addDrawable( _cameraModeText.get() );
osg::PositionAttitudeTransform* titlePAT = new
osg::PositionAttitudeTransform;
titlePAT-setPosition( osg::Vec3f( 10, 70, 0.f ) );
titlePAT-addChild(textGeode);
return titlePAT;
}
void setSceneText( const std::string preset )
{
_modeText-setText( Preset: + preset );
}
void setCameraText(const std::string mode )
{
_cameraModeText-setText( Camera: + mode );
}
[osg-users] Building VPB fails - new .osg plugin?
Hi Robert, I'm building VPB from svn trunk to do a bit of terrain generation, and I got a suspicious compile warning and some linker errors: Warning: 1..\..\..\src\vpb\BuildOptionsIO.cpp(202) : warning C4005: 'ADD_ENUM_VALUE' : macro redefinition 1 C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgDB/Serializer(845) : see previous definition of 'ADD_ENUM_VALUE' osgDB/Serializer defines ADD_ENUM_VALUE thus: #define ADD_ENUM_VALUE(VALUE) \ serializer-add(#VALUE, MyClass::VALUE) and vpb/BuildOptionsIO.cpp defines it thus: #define ADD_ENUM_VALUE(VALUE) \ serializer-add(BuildOptions::VALUE, #VALUE) -- Should the VPB defines be prefixed with VPB_ so they can't clash with OSG defines perhaps? Linker errors: 1BuildOptionsIO.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: __thiscall osgDB::TemplateRegisterDotOsgWrapperProxyclass BuildOptionsLookUps::TemplateRegisterDotOsgWrapperProxyclass BuildOptionsLookUps(class osg::Object *,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,bool (__cdecl*)(class osg::Object ,class osgDB::Input ),bool (__cdecl*)(class osg::Object const ,class osgDB::Output ),enum osgDB::DotOsgWrapper::ReadWriteMode) (__imp_??0?$templateregisterdotosgwrapperpr...@vbuildoptionslookups@@@osgDB@@q...@pavobject@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@1p6a_naa...@aavinput@1@@zp6a_nab...@aavoutput@1@@zw4readwritem...@dotosgwrapper@1@@Z) referenced in function void __cdecl `dynamic initializer for 'BuildOptions_Proxy''(void) (??__EBuildOptions_Proxy@@YAXXZ) 1BuildOptionsIO.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: __thiscall osgDB::TemplateRegisterDotOsgWrapperProxyclass BuildOptionsLookUps::~TemplateRegisterDotOsgWrapperProxyclass BuildOptionsLookUps(void) (__imp_??1?$templateregisterdotosgwrapperpr...@vbuildoptionslookups@@@osgDB@@q...@xz) referenced in function void __cdecl `dynamic atexit destructor for 'BuildOptions_Proxy''(void) (??__FBuildOptions_Proxy@@YAXXZ) Not too sure what to do to fix this. Perhaps this is related to the work on the new .osg plugin? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgocean agressive memory leaks
Hi Nick, on windows, it does eats the memory in large chunks after 5 minutes, It reach the limit I'm on Windows... Vista (at work) to be specific. Did you just compile osgOcean and the oceanExample? Which compiler? Which version of OSG? Sorry I'm kind of out of ideas, since it works fine for me... Can you look into the code since you can reproduce it? I suggest you start with OceanScene::init() and start by commenting out the whole method, see if the leak goes away, then uncomment half of it, check again, etc. until you've found the source... The block at the start where things are being set to NULL should cause objects in ref_ptrs to be freed before they're recreated... Good luck, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building VPB fails - new .osg plugin?
Hi Robert, Build fix for VPB now checked in. Which marks revision #1000 in the VPB repo, where do I send the champagne? ;-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building VPB fails - new .osg plugin?
Hi Robert, Cool, I hadn't spotted that milestone go by. Keep the champage in reserve for when I tag 1.0 ;-) Heh, ok :-) BTW, your fixes didn't fix the linker errors I had also reported: 1BuildOptionsIO.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: __thiscall osgDB::TemplateRegisterDotOsgWrapperProxyclass BuildOptionsLookUps::TemplateRegisterDotOsgWrapperProxyclass BuildOptionsLookUps(class osg::Object *,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,bool (__cdecl*)(class osg::Object ,class osgDB::Input ),bool (__cdecl*)(class osg::Object const ,class osgDB::Output ),enum osgDB::DotOsgWrapper::ReadWriteMode) (__imp_??0?$templateregisterdotosgwrapperpr...@vbuildoptionslookups@@@osgDB@@q...@pavobject@osg@@abv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@1p6a_naa...@aavinput@1@@zp6a_nab...@aavoutput@1@@zw4readwritem...@dotosgwrapper@1@@Z) referenced in function void __cdecl `dynamic initializer for 'BuildOptions_Proxy''(void) (??__EBuildOptions_Proxy@@YAXXZ) 1BuildOptionsIO.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: __thiscall osgDB::TemplateRegisterDotOsgWrapperProxyclass BuildOptionsLookUps::~TemplateRegisterDotOsgWrapperProxyclass BuildOptionsLookUps(void) (__imp_??1?$templateregisterdotosgwrapperpr...@vbuildoptionslookups@@@osgDB@@q...@xz) referenced in function void __cdecl `dynamic atexit destructor for 'BuildOptions_Proxy''(void) (??__FBuildOptions_Proxy@@YAXXZ) I guess perhaps osgDB::TemplateRegisterDotOsgWrapperProxy is missing an export declaration? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building VPB fails - new .osg plugin?
Hi Robert, It's got an OSGDB_EXPORT declaration, but it's a template so shouldn't have one... I've now removed this and checked it into svn/trunk. Could you please test? Yep, that did it. Thanks. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgocean agressive memory leaks
Hi Nick, I nailed this down to ocean-getOceanScene()-setSunDirection(sunpos); calling this each frame increases the mem usage I'll check this out on Monday at work. At first glance setSunDirection() shouldn't cause leaks but perhaps it's the dirty each frame that it causes that leaks. Perhaps a missing ref_ptr or a circular ref_ptr. I'll get back to you on Monday. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgocean agressive memory leaks
Hi Nick, Great. Yeas, that is what I was thinking as well. the sun direction set dirties the scene so the init is called over and over again. I am not into the details of osgscene too much, but for me it looks like an overhead to recreate just about everything on sun position change. init() should free things cleanly though, if everything is in ref_ptrs and is removed from the scene correctly. And the sun position should not be set each frame anyways, only if needed... I'll check it out tomorrow. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem attaching a camera to a node
Hi Charles, The only problem is: every time I attach the camera to the PositionAttitudeTransform node, I get a segmentation fault. Is it possible to attach a camera to a PositionAttitudeTransform node? In OSG, you can't put a camera as child of another node in the hopes of getting the camera to follow that node. The camera is the root of the graph, and everything under it is being rendered. So in adding the camera as child to another rendered node in the graph, you're creating a cycle in your scene graph, which results in an infinite loop. You can either control your camera's view matrix each frame yourself (using viewer-getCamera()-setViewMatrix(...) ) or use a camera manipulator. If you want to follow a node you can use an osgGA::NodeTrackerManipulator (call its setTrackNode() method to tell it which node you want it to follow). So you could have your PositionAttitudeTransform updated by the Bullet object as you had before, and that's the node you would follow with the NodeTrackerManipulator. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG_PLUGIN_EXTENSION not being set in Xcode for the Db, current svn
Hi Robert, This problem will be fallout from a fix for Mingw's freetype header location. I've just reverted this change as it obviously cause more pain than gain. Totally agree. If I have some time I'll see if I can find another fix, and post it to osg-users first for others to test. But for now I'm happy making a symlink. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MinGW and OpenSceneGraph
Hello Laurence,
Below an overview of my settings (just in case somebody wants to confirm
the results)
Thanks a lot for testing and for reporting your findings!
I'll just comment on one thing:
(5) Qt libraries 4.6.1 for Windows (minGW 4.4, 277 MB)
Download: http://qt.nokia.com/downloads/windows-cpp
Install: just run the setup and use the default location (C:\Qt\4.6.1)
...
Unlike what Jean-Sebastien Guay reports here
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/6738 I
don't have any problems (might already been fixed):
osgviewerQT - no issues
osgviewerQtWidget - no issues
Excellent, note that I had a preinstalled Qt 4.4.3 (because that's the
version we use in our software at work) for Windows / Visual Studio,
which is probably what was picked up by CMake, and that's probably the
reason I had problems. Anyways, I didn't really want to test that many
optional compiles (I had already tested Curl, FFMPEG, etc so I think it
was enough for most uses). ;-)
The only application that does not wants to build is osgQtBrowser (error
message below)
The fix is simple:
The missing header files should be here: C:\Qt\4.6.1\include\QtCore
Seems like the CMakeList.txt files doesn't include the QTCORE header files.
Patch:
C:\OpenSceneGraphSrc\OpenSceneGraphSVN\examples\osgQtBrowser\CMakeLists.txt
from: INCLUDE_DIRECTORIES(${QT_INCLUDE_DIR} )
to: INCLUDE_DIRECTORIES(${QT_INCLUDE_DIR} ${QT_QTCORE_INCLUDE_DIR})
It should now compile just fine.
Please send the whole modified CMakeLists.txt file to osg-submissions.
That's the way to submit fixes to OSG.
It almost compiles out of the box, great job :) ! Only one CMakeList.txt
file needs to be patched and perhaps users should be made aware about
the symlink (to fix the freetype issue).
Yeah, that could be documented (where? Perhaps a message in CMake if
MinGW is detected?)
Thanks again,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgocean and reflected scene
Hi Nick, is there a way to have a node to be only reflected but not rendered? I have tryied to set up the node mask to just ocean-getOceanScene()-getReflectedSceneMask() but the node still gets rendered This has nothing to do with osgOcean... If you want your node to not be rendered you need to set up the viewer's cull visitor to have a traversal mask different than 0x (which means render anything with a non-zero node mask). So in your case you could use say 0x ~ocean-getOceanScene()-getReflectedSceneMask() which is all bits except the reflected scene mask. You can get the viewer's cull visitor this way: osgViewer::Renderer* renderer = dynamic_castosgViewer::Renderer*(viewer-getCamera()-getRenderer()); renderer-getSceneView(0)-getCullVisitor(); (or if you're using CompositeViewer, get each view's camera and then...) (also do it for SceneView 1 - the SceneViews are double-buffered in multithreaded viewers, better be safe). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dependancies with Visual2005 SP2
Hello Sebastien, I am running on Visual 2008 SP2 with osg 2.8.2 2005 or 2008? Here you say 2008, and lower you say 2005... Since you said 2005 multiple times I'll assume 2005. I have seen no info on an SP2 for Visual Studio 2005 (or 2008 either for that matter). Are you sure? Searching for Visual C++ 2005 SP2 on Google seems to give lots of results that say that it doesn't exist - for example: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/2f34b83c-14ab-4d7e-96a0-5c8f8716fbf7/ which is pretty recent. I have just downloaded osg binaries for visual 2005 SP1 and I have this message when I launch my app in debug mode : The application failed to initialized properly (0xc0150002). Click on OK to terminate the application. Well I guess that does not work because I use Visual2005 SP2 et not SP1. After few research on this forum, I have read that my solution is to compile all osg library (and plugins) myself, so I did, and that works. In general, before you go recompiling things, you should use Dependency Walker to see if that's the real problem. See below. My question is now about the dependancies. When I want to load a mesh (.ive file) I need zlib1d.dll, so I have donwloaded this library from VC2005 SP1 dependancies. But I have the could find plugin to read objects from file ...ive message. The plugin was compiled and is present in osgPlugins-2.8.2/osgdb_ived.dll directory. I am pretty sure this error comes from an incompatibility with zlib1d.dll because the osg binary dependancies are also available on VC2005 SP1, and not on VC2005 SP2. What do you think ? and If I am right, how to get the VC2005 SP2 dependancies ? Does any one had already this problem ? You won't have to do that for zlib, it's a C only library. C only libraries work on all runtimes without having to be recompiled. It's only C++ libraries that need to be recompiled for different runtimes. So my guess is that something else is the problem. Is zlib1.dll on your app's DLL search path? (i.e. in the app's directory, or in another directory on your PATH) I personally copy all DLLs from 3rdParty/bin to MyOSGApp/bin so that they are found when my OSG app runs (libpng, zlib, ...). Again, Dependency Walker will help you. You can load the app with it, and it will tell you about any DLLs your app can't find, and then you can run the app and it will tell you of any delay-load DLLs that can't be found (which is the case for zlib1.dll when the ive plugin depends on it). Also try running OSG or your app with OSG_NOTIFY_LEVEL=DEBUG to see some more info. This will tell you if the app finds the ive plugin itself and where it's loading it from - make sure it doesn't load another version you might have on your path by mistake. Sadly it doesn't tell you about DLLs that the plugins themselves depend on, but Dependency Walker will help there. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vista/Windows 7 visual problems on resize
Hi Gordon, But windows 7 and NVIDIA drivers fails and dies a lot for both Opengl and Direct X, and that causes issues even though Window 7 recovers and restarts the driver is sucks up resources leading slowdowns and crashes You see a lot of nvlddmkm.sys problems in the event logs ( there's a lot folks suffering this) Weird, I've been using Windows 7 since the Beta with nVidia cards and I haven't seen this at all (ever). I've been both developing OSG-based apps and gaming on that machine since then. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vista/Windows 7 visual problems on resize
Hello Andrew, When running on Windows 7/Vista using accelerated graphics, and when resizing a window, an MFC OSG window flashes a lot and phantom bits of the window frame are left behind while resizing. The same is seen when using an MFC CRectTracker and TrackRubberBand on the OSG 3D window, the old Rect is not properly erased and the tracks of the box are left behind. This won't help you much, but we haven't seen these kinds of issues with OSG either running its own window or embedded in a QWidget on Windows Vista/7. So perhaps it's a problem with the MFC part of your app. I can't be sure of course, never having used OSG with MFC myself. I hope this additional data point will help... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN 10968 freetype plugin broken on OS X / MacPorts
Hi Robert, Could you have a look to see if you can get CMakeLists.txt configuration that adds in the path to where the headers are. If we can get it working then we may just have to revert the changes for Mingw and force Mingw users to fix there local install of Freetype. Another solution could be to add the necessary path for MinGW to the list of already existing paths (which seem to work for everyone) instead of modifying the existing paths. Additional include paths (that don't resolve to existing directories on your machine) are just ignored by the compiler anyways... But as I said when we started this, I'm perfectly fine with requiring a symlink for MinGW... We've pretty much established that MinGW's paths for freetype are broken at a more basic level anyways. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget::input work
Hi Nick,
However, I started the osgwidgetinput example and for some reason it is
not getting my input from the keyboard.
This is the same problem I noticed in other osgWidget classes lately.
Someone changed the signature of virtual methods in the EventInterface
class (which Widget inherits and thus, all other Widgets too) adding a
const, but didn't change the signature of methods that are supposed to
overload those virtual methods in derived classes. So for example,
EventInterface defines:
virtual bool keyDown (int, int, const WindowManager*) { return false; }
virtual bool keyUp (int, int, const WindowManager*) { return false; }
but Input defines:
virtual bool keyUp (int, int, WindowManager*);
virtual bool keyDown (int, int, WindowManager*);
So there is no compile error, but the base class methods are called
instead of the derived class methods because their argument lists don't
match.
Here's the change for Input. It would be nice to go across all osgWidget
classes and fix this if you have the time. I already did it for Frame a
week or so ago, and this fixes Input, but there are bound to be more.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2008 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
// Code by: Jeremy Moles (cubicool) 2007-2008
#ifndef OSGWIDGET_INPUT
#define OSGWIDGET_INPUT
#include osgWidget/Label
namespace osgWidget {
// This is a string of values we use to try and determine the best Y
// descent value (yoffset); you're welcome to use what works best for
// your font.
const std::string DESCENT_STRING(qpl);
class OSGWIDGET_EXPORT Input: public Label
{
public:
Input(const std::string = , const std::string = , unsigned int =
20);
virtual void parented (Window*);
virtual void positioned ();
virtual bool focus (const WindowManager*);
virtual bool unfocus (const WindowManager*);
virtual bool keyUp (int, int, const WindowManager*);
virtual bool keyDown (int, int, const WindowManager*);
void setCursor(Widget*);
unsigned int calculateBestYOffset (const std::string = qgl);
void setXOffset(point_type xo) {
_xoff = xo;
}
void setYOffset(point_type yo) {
_yoff = yo;
}
void setXYOffset(point_type xo, point_type yo) {
_xoff = xo;
_yoff = yo;
}
osg::Drawable* getCursor() {
return _cursor.get();
}
const osg::Drawable* getCursor() const {
return _cursor.get();
}
point_type getXOffset() const {
return _xoff;
}
point_type getYOffset() const {
return _yoff;
}
XYCoord getXYOffset() const {
return XYCoord(_xoff, _yoff);
}
protected:
virtual void _calculateSize(const XYCoord);
void _calculateCursorOffsets();
point_type _xoff;
point_type _yoff;
unsigned int _index;
unsigned int _size;
unsigned int _cursorIndex;
unsigned int _maxSize;
std::vectorpoint_type _offsets;
osg::ref_ptrWidget_cursor;
};
}
#endif
// -*-c++-*- osgWidget - Code by: Jeremy Moles (cubicool) 2007-2008
#include osg/io_utils
#include osgWidget/WindowManager
#include osgWidget/Input
namespace osgWidget {
Input::Input(const std::string name, const std::string label, unsigned int
size):
Label(name, label),
_xoff(0.0f),
_yoff(0.0f),
_index (0),
_size(0),
_cursorIndex (0),
_maxSize (size),
_cursor (new Widget(cursor)) {
_text-setAlignment(osgText::Text::LEFT_BOTTOM_BASE_LINE);
_text-setKerningType(osgText::KERNING_NONE);
// Make the cursor un-copyable.
_cursor-setCanClone(false);
_cursor-setDataVariance(osg::Object::DYNAMIC);
_cursor-setColor(0.0f, 0.0f, 0.0f, 1.0f);
setEventMask(
// For showing/hiding the cursor.
EVENT_MASK_FOCUS |
// For keypresses, obviously.
EVENT_MASK_KEY |
// For click focusing.
EVENT_MOUSE_PUSH
);
_offsets.resize(size, 0.0f);
Re: [osg-users] Feedback sought on future of osgIntrospection
Hi Robert, Ooo the torrent of posts on this topic is rather daunting... ;-) I personally don't have anything to say, I haven't used osgIntrospection at all... But I've been following the development of the new extensible plugin, and if you can do the same thing with less code and a more manageable infrastructure, why not? :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] getWorldMatrices of Node
Hi MArtin, Danny, It isn't, worldmatrices is a list of all the individual matrices up the leg to the top. No - getWorldMatrices() returns the list of the localToWorld matrices for all paths from the node to the root. So if your node has only one path from itself to the root, then getWorldMatrices() will return only one matrix as it does for you. So in other words, it doesn't return every matrix from the node to the root, it returns a single matrix for each path which contains the whole transform from local to world space. This is because a scene graph in OSG is not a tree (where each node would have a single parent) but a DAG (directed acyclic graph - where each node may have multiple parents). So there may be multiple paths from any node to the root. Only you can know if there is only one, OSG can't know this, so it gives you a function to get localToWorld matrices for all paths and then lets you decide if you want to use just one of them, all of them, or whatever you want. And if you look at what the for loop does, it gives you a different osg::Vec3 for each element of worldMatrices... So that's a different world-space position for each path from the node to the root. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean : GameDev have nice screenshot of ocean rendering.
Hi Adrian, Just FYI http://www.gamedev.net/community/forums/topic.asp?topic_id=558794 Yep, I saw the paper, here are a few more links: The paper itself: http://hal.archives-ouvertes.fr/inria-00443630 The author's page: http://evasion.inrialpes.fr/~Eric.Bruneton/ Looks great, something like that could be integrated as another OceanTechnique in osgOcean if someone wants to do it :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MinGW and OpenSceneGraph
Hi Laurence, @Jean-S (1) libjpeg That's strange, I don't know if mingw32 on ubuntu is using the same files as on windows. I'm currently not using the offical verison of MinGW (latest verison 5.1.6, http://sourceforge.net/projects/mingw/files/) because it is using a GCC compiler version 3.x. Instead I'm using a build from http://nuwen.net/mingw.html#download (currently using 4.3) which is bundled with a more recent GCC compiler (version 4.3.3). The package also includes libjpeg version 7. Yes, and I'm using the same installer to test with. I actually started with your tutorial on installing MinGW and MSYS, and then customized a few things. :-) (2) freetype While this indeed solve the issue without modifying the code, it moves the problem to the shell. Since users still need to manually type this fix... But I think it's better to make the code general and let links handle the difference than the opposite. Else the code becomes a spaghetti of #if(MINGW) #elsif(...) ... A symlink is a simple and clean way to make your system's directory structure look more standard. Since thousands of developers actively use OSG on various flavors of Linux, and it uses freetype/..., I think making MinGW follow this (even if by default it puts the headers in freetype2/...) is a more general solution. (3) curl That should probably do the trick, I'll see if I can make it work. I've actually fixed the problem in my local checkout at home, but I had a few more tests to do yesterday and it was late so I opted to go sleep and send the fixes tomorrow (today). So I will hopefully send the fixes I needed to use to build OSG on MinGW/MSYS tonight. I had a few more fixes to make than what you said, but perhaps they're in things you didn't opt to compile, like osgmovie, osgviewerSDL, the TXP plugin, ... Stay tuned, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling rendering
Hi Guy, This might sound like an odd question, but is there a way to disable rendering (no culling and no draw) while still allowing intersections. The reason why I am asking is because I have a distributed system - i.e. some applications only performs intersections with the scene without rendering it. In addition, the osg update call must still occur since that's where some of my animation states gets uptate, which will change the outcome of intersection results (like sprites). Intersections are completely separate from cull and draw, so you can always do intersections even if no rendering is happening. But the hard part is getting the update visitor to run on your subgraph but not the cull visitor (the results of the cull visitor are used for rendering, so if the cull visitor doesn't run on a subgraph then that subgraph will not be rendered). There's a few ways to do it, I guess I would do that with a cull callback set on the root node of the subgraph you don't want to render, and which doesn't call traverse(node, nv);. That way the cull traversal will stop there for that subgraph, and won't visit the children. But since there's no similar update callback, the update traversal will traverse the whole thing. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MinGW and OpenSceneGraph
Hi Laurence, While creating this tutorial I found some minor issues (In the tutorial I explain how to patch it): I have just sent the fixes I could come up with to osg-submissions. You can look at the message here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/6738 You can also download the zip with the modified source files. If you want to try, please download it and copy the unzipped directory structure over a fresh SVN checkout of the OSG source and see if you have less problems. For now though I have opted to keep the solution I gave for the freetype plugin, i.e. cd /mingw/include ln -s freetype2 freetype We'll see what Robert says about that, but I personally think it's better to have a standard path, and if one type of system has a different path then use symlinks to make it conform to the standard. Other than that, I had more issues than you apparently had, but I hope most if not all of them are fixed by my changes. I tested what I could and almost everything worked as it should (sound in osgmovie and the Qt examples being the only exceptions). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent node cast shadow with ShadowMap?
Hello Dominic, I would like to have my object cast a shadow to its environment with ShadowMap and ShadowedScene. This works, but - like ShadowMap defines - there are shadows on the object self. It is not possible to turn off these shadows, is it? The ShadowMap-based techniques only honor the CastShadow node mask. If you need to have a node to not receive shadows, you'll need to create a custom shader (you can base it on the shaders which are applied by default to ShadowMap-based techniques, which can be found in the source .cpp file for the technique (in src/osgShadow) and then add for example a uniform bool receivesShadow, which you'll set to true on your root node and false on your node which you don't want to have shadows on it. Then in the shader you check that uniform before doing the shadow map lookup. However if you need a node to cast shadows on all but itself, and receive shadows from all bit itself, I'm not sure how you'd achieve that. What I describe above will result in the node casting shadows on everything, but not receiving shadows from anything (including itself). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Can't export OSG to 3DS in 2.9.6 and can't build osgIntrospection Lib
Hello Agostinho, Regarding the compilation problem, it was solved, as you said. But I think that info should be in the documentation or in a readme file, because it's so important, or if it is there, it should be made more visible because I searched a lot and still couldn't find it. The CMake options are documented in their description which you'll see if you hover over them. Of course, documentation can always be improved. I don't know if there's a page on the Wiki which describes the common CMake options. Well, now I have 277MB of compiled files of the new version, which includes, all the libs, examples, 3rdparty, with added lib2xml (which I got it myself and added to the project). Now I think it would be fair for me to share it with the world, but I don't know if there is a place where I can upload such volume of files. Is there? There are binaries on www.openscenegraph.org, but only for stable releases. If a developer wants a developer release it's expected that they'll compile it themselves, so I don't think it's that useful to put binaries of dev releases on the web site (Robert may disagree). Regarding the problem about converting to .3ds, it's really weird. I'll have to let Sukender check your files out, as he developed the 3ds write functionality. Sukender, see the link below for the zip file Agostinho attached to his post. Attachments: http://forum.openscenegraph.org//files/debug_info_3ds_plugin_107.zip J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText issue
Hi Nick, I am trying to write some more sophisticated input control on top of osg. The one in osgWidget::Input is ok but I am to get it more feature rich. Now, I have all the code almost done, and I come accross one issue: I can't really help except to tell you that Jeremy Moles who wrote osgWidget came across this issue when writing osgWidget::Input, and posted here, and at that time no one had any help to offer. I hope you can find a way to do what you want, and then improve osgWidget::Input with that functionality! J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText issue
Hi Nick, one thing I dont like on osgWidget::Input is how inefficiently works with the text so I wrote my own Do you have the time to try and improve osgWidget::Input? If you find it inefficient chances are others will too (for example me :-) I will probably use it in the near future), but I think it's just not being used a lot by other OSG users yet. Another benefit to you is that if you can improve osgWidget::Input to the point where you can use it yourself (instead of writing your own widget) then maintenance of the code shifts and you have less code to maintain on your side... 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
