Re: [osg-users] An error in the implementation of the old function void View::setUpViewInWindow in OSG-3.1.7
Hi Evgeny,
Thanks for the report. This bug has been fixed already, and is part of 3.1.8 ;-)
Cheers,
Robert.
On 26 June 2013 03:51, Evgeny Pereguda evgeny-pereg...@yandex.ru wrote:
Hi,
I have started to use the last version of OSG - 3.1.7, and I found that
implementation of old function void View::setUpViewInWindow(int x, int y, int
width, int height, unsigned int screenNum) has the mistake:
Code:
void View::setUpViewInWindow(int x, int y, int width, int height, unsigned
int screenNum)
{
apply(new osgViewer::SingleWindow(x,y,width,screenNum));
}
It means that number of monitor (screenNum) is used as the height of window -
default is 0 - it means that height of window will be the same like height of
primary Screen. The better resolving is:
Code:
void View::setUpViewInWindow(int x, int y, int width, int height, unsigned
int screenNum)
{
apply(new osgViewer::SingleWindow(x,y,width, height,screenNum));
}
I think, that it will be better to say about this bug to senior developers.
Thank you!
Cheers,
Evgeny
Code:
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54902#54902
___
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] Passing location-based data to a fragment shader
Hi Shahar,
I read this post and found it interesting. Just out of curiosity :
Each texel in the new texture, should be set based on the world location of
the corresponding texel in the current geometry texture
Are you trying to overlay a texture on top of txp archive and it should be
georeferenced? If so, there might be a different approach
Nick
On Tue, Jun 25, 2013 at 3:50 PM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
Hi Shahar,
answers below.
Sebastian Messerschmidt wrote:
Hi Shahar Kosti:
As you don't provide any exact numbers I can only guess. But usually I'd
bind one or more textures per tile of paged set.
Depending on your hardware bind of 8192x8192 textures is no problem.
Can you be a bit more specific on how big the set is?
Also for the hidden textures - I don't really get what you mean. My best
guess is, that you mean not displayed.
Therefore write a custom fragment shader and bind the data-textures
along with you diffuse or whatever textures to the stateset of the tile.
As the fragment shader is fully programmable, it is your choice what is
done with the data.
cheers
Sebastian
Hi Sebastian,
Sorry for my late reply, it took me some time to get the data.
One TXP I'm currently looking at, represents a 3000 km² area with texture
resolution of 5m/pixel. Some areas have better resolution, up to 10
cm/pixel. The additional metadata has similar resolution. So obviously
wouldn't fit on a single texture.
Okay, so the single TXP file represents the whole area? That's kinda hard,
I thought you have multiple tiles representing parts of your complete data
set.
Anyways, First of all, your data sets need to be aligned somehow.
Regarding your suggestions, could you elaborate on the bind one or more
textures per tile of paged set approach?
My current approach (which doesn't work), is to intercept paged nodes
using a custom ReadFileCallback, which runs a NodeVisitor. The visitor
finds all Geode objects and then the underlying geometries. I can bind a
new texture to these geometries, but I'm not sure how to set the values
correctly.
You don't really need to bind at a level this deep. Usually if the
terrain tile is loaded and represent a LOD you want to work with, you can
simple add your data texture(s) as uniform to the stateset of the tile.
Given you have a texture with the data-image called texture you can do
it this way in your callback:
osg::StateSet* state_set = node-getOrCreateStateSet();
osg::Uniform* sampler = new osg::Uniform(MyDataSamper, 2 /*texture
unit*/);
state_set-**setTextureAttribute(unit, texture
,osg::StateAttribute::ON);
state_set-addUniform(sampler)**;
With this you bind the texture to a sampler for your shader, at the
texture unit 2. Depending on how many textures are already bound you might
need to modify the unit.
In the fragment shader you can now access the texture via:
uniform sampler2D MyDataSampler
..
..
main()
{
vec2 tex_coord = gl_TexCoord[0].st;
vec4 data = texture2D(MyDataSampler, tex_coord);
}
Each texel in the new texture, should be set based on the world location
of the corresponding texel in the current geometry texture. I'm not sure
how to do that using the geometry vertex and texture coordinate indices.
I hope this is clear enough.
This is a different question. If your terrain-data already contains a base
texture (like a satellite photo), the gl_TexCoord[0] might be matching
already.
If not you might want to use texture coordinate generation in the vertex
shader to get world-space texture coordinates.
It totally depends on your data.
For a first try, I'd load a dummy texture for each tile and pass it to the
gl_FragColor in the fragment shader to see how your coordinates are.
cheers
Sebastian
Thanks for the help,
Shahar
--
Read this topic online here:
http://forum.openscenegraph.**org/viewtopic.php?p=54810#**54810http://forum.openscenegraph.org/viewtopic.php?p=54810#54810
__**_
osg-users mailing list
osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
__**_
osg-users mailing list
osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question regarding new Geometry implementation
Hi Robert, I'm currently checking the new 3.1.8 release with much appreciated new osg::Geometry implementation. There are some question comming up however: I'm trying to adapt some of the osg-plugins to the new Geometry, for instance the openflight implementation. There are calls like those: geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX); If I understood everything correctly, those calls are to be replaced with: geometry-getColorArray().setBinding(osg::Array::BIND_PER_VERTEX) Is this correct? Those binding are set afterwards, due to the openflight structure, so I guess this is the way to go. If so, I'd be happy to fix the openflight plugin. cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question regarding new Geometry implementation
Hi Sebastian, On 26 June 2013 10:03, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: I'm currently checking the new 3.1.8 release with much appreciated new osg::Geometry implementation. There are some question comming up however: I'm trying to adapt some of the osg-plugins to the new Geometry, for instance the openflight implementation. There are calls like those: geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX); If I understood everything correctly, those calls are to be replaced with: geometry-getColorArray().setBinding(osg::Array::BIND_PER_VERTEX) Is this correct? Those binding are set afterwards, due to the openflight structure, so I guess this is the way to go. If so, I'd be happy to fix the openflight plugin. For OSG-3.2 I'll maintain the Geometry::set*Binding() methods, but once 3.2 is out I'll move these methods into deprecated_osg::Geometry, so for the current release cycle making this change won't be critical. I'd like it to happen as users read OSG code as template of how to write their own applications, but such changes will be a low priority. W.r.t preferred usage, you can now do: osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_PER_VERTEX); geometry-setColorArray(colors); Or: osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_PER_VERTEX); geometry-setColorArray(colors, osg::Array::BIND_PER_VERTEX); The later would be the quickest way to convert existing code as you'd just combine the original two setColorArray(..); setColorBinding(..) into a single setColorArray() call. Or.. you could do the geometry-getColorArray()-setBinding(osg::Array::BIND_PER_VERTEX) as you suggested as this is perfectly legal, but a little long winded and requires that getColorArray() has already been assigned. -- If I have some time spare I may move the Geometry::AttributeBinding/set*Binding() code into deprecated_osg::Geometry and attempt a build of the OSG. Lots of code will break and need moving across to the new scheme so I'm wary of this. I may just tackle the core libraries and examples, others are welcome to pitch in with this work. The result should be more streamlined code and more compatible with future rev of the OSG. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question regarding new Geometry implementation
Hi Robert, Okay, so in my case (in which I get the information about the binding long after the array was created/filled) it is and will be legal to use the long winded setBinding? cheers Sebastian Hi Sebastian, On 26 June 2013 10:03, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: I'm currently checking the new 3.1.8 release with much appreciated new osg::Geometry implementation. There are some question comming up however: I'm trying to adapt some of the osg-plugins to the new Geometry, for instance the openflight implementation. There are calls like those: geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX); If I understood everything correctly, those calls are to be replaced with: geometry-getColorArray().setBinding(osg::Array::BIND_PER_VERTEX) Is this correct? Those binding are set afterwards, due to the openflight structure, so I guess this is the way to go. If so, I'd be happy to fix the openflight plugin. For OSG-3.2 I'll maintain the Geometry::set*Binding() methods, but once 3.2 is out I'll move these methods into deprecated_osg::Geometry, so for the current release cycle making this change won't be critical. I'd like it to happen as users read OSG code as template of how to write their own applications, but such changes will be a low priority. W.r.t preferred usage, you can now do: osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_PER_VERTEX); geometry-setColorArray(colors); Or: osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_PER_VERTEX); geometry-setColorArray(colors, osg::Array::BIND_PER_VERTEX); The later would be the quickest way to convert existing code as you'd just combine the original two setColorArray(..); setColorBinding(..) into a single setColorArray() call. Or.. you could do the geometry-getColorArray()-setBinding(osg::Array::BIND_PER_VERTEX) as you suggested as this is perfectly legal, but a little long winded and requires that getColorArray() has already been assigned. -- If I have some time spare I may move the Geometry::AttributeBinding/set*Binding() code into deprecated_osg::Geometry and attempt a build of the OSG. Lots of code will break and need moving across to the new scheme so I'm wary of this. I may just tackle the core libraries and examples, others are welcome to pitch in with this work. The result should be more streamlined code and more compatible with future rev of the OSG. Cheers, Robert. ___ 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] how to control manually every frame of animation in a BasicAnimationManager
Hi, I'm trying to control a BasicAnimationManager * manually i.e. I like to be able to implement a command to display a certain keyframe of the animation. At the moment I'm already able to launch play, stop with various play modes on a fbx model. I've found the manner to extract channels [1] and I have tried to set value of a specific channel but it seems not to work. How does it work internally? I need this because I like to launch the animation in a collaboration environment in which animation on different pc should be synchronized. As first thing I could also be satisfied to be able only to position animation as before playing animation in a single step (without executing the animation with play mode ONCE). Thank you! Cheers, Francesco [1] http://forum.openscenegraph.org/viewtopic.php?t=9881highlight= Francesco Argese -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54923#54923 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Display Order with OpenGL ES 2.0 on Android
Hi,
I'm facing a little problem with OSG on Android : I use an ortho2D camera to
display simple quads, but they are displayed in the wrong order.
Simple example : I try to display a green square in front of a green square, so
I add the red square first in my graph, and then my green square.
On my PC, with OSG built with openGl es 2 compatibility it works, but on my
android phone, the red square is displayed in front of the green square.
Any idea ?
Here is a sample code.
static const char vertSource[] =
attribute vec4 osg_Vertex;
\n
attribute vec4 osg_Color;
\n
attribute vec4 osg_MultiTexCoord0;
\n
uniform mat4 osg_ModelViewProjectionMatrix;
\n
varying vec4 v_col;
\n
\n
void main(void)
\n
{
\n
gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex;
\n
v_col = osg_Color;
\n
}
\n
\n;
static const char fragSource[] =
precision mediump float;
\n
varying vec4 v_col;
\n
void main(void)
\n
{
\n
gl_FragColor = v_col;
\n
gl_FragColor.a = 0.5;
\n
}
\n
\n;
osg::Geode* createQuad(const osg::Vec2 size, const osg::Vec4 color)
{
osg::Geode *geode = new osg::Geode();
osg::Geometry *geometry = new osg::Geometry();
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-push_back(osg::Vec3(0, 0, 0));
vertices-push_back(osg::Vec3(0, 0, size.y()));
vertices-push_back(osg::Vec3(size.x(), 0, size.y()));
vertices-push_back(osg::Vec3(size.x(), 0, 0));
geometry-setVertexArray(vertices);
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(color);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_OVERALL);
geometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,vertices-size()));
osg::Program* program = new osg::Program();
osg::Shader* frag = new osg::Shader(osg::Shader::FRAGMENT, fragSource);
osg::Shader* vert = new osg::Shader(osg::Shader::VERTEX, vertSource);
program-addShader(vert);
program-addShader(frag);
geode-getOrCreateStateSet()-setAttribute(program);
geode-addDrawable(geometry);
return geode;
}
int main()
{
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer();
viewer-setThreadingModel(osgViewer::ViewerBase::SingleThreaded);
viewer-setCameraManipulator(new osgGA::TrackballManipulator());
#ifdef ANDROID
viewer-setUpViewerAsEmbeddedInWindow(0,0, 800, 600);
viewer-realize();
#else
viewer-setUpViewInWindow(40,40,800, 600);
#endif
viewer-getCamera()-getOrCreateStateSet()-setMode(GL_LIGHTING,
osg::StateAttribute::OFF | osg::StateAttribute::OVERRIDE |
osg::StateAttribute::PROTECTED);
viewer-getCamera()-getOrCreateStateSet()-setMode(GL_DEPTH_TEST,
osg::StateAttribute::OFF | osg::StateAttribute::OVERRIDE |
osg::StateAttribute::PROTECTED);
viewer-getCamera()-setProjectionMatrixAsOrtho2D(-400, 400,
Re: [osg-users] Question regarding new Geometry implementation
Hi Sebastian, On 26 June 2013 10:34, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Okay, so in my case (in which I get the information about the binding long after the array was created/filled) it is and will be legal to use the long winded setBinding? The Array::setBinding() is the new API and the means for changing the Array binding once it's been created/assigned, so the answer would be YES :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgEarth for comercial uses
Carlos, To echo what Chris said, you can use osgEarth for free in your commercial application. Nothing more is required except that you abide by the license, which says that any changes you make to the osgEarth SDK itself must be made public. ReadyMap.org is not available for commercial use. For high-resolution data you will need to license data from a data provider like ESRI, Microsoft, Digital Globe, etc. You can also purchase data from brokers like MapMart. There are lots of free sources as well, here is a list: http://docs.osgearth.org/en/latest/data.html#where-to-find-data Glenn Waldron / @glennwaldron On Mon, Jun 24, 2013 at 1:35 PM, Carlos Sanches ces...@gmail.com wrote: Hello Glenn ! I d like to know how to proceed to use the osgearth in weather forecast in a broadcast television. We are developing an application using OsgEarth and readymap or arcgis online maps. We ll try to sell this in a future here in Brazil . We want to know how much ll cost this. And if you can sen a better map because some places in Brazil area we have clouds over the tiles. You can answer me in a private e-mail ces...@gmail.com Thank you ! On Fri, Jun 21, 2013 at 12:39 PM, Glenn Waldron gwald...@gmail.comwrote: Carlos, Best way is to use the contact form: http://pelicanmapping.com/?page_id=2 Or email me at gwald...@pelicanmapping.com Thanks. Glenn Waldron / @glennwaldron On Fri, Jun 21, 2013 at 11:34 AM, Carlos Sanches ces...@gmail.comwrote: Hello ! Please I m trying to contact pelican for information about to use maps for comercial ends. The e-mails are returning. Does anybody knows how to contact then ? Thank you ! -- ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changes to osgDB::fstream
Hello, Well due to much frustration I've gone into the source code and modified it so that osgDB::ofstream and osgDB::ifstream don't inherit from std::ifstream or std::ofstream. I've added functions so that it replicates how the class acted before. I also had to change how osgDB::Output worked, because it inherited from osgDB::fstream as well. Once again I've added functions to replicate the previous behavior. I do realize the downside to this. The osgDB::ouput\fstream classes no longer have the polymorphic ability, i.e. use as a std::fstream object. If anyone else is having the same link problems as I am, please email me and I can give you the source code that works for me. Thanks, Braden Edmunds -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54936#54936 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changes to osgDB::fstream
Hi Braden, I'm curious why you seem to be having more problems than other VisualStudio users, it seems like you've had to jump through more hoops than most to get around this VisualStudio bug. Could you post your changes to osg-submissions. I can review them to see if it would be appropriate to merge. Cheers, Robert. On 26 June 2013 17:55, Braden Edmunds edmu...@reaction-eng.com wrote: Hello, Well due to much frustration I've gone into the source code and modified it so that osgDB::ofstream and osgDB::ifstream don't inherit from std::ifstream or std::ofstream. I've added functions so that it replicates how the class acted before. I also had to change how osgDB::Output worked, because it inherited from osgDB::fstream as well. Once again I've added functions to replicate the previous behavior. I do realize the downside to this. The osgDB::ouput\fstream classes no longer have the polymorphic ability, i.e. use as a std::fstream object. If anyone else is having the same link problems as I am, please email me and I can give you the source code that works for me. Thanks, Braden Edmunds -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54936#54936 ___ 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
