Re: [osg-users] Rewriting of the osgt reader (was: Re: Infinite loop at osgt loading)
Hi Wang, I can confirm that your fix works, with the models in OpenSceneGraph-Data-3.0.0 and also with a couple of my own models. I use Windows 7 64 bit and VC++ 2008 Express. Regards, Andreas On 2011-07-01 03:36, Wang Rui wrote: Hi All, A serious problem was found that some newly added .osgt models (spaceship, lz and dumptruck) will cause infinite loop while reading. I've studied into the source code and guessed the reason is that istream under Windows doesn't handle unget() in an expected way. That is, the reading buffer may be filled somehow so that unget() will fail and thus mark the entire stream as 'bad'. The whole loading process will then be locked and that's what we see currently. The problem can be located in osgPlugins/osg/AsciiStreamOperator.h, AsciiInputIterator::matchString() method. I tried handling the stream in some other ways but couldn't work out a good one that could put back characters stablely. To avoid opening another can of worms, finally I decide to rewrite some of the osgt reader and treat the string to be wrote back as a 'pre-read' string that would be handled later before the stream. A quick test shows that these models can be loaded successfully after the modification. Could you please help test the .osgt reader under Windows and other platforms to make sure it can work? It will be appreciated if there are enough feedbacks and bug reports before I could submit the change with security. Thanks, Wang Rui ___ 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] osgSim::MultiSwitch in osgt
Hi,
Another problem with osgSim and osgt: When converting the attached
switch_test.flt to switch_test.osgt with osgconv and then trying it in
osgviewer, I get the following warnings (even if it loads and shows):
AsciiInputIterator::readProperty(): Unmatched property }, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property {, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property FALSE, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property 3, expecting
SwitchSet
I don't know if it's the writing or reading that's failing. Maybe it
would be a good idea to write the line number in these warnings, if it's
possible.
Regards,
Andreas
switch_test.flt
Description: Binary data
#Ascii Scene
#Version 80
#Generator OpenSceneGraph 3.0.0
osg::Group {
UniqueID 1
Name db
UserDataContainer TRUE {
osg::DefaultUserDataContainer {
UniqueID 2
}
}
Children 1 {
osgSim::MultiSwitch {
UniqueID 3
Name sw1
Children 3 {
osg::Group {
UniqueID 4
Name o1
UserDataContainer TRUE {
osg::DefaultUserDataContainer {
UniqueID 5
UDC_UserData {
osgSim::ObjectRecordData {
UniqueID 6
Data Flags 0
RelativePriority 0
Transparency 0
EffectID1 0
EffectID2 0
Significance 0
}
}
}
}
Children 1 {
osg::Geode {
UniqueID 7
Name p1
DataVariance STATIC
StateSet TRUE {
osg::StateSet {
UniqueID 8
DataVariance STATIC
ModeList 2 {
GL_CULL_FACE ON
GL_LIGHTING OFF
}
AttributeList 1 {
osg::CullFace {
UniqueID 9
}
Value OFF
}
}
}
Drawables 1 {
osg::Geometry {
UniqueID 10
DataVariance STATIC
PrimitiveSetList 1 {
DrawArrays GL_QUADS 0 4
}
VertexData {
Array TRUE ArrayID 1 Vec3fArray 4 {
-3 0 -1
-1 0 -1
-1 0 1
-3 0 1
}
Indices FALSE
Binding BIND_PER_VERTEX
Normalize 0
}
ColorData {
Array TRUE ArrayID 2 Vec4fArray 1 {
1 0 0 1
}
Indices FALSE
Binding BIND_OVERALL
Normalize 0
}
}
}
}
}
}
osg::Group {
UniqueID 11
Name o2
UserDataContainer TRUE {
osg::DefaultUserDataContainer {
UniqueID 12
UDC_UserData {
osgSim::ObjectRecordData {
UniqueID 13
Data Flags 0
RelativePriority 0
Transparency 0
EffectID1 0
EffectID2 0
Significance 0
}
}
}
}
Children 1 {
osg::Geode {
UniqueID 14
Name p2
DataVariance STATIC
StateSet TRUE {
osg::StateSet {
UniqueID 8
}
}
Drawables 1 {
osg::Geometry {
UniqueID 15
DataVariance STATIC
PrimitiveSetList 1 {
DrawArrays GL_QUADS 0 4
}
VertexData {
Array TRUE ArrayID 3 Vec3fArray 4 {
-1 0 -1
1 0 -1
1 0 1
-1 0 1
}
Indices FALSE
Binding BIND_PER_VERTEX
Normalize 0
}
ColorData {
Array TRUE ArrayID 4 Vec4fArray 1 {
1 1 0 1
}
Indices FALSE
Binding BIND_OVERALL
Normalize 0
}
}
}
}
}
}
osg::Group {
UniqueID 16
Name o3
UserDataContainer TRUE {
[osg-users] Creating a 0.5 TB osgTerrain Database: Best file format?
Hi, I plan to process a osgTerrain database with more than 1 TB source data with VPB. The last version I processed was a .ive database. Now we have the new standard file formats osgx, osgt and osgb. Which would be the best choice regarding runtime performance and regarding size? My current coice would be osgb but I'm not sure. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41082#41082 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating a 0.5 TB osgTerrain Database: Best file format?
Hi Torben, The osgb format would be good for your requirement. It is a kind of binary format similar to ive, but supports separated serializer libraries, and can be extended to support user classes and compressors. Cheers, Wang Rui 2011/7/1 Torben Dannhauer tor...@dannhauer.info: Hi, I plan to process a osgTerrain database with more than 1 TB source data with VPB. The last version I processed was a .ive database. Now we have the new standard file formats osgx, osgt and osgb. Which would be the best choice regarding runtime performance and regarding size? My current coice would be osgb but I'm not sure. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41082#41082 ___ 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] osgSim::MultiSwitch in osgt
Hi Andreas,
Ahhh... I'll try to fix it this weekend. It is just another slip of the pen.
Wang Rui
2011/7/1 Andreas Ekstrand andreas.ekstr...@remograph.com:
Hi,
Another problem with osgSim and osgt: When converting the attached
switch_test.flt to switch_test.osgt with osgconv and then trying it in
osgviewer, I get the following warnings (even if it loads and shows):
AsciiInputIterator::readProperty(): Unmatched property }, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property {, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property FALSE, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property 3, expecting
SwitchSet
I don't know if it's the writing or reading that's failing. Maybe it would
be a good idea to write the line number in these warnings, if it's possible.
Regards,
Andreas
___
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] Creating a 0.5 TB osgTerrain Database: Best file format?
Hi Wang, that was fast! I have some further questions regarding some VPB features, but I post the in the VPB forum. Thanks for the info! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41084#41084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgSim::MultiSwitch in osgt
Great, Wang. Thanks for looking into these issues so quickly. Much
appreciated.
Regards,
Andreas
On 2011-07-01 08:45, Wang Rui wrote:
Hi Andreas,
Ahhh... I'll try to fix it this weekend. It is just another slip of the pen.
Wang Rui
2011/7/1 Andreas Ekstrandandreas.ekstr...@remograph.com:
Hi,
Another problem with osgSim and osgt: When converting the attached
switch_test.flt to switch_test.osgt with osgconv and then trying it in
osgviewer, I get the following warnings (even if it loads and shows):
AsciiInputIterator::readProperty(): Unmatched property }, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property {, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property FALSE, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property 3, expecting
SwitchSet
I don't know if it's the writing or reading that's failing. Maybe it would
be a good idea to write the line number in these warnings, if it's possible.
Regards,
Andreas
___
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] [vpb] Questions regarding setname, optional layers and layer inheritance
Hi, I'm plan to process a large database with more than 1 TB of source data. Therefore I don't want to include all source data into a single database but would like to have a modular database with optional parts. I browsed the VPB sources and discovered somer options I do not understand, I would be glad to get some basic hints.. The unknown options are: --layer-inheritance [Lowest/Nearest/No] : What does this option cause? --set setname, What is a set name? what is the difference to the comment string I can add to the topmost node of the database via --comment? --optional-set setname --remove-optional-set setname --optional-image-layout [inline/external-set-dir/external-local-dir] --optional-elevation-layout [inline/external-set-dir/external-local-dir] How does the idea of optional layers work? I assume it is possible to plug in optional layers for DEM and for textures independent? What is about the layout (inline/external-set-dir/external-local-dir) Any hint wherer to look to learn how that works? Do I need a special terrain technique to use such a database with optional layers, or can I use the standard osgViewer? As return of investment of your help, I will write a usage example in the VPB wiki as soon as I understand how that works. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41087#41087 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Compute angle betweens two vectors
Hi, This is a newbie question ! Is there a way using OSG Math to compute the angle between two vectors of osg::Vec3. Thank you Mohamed ALJI -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41089#41089 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] Why there are different versions of lib PNG in the 3rd party dependencies?
Heya! Nice and simple answer! Thanks dude! Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41091#41091 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compute angle betweens two vectors
On 7/1/2011 6:04 AM, Mohamed Alji wrote: This is a newbie question ! Is there a way using OSG Math to compute the angle between two vectors of osg::Vec3. No OSG math required. The dot product of two unit vectors is the cosine of their angle, so use acos() to get the angle from the dot product. -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compute angle betweens two vectors
Thank you for your answer. Mohamed ALJI -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41095#41095 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rewriting of the osgt reader (was: Re: Infinite loop at osgt loading)
Hi Wang Rui, On 1/07/11 3:36 , Wang Rui wrote: Could you please help test the .osgt reader under Windows and other platforms to make sure it can work? It will be appreciated if there are enough feedbacks and bug reports before I could submit the change with security. Tested the .osgt models from OpenSceneGraph-Data on OS X and they all work. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] readNodeFile() with OBJ files is extremely slow when used in Qt4 app
Well, I've finally found the problem. It is in Model::readOBJ() method in obj.cpp file. The problem is that sscanf() reads data from *.obj file in default locale. Qt has the following code inside its QCoreApplication constructor: Code: setlocale(LC_ALL, );// use correct char set mapping Which means setting the entire default locale (http://www.cplusplus.com/reference/clibrary/clocale/setlocale/). Given that, sscanf starts to interpret '.' character as alphabetic in some locales (including mine, ru_RU.UTF-8 where floats are divided by ',' symbol). So it reads values (for instance, vertex coordinates) until the first '.' appears. Now it stops, x coord gets integer part of float and the rest y and z gets 0. Then, duplicate search in TriStripifyVisitor finds many, many duplicate and only 100 or so unique vertices. As a result, stripify() function works extremely slow with such an input data. I think it should be set C locale before reading *.obj file in readOBJ as *.obj format is so restrictive and not dependent of current user locale. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41097#41097 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] readNodeFile() with OBJ files is extremely slow when used in Qt4 app
On 1/07/11 16:19 , Alexey Chernov wrote: I think it should be set C locale before reading *.obj file in readOBJ as *.obj format is so restrictive and not dependent of current user locale. Rather than setting the global locale, maybe we set the 'C' locale on the I/O streams only: ios_base::imbue(locale::classic()) /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Strange osgText::Text problem while moving from OSG2.9.8 to OSG 3.0.0
Hello everyone! :D
We are porting our application from OSG 2.9.8 to OSG 3.0.0 but the
osgText::Text is not working properly. I am creating an osgText::Text with
SCREEN axis alignment and SCREEN_COORDS character size mode, but it does not
show up. In order to make it show up I have to create a random drawable
(drawables with zero size eg. sphere with zero radius won't work) and add it to
the osgText::Text's Geode. At the start I thought I was doing something wrong.
So, I stripped down the osgText Example and I realized that the example has the
same problem. If you trip down everything but 'text5' text, and remove the
sphere that is attached on the 'text5' text's geode, then you won't be able to
see the text. Now, If you take this code and compile it using OSG 2.9.8 the
text will be visible!
Am I missing something?
Here is a simple example of the problem. Ready to compile and run (just add the
headers):
Code:
osgText::Text* createText( const osg::Vec3 position )
{
osgText::Text* text = new osgText::Text();
text-setColor(osg::Vec4(1.0f,1.0f,1.0f,1.0f));
text-setCharacterSize(32.0f);
text-setPosition(position);
text-setAxisAlignment(osgText::Text::SCREEN);
text-setCharacterSizeMode(osgText::Text::SCREEN_COORDS);
text-setDrawMode(osgText::Text::TEXT | osgText::Text::BOUNDINGBOX);
text-setText(CharacterSizeMode SCREEN_COORDS(size 32.0));
return text;
}
int main( int agc, char** argv )
{
osg::Group* root = new osg::Group;
osgText::Text* text01 = createText( osg::Vec3(0.0f,0.0f,0.0f) );
osg::Geode* text01Geode = new osg::Geode();
text01Geode-addDrawable(text01);
root-addChild(text01Geode);
/// uncomment the following two lines and the text will appear!
//osg::ShapeDrawable* shape = new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0f,0.0f,0.0f),0.1f));
//text01Geode-addDrawable(shape);
osgViewer::Viewer viewer;
viewer.setSceneData(root);
viewer.setUpViewInWindow(50,50,800,600);
viewer.run();
return EXIT_SUCCESS;
}
Thank you for your time!
Cheers,
George
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41099#41099
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange osgText::Text problem while moving from OSG2.9.8 to OSG 3.0.0
Hi, George
We run into same issue yesterday, and as far as i can tell, this changed
between osg 2.9.9 (all works ok) and 2.9.10(nothing visible). osgText is culled
when it shouldnt for some reason. For temporary solution you can turn off
culling on geode with text or add some other drawable as u did.
01.07.2011, 19:00, George Bekos bekos...@live.com:
Hello everyone! :D
We are porting our application from OSG 2.9.8 to OSG 3.0.0 but the
osgText::Text is not working properly. I am creating an osgText::Text with
SCREEN axis alignment and SCREEN_COORDS character size mode, but it does not
show up. In order to make it show up I have to create a random drawable
(drawables with zero size eg. sphere with zero radius won't work) and add it
to the osgText::Text's Geode. At the start I thought I was doing something
wrong. So, I stripped down the osgText Example and I realized that the
example has the same problem. If you trip down everything but 'text5' text,
and remove the sphere that is attached on the 'text5' text's geode, then you
won't be able to see the text. Now, If you take this code and compile it
using OSG 2.9.8 the text will be visible!
Am I missing something?
Here is a simple example of the problem. Ready to compile and run (just add
the headers):
Code:
osgText::Text* createText( const osg::Vec3 position )
{
osgText::Text* text = new osgText::Text();
text-setColor(osg::Vec4(1.0f,1.0f,1.0f,1.0f));
text-setCharacterSize(32.0f);
text-setPosition(position);
text-setAxisAlignment(osgText::Text::SCREEN);
text-setCharacterSizeMode(osgText::Text::SCREEN_COORDS);
text-setDrawMode(osgText::Text::TEXT | osgText::Text::BOUNDINGBOX);
text-setText(CharacterSizeMode SCREEN_COORDS(size 32.0));
return text;
}
int main( int agc, char** argv )
{
osg::Group* root = new osg::Group;
osgText::Text* text01 = createText( osg::Vec3(0.0f,0.0f,0.0f) );
osg::Geode* text01Geode = new osg::Geode();
text01Geode-addDrawable(text01);
root-addChild(text01Geode);
/// uncomment the following two lines and the text will appear!
//osg::ShapeDrawable* shape = new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0f,0.0f,0.0f),0.1f));
//text01Geode-addDrawable(shape);
osgViewer::Viewer viewer;
viewer.setSceneData(root);
viewer.setUpViewInWindow(50,50,800,600);
viewer.run();
return EXIT_SUCCESS;
}
Thank you for your time!
Cheers,
George
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41099#41099
___
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] Strange osgText::Text problem while moving from OSG2.9.8 to OSG 3.0.0
Hi George, Sergey, We run into same issue yesterday, and as far as i can tell, this changed between osg 2.9.9 (all works ok) and 2.9.10(nothing visible). osgText is culled when it shouldnt for some reason. For temporary solution you can turn off culling on geode with text or add some other drawable as u did. I seem to remember people talking about a bug in the osgText bounds computation that causes it to never calculate its bounds, so they always stay at the initial value (which is an invalid bounds) and so the text is always culled (and thus it can never calculate its bounds, and so on). Not much to go on but it might be the hint that helps you to fix this... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText performance
HiYour stats measured on release build? With MSVS debug builds tend to be about order of magnitude slower.You can reduce cull time by changing graph structure to quadtree like graph.Some part of cull time comes from autotransforms. You can try to get rid of them and use one ortho projection for all labels, moving them around to correct position on screen. At least you should be able to use one autotransform for each icon + text pair instead of two.Make sure that you dont call setText on osgText::Text each frame with same string, this may causing your update time increase.You can try to move lod nodes higher on graph tree structure, this may save some performance.I dont think you will be able to do much with draw time, you draw lots of drawables, more you get longer it goes.Cheers,Sergey.01.07.2011, 16:04, "Rahul Srivastava" ra...@darshan3d.com:Hi, Good day to you all. 1 I am trying to render icons and text very similar to what google earth does with placemarks. I have put in about 150 icons and texts in the scene. I get a large drop in performance when rendering text as illustrated in the WithText.png screenshot. My system configuration is:- CPU - AMD Phenom II X4 955 processor (Quad-Core) GPU - NVIDIA GTS 450 RAM - 4 GB DDR3 OS - Windows 7 64-bit Is there a method to increase the text rendering performance? 2 I also notice a large increase in event and cull traversals when only the icons are added. My FPS drops from ~280 (WithoutIcons.png) to around ~80(WithoutText.png). Each node of my icon + text looks like SingleNode.png. Kindly advise on how to reduce the corresponding times since the application is required to render a large dataset (in thousands). Regards, -- Rahul Srivastava ra...@vizexperts.com +91-98738-85880 Senior MTS, Core Technologies, VizExperts India Pvt. Limited, Gurgaon, Haryana - 122001 www.vizexperts.com ___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] render depth buffer to image for one time
Hi Sergey I would like to understand exactly how the graphics pipeline works and am struggling to figure this out by digging through the code (are there free books that deal with OSG and its implementation details in-depth? I dont mean the QSG by Paul Martz...). Also, my understanding of OpenGL is lacking in some places especially in implementation details so perhaps this will help clear things up for me. In the prerender example we have something like this: 0: camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); 1: camera-attach(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0), image); 2: camera-setPostDrawCallback(new MyCameraPostDrawCallback(image)); 3: textureRect[tex_to_get]-setImage(0, image); As far as I understand this works as follows 0: This generates an FBO which has no data storage until I attach data storage to it (next step) ? Is this true? What happens then when I attach a color attachment but dont attach a depth buffer attachment? Does OSG automatically generate one for me? I ask because in regular OpenGL when you dont attach a depth attachment to an FBO then rendering to the FBO using glEnable(GL_DEPTH_TEST) produces incorrect results... 1: The image attached to the camera is the data storage for the FBO created in step 0. If this is the case then it means the FBO sits in RAM and not on the GPU. Is that true? 2:Here we set a post render callback using the image as our input. As far as I understand this means that the image (which is sitting in RAM) is edited in place. That means that as long as we dont need the data for actual rendering then we are being efficient because we dont copy to the GPU. Which brings up the next line... 3: We specify that a texture has the image as its image. I dont entirely understand what this means. When we create the original texture then OpenGL allocates space on the GPU for that texture. By using setImage(0,image) then does that mean that whatever is in that image (which sits on RAM) must always be copied to the GPU texture before the texture can be used at render time? All in all I feel quite confused and would like to understand how to do the above process efficiently. Ideally I would like to : pass dynamic geometry to the GPU every frame and have that rendered to textures inside the GPU. Occassionally I would like to ask the GPU to send the RTT textures back to the CPU, update them on the CPU and then send them back to the GPU. How should I be doing that in the most efficient way possible? Thank you! Cheers, aaron -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41103#41103 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture2D subload callback gone mad
On 8/20/2010 7:21 AM, Thomas Hogarth wrote: Hi All I've been using texture2d subload callbacks for quite a while now to stream video images into power of 2 textures. I also have a Texture Rectangle version which runs fine on 80% of machines I use so it's not often I run the Texture2D version. Any how, yesterday a client was complaining that her screen had gone black and upon investigation I found that suddenly my osg::Texture2D::SubloadCallback was calling load nearly every frame then calling subload only occasionally. This has also caused my memory use to go crazy (ouput looks a bit like the below) LOAD TEX SUB LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX SUB LOAD TEX LOAD TEX I know it's something I must have changed but was wondering if anyone could point me to specifically what makes load get called instead of subload. Cheers Tom I just wanted to follow up and say that I have started to see this issue now that I'm doing subload on a power-of-two sized texture on trunk code. 2.8.x does not seem to suffer the problem. Did anyone ever find a solution to this, or is there some guidelines for how to get subload to work properly on 2.9.x and 3.x? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ANN: osgText::TextNode API
Hello all! In just a few days (I will finish the code over the holidays) I'm going to be submitting a bit of code to Robert to evaluate for inclusion into OSG proper. It is a continuation of his experimentation with a new text interface called TextNode. TextNode diverges a great deal from what you might be used to with Text and Text3D objects, but in the end the transition (if Robert accepts it :)) will be worth it. The API has been cleaned up, internal data is much easier to get at, and the rendering and layout backends have become pluggable. Before I finish up the last bits so that a first beta version can be submitted and people can begin experimenting with it, I'd like to solicit some input. 1) I'm dropping all support for the FFP. I mean, c'mon. It makes the code substantially harder to maintain and understand. If this causes the code to be rejected (or perhaps results in Text and Text3D staying around for a bit longer to support FFP), then so be it. :) In lieu of this, however, I'd like some opinions on which version of GLSL I should target and how well that version is currently supported by OSG. 2) TextNode (3D) glyph support is working quite well; it wasn't hard, since most of the code was already there in the backend. Each glyph is cached based on its Style and Font, put into a PAT, and then finally all of the text is squished into a top-level MatrixTransform. I continue to use the setAlignment() and setAxisAlignment() API, but obviously you're free to do whatever you like. How does this sound to everyone? 3) TextNode (2D) is still going to require a bit of work at the time of the first submission. In the new API, osg::Geometry objects are constructed using quads textured with the 2D glyphs and, again, packaged into a top-level MatrixTransform. A remaining (serious) question is how to do drop-shadows and outlines? 4) As some of you may know, I am also the author of osgCairo and osgPango. Both of these nodekits came to be as I was working on osgWidget, which--combined with getting sick--seriously sidetracked that project. :) (I haven't forgot about osgWidget though--hang in there!) This isn't an attempt to plug that software, but rather me posing a question I've asked before: 4.a) The 2D quality provided by osgPango simply cannot be matched by anything any of us could do by hand. This is partly due to osgPango's massive user base and its main developers, but it is also due to the fact that the Glyph rasterizer is Cairo. Now, I won't be so bold as to ask OSG to accept osgPango (yet :)), but what I would like to do is provide a way for Cairo to do the glyph rasterization instead of doing it manually with Freetype. This is the approach osgPango takes, and it lets osgPango provide a very powerful glyph effect API. Let me elaborate below... In current 2D OSG, you request a string of text. Each character is iterated over and the backend calls FT_Load_Char to render each glyph at a particular resolution, at which point that glyph is put into a texture atlas to be reused later. If we supported Cairo as a rasterizing backend, we would instead be given the glyph information for each character as a vector path and would have the freedom to do whatever Cairo's drawing API allows with it. In the most basic case, this would be a simple fill() operation, but as you can see from the osgPango screenshots: http://www.jeremymoles.com/osgPango , a lot of interesting things can be done when you have a vectorized path of a glyph. :) Don't misunderstand me though: osgPango isn't going anywhere! The layout support alone provided by osgPango is incredible, and it is able to provide additional information to the rasterizer for higher quality fonts (it also supports more than just Freetype; Atsui and the Windows font backend, for example). It also understands just about every language and locale out there, so text is always positioned properly. But I would like to at least like to pose the idea of using Cairo as the rasterizer, or at least providing a plugin (since it is the freetype plugin in the osgPlugins directory that actually is responsible for building the glyph atlas) to do this. --- I TRULY feel like if we can get this UI stuff under control (which is why I started working on osgWidget, osgCairo, osgPango) we can absolutely establish OSG as the premiere OpenGL toolkit. Hopefully I can make enough strides in this area in my freetime so that one day I can do it FULL TIME for a living. :) If anyone is familiar with Scaleform (and if you've played any games made in the last 5 years, you can't have missed it), something of that visual quality and style is what I envision for OSG one day (minus the Flash absurdity)...
Re: [osg-users] ANN: osgText::TextNode API
I would also like to quickly top-post myself and say that I see A LOT of posts on the lists lately about osgText, and the next few months might be a great time for people to pitch in with TextNode and get their stuff working. :) On Fri, 2011-07-01 at 13:19 -0400, Jeremy Moles wrote: Hello all! In just a few days (I will finish the code over the holidays) I'm going to be submitting a bit of code to Robert to evaluate for inclusion into OSG proper. It is a continuation of his experimentation with a new text interface called TextNode. TextNode diverges a great deal from what you might be used to with Text and Text3D objects, but in the end the transition (if Robert accepts it :)) will be worth it. The API has been cleaned up, internal data is much easier to get at, and the rendering and layout backends have become pluggable. Before I finish up the last bits so that a first beta version can be submitted and people can begin experimenting with it, I'd like to solicit some input. 1) I'm dropping all support for the FFP. I mean, c'mon. It makes the code substantially harder to maintain and understand. If this causes the code to be rejected (or perhaps results in Text and Text3D staying around for a bit longer to support FFP), then so be it. :) In lieu of this, however, I'd like some opinions on which version of GLSL I should target and how well that version is currently supported by OSG. 2) TextNode (3D) glyph support is working quite well; it wasn't hard, since most of the code was already there in the backend. Each glyph is cached based on its Style and Font, put into a PAT, and then finally all of the text is squished into a top-level MatrixTransform. I continue to use the setAlignment() and setAxisAlignment() API, but obviously you're free to do whatever you like. How does this sound to everyone? 3) TextNode (2D) is still going to require a bit of work at the time of the first submission. In the new API, osg::Geometry objects are constructed using quads textured with the 2D glyphs and, again, packaged into a top-level MatrixTransform. A remaining (serious) question is how to do drop-shadows and outlines? 4) As some of you may know, I am also the author of osgCairo and osgPango. Both of these nodekits came to be as I was working on osgWidget, which--combined with getting sick--seriously sidetracked that project. :) (I haven't forgot about osgWidget though--hang in there!) This isn't an attempt to plug that software, but rather me posing a question I've asked before: 4.a) The 2D quality provided by osgPango simply cannot be matched by anything any of us could do by hand. This is partly due to osgPango's massive user base and its main developers, but it is also due to the fact that the Glyph rasterizer is Cairo. Now, I won't be so bold as to ask OSG to accept osgPango (yet :)), but what I would like to do is provide a way for Cairo to do the glyph rasterization instead of doing it manually with Freetype. This is the approach osgPango takes, and it lets osgPango provide a very powerful glyph effect API. Let me elaborate below... In current 2D OSG, you request a string of text. Each character is iterated over and the backend calls FT_Load_Char to render each glyph at a particular resolution, at which point that glyph is put into a texture atlas to be reused later. If we supported Cairo as a rasterizing backend, we would instead be given the glyph information for each character as a vector path and would have the freedom to do whatever Cairo's drawing API allows with it. In the most basic case, this would be a simple fill() operation, but as you can see from the osgPango screenshots: http://www.jeremymoles.com/osgPango , a lot of interesting things can be done when you have a vectorized path of a glyph. :) Don't misunderstand me though: osgPango isn't going anywhere! The layout support alone provided by osgPango is incredible, and it is able to provide additional information to the rasterizer for higher quality fonts (it also supports more than just Freetype; Atsui and the Windows font backend, for example). It also understands just about every language and locale out there, so text is always positioned properly. But I would like to at least like to pose the idea of using Cairo as the rasterizer, or at least providing a plugin (since it is the freetype plugin in the osgPlugins directory that actually is responsible for building the glyph atlas) to do this. --- I TRULY feel like if we can get this UI stuff under control (which is why I started working on osgWidget, osgCairo, osgPango) we can absolutely establish OSG as the premiere OpenGL toolkit. Hopefully I can make enough strides in this area in my freetime so
Re: [osg-users] Texture2D subload callback gone mad
On 7/1/2011 11:03 AM, Chris 'Xenon' Hanson wrote: On 8/20/2010 7:21 AM, Thomas Hogarth wrote: Hi All I've been using texture2d subload callbacks for quite a while now to stream video images into power of 2 textures. I also have a Texture Rectangle version which runs fine on 80% of machines I use so it's not often I run the Texture2D version. Any how, yesterday a client was complaining that her screen had gone black and upon investigation I found that suddenly my osg::Texture2D::SubloadCallback was calling load nearly every frame then calling subload only occasionally. This has also caused my memory use to go crazy (ouput looks a bit like the below) LOAD TEX SUB LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX LOAD TEX SUB LOAD TEX LOAD TEX I know it's something I must have changed but was wondering if anyone could point me to specifically what makes load get called instead of subload. Cheers Tom I just wanted to follow up and say that I have started to see this issue now that I'm doing subload on a power-of-two sized texture on trunk code. 2.8.x does not seem to suffer the problem. Did anyone ever find a solution to this, or is there some guidelines for how to get subload to work properly on 2.9.x and 3.x? Not sure this is related, but the texture object cache feature never made it into the 2.8.x series. -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
Hi aaron 0: osg can manage missing attachments for you if they are needed. This behaviour is configurable with env variables and in code. I dont actually remember default behaviour, but i think it will attach color and\or depth renderbuffers if they needed and missing, not sure about stencil. 1: as far as i remember this works by creating renderbuffer and then using glReadPixels from fbo to ram (image data storage). You can use image with pbo to make use of asynchronous dma transfers. Render to texture works faster, but you dont get your data on cpu side. 2: cant say much because didnt looked at example sources 3: texture-setImage(...) works like initializing gl texture with data stored in osg image with glTexImage(...), it will be copied in gpu memory and updated by osg if image changes. In this step you could also benefit from using image with pbo to get asynchronous copy. How should I be doing that in the most efficient way possible? Depends on data size, frequency of gpu-ram transfers and image processing speed on cpu. If you can process your image on gpu i'd stick with that and skip cpu processing altogether. Transfers gpu-ram not so fast in any case, though pbo usage can help hide latency. Cheers, Sergey. 01.07.2011, 19:49, aaron wetzler aaronwetz...@gmail.com: Hi Sergey I would like to understand exactly how the graphics pipeline works and am struggling to figure this out by digging through the code (are there free books that deal with OSG and its implementation details in-depth? I dont mean the QSG by Paul Martz...). Also, my understanding of OpenGL is lacking in some places especially in implementation details so perhaps this will help clear things up for me. In the prerender example we have something like this: 0: camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); 1: camera-attach(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0), image); 2: camera-setPostDrawCallback(new MyCameraPostDrawCallback(image)); 3: textureRect[tex_to_get]-setImage(0, image); As far as I understand this works as follows 0: This generates an FBO which has no data storage until I attach data storage to it (next step) ? Is this true? What happens then when I attach a color attachment but dont attach a depth buffer attachment? Does OSG automatically generate one for me? I ask because in regular OpenGL when you dont attach a depth attachment to an FBO then rendering to the FBO using glEnable(GL_DEPTH_TEST) produces incorrect results... 1: The image attached to the camera is the data storage for the FBO created in step 0. If this is the case then it means the FBO sits in RAM and not on the GPU. Is that true? 2:Here we set a post render callback using the image as our input. As far as I understand this means that the image (which is sitting in RAM) is edited in place. That means that as long as we dont need the data for actual rendering then we are being efficient because we dont copy to the GPU. Which brings up the next line... 3: We specify that a texture has the image as its image. I dont entirely understand what this means. When we create the original texture then OpenGL allocates space on the GPU for that texture. By using setImage(0,image) then does that mean that whatever is in that image (which sits on RAM) must always be copied to the GPU texture before the texture can be used at render time? All in all I feel quite confused and would like to understand how to do the above process efficiently. Ideally I would like to : pass dynamic geometry to the GPU every frame and have that rendered to textures inside the GPU. Occassionally I would like to ask the GPU to send the RTT textures back to the CPU, update them on the CPU and then send them back to the GPU. How should I be doing that in the most efficient way possible? Thank you! Cheers, aaron -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41103#41103 ___ 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] DOFTransform MultOrder Question
I've been looking through the on-line documentation and while the osgSim::DOFTransform looks fairly straight forward and additionally there are plenty of examples that implement it. I am still rather curious about the MultOrder enumerator and its related functions that get/set it. I really don't have any clear reason of how it maybe used and why. Could someone possible give me a abstract scenario where it would be needed. Thank you! Sincerely Scott -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41109#41109 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DOFTransform MultOrder Question
On 7/1/2011 12:46 PM, Scott Wasinger wrote: I've been looking through the on-line documentation and while the osgSim::DOFTransform looks fairly straight forward and additionally there are plenty of examples that implement it. I am still rather curious about the MultOrder enumerator and its related functions that get/set it. I really don't have any clear reason of how it maybe used and why. Could someone possible give me a abstract scenario where it would be needed. Did you check the OpenFlight spec? http://www.presagis.com/products_services/standards/openflight/more/openflight_specifications/ It's been a while since I read it, but I imagine it covers this aspect of the DOF record. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DOFTransform MultOrder Question
Hi, Thank you. I check it out -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41112#41112 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] osgWorks Build Error
I tried to build osgWorks 1.1 and encountered a compile error Scanning dependencies of target osgwTools [ 2%] Building CXX object src/osgwTools/CMakeFiles/osgwTools.dir/CameraConfigObject.cpp.o ~/osgWorks_01_01_00/src/osgwTools/CameraConfigObject.cpp: In member function ~/osgWorks_01_01_00/src/osgwTools/CameraConfigObject.cpp:104:77: error: operands to ?: have different types ‘osg::DisplaySettings*’ and ‘osg::ref_ptrosg::DisplaySettings’ make[2]: *** [src/osgwTools/CMakeFiles/osgwTools.dir/CameraConfigObject.cpp.o] Error 1 make[1]: *** [src/osgwTools/CMakeFiles/osgwTools.dir/all] Error 2 make: *** [all] Error 2 CameraConfigObject::store original: Code: osg::DisplaySettings* ds = masterCamera-getDisplaySettings() != NULL ? masterCamera-getDisplaySettings() : osg::DisplaySettings::instance(); my mod: Code: osg::DisplaySettings* ds = masterCamera-getDisplaySettings(); if(ds == NULL) ds = osg::DisplaySettings::instance(); Everything worked after this mod -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=4#4 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange osgText::Text problem while moving from OSG2.9.8 to OSG 3.0.0
I think JS is talking about the problem I was having. Here's a hacky fix that worked for me. I probably should have already sent this to osg-submissions, but maybe you can validate it first or think of something better. Try changing this one line in TextBase.cpp: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2011-June/052479.html -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 11 Date: Fri, 01 Jul 2011 11:31:00 -0400 From: Jean-S?bastien Guay jean-sebastien.g...@cm-labs.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Strange osgText::Text problem while moving from OSG2.9.8 to OSG 3.0.0 Message-ID: 4e0de834.40...@cm-labs.com Content-Type: text/plain; charset=UTF-8; format=flowed Hi George, Sergey, We run into same issue yesterday, and as far as i can tell, this changed between osg 2.9.9 (all works ok) and 2.9.10(nothing visible). osgText is culled when it shouldnt for some reason. For temporary solution you can turn off culling on geode with text or add some other drawable as u did. I seem to remember people talking about a bug in the osgText bounds computation that causes it to never calculate its bounds, so they always stay at the initial value (which is an invalid bounds) and so the text is always culled (and thus it can never calculate its bounds, and so on). Not much to go on but it might be the hint that helps you to fix this... J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DOFTransform MultOrder Question
Paul After looking at the DOF record from the OpenFlight Specifications Doc I now think that the enumerator simply changes the order of rotations. Cheers, Scott -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41113#41113 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] osgWorks Build Error
Most likely you are using incompatible versions of osgWorks and OSG. Check the compatibility matrix: http://code.google.com/p/osgworks/wiki/CompatibilityMatrix It looks like you are using osgWorks 1.1, so you should have OSG version = 2.8.4 (well, okay, = 2.8.5 actually -- the page is slightly out of date). osgWorks trunk HEAD has support for OSG 2.9.x and 3.0.0, but osgWorks is under development at this point and really isn't close to being in a taggable release form, so it's hard to say when a formal release compatible with OSG v3.0.0 will be available. -Paul On 7/1/2011 1:32 PM, Scott Wasinger wrote: I tried to build osgWorks 1.1 and encountered a compile error Scanning dependencies of target osgwTools [ 2%] Building CXX object src/osgwTools/CMakeFiles/osgwTools.dir/CameraConfigObject.cpp.o ~/osgWorks_01_01_00/src/osgwTools/CameraConfigObject.cpp: In member function ~/osgWorks_01_01_00/src/osgwTools/CameraConfigObject.cpp:104:77: error: operands to ?: have different types ‘osg::DisplaySettings*’ and ‘osg::ref_ptrosg::DisplaySettings’ make[2]: *** [src/osgwTools/CMakeFiles/osgwTools.dir/CameraConfigObject.cpp.o] Error 1 make[1]: *** [src/osgwTools/CMakeFiles/osgwTools.dir/all] Error 2 make: *** [all] Error 2 CameraConfigObject::store original: Code: osg::DisplaySettings* ds = masterCamera-getDisplaySettings() != NULL ? masterCamera-getDisplaySettings() : osg::DisplaySettings::instance(); my mod: Code: osg::DisplaySettings* ds = masterCamera-getDisplaySettings(); if(ds == NULL) ds = osg::DisplaySettings::instance(); Everything worked after this mod -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=4#4 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
