Re: [osg-users] indices
Hi Renato, I haven't read your other postings, but to answer this and in anticipation of what your next questions may be, I'd like to point you to a site that will help with a lot of what goes on under the hood. First to answer your question go and read this little primer on modern opengl vertex arrays: http://www.songho.ca/opengl/gl_vertexarray.html It will explain what is going on under the hood of OpenSceneGraph. What OSG does is get rid of you having to maintain all of the opengl state and focus on the data. Your question about the index array is directly answered there. Dig around the top pages and you will most likely find the answers to your future questions: http://www.songho.ca/opengl/ OSG uses transpose matrices. You don't have to understand that to use OSG, but if you know linear algebra and are planning on manipulating matrices by hand you need to know that. Good luck! -K On Thu, 1 Mar 2012, Renato Oliveira wrote: Hi, Sorry for this question, but i want to know exaclty what is an indice and what is used for. the way that i understood is basicly an ID number to the vertexes? i am a completly noob in 3D graphics programming and some terms i quite dont understand yet. Thank you! Cheers, Renato -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45936#45936 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Keith ParkinsU of R Center for Visual Science Meliora Hall, Room 253 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hard coded Arial font
You can set the font.
osg::ref_ptrosgText::Font font = osgText::readFontFile('yourfont.ttf');
osg::ref_ptrosgText::Text txt = new osgText::Text;
txt-setFont(font.get());
-K
On Tue, 13 Dec 2011, Thomas Lerman wrote:
I see arial.ttf referred 13 times, most of which are hardcoded in the fonts
directory. Most of my development has been on Windows and that font is
standard. Recently, I did some stuff on Linux where Arial is not a default font
and therefore text looked pretty ugly. It was somewhat of a pain to get the
font installed and ended up just copying arial.ttf in with my application. It
sure would be nice to be able to set some configuration to be able to change
which font is used.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44367#44367
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hard coded Arial font
Yes, you are correct that this wouldn't help with StatsHandler or
HelpHandler. For StatsHandler you might be able to get away with
deriving a class like this:
class MyStatsHandler : public osgViewer::StatsHandler {
public:
MyStatsHandler() : _font(myfont.ttf) {}
};
otherwise you can just set _font in the constructor.
HelpHandler isn't so easy. You should look at HelpHandler.cpp to get a
feel for the geometry layout, and derive a subclass or use a NodeVisitor
to walk the geometry and update those fonts.
I think that those are the only two classes that make the osg core and use
fonts though (osgAnimation/StatsHandler.cpp and osgShadow/ShadowMap.cpp
also have fonts hardcoded).
I don't believe that there is a cureall solution though.
-K
On Tue, 13 Dec 2011, Thomas Lerman wrote:
Would that not set the font for those created objects and not for the system? In
other words, I believe things like StatsHandler HelpHandler would still use
the hard-coded fonts. Am I missing something?
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44369#44369
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] unexpected behavior
Hi Robert, Thanks for the help. It was late and I was stuck, but you definitely pointed me in the right direction. The one non-stock piece that ended up being the culprit was the computeHomePosition method in my camera manipulator. I ended up dumping camera information to see the difference between the home position (as well as checking the clip near/far clip planes) when both models were loaded and when only my model was loaded. thanks again for all your work! -K On Tue, 27 Sep 2011, Robert Osfield wrote: HI Keith, From the scant details and the number of variables that could effect thigns we can only guess what might be the problem. My best guess would be that perhaps the sky dome is very large so pushing the far plane and the near plane with it, such that the near plane is clipping out the geometry you are expecting to see. Robert. On Tue, Sep 27, 2011 at 3:20 AM, Keith Parkins kpark...@cs.rochester.edu wrote: Hi all, I am having the weirdest problem. I have generated a scene graph with a pre-render camera that does the skydome and then this: osg::ref_ptrosg::Group root = new osg::Group; root-setName(root); setSceneData(root.get()); osg::ref_ptrmear::SkyDome sky = new mear::SkyDome; sky-setView(this); root-addChild(sky.get()); // for testing //root-addChild(osgDB::readNodeFile(GH_Geometry_6_29_11.osgb)); root-addChild(osgDB::readNodeFile(/home/keith/GH_Geometry_6_29_11.osgb)); root-addChild(osgDB::readNodeFile(cow.osgt)); Now, if I leave the fullpath GH model and the cow in there, I see the GH model and the cow. If I comment out the GH model line, I just see the cow. If I leave the fullpath model loaded and comment the cow out I don't see anything (except the sky). This is called from a View setup in a CompositeViewer/QWidget. bizarre, -Keith ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] unexpected behavior
Hi all, I am having the weirdest problem. I have generated a scene graph with a pre-render camera that does the skydome and then this: osg::ref_ptrosg::Group root = new osg::Group; root-setName(root); setSceneData(root.get()); osg::ref_ptrmear::SkyDome sky = new mear::SkyDome; sky-setView(this); root-addChild(sky.get()); // for testing //root-addChild(osgDB::readNodeFile(GH_Geometry_6_29_11.osgb)); root-addChild(osgDB::readNodeFile(/home/keith/GH_Geometry_6_29_11.osgb)); root-addChild(osgDB::readNodeFile(cow.osgt)); Now, if I leave the fullpath GH model and the cow in there, I see the GH model and the cow. If I comment out the GH model line, I just see the cow. If I leave the fullpath model loaded and comment the cow out I don't see anything (except the sky). This is called from a View setup in a CompositeViewer/QWidget. bizarre, -Keith ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] VRML plugin: help in compiling
Hi Paolo, The openvrml loader is basic right now and cannot handle any VRML file. I suspect that this is what you are running into. If you look at the function convertFromVRML (ReaderWriterVRML2.cpp:~247) you will find that the loader can only handle Group, Transform, and Shape nodes, a subset of openvrml. There have been dynamic casts in there in the past that didn't test for null (failed) results which in turn would cause a crash. If you want to test whether this is the cause of your problem, you should probably start by monitoring entry to the above function and checking the openvrml node type by looking at obj-type().id() (returns a string with node type). You could also look through your vrml file and see whether it uses tags other than the ones mentioned above. -Keith On Wed, 7 Sep 2011, Paolo Piazzi wrote: rmilh wrote: I don't have VS2010. My libs and dlls are build with VS2008. What does the compiler say when yout try to build openvrml-dl project? Maybe the main project openvrml is missing a dependency to the openvrml-dl.lib. openvrml-dl project was built correctly. I added a dependency to openvrml-dld.lib to openvrml project too. Now the osgviewerd.exe can fing the wrl plugin, but it gives me this error in http://imageshack.us/photo/my-images/685/errorosg.jpg/ -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42489#42489 Keith ParkinsU of R Center for Visual Science kparkins at cvs.rochester.edu Meliora Hall, Room 253 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG VRML plugin
class/struct/union 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(101): error C2064: term does not evaluate to a function taking 0 arguments 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(101): error C2228: left of '.size' must have class/struct/union 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(103): error C2064: term does not evaluate to a function taking 0 arguments 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(117): error C2440: 'initializing' : cannot convert from 'const openvrml::field_value' to 'std::auto_ptr_Ty' 2 with 2 [ 2 _Ty=openvrml::field_value 2 ] 2 No constructor could take the source type, or constructor overload resolution was ambiguous 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(119): error C2064: term does not evaluate to a function taking 0 arguments 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(119): error C2228: left of '.get' must have class/struct/union 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(136): error C2440: 'initializing' : cannot convert from 'const openvrml::field_value' to 'std::auto_ptr_Ty' 2 with 2 [ 2 _Ty=openvrml::field_value 2 ] 2 No constructor could take the source type, or constructor overload resolution was ambiguous There are more errors, but all of them are similar. Any ideas about what?s wrong? Thank you. Héctor Keith ParkinsU of R Center for Visual Science kpark...@cvs.rochester.edu Meliora Hall, Room 253 office: (585) 275-2460 lab: (585) 275-2230___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] vrml plugin for 2.9.14
Hi all,
I was playing around with the dev release 2.9.14 on Windows (not the
latest svn) and had to play around with some build files to get it to
compile. I'm no guru on cmake by any stretch, but to compile the plugin I
had to edit one of the cmake files. First though, I downloaded openvrml
0.17.12 and used my existing boost build (1.44.0 the plugin readme says
to use an older version of boost, but I think this version works too). I
noticed that cmake wanted to find openvrml _antlr and _regex libraries,
but both are no longer used in openvrml. I commented out the following
lines in src/osgPlugins/vrml/CMakeLists.txt:
#FIND_LIBRARY(OPENVRML_ANTLR_LIBRARY
#NAMES antlr.lib
#PATHS $ENV{OPENVRML_DIR}/lib)
#FIND_LIBRARY(OPENVRML_ANTLR_LIBRARY_DEBUG
#NAMES antlrd.lib
#PATHS $ENV{OPENVRML_DIR}/lib)
#FIND_LIBRARY(OPENVRML_REGEX_LIBRARY
#NAMES regex.lib
#PATHS $ENV{OPENVRML_DIR}/lib)
#FIND_LIBRARY(OPENVRML_REGEX_LIBRARY_DEBUG
#NAMES regexd.lib
#PATHS $ENV{OPENVRML_DIR}/lib)
and
SET(TARGET_LIBRARIES_VARS
#OPENVRML_ANTLR_LIBRARY
#OPENVRML_REGEX_LIBRARY
OPENVRML_LIBRARY
JPEG_LIBRARY
PNG_LIBRARY
ZLIB_LIBRARY)
Then I was able to run cmake without a problem.
The last thing I had to do was to set one of the use/build macros
defined in the openvrml library file openvrml-config.h. You need
to choose either OPENVRML_USE_DLL or OPENVRML_USE_LIB depending on
whether you are linking to dynamic or static libs. In VisualStudio, you
just open up the properties window, find the Preprocessor menu under
Configuration Properties-C/C++. Then click Preprocessor Definitions
and add eitherOPENVRML_USE_DLL or OPENVRML_USE_LIB.
I didn't notice any mention of this in the osg-users list, so I thought
I'd send this out in case anyone else had this problem. If there is a
cleaner solution that I missed, please do correct me.
Thanks,
-K
Keith ParkinsU of R Center for Visual Science
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera intrinsics
Hi Benedikt,
I don't have time to look at this right now, but off the top of my head
the sign difference that you noticed may be because I grabbed this from
a reverse projection that I did (the projection was bounced off some
mirrors to a back projection which in turn was viewed by looking into
another mirror). So if everything was flipped when you tried this, that
was probably the reason why.
-K
On Wed, 6 Apr 2011, benedikt naessens wrote:
Keith Parkins wrote:
After looking at this again, I am unclear as to whether you have built
the projection matrix from the intrinsic parameters. I was assuming that
you had made it by hand. To do that you would do something like this:
//-//
// The _intrinsic variable holds the five values for the intrinsic
// matrix. The intrinsic * our pixel transform to get the projections
// matrix. The intrinsic values (itr[]) are given as five doubles
// such that:
//
//| itr[0] itr[1] itr[2] |
//| 0itr[3] itr[4] |
//| 0 0 0 |
//
//| alpha_u gamma u_0 |
//| 0alpha_v v_0 |
//| 0 0 0 |
//
//-//
void
-Camera::calcProjection() {
double alpha_u, alpha_v;
// calc alphas
alpha_u = _intrinsic[0];
double cot_theta = - _intrinsic[1]/_intrinsic[0];
double sin_theta = sqrt(1/(1+cot_theta*cot_theta));
alpha_v = _intrinsic[3] * sin_theta;
double skew = _intrinsic[1];
double u0, v0;
u0 = _intrinsic[2]; v0 = _intrinsic[4];
double left = -u0 / alpha_u * _near;
double bottom = (_screen_height-v0) / alpha_v * _near;
double right = (_screen_width - u0) / alpha_u * _near;
double top = -v0 / alpha_v * _near;
_projection[0] = 2 * _near / (right - left);
_projection[4] = 2 * _near * skew / ((right - left) * alpha_u);
_projection[5] = 2 * _near / (top - bottom);
_projection[8] = -(right + left)/(right - left);
_projection[9] = -(top + bottom)/(top - bottom);
_projection[10] = (_far + _near) / (_far - _near);
_projection[11] = 1;
_projection[14] = -2 * _far * _near/(_far-_near);
|}
/lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Post generated by Mail2Forum[/quote]
There seems to be a mismatch between the projection matrix generated by e.g.
makePerspective and the projection matrix elements you suggest here.
When I do the comparison between the two, it seems that:
_projection[5], _projection[8], _projection[9] and _projection[11] have
opposite signs.
I'm also a bit surprised that the projection matrix generated by OSG
(makePerspective) has -1 instead of 1 for _projection[11]. Maybe that has
something to do with the inversion of the Y axis (0,0 in the bottom left
instead of the top left) ?
Can you give me a suggestion why these differences exist ?
Thanks !
Benedikt.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38253#38253
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Keith ParkinsU of R Center for Visual Science
kpark...@cvs.rochester.edu Meliora Hall, Room 253
office: (585) 275-2460 lab: (585) 275-2230
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
Once again, thanks to everyone who has offered help. I ended up setting breakpoints on the five glBegin calls in Geometry.cpp, yet my code doesn't seem to hit any of them. This is running on WindowsXP/NVidia gtx260 (drivers 6.14.12.5721) if that makes a difference. I know when I run stuff on my linux box at home, I have to use fluxbox instead of gnome because gnome kills my frame rate in the same way I am seeing on the WindowsXP box. In gnome, I can run the scene and I'll get horrible ~10fps while in fluxbox it gets ~400fps. Because of hardware requirements, I have to run this on XP. I can't seem to find any other glBegin entry points. Does anyone have any suggestions? I checked to make sure that I wasn't explicitely dirtying the display lists. Thanks again! -K On Wed, 1 Dec 2010, Keith Parkins wrote: Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
Hi J-S and Robert, I was using a debug build. I'm trying out a release build, but I am swamped and trying to do a bunch of things. I'll get back sometime in the next day with my results. I'm hoping this is it because the one difference between osgviewer and my app is that I am using debug libs. of STL usage at runtime in Debug builds - don't argue that it's a bad thing to do, I agree, but I'm not Microsoft...) Trust me, I'm not going to get into any design arguments. People in glass houses and all . . . . Unless you want to get into some text editor argument (all hail ed!!). Those seem productive. ;-) -K On Thu, 2 Dec 2010, Jean-Sébastien Guay wrote: Hi Robert, I don't know if this is relevant, but for all performance testing you should use an optimized build, debug builds, especially using VS totally destroy performance. He could still be using an optimized build and setting breakpoints, as debug information settings are separate from optimization settings, and as long as you're in a Release build, you won't be using the debug STL (which is what destroys OSG's performance in Debug builds - since OSG uses the STL heavily in its traversals and VC++ does extensive/expensive checking of STL usage at runtime in Debug builds - don't argue that it's a bad thing to do, I agree, but I'm not Microsoft...) We sometimes include debug info in Release builds to be able to debug some problems that happen only in optimized builds. Sometimes the stack traces it gives then is bogus because of the optimization, but it's still useful if you know what to do with 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
J-S and Robert, You rule! That was it. Don't link to debug libraries on Windows -K On Thu, 2 Dec 2010, Jean-Sébastien Guay wrote: Hi Keith, I was using a debug build. I'm trying out a release build, but I am swamped and trying to do a bunch of things. I'll get back sometime in the next day with my results. I'm hoping this is it because the one difference between osgviewer and my app is that I am using debug libs. Ah, so my apologies to Robert, he was right to mention it. I thought that had been mentioned at the beginning of the thread, but it must have been another thread. As both Robert and I said, doing any kind of performance measurement in VC++ in Debug builds will lead to bad results (unrepresentative of the real performance). I've seen cases where the performance from one run to the next was totally different, with no changes to source code, with Debug builds. So try to find out what's slowing down the program in that case... :-) But using a Release build (optimization turned on, Release C++ runtime, Release STL) with debugging symbols turned on (/Z* compiler options and /DEBUG linker option) is fine, performance will be a bit slower but still representative. And another part of the equation is running in the debugger or not. Pressing F5 attaches the debugger, whether in Debug or Release builds. That slows things down a bit too (because the debugger can show you what DLLs have been loaded while it's happening, things like that). Pressing Ctrl-F5 does not attach the debugger, whether in Debug or Release builds. You always have the option to attach it later (when a crash happens, or when you get to the point in your app that you want to trace), by using the Debug - Attach to Process menu option. If doing performance testing, I will use a Release build, no debugging symbols, and press Ctrl-F5 to get accurate results (the same as an end-user would get on my machine). I've seen especially large slowdowns when running in the debugger versus not running in the debugger (even with Release builds) when using boost::persistence, but that's just one example. So in that case I might start with Ctrl-F5, load our data files (which is done with boost::persistence), and then attach the debugger once boost::persistence has finished doing its 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] debugging slow path
Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
So I added a nodevisitor to traverse my scene like so:
class checkFastPath : public osg::NodeVisitor {
public:
checkFastPath() :
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}
virtual void apply(osg::Geode geode) {
for(unsigned int i=0;igeode.getNumDrawables();++i) {
osg::Geometry*geometry =
geode.getDrawable(i)-asGeometry();
if (geometry) {
std::string name = geometry-getName();
if (!geometry-areFastPathsUsed())
std::cout name is not using fast path\n;
}
}
}
checkFastPath fptest;
getSceneData()-accept(fptest);
Nothing comes up. I did have an else on this test
(!geometry-areFastPathsUsed()) to make sure that I was hitting the
conditional. I did the same test before quitting and nothing comes up,
neither after initialization nor at the end.
Any ideas? Are there any other roads to the short path?
On Wed, 1 Dec 2010, Keith Parkins wrote:
Hi,
My app is currently rendering via the slow path. I've checked for
DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either.
Dose anyone know of other things I should be looking for? I am walking
through the rendering stage to see if I can figure out what is getting set
that is putting me on the slow track, but I don't have endless amounts of
time to do this. If anyone has any understanding of this, I would be most
appreciative if you could point me in the right direction.
If you need more information, check my post FBO problem?
Thanks!
Keith
PS: Thanks a lot for the help, Jason.
On Tue, 30 Nov 2010, Jason Daly wrote:
On 11/30/2010 08:09 PM, Keith Parkins wrote:
I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL);
and I did see a model with NormalBinding PER_VERTEX. Should I be
setting
these to BIND_OFF or is it just BIND_PER_PRIMITIVE?
No, BIND_PER_PRIMITIVE is the bad binding. All of the others are
fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes,
I'm not sure why you'd be falling off the fast path. There may be other
reasons for it, but I can't think of them...
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FBO problem? (fwd)
A follow-up: I used an opengl tracer and found that in my app there are calls to glBegin and glEnd while in the osgviewer dump there aren't any. I am using the same models in both. glNormal3fv has 6 calls in osgviewer, yet mine has 426974. Any ideas on how that happened? I am not knowingly using DrawArrayLengths, but I DID use some DrawArrays (w/o indices). -- Forwarded message -- Date: Tue, 30 Nov 2010 14:43:20 -0500 (Eastern Standard Time) From: Keith Parkins kpark...@cs.rochester.edu To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: FBO problem? Hi, I'm working on a driving simulator. I have been having problems meeting my frame rate requirements. I spent a lot of time tuning the scene, making sure that I wasn't using DrawArrayLengths, using instances of geometry, instances of blocks of buildings as a tile (5 blocks get repeated over 25 possible locations), and flattening static tranforms. In the end, I was still hitting massive cull times and massive draw(GPU) times. I wrote some portal culling type algorithm for culling blocks depending on where in the grid the camera is and I am still getting ~26Hz over large areas of the town. I finally dumped the scene out to a file and loaded that with osgviewer. I got 60Hz without a sweat; vsync is locked and there is no custom culling. The bug must be in the rendering, not the scene itself. My main viewer has a couple of cameras hanging off of it as a switch node depending on what screen I'm in. The main view gets added like this: getSceneData()-asGroup()-addChild(_town_view.get()); _town_view is derived from a osg::Camera and points to a screen with a texture attached to an FBO. We are projecting the screen onto a curved surface, so this is done for the geometry correction phase. The screen mesh is static. The RTT camera is initialized like this: _camera-setClearColor(osg::Vec4(0.0,0.0,0.0,1.0)); _camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); _camera-setViewport(0, 0, (int)TEX_W, (int)TEX_H); _camera-setRenderOrder(osg::Camera::PRE_RENDER); _camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); _camera-setViewMatrixAsLookAt(_pos + _head_pos + _eye_pos, _pos + _head_pos + _eye_pos + rotate * _dir, _up); _camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); _view_root-addChild(_camera.get()); _camera-addChild(_scene_root.get()); _scene_root is the scene that I wrote out and tested. I am using bullet to control the car physics, but right now I only have it registering a plane where the road is. In other words it's just moving the camera and doing isects with the plane, very simple. I've stripped out all extraneous code, including physics, and just have town loading and am still having the same problem. the scene: class myviewer: osg::Viewer sceneData - class townview : osg::Camera(NESTED_RENDER) townview-child - geode screen w/ RTT texture townview-child - RTT _camera(PRE_RENDER) _camera- _scene_root using osgviewer: Camera 0 Bins 2 Materials 2265 Drawables 2265 Vertices 59835 View 0 Stateset706 5080 Group 480 2127 Transform 213 459 Geode 757 4616 Drawable827 5040 Geometry827 5040 Vertices35574 1000261 Prims 21287 60407 Framerate: 60Hz my app: Camera 0 Bins 3 Materials 1939 Drawables 1939 Vertices 51436 View 0 Stateset608 1982 Group 75 273 Transform 192 227 Geode 237 1032 Drawable825 1965 Geometry825 1965 Vertices35374 51799 Prims 20490 29791 Framerate: 20Hz I've walked through the culling section of the code, added cull callbacks to nodes, and the only thing I can verify is that it just takes forever culling each block in my app. My app marks which blocks are visible during an update traversal and only does so when the camera switches to another grid co-ordinate. My app should be visiting less nodes (verified in callbacks and View output above) and yet it is getting nailed. You can see that I flatten Transforms above. What is happening I'm at my wits end on this. I thought that I was visiting nodes more than once on the culling traversal, but my node callbacks don't show that; they just confirm that the majority of the time spent culling is in each block. I've attached two images of the stats screen. The myapp image is using the default lighting like osgviewer which is why you can't see the skymap in it. Please help! -K ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO problem? (fwd)
Okay, DrawArrays also uses the slow path. I was under the impression that only DrawArrayLengths were. The only hint I had of this before digging through the source was a posting here that said not to use DrawArrayLengths. Maybe a warning should be put in the doxygen file for those primitives? -K On Tue, 30 Nov 2010, Keith Parkins wrote: A follow-up: I used an opengl tracer and found that in my app there are calls to glBegin and glEnd while in the osgviewer dump there aren't any. I am using the same models in both. glNormal3fv has 6 calls in osgviewer, yet mine has 426974. Any ideas on how that happened? I am not knowingly using DrawArrayLengths, but I DID use some DrawArrays (w/o indices). -- Forwarded message -- Date: Tue, 30 Nov 2010 14:43:20 -0500 (Eastern Standard Time) From: Keith Parkins kpark...@cs.rochester.edu To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: FBO problem? Hi, I'm working on a driving simulator. I have been having problems meeting my frame rate requirements. I spent a lot of time tuning the scene, making sure that I wasn't using DrawArrayLengths, using instances of geometry, instances of blocks of buildings as a tile (5 blocks get repeated over 25 possible locations), and flattening static tranforms. In the end, I was still hitting massive cull times and massive draw(GPU) times. I wrote some portal culling type algorithm for culling blocks depending on where in the grid the camera is and I am still getting ~26Hz over large areas of the town. I finally dumped the scene out to a file and loaded that with osgviewer. I got 60Hz without a sweat; vsync is locked and there is no custom culling. The bug must be in the rendering, not the scene itself. My main viewer has a couple of cameras hanging off of it as a switch node depending on what screen I'm in. The main view gets added like this: getSceneData()-asGroup()-addChild(_town_view.get()); _town_view is derived from a osg::Camera and points to a screen with a texture attached to an FBO. We are projecting the screen onto a curved surface, so this is done for the geometry correction phase. The screen mesh is static. The RTT camera is initialized like this: _camera-setClearColor(osg::Vec4(0.0,0.0,0.0,1.0)); _camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); _camera-setViewport(0, 0, (int)TEX_W, (int)TEX_H); _camera-setRenderOrder(osg::Camera::PRE_RENDER); _camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); _camera-setViewMatrixAsLookAt(_pos + _head_pos + _eye_pos, _pos + _head_pos + _eye_pos + rotate * _dir, _up); _camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); _view_root-addChild(_camera.get()); _camera-addChild(_scene_root.get()); _scene_root is the scene that I wrote out and tested. I am using bullet to control the car physics, but right now I only have it registering a plane where the road is. In other words it's just moving the camera and doing isects with the plane, very simple. I've stripped out all extraneous code, including physics, and just have town loading and am still having the same problem. the scene: class myviewer: osg::Viewer sceneData - class townview : osg::Camera(NESTED_RENDER) townview-child - geode screen w/ RTT texture townview-child - RTT _camera(PRE_RENDER) _camera- _scene_root using osgviewer: Camera 0 Bins 2 Materials 2265 Drawables 2265 Vertices 59835 View 0 Stateset706 5080 Group 480 2127 Transform 213 459 Geode 757 4616 Drawable827 5040 Geometry827 5040 Vertices35574 1000261 Prims 21287 60407 Framerate: 60Hz my app: Camera 0 Bins 3 Materials 1939 Drawables 1939 Vertices 51436 View 0 Stateset608 1982 Group 75 273 Transform 192 227 Geode 237 1032 Drawable825 1965 Geometry825 1965 Vertices35374 51799 Prims 20490 29791 Framerate: 20Hz I've walked through the culling section of the code, added cull callbacks to nodes, and the only thing I can verify is that it just takes forever culling each block in my app. My app marks which blocks are visible during an update traversal and only does so when the camera switches to another grid co-ordinate. My app should be visiting less nodes (verified in callbacks and View output above) and yet it is getting nailed. You can see that I flatten Transforms above. What is happening I'm at my wits end on this. I thought that I was visiting nodes more than once on the culling traversal, but my node callbacks don't show that; they just confirm that the majority of the time spent culling is in each block. I've attached two images of the stats screen. The myapp image is using the default lighting like osgviewer which is why you can't see the skymap in it. Please help! -K ___ osg
Re: [osg-users] FBO problem? (fwd)
On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 04:23 PM, Keith Parkins wrote: Okay, DrawArrays also uses the slow path. I was under the impression that only DrawArrayLengths were. The only hint I had of this before digging through the source was a posting here that said not to use DrawArrayLengths. My understanding was that neither DrawArrays nor DrawArrayLengths would use slow paths (they should both be using glDrawArrays(), which is fast). Unfortunately, I can't deduce from the information you've provided why you'd be falling onto the slow path. Are you using attribute indices on your Geometry (setVertexIndices(), setNormalIndices(), etc.)? Are you using BIND_PER_PRIMITIVE for any of your attributes? Those are the most common reasons. --J I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? Thanks! -K ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CompositeViewer w multiviews event traversals
Hello everyone, I am trying to use multiple views where only one view should show at a time, and where each view has GUIEventHandlers that handle the same input controls (a usb gamepad say) differently. I was going to use nodemasks to turn off the maincameras in views that weren't active as mentioned in this thread: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-August/000704.html Do I have to do something special to disable the event traversal/guieventhandler so that the same control will not change some state in the disabled Views? Or is the disabled view separated from all traversals once the main camera mask is zeroed? Thanks! -Keith Keith ParkinsU of R Center for Visual Science kpark...@cvs.rochester.edu Meliora Hall, Room 253 office: (585) 275-2460 lab: (585) 275-2230 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera intrinsics
Use camera-setProjectionMatrix(intrinsic_parameter_matrix); Not sure what you are trying to do with respect to the other question you have. On Tue, 27 Jul 2010, Ricky Flintoff wrote: Hi, I have a quick question. I looked up online on setting camera intrinsics (5 parameters, including radial distortion). Would I be using viewer.getCamera()-setProjectionMatrixAsPerspective(intrinsic_parameter_matrix)? Also, can I do this (with a different matrix) before rendering each frame? Thank you! Cheers, Ricky -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30318#30318 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Keith ParkinsU of R Center for Visual Science ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera intrinsics
After looking at this again, I am unclear as to whether you have built
the projection matrix from the intrinsic parameters. I was assuming that
you had made it by hand. To do that you would do something like this:
//-//
// The _intrinsic variable holds the five values for the intrinsic
// matrix. The intrinsic * our pixel transform to get the projections
// matrix. The intrinsic values (itr[]) are given as five doubles
// such that:
//
//| itr[0] itr[1] itr[2] |
//| 0itr[3] itr[4] |
//| 0 0 0 |
//
//| alpha_u gamma u_0 |
//| 0alpha_v v_0 |
//| 0 0 0 |
//
//-//
void
-Camera::calcProjection() {
double alpha_u, alpha_v;
// calc alphas
alpha_u = _intrinsic[0];
double cot_theta = - _intrinsic[1]/_intrinsic[0];
double sin_theta = sqrt(1/(1+cot_theta*cot_theta));
alpha_v = _intrinsic[3] * sin_theta;
double skew = _intrinsic[1];
double u0, v0;
u0 = _intrinsic[2]; v0 = _intrinsic[4];
double left = -u0 / alpha_u * _near;
double bottom = (_screen_height-v0) / alpha_v * _near;
double right = (_screen_width - u0) / alpha_u * _near;
double top = -v0 / alpha_v * _near;
_projection[0] = 2 * _near / (right - left);
_projection[4] = 2 * _near * skew / ((right - left) * alpha_u);
_projection[5] = 2 * _near / (top - bottom);
_projection[8] = -(right + left)/(right - left);
_projection[9] = -(top + bottom)/(top - bottom);
_projection[10] = (_far + _near) / (_far - _near);
_projection[11] = 1;
_projection[14] = -2 * _far * _near/(_far-_near);
|}
On Tue, 27 Jul 2010, Ricky Flintoff wrote:
Hi,
I have a quick question. I looked up online on setting camera intrinsics (5
parameters, including radial distortion). Would I be using
viewer.getCamera()-setProjectionMatrixAsPerspective(intrinsic_parameter_matrix)?
Also, can I do this (with a different matrix) before rendering each frame?
Thank you!
Cheers,
Ricky
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=30318#30318
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VS 2010 and OSG v2.8.3?
From your log it looks like the only problem you are having, which I encountered as well, is the new C++/stl problem. You need to add: #include iterator to the header file NodeCallBack. This should get rid of most of the errors, but you may have to add the above include to other files as well. Say you build it again and get: 5GraphicsContext.cpp(680): error C2039: 'back_inserter' : is not a member of 'std' 5GraphicsContext.cpp(680): error C3861: 'back_inserter': identifier not found Then add #include iterator to GraphicsContext.cpp. Try just editing NodeCallBack's header because it needs to be there and I think it catches most of the other undeclared back_inserter calls. -K On Thu, 22 Jul 2010, D??enan Zuki? wrote: Hi, I just compile-tested OSG 2.8.3 with VS2010, x64 target. It has build errors (full log attached). Furthermore, I cannot switch to VS2010 because Qt doesn't support it at the moment. Cheers, Dženan Keith ParkinsU of R Center for Visual Science___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RTT single frame
Hi,
I am trying to dynamically make a smaller LOD for a street block
populated with buildings. To do this, I am trying to render different
views into texture memory to apply onto a simple cube during the
scene building section of code before entering the main loop. These are
static images, so I want to render into texture memory once before the
app goes into the main loop.
Right now, I took the osgprerender example as a starting point and
modified the call createPreRenderSubGraph. Instead of adding the camera
with the prerender node to the main scenes subgraph:
// parent-addChild(camera);
osg::ref_ptrosgViewer::Viewer view = new osgViewer::Viewer;
view-init();
view-setCamera(camera);
view-setSceneRoot(prerendernode);
view-frame();
// I attached the color buffer to an image so:
osgDB::writeImageFile(image, imagefilename);
camera-detatch(osg::Camera::COLOR_BUFFER)
return parent;
}
This works except that I am sure it is overkill. If I try to call
renderingTraversals() without realizing the viewer, I don't get
anything. What is the right way to render a single frame into texture
memory? Keep in mind that the above will be a loop:
{ . . .
foreach block:
{ . . . .
foreach cameraposition:
createTexturememory()
camera-attach(color_buffer, tex_mem)
camera-move()
renderframe()
camera-detatch(color_buffer)
// create stateset and node with texture tex_mem
Thanks,
Keith
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems with weather
Hi Jose, Are you applying the fog in your shader? Remember that the GLSL spec states that Fog is not applied once a fragment shader has been supplied. Your shader replaces the fixed function shader that applied the fog. Check out: http://www.idevgames.com/forum/showthread.php?t=12436 for a discussion. The fog equation is easy to understand. Check out chapter 6, Blending etc., in the Red Book if you have problems understanding the code in the above link. -Keith On Tue, 13 Jul 2010, Jose Rincon wrote: Hi, I have a scene with weather(in this case with fog) but in the moment I apply a light shader, the weather dissapears. Is there a possibility of having the weather I had before? Thank you! Cheers, Jose -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29962#29962 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
