Re: [osg-users] Camera and light problem
Hi Jon
If you add your transform to the camera, it is normal that the light follow
the camera..
If you want to keep the light at the same position, you have to attach it
near the root node, and attach the rest of the scene a lower levels than it.
Each child inherit from its parents, so if you attach a group to a
transform, each child of the group (and their children) will follow the
group's transformation.
Vincent.
2008/3/5, Jon [EMAIL PROTECTED]:
Hi all,
I have currently a simple model on my scene, and I've added a light to the
scene represented by a small sphere.
I would like to fix light position and I don't want this one to move with
the model (when I move the camera), or to move it independently from the
main camera...
So I decided to add a camera and to add the light to this one, this didn't
solve the problem, both are moving togethers.
Following is the main code that creates and place objects.
I cannot use normals because I don't have geometry node.
I would appreciate some help for this easy problem!
Thanks in advance.
Jon.
{
…
//_modelGraph group represents the current scene
//_root group will contains _modelGraph plus the light
//create a group for the light
_lightGraph = new osg::Group;
…
_root-addChild(_modelGraph.get());
//create a camera to install the light
osg::ref_ptrosg::Camera camera = new osg::Camera;
// just inherit the main cameras view
camera-setProjectionMatrix(osg::Matrix::identity());
camera-setViewMatrix(osg::Matrix::identity());
//create the light
osg::ref_ptrosg::Light light = new osg::Light;
//Set options…
//create a lightsource for the light
osg::ref_ptrosg::LightSource lightSource = newosg::LightSource;
lightSource-setLight(light.get());
lightSource-setLocalStateSetModes(osg::StateAttribute::ON);
//create a transformation node that will move the node in the scene
osg::ref_ptrosg::MatrixTransform transform = newosg::MatrixTransform;
transform-addChild(lightSource.get());
//Position the light
osg::Vec3 pos(-5.0f, 10.0f, 0.0f);
transform-setMatrix(osg::Matrix::translate(pos));
//Add the transform to the camera
camera-addChild(transform.get());
//create a small sphere to represent the lights position
osg::ref_ptrosg::Geode geode = new osg::Geode;
osg::ref_ptrosg::TessellationHints hints = newosg::TessellationHints;
hints-setDetailRatio(0.3);
osg::ref_ptrosg::ShapeDrawable shape = new
osg::ShapeDrawable(newosg::Sphere(osg::Vec3(
0.0f, 0.0f, 0.0f), 0.6f), hints.get());
shape-setColor(lightColor);
geode-addDrawable(shape.get());
transform-addChild(geode.get());
camera-addChild(_lightGraph.get());
// set the camera to render before the main camera (else just the
light appears on a black screen)
camera-setRenderOrder(osg::Camera::NESTED_RENDER);
_root-addChild(camera.get());
}
___
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] how to update the Camera
Hi, Robert: is there any limit on calling setHomePosition and computeHomePosition()? I have taken a try, but it didn't works. xiaodong On Mon, Mar 3, 2008 at 5:23 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Xiaodong, Could it be that you are looking for the camera manipulator setHomePosition or computeHomePosition method? i.e. viewer.getCamaraManipulator()-setHomePosition(...); Robert. On Mon, Mar 3, 2008 at 2:35 AM, Wu Xiaodong [EMAIL PROTECTED] wrote: Hi, I am freshman in OpenSceneGrapph. Now I have some issue on updating the Camera when the Geode under it was updated. the details of the issue is as following. 1st step. I build a viewer and its scene graph with only one osg::Geometry which contains nothing. and set a TrackballManipulator to the viewer's camera; osg::ref_ptrosgGA::TrackballManipulator trackBall = new osgGA::TrackballManipulator; setCameraManipulator( trackBall.get() ); 2nd step. I update the one Geometry by a object of the class derived from the Geometry node's UpdateCallBack class; the default track ball center seems to be the (0,0,0); when the Gemetry is updated, the Geometry node's center is changed into (x0,y0,z0); but the track ball rotate around the vertex ( 0,0,0). How can I make it rotate around the (x0,y0,z0 ); I read the OSG's reference docs, may I can achieve it by setPreDrawCallback (DrawCallback *cb) . Is there any advice about the application above, Thanks. Xiaodong Wu ___ 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] how to update the Camera
2008/3/6 Wu Xiaodong [EMAIL PROTECTED]: Hi, Robert: is there any limit on calling setHomePosition and computeHomePosition()? I have taken a try, but it didn't works. What do you mean by it didn't work, did it do the wrong thing, did it do nothing at all? These methods just set the home position of the camera manipulator, they don't actual change the current view, to do this you need to call home() on the viewer or camera manipulator. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Font Quality / osgWidget
Hi Jeremy, It shouldn't really matter which order you do things in. The GlyphTexture will be populated in a different order but it shouldn't make any difference beyond this. The fact you are observing a difference suggests that GlyphTexture population order is affecting things in some way. I can't think off hand what this might be - the only very vague guess would that the tex coords are different in some way, perhaps this is related to the clipping you've observed. FYI, I might be doing some refactoring work of the rendering code inside osgText in the not too distant future. At this point I will need to review the lots of code internally with osgText so it'd be a good time to have some unit tests to utilise - osgWidget might well be a good way to generate unit tests ;-) Robert. On Wed, Mar 5, 2008 at 10:33 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I'd like to add another bit of info to this thread; attached are two screenshots (good.png bad.png) rendered using almost identical code: good.png (sharp, crisp) text-setFontResolution(...) text-setCharacterSize(...) text-setText(...) bad.png (very blurry) text-setText(...) text-setFontResolution(...) text-setCharacterSize(...) text-update() Is there something wrong with my 2nd usage of osgText::Text such that I get the poorer quality? I understand that in the first usage the font sizes are already set before the initial text is rendered internally, but shouldn't the 2nd usage produce identical results, given that I call update after setting the new values? (My assumption here, however, could be woefully wrong, but will be useful information either way. :)) On Wed, 2008-03-05 at 16:10 -0500, Jeremy Moles wrote: I've attached a screenshot of some text rendered in a very standard way using osgText: text-setFont(std::string(fonts/monospace.ttf)); text-setCharacterSize(size); text-setFontResolution(size, size); text-setText(label); text-setColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f)); In the screenshot, a the very bottom, you'll see a bit of text called label 6 (copy). Take a close look at the following characters: a, e, 6, ( ...and you'll notice that the glyphs are 1 (perhaps 2) pixels chopped off at the left. I've been hunting this down forever--in fact, I've made a lot of similar posts in the past--but I simply cannot prevent this occurrence in a predictable way. If I play with the font sizes I can sometimes achieve nearly perfect font quality, but it's all guess-work. So I've decided to go back to square one and ask the mailing lists: can anyone with any heavy osgText experience give me any hints as to what is going on? I've tried all of the KERNING options (though this is a monospace font), I've tried hacking Text/TextBase.cpp so that each Glyph absolutely is pixel aligned, I've tried all manner of different fonts--but nothing seems to give predictable rendering results. My suspicion is that the GlyphQuads object's _texcoords values are getting calculated slightly wrong in some cases, but I'm not sure. Having precise font quality in osgWidget will be really important, so I'm willing to make any code changes necessary to facilitate this... ___ 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] how to update the Camera
Hi Robert: Thank you very much. I mean *do nothing at all*, and I solve also the problem by calling the *home(); *The OpenSceneGraph is great. xiaodong On Thu, Mar 6, 2008 at 5:10 PM, Robert Osfield [EMAIL PROTECTED] wrote: 2008/3/6 Wu Xiaodong [EMAIL PROTECTED]: Hi, Robert: is there any limit on calling setHomePosition and computeHomePosition()? I have taken a try, but it didn't works. What do you mean by it didn't work, did it do the wrong thing, did it do nothing at all? These methods just set the home position of the camera manipulator, they don't actual change the current view, to do this you need to call home() on the viewer or camera manipulator. 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
Re: [osg-users] Font Quality / osgWidget
Hi all, I've also experienced the font chopping problem and have also observed that the order of initialisation definately makes a difference to the output. My latest 'fix' was to use different fonts for the two sizes of text I want to display. jp Robert Osfield wrote: Hi Jeremy, It shouldn't really matter which order you do things in. The GlyphTexture will be populated in a different order but it shouldn't make any difference beyond this. The fact you are observing a difference suggests that GlyphTexture population order is affecting things in some way. I can't think off hand what this might be - the only very vague guess would that the tex coords are different in some way, perhaps this is related to the clipping you've observed. FYI, I might be doing some refactoring work of the rendering code inside osgText in the not too distant future. At this point I will need to review the lots of code internally with osgText so it'd be a good time to have some unit tests to utilise - osgWidget might well be a good way to generate unit tests ;-) Robert. On Wed, Mar 5, 2008 at 10:33 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I'd like to add another bit of info to this thread; attached are two screenshots (good.png bad.png) rendered using almost identical code: good.png (sharp, crisp) text-setFontResolution(...) text-setCharacterSize(...) text-setText(...) bad.png (very blurry) text-setText(...) text-setFontResolution(...) text-setCharacterSize(...) text-update() Is there something wrong with my 2nd usage of osgText::Text such that I get the poorer quality? I understand that in the first usage the font sizes are already set before the initial text is rendered internally, but shouldn't the 2nd usage produce identical results, given that I call update after setting the new values? (My assumption here, however, could be woefully wrong, but will be useful information either way. :)) On Wed, 2008-03-05 at 16:10 -0500, Jeremy Moles wrote: I've attached a screenshot of some text rendered in a very standard way using osgText: text-setFont(std::string(fonts/monospace.ttf)); text-setCharacterSize(size); text-setFontResolution(size, size); text-setText(label); text-setColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f)); In the screenshot, a the very bottom, you'll see a bit of text called label 6 (copy). Take a close look at the following characters: a, e, 6, ( ...and you'll notice that the glyphs are 1 (perhaps 2) pixels chopped off at the left. I've been hunting this down forever--in fact, I've made a lot of similar posts in the past--but I simply cannot prevent this occurrence in a predictable way. If I play with the font sizes I can sometimes achieve nearly perfect font quality, but it's all guess-work. So I've decided to go back to square one and ask the mailing lists: can anyone with any heavy osgText experience give me any hints as to what is going on? I've tried all of the KERNING options (though this is a monospace font), I've tried hacking Text/TextBase.cpp so that each Glyph absolutely is pixel aligned, I've tried all manner of different fonts--but nothing seems to give predictable rendering results. My suspicion is that the GlyphQuads object's _texcoords values are getting calculated slightly wrong in some cases, but I'm not sure. Having precise font quality in osgWidget will be really important, so I'm willing to make any code changes necessary to facilitate this... ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shadow Map and threading mode
Hello, I was wondering if there were any known problems related to using osgShadow::ShadowMap and changing the threading mode. In the osgshadow example (SVN), if I change the threading mode (I added a threading handler to it) my graphics driver crashes. In our own software based on OSG 2.2 and using a CompositeViewer, on some machines the problem is more interesting (after a fashion): when the threading mode is changed, the shadow stops moving with the mobile object which causes it (i.e. it stays where it was when the threading mode changed, apparently not updating anymore). On my own machine it just crashes as well, like the SVN version, but on others that's what happens. I haven't double-checked on those machines what happens with the osgshadow example though. So, I just want to know if I should expect it to work or if that's something that's expected not to work for now. This is on Windows (XP / Vista), nVidia 7900 and 8800 cards. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RE Plugin loading problems....
Hi Robert Gordon, Thanks for your interest in this. I'm as certain as I can be that the dll is failing to load because its usage is within an ActiveX control. Under Visual studio you can switch on extended information for seeing what happens when the LoadLibrary is performed. The output records the fact that when trying to load the osgdb_ive.dll file, the loader failed to find the osgSim.dll. This dll is in the same location as the ive dll, and was built at the same time. The output also shows the path that was searched. Within the path was the . directory. I take this to mean ie the current execution path directory. As the LoadLibrary found the osgdb_ive.dll, I can only assume that its knowledge of where it is running from is correct, as the ActiveX control is also located, and registered, within the directory that the osg dll's are. So the only conclusion I can come to is that when dynamically loading a dll that has dependencies on other, as yet not loaded dlls, within an ActiveX control, there appears to be an issue. When I get a chance I'll set up a little test case, and assuming this proves to be the case, I'll submit it to the forum - only for the Windows users thought ;-( If you want more info I can send the extended output from Visual Studio. Its quite explicit in where it fails. Kind regards Neil. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgSim::HeightAboveTerrain and osgintersection
I'm trying to use the osgSim::HeightAboveTerrain class to compute terrain heights at various points within a TXP database. The intent is to get an array of Vec3d's such that I can create a grid pattern using osg::Geometry that (coarsely) represents the database (I tried the OverlayNode and other examples, but the textures just didn't work for me). In my code, I basically create a osgSim::HeightAboveTerrain object, then loop through various points laterally offset from the terrain's center point (as determined by the bounding sphere). With each point, I call the 'computeHeightAboveTerrain' method using the terrain node (read in using osgDB::readNodeFile) and the computed point to get the height above the terrain. Unfortunately, all of the calls return the same height. The terrain is of a mountainous region, so the actual terrain height varies considerably from point to point. As a check, I ran the osgintersection example using the TXP database. For this example, it also returns a constant height (and the same height that I receive in my code). Any suggestions on why a constant height is returned? Are there steps that I'm missing? I searched the mailing list archives and couldn't find any discussions related to my problem. BTW, The TXP database is a paged LOD database with a Z-up orientation. TIA. chuck ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgSim::HeightAboveTerrain and osgintersection
Hi Chuck, osgSim:HeightAboveTerrain or osgSim:ElevationSlice might be of interest, the later is the one I'd use as it give you the whole data. But... both of these query for the heights res tiles, which won't be aligned to the terrain at all LOD levels soo... it won't actually work that well for a general runtime database. As for the specifics of what its not working with a TXP database I can't say - the osgSim classes as explicitly designed to handle paged database so in theory should work just fine. Perhaps the fact that the TXP plugin does some funky management of PagedLOD levels to try and restrict how far apart adjacent tiles can be in LOD level is the cause. One would need to go through with a debugger to be sure. Either way if you want a visual grid on your paged terrain I don't think computing intersections and generating polygons will cut it due to the nature of elevation changes as LOD levels pop in. The best approach you could try would be to compute the intersections on the fly as tiles a loaded in via a custom Registry::ReadCallback - this would use the PlaneIntersector to get the intersections with each new loaded subgraph. However, the approach I'd use would be a custom shader that computes the position in space of each fragment on the terrain and decides to render different colours depending in the fragment was closest enough to a grid interval or not. Such a shader would work with any type of terrain and would be pretty light weight. Robert. On Thu, Mar 6, 2008 at 5:50 PM, Cole, Charles E. (LARC-B702)[GENEX SYSTEMS] [EMAIL PROTECTED] wrote: I'm trying to use the osgSim::HeightAboveTerrain class to compute terrain heights at various points within a TXP database. The intent is to get an array of Vec3d's such that I can create a grid pattern using osg::Geometry that (coarsely) represents the database (I tried the OverlayNode and other examples, but the textures just didn't work for me). In my code, I basically create a osgSim::HeightAboveTerrain object, then loop through various points laterally offset from the terrain's center point (as determined by the bounding sphere). With each point, I call the 'computeHeightAboveTerrain' method using the terrain node (read in using osgDB::readNodeFile) and the computed point to get the height above the terrain. Unfortunately, all of the calls return the same height. The terrain is of a mountainous region, so the actual terrain height varies considerably from point to point. As a check, I ran the osgintersection example using the TXP database. For this example, it also returns a constant height (and the same height that I receive in my code). Any suggestions on why a constant height is returned? Are there steps that I'm missing? I searched the mailing list archives and couldn't find any discussions related to my problem. BTW, The TXP database is a paged LOD database with a Z-up orientation. TIA. chuck ___ 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] Font Quality / osgWidget
I ran into the same problem and I agree that the appearance of the
clipped text is quite ugly. Unfortunately, the problem lies within the
design of osgText and not your usage of it.
Texels sampled within the character cell are linearly blended with one
another, giving an antialiasing effect internal to the character cell.
However, when a character cell has a texel set at its edge, no
blending takes place outside that edge because the texture isn't drawn
outside the quad.
My solution was to modify osgText to draw larger quads for the
character cells (by one texel in each direction), adjusting texture
coordinates accordingly. Side effects are that character cells now
overlap so depth testing needs to be disabled (or some sort of
stenciling operation performed), and extra margin should be allocated
for each character in the texture (using Font::setGlyphImageMargin).
Another possible solution is to disable texture filtering, so all
parts of each character will have the same clipped appearance. If
you're already using some sort of full screen antialiasing this might
not look too bad.
Below is my modified version of Text::computeGlyphRepresentation()
from osgText/Text.cpp. The modified code is controlled by #ifdefs.
Robert: Given the restrictions (depth writing needs to be disabled),
is this something you would want to add to osg? Perhaps configurable
as an optional method of text rendering? If so, I'll submit the
changed files to the submissions list.
void Text::computeGlyphRepresentation()
{
Font* activefont = getActiveFont();
if (!activefont) return;
_textureGlyphQuadMap.clear();
_lineCount = 0;
if (_text.empty())
{
_textBB.set(0,0,0,0,0,0);//no size text
computePositions(); //to reset the origin
return;
}
OpenThreads::ScopedLockFont::FontMutex
lock(*(Font::getSerializeFontCallsMutex()));
// initialize bounding box, it will be expanded during glyph
position calculation
_textBB.init();
osg::Vec2 startOfLine_coords(0.0f,0.0f);
osg::Vec2 cursor(startOfLine_coords);
osg::Vec2 local(0.0f,0.0f);
unsigned int previous_charcode = 0;
unsigned int linelength = 0;
bool horizontal = _layout!=VERTICAL;
bool kerning = true;
unsigned int lineNumber = 0;
activefont-setFontResolution(_fontWidth,_fontHeight);
float hr = _characterHeight/(float)activefont-getFontHeight();
float wr = hr/_characterAspectRatio;
for(String::iterator itr=_text.begin();
itr!=_text.end();
)
{
// record the start of the current line
String::iterator startOfLine_itr = itr;
// find the end of the current line.
osg::Vec2 endOfLine_coords(cursor);
String::iterator endOfLine_itr =
computeLastCharacterOnLine(endOfLine_coords, itr,_text.end());
linelength = endOfLine_itr - startOfLine_itr;
// Set line position to correct alignment.
switch(_layout)
{
case LEFT_TO_RIGHT:
{
switch(_alignment)
{
// nothing to be done for these
//case LEFT_TOP:
//case LEFT_CENTER:
//case LEFT_BOTTOM:
//case LEFT_BASE_LINE:
//case LEFT_BOTTOM_BASE_LINE:
// break;
case CENTER_TOP:
case CENTER_CENTER:
case CENTER_BOTTOM:
case CENTER_BASE_LINE:
case CENTER_BOTTOM_BASE_LINE:
cursor.x() = (cursor.x() - endOfLine_coords.x()) *
0.5f;
break;
case RIGHT_TOP:
case RIGHT_CENTER:
case RIGHT_BOTTOM:
case RIGHT_BASE_LINE:
case RIGHT_BOTTOM_BASE_LINE:
cursor.x() = cursor.x() - endOfLine_coords.x();
break;
default:
break;
}
break;
}
case RIGHT_TO_LEFT:
{
switch(_alignment)
{
case LEFT_TOP:
case LEFT_CENTER:
case LEFT_BOTTOM:
case LEFT_BASE_LINE:
case LEFT_BOTTOM_BASE_LINE:
cursor.x() = 2*cursor.x() - endOfLine_coords.x();
break;
case CENTER_TOP:
case CENTER_CENTER:
case CENTER_BOTTOM:
case CENTER_BASE_LINE:
case CENTER_BOTTOM_BASE_LINE:
cursor.x() = cursor.x() + (cursor.x() -
endOfLine_coords.x()) * 0.5f;
break;
// nothing to be done for these
//case RIGHT_TOP:
//case RIGHT_CENTER:
//case RIGHT_BOTTOM:
//case RIGHT_BASE_LINE:
//case RIGHT_BOTTOM_BASE_LINE:
// break;
default:
break;
}
break;
}
case VERTICAL:
Re: [osg-users] Font Quality / osgWidget
Great info!
Is there any way we can get this modification as an attachment, and not
inline? The likelihood of Robert looking at it seriously is very low if
it's not easily detachable from the e-mail. :)
But again, this is great, great info! Thanks a ton!
On Thu, 2008-03-06 at 10:09 -0800, Mark Sciabica wrote:
I ran into the same problem and I agree that the appearance of the
clipped text is quite ugly. Unfortunately, the problem lies within the
design of osgText and not your usage of it.
Texels sampled within the character cell are linearly blended with one
another, giving an antialiasing effect internal to the character cell.
However, when a character cell has a texel set at its edge, no
blending takes place outside that edge because the texture isn't drawn
outside the quad.
My solution was to modify osgText to draw larger quads for the
character cells (by one texel in each direction), adjusting texture
coordinates accordingly. Side effects are that character cells now
overlap so depth testing needs to be disabled (or some sort of
stenciling operation performed), and extra margin should be allocated
for each character in the texture (using Font::setGlyphImageMargin).
Another possible solution is to disable texture filtering, so all
parts of each character will have the same clipped appearance. If
you're already using some sort of full screen antialiasing this might
not look too bad.
Below is my modified version of Text::computeGlyphRepresentation()
from osgText/Text.cpp. The modified code is controlled by #ifdefs.
Robert: Given the restrictions (depth writing needs to be disabled),
is this something you would want to add to osg? Perhaps configurable
as an optional method of text rendering? If so, I'll submit the
changed files to the submissions list.
void Text::computeGlyphRepresentation()
{
Font* activefont = getActiveFont();
if (!activefont) return;
_textureGlyphQuadMap.clear();
_lineCount = 0;
if (_text.empty())
{
_textBB.set(0,0,0,0,0,0);//no size text
computePositions(); //to reset the origin
return;
}
OpenThreads::ScopedLockFont::FontMutex
lock(*(Font::getSerializeFontCallsMutex()));
// initialize bounding box, it will be expanded during glyph
position calculation
_textBB.init();
osg::Vec2 startOfLine_coords(0.0f,0.0f);
osg::Vec2 cursor(startOfLine_coords);
osg::Vec2 local(0.0f,0.0f);
unsigned int previous_charcode = 0;
unsigned int linelength = 0;
bool horizontal = _layout!=VERTICAL;
bool kerning = true;
unsigned int lineNumber = 0;
activefont-setFontResolution(_fontWidth,_fontHeight);
float hr = _characterHeight/(float)activefont-getFontHeight();
float wr = hr/_characterAspectRatio;
for(String::iterator itr=_text.begin();
itr!=_text.end();
)
{
// record the start of the current line
String::iterator startOfLine_itr = itr;
// find the end of the current line.
osg::Vec2 endOfLine_coords(cursor);
String::iterator endOfLine_itr =
computeLastCharacterOnLine(endOfLine_coords, itr,_text.end());
linelength = endOfLine_itr - startOfLine_itr;
// Set line position to correct alignment.
switch(_layout)
{
case LEFT_TO_RIGHT:
{
switch(_alignment)
{
// nothing to be done for these
//case LEFT_TOP:
//case LEFT_CENTER:
//case LEFT_BOTTOM:
//case LEFT_BASE_LINE:
//case LEFT_BOTTOM_BASE_LINE:
// break;
case CENTER_TOP:
case CENTER_CENTER:
case CENTER_BOTTOM:
case CENTER_BASE_LINE:
case CENTER_BOTTOM_BASE_LINE:
cursor.x() = (cursor.x() - endOfLine_coords.x()) *
0.5f;
break;
case RIGHT_TOP:
case RIGHT_CENTER:
case RIGHT_BOTTOM:
case RIGHT_BASE_LINE:
case RIGHT_BOTTOM_BASE_LINE:
cursor.x() = cursor.x() - endOfLine_coords.x();
break;
default:
break;
}
break;
}
case RIGHT_TO_LEFT:
{
switch(_alignment)
{
case LEFT_TOP:
case LEFT_CENTER:
case LEFT_BOTTOM:
case LEFT_BASE_LINE:
case LEFT_BOTTOM_BASE_LINE:
cursor.x() = 2*cursor.x() - endOfLine_coords.x();
break;
case CENTER_TOP:
case CENTER_CENTER:
case CENTER_BOTTOM:
case CENTER_BASE_LINE:
case CENTER_BOTTOM_BASE_LINE:
cursor.x() = cursor.x() +
[osg-users] Custom stats?
Hi, I'd like to display some custom stats every frame. For example, I have a custom drawable which I'd like to display some information about. What's the best way to go about doing this? Thanks, Brett ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Font Quality / osgWidget
HI Mark,
I'm way too busy with other work now to be able to dive into discuss
osgText in detail right now. You analysis of the problem is good, but
the fix is something that is a general fix. As I said before I
hopefully should get the opportunity to refactor the rendering side to
osgText in the not too distant future, at this point I'll dive fully
in.
Robert.
On Thu, Mar 6, 2008 at 6:09 PM, Mark Sciabica [EMAIL PROTECTED] wrote:
I ran into the same problem and I agree that the appearance of the
clipped text is quite ugly. Unfortunately, the problem lies within the
design of osgText and not your usage of it.
Texels sampled within the character cell are linearly blended with one
another, giving an antialiasing effect internal to the character cell.
However, when a character cell has a texel set at its edge, no
blending takes place outside that edge because the texture isn't drawn
outside the quad.
My solution was to modify osgText to draw larger quads for the
character cells (by one texel in each direction), adjusting texture
coordinates accordingly. Side effects are that character cells now
overlap so depth testing needs to be disabled (or some sort of
stenciling operation performed), and extra margin should be allocated
for each character in the texture (using Font::setGlyphImageMargin).
Another possible solution is to disable texture filtering, so all
parts of each character will have the same clipped appearance. If
you're already using some sort of full screen antialiasing this might
not look too bad.
Below is my modified version of Text::computeGlyphRepresentation()
from osgText/Text.cpp. The modified code is controlled by #ifdefs.
Robert: Given the restrictions (depth writing needs to be disabled),
is this something you would want to add to osg? Perhaps configurable
as an optional method of text rendering? If so, I'll submit the
changed files to the submissions list.
void Text::computeGlyphRepresentation()
{
Font* activefont = getActiveFont();
if (!activefont) return;
_textureGlyphQuadMap.clear();
_lineCount = 0;
if (_text.empty())
{
_textBB.set(0,0,0,0,0,0);//no size text
computePositions(); //to reset the origin
return;
}
OpenThreads::ScopedLockFont::FontMutex
lock(*(Font::getSerializeFontCallsMutex()));
// initialize bounding box, it will be expanded during glyph
position calculation
_textBB.init();
osg::Vec2 startOfLine_coords(0.0f,0.0f);
osg::Vec2 cursor(startOfLine_coords);
osg::Vec2 local(0.0f,0.0f);
unsigned int previous_charcode = 0;
unsigned int linelength = 0;
bool horizontal = _layout!=VERTICAL;
bool kerning = true;
unsigned int lineNumber = 0;
activefont-setFontResolution(_fontWidth,_fontHeight);
float hr = _characterHeight/(float)activefont-getFontHeight();
float wr = hr/_characterAspectRatio;
for(String::iterator itr=_text.begin();
itr!=_text.end();
)
{
// record the start of the current line
String::iterator startOfLine_itr = itr;
// find the end of the current line.
osg::Vec2 endOfLine_coords(cursor);
String::iterator endOfLine_itr =
computeLastCharacterOnLine(endOfLine_coords, itr,_text.end());
linelength = endOfLine_itr - startOfLine_itr;
// Set line position to correct alignment.
switch(_layout)
{
case LEFT_TO_RIGHT:
{
switch(_alignment)
{
// nothing to be done for these
//case LEFT_TOP:
//case LEFT_CENTER:
//case LEFT_BOTTOM:
//case LEFT_BASE_LINE:
//case LEFT_BOTTOM_BASE_LINE:
// break;
case CENTER_TOP:
case CENTER_CENTER:
case CENTER_BOTTOM:
case CENTER_BASE_LINE:
case CENTER_BOTTOM_BASE_LINE:
cursor.x() = (cursor.x() - endOfLine_coords.x()) *
0.5f;
break;
case RIGHT_TOP:
case RIGHT_CENTER:
case RIGHT_BOTTOM:
case RIGHT_BASE_LINE:
case RIGHT_BOTTOM_BASE_LINE:
cursor.x() = cursor.x() - endOfLine_coords.x();
break;
default:
break;
}
break;
}
case RIGHT_TO_LEFT:
{
switch(_alignment)
{
case LEFT_TOP:
case LEFT_CENTER:
case LEFT_BOTTOM:
case LEFT_BASE_LINE:
case LEFT_BOTTOM_BASE_LINE:
cursor.x() = 2*cursor.x() - endOfLine_coords.x();
break;
case CENTER_TOP:
case CENTER_CENTER:
case
Re: [osg-users] Custom stats?
HI Brett, Just have a look how the present stats are done via the StatsHandler, it should tell you the various things that can be done to get things renderered and updated - there should be no need for custom drawables as it can all be done with standard OSG objects. Robert. On Thu, Mar 6, 2008 at 6:24 PM, Brett Wiesner [EMAIL PROTECTED] wrote: Hi, I'd like to display some custom stats every frame. For example, I have a custom drawable which I'd like to display some information about. What's the best way to go about doing this? Thanks, Brett ___ 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::HeightAboveTerrain and osgintersection
Thanks Robert. I was hoping what seemed to be the simplest solution would work. I'll pursue a little further, particularly in the TXP plug-in. Is there a way to force specific LOD's to load (particularly the highest)? I think the shader solution is probably the best and would actually lead into some other work that I'd like to do. Unfortunately, I really don't know anything about shaders. So, I've got quite a bit of learning to do before I can attempt. chuck -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, March 06, 2008 1:04 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgSim::HeightAboveTerrain and osgintersection Hi Chuck, osgSim:HeightAboveTerrain or osgSim:ElevationSlice might be of interest, the later is the one I'd use as it give you the whole data. But... both of these query for the heights res tiles, which won't be aligned to the terrain at all LOD levels soo... it won't actually work that well for a general runtime database. As for the specifics of what its not working with a TXP database I can't say - the osgSim classes as explicitly designed to handle paged database so in theory should work just fine. Perhaps the fact that the TXP plugin does some funky management of PagedLOD levels to try and restrict how far apart adjacent tiles can be in LOD level is the cause. One would need to go through with a debugger to be sure. Either way if you want a visual grid on your paged terrain I don't think computing intersections and generating polygons will cut it due to the nature of elevation changes as LOD levels pop in. The best approach you could try would be to compute the intersections on the fly as tiles a loaded in via a custom Registry::ReadCallback - this would use the PlaneIntersector to get the intersections with each new loaded subgraph. However, the approach I'd use would be a custom shader that computes the position in space of each fragment on the terrain and decides to render different colours depending in the fragment was closest enough to a grid interval or not. Such a shader would work with any type of terrain and would be pretty light weight. Robert. On Thu, Mar 6, 2008 at 5:50 PM, Cole, Charles E. (LARC-B702)[GENEX SYSTEMS] [EMAIL PROTECTED] wrote: I'm trying to use the osgSim::HeightAboveTerrain class to compute terrain heights at various points within a TXP database. The intent is to get an array of Vec3d's such that I can create a grid pattern using osg::Geometry that (coarsely) represents the database (I tried the OverlayNode and other examples, but the textures just didn't work for me). In my code, I basically create a osgSim::HeightAboveTerrain object, then loop through various points laterally offset from the terrain's center point (as determined by the bounding sphere). With each point, I call the 'computeHeightAboveTerrain' method using the terrain node (read in using osgDB::readNodeFile) and the computed point to get the height above the terrain. Unfortunately, all of the calls return the same height. The terrain is of a mountainous region, so the actual terrain height varies considerably from point to point. As a check, I ran the osgintersection example using the TXP database. For this example, it also returns a constant height (and the same height that I receive in my code). Any suggestions on why a constant height is returned? Are there steps that I'm missing? I searched the mailing list archives and couldn't find any discussions related to my problem. BTW, The TXP database is a paged LOD database with a Z-up orientation. TIA. chuck ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Debugging issues with VS80
I am moving my code from VS 2003 to VS 2005 SP1. My code compiles correctly. The problem I have is when I run the program in debug mode I get an access violation saying __non_rtti_object being accessed for the following function: _pGraphicsContext = osgViewer::GraphicsWindowWin32::getWindowingSystemInterface()-createGraphicsContext(_pTraits); I have enabled RTTI (the /GR option). I am using the release osg dlls compiled in vs 2005 available on the website (did the same thing for VS 2003 and things worked fine). Any ideas what the problem could be. Thanks. -Prasant ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Transforms
Quick notation question: When I have a MatrixTransform* mt and a Matrix m and I do this: mt-postMult(m), which of the following am I mathematically doing? mt = mt * m; or mt = m * mt Thanks, Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Font Quality / osgWidget
This is another bug in osg. The problem now is with the relationship
between text and font objects. When a text object draws a new character
with the font, it changes the font's resolution to the text object's
font resolution prior to creating new characters. Future uses of those
characters from that font use the resolution already set. This font
resolution behavior is order dependent and explains the differing
behavior when initializing text objects in different orders.
The resolution control should be removed from the text object and placed
(solely) in the font. I.e. text objects should not be calling
setFontResolution on their fonts because this will affect other text
using the same font. Alternatively, the font interface can be changed so
that a single font object can manage multiple resolutions.
To get around the problem, you can try using a different font object for
each text object that uses a different resolution. To fix the example
code, you should simply create a unique font object for each text
object.
-Original Message-
From: Jeremy Moles [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2008 1:25 PM
To: OpenSceneGraph Users; Mark Sciabica
Subject: Re: [osg-users] Font Quality / osgWidget
On Thu, 2008-03-06 at 11:18 -0700, Mark Sciabica wrote:
OK, here's the file as an attachment.
I applied your changes and got very noticeable results. :)
Something strange though:
Notice in the two screenshots attached, I switch between rendering
15-16's and then 16-15's. The first rendered size is always nice annd
crisp; the second rendered text size is always smudgy compared to the
first. Furthermore, this has nothing to do with font sizes, as both
modes demonstrate the effect. I'm not entirely familiar with the effect
of sub-pixel hinting, but perhaps this is a result of it...
Maybe I'll be able to track this down in the next few days, so that
Robert won't have any bugs to contend with later. :) At any rate, things
are looking good, and I'm really glad to be so close to really nice font
clarity...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jeremy
Moles
Sent: Thursday, March 06, 2008 11:11 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Font Quality / osgWidget
Great info!
Is there any way we can get this modification as an attachment, and
not
inline? The likelihood of Robert looking at it seriously is very low
if
it's not easily detachable from the e-mail. :)
But again, this is great, great info! Thanks a ton!
On Thu, 2008-03-06 at 10:09 -0800, Mark Sciabica wrote:
I ran into the same problem and I agree that the appearance of the
clipped text is quite ugly. Unfortunately, the problem lies within
the
design of osgText and not your usage of it.
Texels sampled within the character cell are linearly blended with
one
another, giving an antialiasing effect internal to the character
cell.
However, when a character cell has a texel set at its edge, no
blending takes place outside that edge because the texture isn't
drawn
outside the quad.
My solution was to modify osgText to draw larger quads for the
character cells (by one texel in each direction), adjusting texture
coordinates accordingly. Side effects are that character cells now
overlap so depth testing needs to be disabled (or some sort of
stenciling operation performed), and extra margin should be
allocated
for each character in the texture (using Font::setGlyphImageMargin).
Another possible solution is to disable texture filtering, so all
parts of each character will have the same clipped appearance. If
you're already using some sort of full screen antialiasing this
might
not look too bad.
Below is my modified version of Text::computeGlyphRepresentation()
from osgText/Text.cpp. The modified code is controlled by #ifdefs.
Robert: Given the restrictions (depth writing needs to be disabled),
is this something you would want to add to osg? Perhaps configurable
as an optional method of text rendering? If so, I'll submit the
changed files to the submissions list.
void Text::computeGlyphRepresentation()
{
Font* activefont = getActiveFont();
if (!activefont) return;
_textureGlyphQuadMap.clear();
_lineCount = 0;
if (_text.empty())
{
_textBB.set(0,0,0,0,0,0);//no size text
computePositions(); //to reset the origin
return;
}
OpenThreads::ScopedLockFont::FontMutex
lock(*(Font::getSerializeFontCallsMutex()));
// initialize bounding box, it will be expanded during glyph
position calculation
_textBB.init();
osg::Vec2 startOfLine_coords(0.0f,0.0f);
osg::Vec2 cursor(startOfLine_coords);
osg::Vec2 local(0.0f,0.0f);
unsigned int previous_charcode = 0;
unsigned int linelength = 0;
bool horizontal = _layout!=VERTICAL;
bool kerning = true;
unsigned int
[osg-users] TerraPage tile having own origin
Hi, I'm building a large visual database using Terra Page and running on OSG. I read that from Terra Vista help that Terra Vista allows the TXP database to have an origin for each tile instead of the whole gaming area. It states that This setting requires an extra offset for the runtime. Anyone knows how do we load such a database in OSG? I may need such a DB because my current XYZ is causing a lot of jittering from terrain to models and lights. Below is an extract from Terra Vista Help. Use this field to tell Terra Vista whether the coordinates in your output TXP database are offset with respect to the origin of the Gaming Area, or with respect to each tile. This could, for example, help if your coordinates were getting too large. Your choices here are: Origin. When set to Origin each tile will be relative to the origin of the database. This is the default setting. Tile. If set to Tile, each TerraPage tile will be relative to its own origin. This setting requires an extra offset for the runtime. The advantage of using Tile, is that there is more numerical accuracy for larger databases. Kiff -Original Message- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Changing day night textures of models in TerraPage OSG
Hi, How do we change the Day/Night/Dry/Wet textures of 3D models and runways that are planted in Terra Page? Anyone can help? Kiff -Original Message- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg with MFC and SDI
hi all I need an example mfc and SDI with OSG 2.3.4. can you help me? - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
