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] 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
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
On Thu, Mar 6, 2008 at 6:53 PM, Cole, Charles E. (LARC-B702)[GENEX SYSTEMS] [EMAIL PROTECTED] wrote: 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)? No, you can only force the highest by iterating from top to bottom like the osgSim::HeightAboveTerrain does. 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. Shaders are really just little C programs with contraints on the data in and data out, its a bit bewildering at first but quite a bit of fun once you get going. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transforms
Hi Renan, mt-postMult(m) is mt = mt * m; Robert. On Thu, Mar 6, 2008 at 7:29 PM, Renan Mendes [EMAIL PROTECTED] wrote: 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg with MFC and SDI
On Fri, Mar 7, 2008 at 6:53 AM, Tran Thanh Hiep [EMAIL PROTECTED] wrote: hi all I need an example mfc and SDI with OSG 2.3.4. can you help me? I have now clue what SDI might be, but there is an osgviewerMFC example. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing day night textures of models in TerraPage OSG
On Fri, Mar 7, 2008 at 2:59 AM, Kiff Loh [EMAIL PROTECTED] wrote: How do we change the Day/Night/Dry/Wet textures of 3D models and runways that are planted in Terra Page? I haven't heard about multiple texture variants in TXP before, but then I don't have Terrex's products, just contributed to the plugin from time to time. I'd recommend chatting with Terrax about it to find out how they store these variants, and how one might go about accessing them. Terrex use the OSG internally in several of their products, and are the lead authors on the OSG's TXP plugin, so should know how to go about it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TerraPage tile having own origin
Hi Kiff, I not familiar with the local tile origin support in TXP, so you best bet is go talk to Terrex engineers about this feature. FYI, The VirualPlanetBuilder generates tiles all with a local origin and a MatrixTransfrom above each tile to place in to the 3D world. The OSG's internal matrices default to double matrices, and the camera setup up code all uses doubles so precision is maintained all the way till the data is passed to OpenGL, so VPB generated database work just fine with whole earth databases right down to ground level. So on the OSG side everything is up to the task, its just a matter of getting things on the TXP plugin side to set things up in a similar way. Robert. On Fri, Mar 7, 2008 at 2:49 AM, Kiff Loh [EMAIL PROTECTED] wrote: 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] File search and absolute paths
On Fri, Mar 7, 2008 at 3:52 PM, Paul Martz [EMAIL PROTECTED] wrote: A client recently pointed out that if you call readNodeFile() and specify a file with an absolute (or even relative) path, but the file can't be found using that path, then the path is stripped and the osgDB looks for the file without the path. Is there a reason for this? I'd think OSG should just return an error if the file can't be found in the path specified. Just curious... Its so you override an absolute path that is no longer valid for the new computer. This often happens when you have a model saved with absolute path for a specific machine, then the data and its imagery is moved to another machine with the imagery filenames now completely wrong, here the DataFileSearchPath + stripped filenames comes to the rescue. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Custom stats?
Hi Brett, Thanks for the further explanation, I know understand a bit more about what you are after. I'm afraid off the top of my head I can think of the specifics of what you'll need to do. You may well need to write you own traversal of the main view's RenderStage rather than relying upon the RenderBin::getStats(..) method. Robert. On Fri, Mar 7, 2008 at 1:57 PM, Brett Wiesner [EMAIL PROTECTED] wrote: Robert, I already have a custom drawable; in fact that's what I want to view the stats of. For example, in the drawable is some openGL code which produces some billboards, and I want to know show how many billboards it's drawing. When I toggle the stats on and off, I'd like to see something like Billboards: 2040 along with the framerate info etc. I've looked at the stats handler and traced the code around. Here's what it seems like I need to do... Please correct me if I'm wrong. 1. Add attributes to osg::Stats for the things I care about. (ie: Billboards) 2. Derive from osg::statsHandler to get at those attributes and draw them. I'm a little confused here about the link between stats and statistics but it seems like I also need to... 3. Derive from osg::Statistics (BillBoardStatistics) and add members for things I care about (ie: myNumBillboards). 4. Add an accept method to my custom drawable class so that when the osg::statsvisitor visits I can get at my derived BillBoardStatistics class and update it with info about the number of billboards. Like I said, I'm confused about the connection between osg::stats and osg::statistics. Is there a connection? How does it work? Am I just way off here? Thanks, Brett Robert Osfield wrote: 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 ___ 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] Bad lighning for osg::Text objects in cheap hardware or mesa software renderer
Hi Andreas, This looks like a bug in the OpenGL driver, and as such try looking at updates to the driver to see if it fixes things. Robert. On Sun, Mar 9, 2008 at 11:05 AM, Andreas Goebel [EMAIL PROTECTED] wrote: Hi, I have the problem that many of my customers (schools) use cheap hardware. I use many osg::Text objects, and with cheap hardware (or the mesa software renderer) they look bad when the distance to the text is getting less. I attach two samples, the good sample is taken with my own hardware, whereas the bad one is taken with a mesa software renderer. I already tried disabling mipmapping, but this did not help. Suggestions for workarounds are highly welcome! 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] FrameBufferObjects and multithreading.
HI Jim, There are limits with the time of threading you can do with cameras that share the same graphics context - the draw traversals has to be single threaded for each camera's rendering, this applies to FBO's as well as normal rendering to a graphics window. You should be able to still run multi-threaded if you have multiple graphics contexts, but the osgdistortion example just uses on graphics context, and multiple FBOs. The example should be able to run DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext, if it can't perhaps there is something about the example that isn't thread safe, I am the author so should know, but alas don't recall the details off the top of my head. When I get some time I'll change the osgdistortion example to allow other threading models and see what happens. Robert. On Sun, Mar 9, 2008 at 8:15 PM, Jim Terhorst [EMAIL PROTECTED] wrote: I am having some difficulty getting FrameBufferObjects to work with multithreading. My application is very close to the osgdistortion example. I noticed that osgdistortion was forcing itself into single threaded operation. When i run it, multi-threaded I get frame buffer object errors from RenderStage::drawInner saying that there is an fbo problem, the FBO status is 0x8cd7, which is GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT. Is this a known problem? Does anyone know of a workaround? Does anyone have experience using FrameBufferObjects with multi-thread'ing? Thanks in advance, jim t ___ 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] get function in osg::Matrixf
Hi Renan, What would a getCoefficients method do?? Do you mean just the 4x4 float/double elements in the matrix? If so there are already methods for accessing the raw data via ptr() and operator(i,j) for accessing the elements. On Sun, Mar 9, 2008 at 9:43 PM, Renan Mendes [EMAIL PROTECTED] wrote: Hi, I'm new in using open source software. Because of that I don't know how to modify the library's code according to my needs. For instance, I'd like to create a getCoefficients() function in osg::Matrix, but I don't know where to make that change. I'm using windows and I've followed the installation step-by-step guide shown on OSG's website. Can anybody teach me how to do it? Thanks. Renan M Z Mendes ___ 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] Philips WOW TV displays...
Hi Guys, As a general comment, the core OSG doesn't yet support the Philip's type of stereo out of the box. Although it isn't really stereo is it... its mono + depth which is a little different, the stereo is in the display unit... At some point I'd see it as natural to roll this type of 3D display support into the core OSG. I don't have such a display to play with so I'm afraid its something that others will have to code up and submit. Right now 3D display support is done at a relatively low level in osgUtil::SceneView with it hiding all the implementation details. This isn't the most efficient way to do it though as it forces the 3D display support down into a single threaded part of the pipeline. A much more scalable route would be to do add 3D display support into osgViewer, and use high level slave cameras to set up the appropriate rendering. So... if you do plan to submit support for Philip's 3D display then I'd recommend doing it in a similar way to the way that osgdistortion is put together using slave cameras and FBO's. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Where to get the State from?
HI Art,
As osg::GraphicsContext has a osg::State object, while the
Viewer/Composite class has a collections one or more
GraphicsContexts virtue of the Cameras that they maintain. The viewer
classes have a convenience method getContexts(ViewerBase:Contexts)
which you can use to get the contexts. i.e.
Viewer::Contexts contexts;
viewer.getContexts(contexts);
for(Viewer::Contexts::iterator itr = contexts.begin();
itr != contexts.end();
++itr)
{
osg::GraphicsContext* context = *itr;
osg::State* state = context-getState();
// do with me what you will
}
On Mon, Mar 10, 2008 at 3:39 PM, Art Tevs [EMAIL PROTECTED] wrote:
Hi folks,
imagine I have a class derived from osgViewer::Viewer.
No I need the correct osg::State to apply something.
Where to get it from?
1. One solution could be:
dynamic_castosgViewer::Renderer*(getCamera()-getRenderer())-getSceneView(0)-getState();
however this state seems not to be initialized and I
have manually to call the initializeExtensionProcs()
method. And this seems not to be elegant solution.
2. Second solution could be:
_currentContext-getState();
however _currentContext seems to be NULL during the
run of osgViewer::Viewer.
Hence where to get the correct state from? I do not
have any SceneView or similar things defined, just the
customized viewer.
Best regards,
Art
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/set
___
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] Multiple Cameras Render to Single Texture
Hi ? Have a look at the osgdistortion example or the osgViewer::setUp3DSphericalDisplay() code - its sets up six slave cameras which rendering into a texture cube map, and then a final slave camera to render the final distortion correction mesh. Robert. On Mon, Mar 10, 2008 at 9:10 PM, spowers [EMAIL PROTECTED] wrote: I currently have an application that uses several osg::Camera objects that each render to an osg::Image Is there a way to get these Cameras to render to the same texture but use distinct real-estate for each camera? i.e each frame will appear side by side within the texture. I can render them to the screen by setting their viewports to be adjacent to one another but I cant figure out how to save them to a texture in this way without moving data around in the texture buffer. I cant use readPixels or some derivative thereof because I plan to render the cameras to a pixel buffer so that they dont have to be rendered to the screen. In case its necessary, I'm trying to render a full 360 view around a single point with minimal distortion. I've found the best way to do this is to use multiple cameras and line up their frustums so they share a side. Thanks in advance! ___ 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] about compass
On Tue, Mar 11, 2008 at 7:05 AM, IceSharK [EMAIL PROTECTED] wrote: Hi~ scene have a model and a compass which using camere hud. how to rotate compass follow model's rotation making by user input ? You need to use extract the rotation part of the the master camera's view matrix to give you the rotation, then use this when computing the rotation matrix for your compass model. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Vec3 == Vec3d
HI Anders, It isn't possible just to remap the Vec3 typedef from Vec3f to Vec3d, as you have found the their are many places that explicitly rely on floats. Places like BoundingBox and BoundingSphere could potentially be moved across to use Vec3d rather than Vec3f, and the way to do this would be to use a local vec_type typedef. This type of change is best done locally, as has been done with other similar classes such as Plane and LineSegment that now do this. General conversion to using double versions is a bad thing w.r.t rendering, and general performance, not from double maths, but rather memory footprint of double vector data and the inability of OpenGL drivers/hardware to handle double data without converting to floats. The thing to do is to keep all vertex data destined for OpenGL in floats, and just keep high level scene graph objects in doubles where required for precision. In the case of managing whole earth databases, almost all of the work I have done in the past year has been in this area, here I use MatrixTransform's to place geometry in a local coordinate frame into its final ECEF coordinate frame. The OSG's Camera's view matrix is all in doubles, and the cull traversal accumulates all matrices from the camera right down to the geometry leaves in doubles so keep precision for as long as possible. Only when the final matrices are passed to OpenGL does precision get lost, but generally the errors are subpixel by this stage thanks for the tiles local to the viewer having a relatively small modelview matrix translation, and far tiles which do have greater translation and hence high values and more error are further away so the errors are relatively the same - still subpixel so you don't see any jitter. You physics engine integration would be best to use the same approach, keep local origins and transforms to place this in ECEF. Robert. On Tue, Mar 11, 2008 at 11:11 AM, Anders Backman [EMAIL PROTECTED] wrote: Hi all. Im +working in a project where we are rendering objects on Center of Earth (ECC) so we have a z-coordinate of 6.7E6Meters. So obviously we need to transform objects close to origo to be able to render them. I noticed that I got quite a few anomalies in the rendering, flickering/jumping objects. This probably comes from that I do some custom OpenGL rendering in a Drawable, where I update the bounding box of the drawable. In this update of the bounding box, I have the large translation built in, so the BoundingBox will contain the 6.7E6 coordinates and this obvious affects the resolution of the float used everywhere in BoundingBox calculations... So I wanted to use double for this, but this caused quite a lot of problems during build because its more or less hardcoded that Vec3f is default: To avoid this, I would have to apply this translation above the Drawable, instead of sending the matrix to my custom drawable (where I do glMultMatrix()). Now as this transformation is a result of a Physical simulation (in the ECC coordinate space) its not that trivial to get to the result I want, it would more or less require me to get the transformation for each simulated object and multiply with the inverse before sending it to the rendering. This is of course possible, but I was wondering if it would be possible to switch to Vec3d implementation of Vec3 using for example a flag in CMake? I guess all the Vec3Array etc, is still depending on Vec3f for OpenGL compatibility so in theory it would be possible. But in BoundingBox for example float is used explicitly for getMin()/getMax() etc.. Here is the beginning of the list of compilation errors I got when I tried to change Vec3 to Vec3d (in the Vec3 header file): 2C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Array(458) : error C2535: 'void osg::ValueVisitor::apply(osg::Vec3 )' : member function already defined or declared 2 C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Array(444) : see declaration of 'osg::ValueVisitor::apply' 2C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Array(492) : error C2535: 'void osg::ConstValueVisitor::apply(const osg::Vec3 )' : member function already defined or declared 2 C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Array(480) : see declaration of 'osg::ConstValueVisitor::apply' 2C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(82) : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' to 'float ' 2C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(85) : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' to 'float ' 2C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(88) : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' to 'float ' 2C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(91) : error C2440: 'return' :
Re: [osg-users] 3D Studio Max (3DS) Output
Hi Chris, As you have found out there is no write support in the 3ds plugin. The 3ds format is not a good format so its not something I'd actually recommend as a route for interoperability. The OSG is open source though, so if you have the itch then feel free to dive into the code and add write support. Robert. On Tue, Mar 11, 2008 at 4:21 PM, Chris Denham [EMAIL PROTECTED] wrote: I'm looking for a way to export from OSG to 3DS format. I notice that OSG does provide a plugin for loading 3DS, but does not appear to support the output of that format. Looking at the sources for the 3DS plugin, I noticed that there is code that may support part of the process of 3DS output e.g. in c:\OpenSceneGraph\src\osgPlugins\3ds\file.cpp extern LIB3DSAPI Lib3dsBool lib3ds_file_write(Lib3dsFile *file, iostream *strm); extern LIB3DSAPI Lib3dsBool lib3ds_file_save(Lib3dsFile *file, const char *filename); These methods can write out the data structure created during model import, so I wondered how big a job it is to fill in that Lib3dsFile structure with an OSG scene. Has anyone has a go at this? If so, I can volunteer to help finish it off. Suggestions or pointers anyone? Chris Denham. ___ 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] OpenFlight export issues
Hi Paul, W.r.t UserData I'd suggest placing osgSim container for the extra OpenFlight flags, users can then do a dynamic cast of UserData and get the info they want. The osgSim::GeographicLocation class already serves this purpose. W.r.t one or two plugins. Simplicity of high level management would suggest using a single plugin. A single plugin would also promote code reuse. But... if there isn't much code reuse it could make the two sets of code rather unwieldy. If we do continue with two plugins then one could get the .flt reader plugin to load the .flt write plugin on demand. Or extend osgDB::Registry so that one can have multiple plugins registered per format, but I feel this is quite a bit of extra complexity for a small amount of gain in terms of functionality - code complexity in osgDB::Registry itself does need to be taken into consideration, personally I already find it complex enough. Robert. On Tue, Mar 11, 2008 at 5:39 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- I'm making good progress on the OpenFlight exporter plugin and wanted to bounce a couple ideas off you. There is a customer requirement to be able to preserve the OpenFlight Object record flags that indicate don't display at night, don't display at day, etc. Currently, the importer ignores these flags and just creates an osg::Group for an OpenFlight Object record. I'm thinking about saving these flags as UserData on the osg::Group. This brings about the question: Will there be two separate OpenFlight plugins, one for import and one for export? This is the way I had originally envisioned it, but there is an issue with the osgDB not (fully) supporting two plugins for one extension; the only way I've found to get it to work is to explicitly load one of the plugins first. If the import and export are separate plugins, then this complicates sharing data structures such as the proposed UserData to preserve FLT Object flags. If the two plugins should be combined, then I should probably get to work on this now to save me work in the future. Thoughts? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ 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] osgWidget 0.1.6
Hi Jeremy, Good to see another release of osgWidget make it out into the daylight. W.r.t the crash, try forcing the app to be single threaded. Beyond that I can't suggest much. Alas I'm too busy myself for experimenting with osgWidget yet, but I really really want to get started with it. Robert. On Tue, Mar 11, 2008 at 5:46 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I tagged a 0.1.6 of osgWidget: http://osgwidget.googlecode.com I really wouldn't even bother posting about it to be honest but I need a bit of help if anyone is willing to try it. :) Upon building osgWidget (you'll want to get the monospace font and the osgText.cpp patch for maximum font clarity, but they aren't necessary), run the osgwidgetinput example and press the following keys: n SPACE Where that's the actual key 'n' and the spacebar. Something really bizarre is happening on my machine and I'm beginning to think it's a driver bug... what happens though is that I get an Floating Point Exception inside of NVidia's libGL, and it seems to have something to do with the space character in some context. If you immediately insert a space character, you can then follow that with any series of key presses you like, including spaces or otherwise. Anyways, this isn't a big deal (I'm sure I'll get it figured out), but I just wanted to let folks know I'm still alive and things are chugging along slowly. :) (I've been extremely busy these last few weeks writing some system-auditing software in Python for a client, and haven't had much time for hobby code...) ___ 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] removeView from eventHandler - crash ...
Hi Roni,
You can't remove an object while its being operated on, so you need to
change you code so that the event handler sets an operation that you
main loops does at a safe time. You'll need to stop and start
threading as well to avoid threads still using the view when you
remove it, so do something like:
while(!viewer.done())
{
viewer.advance();
viewer.eventTraversal();
viewer.updateTraversal();
if (needToDoSpecialViewerOperation)
{
viewer.stopThreading();
// do my special operations...
viewer.startThreading();
}
viewer.renderingTraversals();
}
On Wed, Mar 12, 2008 at 11:29 AM, Roni Rosenzweig [EMAIL PROTECTED] wrote:
Hello
I added an event handler for dynamically removing a view during the run.
However it crashes because in CompostieViewer::eventTraversals, after the
call to the event handler (which removes the view hence it's deleted)
there's another usage of the view, which is already deleted (there's a call
to the matrix manipulator).
Is there a way to overcome this problem so that views can by removed during
the run by an event handler?
Roni
___
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] Renderstages
Hi Kim, RenderStage/RenderBin/StageGraph/RenderLeaf are a collection of classes used to manage the OSG's rendering backend, controlling both the draw order and state inheritance. The cull traversal reads items like StateSet::RenderBinDetails and in scene graph osg::Camera's as guide of how to set up the RenderState/RenderBin graph. You can via cull callbacks create your own RenderStages/RenderBin and place these in the viewer's active RenderStage, but in general its easier just to use osg::Camera and StateSet::RenderBinDetails to control this part of the rendering backend. Back in the 1.0 days one couldn't do this so flexible so one would be forced into manually creating RenderStage/Bins on each frame, but it was much more awkward and code hungry then the more scene graph centric means. Robert. On Wed, Mar 12, 2008 at 6:27 PM, Kim C Bale [EMAIL PROTECTED] wrote: At the moment I'm using a lot of post/pre render passes to generate a series of effects and was looking toward cleaning up my code. I was browsing the osgUtil lib and came across the renderstage class, it sounds like I could use it to tidy up the structure of my graph. But I don't really understand how they're used. Does anybody know of a good example where they're used outside of the core osg libs? I didn't find anything in the example code. Cheers, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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] OSG 2.2 CEGUI 5.0 no longer works
Hi Sergey,
First up, from my brief experience with CEGUI I can say it's not up to
scratch, as well as being a bit of coding mess it lacks support for
threading and multiple graphics contexts, it falls a long way short of
the capabilities of what OSG applications are capable of. The
osgWidget that's in development has much greater potential in this
respect.
That being said, if you must get the OSG and CEGUI to work together
you have to bring the OSG down to CEGUI level - you must just use it
with a single window, and you must use it single threaded. The OSG
2.x by default will go multi-threaded if you have a multi-core system,
even with a single window, whereas OSG 1.x would only go
multi-threaded when you have multiple windows with a single camera on
each - which is probably why you were lucky with OSG 1.x.
Try adding:
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
Before your viewer.realize();
However, osgWidget does have much greater potential, so I'd recommend
you pitch in an help get it up to speed.
http://code.google.com/p/osgwidget/
Robert.
On Wed, Mar 12, 2008 at 7:34 PM, Leontyev, Sergey [EMAIL PROTECTED] wrote:
Hello Serge,
It still does not work, I tried to add viewer.renderTraversals() before
CEGUI init, it did not do the trick… I also found some of your other posts
and tried to add
state.setActiveTextureUnit(0);
state.setClientActiveTextureUnit(0);
inside of drawImplementation… , still did not work
Everything seems to work but all images are WHITE, there are no errors in
CEGUI log….
Can I ask for the code you are using I can contact you by your gmail email
if you wish
So you are saying it works for you OSG 2.2? I cant understand what I am
doing wrong
Thank you for your time
Sergey
PS here is my main
osgViewer::Viewer viewer;
osg::ref_ptrosg::Group group = new osg::Group;
osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFile(C:/Program
Files/OpenSceneGraph2/data/cow.osg);
group-addChild(loadedModel.get());
viewer.setSceneData(group.get());
viewer.realize();
viewer.renderingTraversals();
osg::ref_ptrosg::Geode geode = new osg::Geode;
osg::ref_ptrCEGUIDrawable cd = new CEGUIDrawable();
geode-addDrawable(cd.get());
group-addChild(geode.get());
CEGUI::DefaultResourceProvider* rp = (CEGUI::DefaultResourceProvider*)
(CEGUI::System::getSingleton().getResourceProvider());
//std::string s = C:\\Program
Files\\CEGUI-SDK-0.5.0b-vc8\\datafiles\\;
std::string s = datafiles\\;
rp-setResourceGroupDirectory(schemes,s+schemes\\);
rp-setResourceGroupDirectory(imagesets, s+imagesets\\);
rp-setResourceGroupDirectory(fonts, s+fonts\\);
rp-setResourceGroupDirectory(layouts,s+layouts\\);
rp-setResourceGroupDirectory(looknfeels, s+looknfeel\\);
rp-setResourceGroupDirectory(lua_scripts,s+lua_scripts\\);
CEGUI::Font::setDefaultResourceGroup(fonts);
CEGUI::Imageset::setDefaultResourceGroup(imagesets);
CEGUI::WindowManager::setDefaultResourceGroup(layouts);
CEGUI::WidgetLookManager::setDefaultResourceGroup(looknfeels);
CEGUI::ScriptModule::setDefaultResourceGroup(lua_scripts);
CEGUI::Scheme::setDefaultResourceGroup(schemes);
cd-loadFont(Commonwealth-10.font);
cd-loadFont(DejaVuSans-10.font);
cd-loadScheme(WindowsLook.scheme);
cd-loadScheme(TaharezLook.scheme);
//cd-loadLayout(unnamed1.layout);
cd-loadLayout(demo8.layout);
//cd-loadLayout(demo7Windows.layout);
viewer.getCamera()-setViewMatrixAsLookAt( osg::Vec3(100, 100, 0),
osg::Vec3(0, 0, 0), osg::Vec3(0, 0, 1));
while(!viewer.done())
{
viewer.frame();
}
And here I added 1900, 1200 ( I also tried to leave it alone and resize
later in main to make it work
CEGUIDrawable::CEGUIDrawable()
{
setSupportsDisplayList(false);
setEventCallback(new CEGUIEventCallback());
new CEGUI::System( new CEGUI::OpenGLRenderer(0, 1900, 1200) );
}
___
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] OSG to Multi-Gen Creator...
On Thu, Mar 13, 2008 at 12:17 PM, [EMAIL PROTECTED] wrote: Sorry if this has been answered before. Just a few days ago I need to go from an OSG Scene to a format that Multi-Gen Creator can read in. Does anyone have any suggestions please ? Wait till Paul Martz makes his OpenFlight writer plugin public and hey presto you have your solution. Have a look through the archives for this week and you should find Paul's last emails mention about this work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PrecipitationEffect and antialiasing
Hi Loinel, Performance when using the preciptiation effects is heavily dependant on fill limit as overdraw is so high. Ideally it'd be possible to disable FSAA when doing precipitation effects as the motion and texture blending pretty well do away with any noticable effect of FSAA on the particles themselves, but alas I don't know of a way of achieving this with present drivers. Regardless though, I'd say all your results are just fine - all well about 100Hz save for 8xS. As all you ever need to reach is your display systems refresh rate having really high frame rates with vysnc is not in any way useful for a final sim that has vsync on. Robert. On Thu, Mar 13, 2008 at 1:32 PM, Lionel Lagarde [EMAIL PROTECTED] wrote: Hi, I'm adding precipitations in our application and I'm very surprised by the performance differences when I use different antialiasing settings. Configuration: Core 2 duo 6400 / GeForce 7900 GTX I run the command osgprecipitation cow.osg No AA: 587 Hz (initial view) 2380 Hz (viewed from above) 2x:554 Hz (initial view) 2046 Hz (viewed from above) 4x:480 Hz (initial view) 1530 Hz (viewed from above) 8xS: 2 Hz (initial view) 440 Hz (viewed from above) The anisotropic filtering also reduce the performances. Can someone confirm these results. Why does the camera position impact the frame rate ? Is there some things that are not rendered when the raindrops are seen from above ? ___ 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] Is there any relationship between Multitexturing of OSG1.2 and Thread Optimization of the NVIDIA control panel
Hi, Multitexturing has absolutely nothing to do with threading on the OSG side, so if the enabling Thread Optimization on the NVidia control panel is almost 100% percent certain to be a bug in the NVidia driver. Robert. On Thu, Mar 13, 2008 at 2:41 PM, zhangguilian [EMAIL PROTECTED] wrote: Hi, I use Multitexturing in my application, when I use NVIDIA graphics driver version 169.21 and turn on the Thread Optimization on the NVIDIA control panel, using the second texture unit seems to make the scene destroyed-the scene has lots of debris(The strange phenomenon is in Attachment), I have only one GPU and its model is NVIDIA GeForce 8800 GTS, every thing will be OK if I turn off the Thread Optimizaiton and using other driver versions, I don't know whether there is any relationship between Multitexturing of OSG1.2 and Thread Optimization of the NVIDIA control panel, and I also wonder how to solve this problem. Thanks very much! zhangguilian 2008-03-10 ___ 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] Testing of SVN version please
Hi All, I am now preparing for another developer release of the OpenSceneGraph and VirtualPlanetBuilder. I'd very much appreciate testing across platforms, please write if things compile and run fine or not. If there are any errors I'll try and get them merged in time for the dev releases that I plan to make in a few hours. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
On Thu, Mar 13, 2008 at 6:15 PM, Andy Skinner [EMAIL PROTECTED] wrote: I built SceneGraphBuilder.i to get a look at the preprocessed code. This looks like: void ( * sunOglCurPrimTablePtr - oglColor4f ) ( sunOglCurrentContext , GLfloat red , GLfloat green , GLfloat blue , GLfloat alpha ) ; There is definitely something whacky there. I'll give renaming a try, and try to find out where this is coming from. I'll go ahead an rename the methods, just removing the gl prefix. I'll check in this change once I've got things built. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing viewport while running
Hi J-A,
If the viewport is smaller than the window and there is nothing else
clearing the window then you will see a left over contents of the
window.
To handle cases like this there is a clear in GraphicsContext that you
can enable via the GraphicsContext::setClear*() methods. The
GraphicsContext clear is off by default as the cameras normally cover
all the window making it not necessary to have this extra clear in
most cases.
Robert.
On Thu, Mar 13, 2008 at 7:08 PM, [EMAIL PROTECTED] wrote:
Hi,
A simple problem:
When I try to modify the viewport zone during execution: the new
viewport content is displayed on top of the old one. Do you know why
the old one is not cleared?
I guess I should use a specific clearing function, but can't find
the right one.
Not my real application (I don't do this every frame), but the same
problem happens for this situation:
...
// In a previous function
viewer_.getCamera()-setViewport(0,0,1280,1024); // initial size
...
while (!viewer_.done())
{
viewer_.getCamera()-setViewport(100,100,300,300);
// Draw the next frame.
viewer_.frame();
}
Thanks in advance!
J-A
___
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] Testing of SVN version please
On Thu, Mar 13, 2008 at 8:55 PM, Andy Skinner [EMAIL PROTECTED] wrote: I'm not finished yet, but your change plus my include in GraphicsWindowX11 seem to work. (See my other email for that.) When you are done could you send me changed file(s), this will avoid the chance of my guessing at the wrong changes. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
As a general comment. I am aware of the regression in some of the osgShadow implementations, these alas seem to have come in along with fixes with to other problems. I don't which set of changes broke things for which sets of models though.. a clear case for more osgShadow related unit tests. One problem with multipass techniques like shadowing is the variability of things like glPolygonOffset, so to this end I think we need to isolate this side completely and test it on its own. I'm currently thinking about writing a new OSG example that will just test glPolygonOffset and then we can all try the example out and share screenshots so we can get a picture of what hardware does what with what settings. Use of osg::Depth as an alternative is something that could also be explored at the same time. I'm heading offline now, catch up w' you all in the morn. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
Hi Paul, On Thu, Mar 13, 2008 at 9:45 PM, Paul Martz [EMAIL PROTECTED] wrote: Release build complete for VS 2005, WinXP. Tested osgdem and it runs well. I noticed it does leave large temporary files lying around after finishing the database: temporaryfile_imageFileName is left in the output directory. Should osgdem delete this after a successful run? This is not new behavior, and has been present since (at least) the last developer release. I am running the following command: osgdem --terrain -d elevFileName -t imageFileName -o out.ive -l 1 The temporary files are produced when it needs to reproject the source data. As you mention they just get dumped in a local directory, while they'd be better off placed in a single directory and/or clean up after the run. Its useful not to clean up after the run though as if you re-run the build you can use the reprojected files as sources instead of the original files and thus avoid reprojection. With modern VPB this whole temporary reprojection has been dealt with in a better way using vpbcache, but its a manual system that you have to invoke vpbcache to prep your data, getting it to do all the required reprojections etc, once the cache is populated the resulting cache file that describes all the data and their reprojections can be used as input to osgdem/vpbmaster and these will then pick files from the cache according to the projection of the sources they need. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] observer_ptr get() return type issue
Hi Will, This isn't really a bug, rather just an implement decision that I made on implementing the obersever_ptr. It is however inconsistent with ref_ptr, which was originally like the oberserver_ptr but I believe I probably relaxed this long ago when coming up against issues of const ref_ptr and no const pointers they were managoing - std::setref_ptr is one such awkward instance. FYI, ref_ptr is a very early addition to the OSG, while observer_ptr is quite recent addition so hasn't had the same exposure to problems that the ref_ptr has had to deal with. Reflecting on things now I think it makes sense the observer_ptr should keep the same behaviour as ref_ptr in the case of the various const dereference/get methods, so I've tweak the observer_ptr so that it now passes back T*, T for the const get(), operator*() and operator-() methods. This will be in OSG-2.3.5 dev release that I'll make this morning. Robert. On Thu, Mar 13, 2008 at 9:54 PM, Will Dicharry [EMAIL PROTECTED] wrote: Hi All, I was working with observer_ptr and noticed that a const gets added to the get() return type. The observer_ptr::get() const method returns a const T*. I think the const modifier on the method should only apply to the observer_ptr object, not to the object that is pointed at. If the pointer is pointing to a const T*, then the return type would be const without modifying the return type of get(). Is this a bug, or is observer_ptr designed this way for some reason? Thanks, Will ___ 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] osgWidget
Hi Sergey, On Fri, Mar 14, 2008 at 1:30 AM, Leontyev, Sergey [EMAIL PROTECTED] wrote: I heard this library will be included before May 2008 and by that time it will it have some basic functionality: panels with buttons, and possibly some other GUI elements such as dropdown lists. Is this right? And will it be stable and suitable for a large project? I can't speak for Jeremy Moles (the author of osgWidget) about timing, he does mention the above intentions, but he is busy and coding up osgWidget in his spare time so one needs to be aware of this - he has made an open call for assistance and being open source there are few barriers beyond time and know how preventing others like yourself for pitching in. As a general note, with open source projects its good practice to release early and often, so you get a very early glimpse of what a project is like, even both its fully designed let alone implemented. This might seem a bit like a half made bed, but the beauty development wise is that actual users can try it out and spot deficiencies or better solutions to problems very early in the life of project, and well before its gone down any paths of no return. The OpenSceneGraph itself is a project where releasing early, years before 1.0 was made in fact, actually help members of the community get involved direction of the project, it made a huge difference to the robustness and quality of the design having real users testing and debugging the design and implementation as it was evolving - it meant that we had a very good hit rate on solving tasks that end users had to solve, rather than just hitting bullet points on a marketing chart. W.r.t integration with the core OSG, the exact timing I can't say, this is down to how the software itself evolves during the next few months and the availability on engineers (there is a constant eb and flow of how busy we are on different tasks). However, I wouldn't worry about this, getting fixated on a particular merge with the main OpenSceneGraph distribution won't actually make much difference to osgWidget itself, it's open source already - you have all the software required to make it work, and being a NodeKit it'll just slot into the OSG at the right time with minimal fuss. Also, there is a possibility that I will be available to help in order to accelerate the release, but I am not sure how this works. Who do I contact? Jeremy Moles is on the list, feel free to use the osg-users mailing list. Just get stuck in. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
Hi Ulrich, I've seen reports of this type of problem before - definition of static values in headers, can't remember the exact times but its happened a couple of time in osg history. Fixes would be to move the definition into the .cpp, to change to using #define or to use an enum. I'll have a bash with converting it to an enum. Robert. On Fri, Mar 14, 2008 at 10:43 AM, Ulrich Hertlein [EMAIL PROTECTED] wrote: I'm getting a build error for r7942 in osgPlugins/osgSim on MacOS X: [ 41%] Built target osgdb_osgparticle Linking CXX shared module ../../../lib/osgPlugins-2.3.5/osgdb_osgsim.so /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: osgSim::ObjectRecordData::FLAT_SHADED osgSim::ObjectRecordData::DONT_ILLUMINATE osgSim::ObjectRecordData::DONT_DISPLAY_AT_DUSK osgSim::ObjectRecordData::GROUPS_SHADOW_OBJECT osgSim::ObjectRecordData::DONT_DISPLAY_AT_NIGHT osgSim::ObjectRecordData::DONT_DISPLAY_IN_DAYLIGHT collect2: ld returned 1 exit status make[2]: *** [lib/osgPlugins-2.3.5/osgdb_osgsim.so] Error 1 make[1]: *** [src/osgPlugins/osgSim/CMakeFiles/osgdb_osgsim.dir/all] Error 2 make: *** [all] Error 2 The values are declared e.g. 'static const unsigned int FLAT_SHADED = ...' in include/osgSim/ObjectRecordData so that should be just fine, no need to link anything for those symbols. From the verbose output I can't see anything obvious missing so I'm a bit baffled by this at the moment. Cheers, /ulrich ___ 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] RE OSG to Multi-Gen Creator...
Hi Neil, I don't know Creator myself either, but I would have thought that it supports some of the export routes that the OSG has - COLLADA and .obj are two there there is a chance it'd support. Perhaps others with Creator itself will be able to answer it. As mentioned in another thread recently there is always 3rd party tools like Polytrans. Robert. On Fri, Mar 14, 2008 at 11:07 AM, [EMAIL PROTECTED] wrote: Hi Robert, Sorry for the noise. In part I couldn't remember what I'd asked before, but also the emphasis of my request was slightly different in that, as I don't know creator at all and don't even have the application, I don't know what other formats it can take in. I do, however, have a client who needs to get models into that package. I was merely asking whether there was an alternative route to getting an osg scene into creator - even via a third party if necessary - so that I could at least get something for my client whilst the OSG pluggin was being developed further by Paul. I shall assume, from your response, that there isn't really an alternative that I can take, and I shall await the release of the new pluggin from Paul. Once again, sorry for the noise. Kind regards Neil. ___ 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] Testing of SVN version please
Hi Ulrich, On Fri, Mar 14, 2008 at 11:06 AM, Robert Osfield [EMAIL PROTECTED] wrote: I've seen reports of this type of problem before - definition of static values in headers, can't remember the exact times but its happened a couple of time in osg history. Fixes would be to move the definition into the .cpp, to change to using #define or to use an enum. I'll have a bash with converting it to an enum. Changing to enum certainly keeps things compiling under Linux. Could you do an svn update and let me now how the compile is? Once I've got confirmation that this works I'll go ahead and make 2.3.5. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
Hi Tony, Thanks for the feedback. I'm aware of the threading issue in osgGA::StateSetManipulator, its easy to fix by setting the DataVariance of the StateSet it modifies to DYNAMIC, but... this will effectively forces the main thread to wait till the whole draw traversal is complete as the StateSet it modifies decorates the whole scene graph. This is rather a heavy impact for just occassionally responding to a key press so I'm looking for a solution that avoids this impact. While I wait for feedback on the OSX I'll ponder on this issue so more to see if I can come up with quick solution, but it may well be something that requires more extensive changes beyond StateSetManipulator and hence more time so would have to wait till after 2.3.5. Robert. On Fri, Mar 14, 2008 at 10:24 AM, Tony Horrobin [EMAIL PROTECTED] wrote: OpenSceneGraph compiles cleanly in the RelWithDebInfo configuration. osgviewer cessnafire.osg There is an issue with toggling textures ( it becomes unresponsive or erratic after a while ) which is fixed by using --SingleThreaded Ubuntu 7.10 Linux 2.6.23.14 #2 SMP Wed Jan 30 16:54:58 GMT 2008 OpenGL renderer string: GeForce 8800 GTS/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 169.09 Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) -Tony ___ 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] Testing of SVN version please
Hi Tony et al, On Fri, Mar 14, 2008 at 11:36 AM, Robert Osfield [EMAIL PROTECTED] wrote: While I wait for feedback on the OSX I'll ponder on this issue so more to see if I can come up with quick solution, but it may well be something that requires more extensive changes beyond StateSetManipulator and hence more time so would have to wait till after 2.3.5. I've implemented a solution to the threading issue in StateSetManipulator. The solution is to clone the StateSet before modifying it, and reassigned this cloned StateSet to the parents of the original StateSet. This process effectively disconnects the original StateSet from the scene graph but otherwise keeps all its variable in tack - so the that the draw traversal that will be running in parallel with the updates (when multi-threaded) will not be affected as it's got its own ref_ptr to the StateSet. My testing at this end suggest that the fixes is solid. If things work out this is possible solution that I could add directly to StateSet, providing a convenience function for doing this cloning and reassignment. Could you do an svn update and let me know if the fix works at you end as well. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
Hi Andy, On Fri, Mar 14, 2008 at 1:30 PM, Andy Skinner [EMAIL PROTECTED] wrote: I've just seen a compile error in osgviewerWX.cpp on OSX, complaining that cout is not a member of std. I'll get back to you about it as soon as I can. To try and fix this I've added an include iostream to osgviewerWX.cpp, could you do an svn update and let me know if its fixed. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
On Fri, Mar 14, 2008 at 2:03 PM, Tony Horrobin [EMAIL PROTECTED] wrote: Hi Robert, I think you forgot to commit osgGA/StateSetManipulator because it's complaining about the clone() not being declared. However, when I add the declaration it compiles and the texture toggle works as expected. Ouch, now fixed, sorry about the missing checkin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
Hi All, I've just merged another fix so could users please do one last svn update just to double check that we haven't broken anything more and that all build errors are now fixed. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.3.5 and VirtualPlanetBuilder-0.9.6 dev release tagged.
Hi All, Details on the new release (rather short on detail, you'll need to look at the ChangeLog which is pretty full if you want all the details): http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases * OpenSceneGraph-2.3.5, released on 14th March 2008. Changes include : New osgthirdpersonview example that demonstrate use of CompositeViewer? to create a 3rd person view on the main windows view, and a new osgmultitexturecontrol example that demonstrate how to implement smooth blending between different layers in a whole earth paged database using multi-texturing. Various bug, cross platform build, typo fixes and minor feature enhancements. source package : OpenSceneGraph-2.3.5.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.5 OpenSceneGraph I've also tagged the VirtualPlanetBuidlder 0.9.6 release: http://www.openscenegraph.org/projects/VirtualPlanetBuilder -- Both these projects are nearing the point that I could probably do OSG-2.4 and VPB-1.0 release quite soon, feature wise I feel they both are pretty near feature complete enough to go with a stable release, so its really about making sure they are robust enough and compile properly across platforms. If these dev releases look reasonable then we could possible go for a stable release of both projects in the next week or two. Thoughts on stable releases? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.5 and VirtualPlanetBuilder-0.9.6 devrelease tagged.
On Fri, Mar 14, 2008 at 5:14 PM, Clay, Bruce [EMAIL PROTECTED] wrote: Robert: Since parts of OSG uses GDAL and GDAL is about ready to issue a stable release, would it be a good idea to time the OSG release shortly after GDAL release? I don't have a problem with going first, it'd make sense to double check that the up comming GDAL release will work with whatever we push out. Testing against GDAL SVN will be a useful test as would upping version number in the search for this GDAL within the OSG's CmakeModle/FindGDAL.cmake file. Do you know what the version number of GDAL will be, and the possible time frame for its realease? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.5 and VirtualPlanetBuilder-0.9.6 dev release tagged.
On Fri, Mar 14, 2008 at 7:43 PM, Jean-Sebastien Guay [EMAIL PROTECTED] wrote: One thing I'd really like to see before a stable release is done is to make sure any osgShadow weirdness is behind us, that it behaves predictably at least in --sm mode, if not --pssm as well (which looks harder to debug to me). It would be very good to solve the osgShadow problems. It'd be interesting to revert to osgShadow in 2.2 and then step forward I'd also like to get the polygon offset fleshed out across different hardware. Next week I'll put together the test app for this purpose. This is a topic another thread though as osgShadow is pretty involved. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A simulation project
Hi Harold, When you say Simulation do you mean a visual simulation? The OSG is just a 3d graphics toolkit, it doesn't do anything beyond visual simulation. As for whether its appropriate for what you want to do I have no clue as its hard to work out what you actual require. If its visuals then yes the OSG can help. Robert. On Fri, Mar 14, 2008 at 10:57 PM, wanyama harold [EMAIL PROTECTED] wrote: Hi guys, iam a final year computer science student and i want to do a project on Simulation of the faculty's building resources. Iam interested in simulating the resources available at the faculty(labs and classrooms) to find out if they could handle a larger number of students or in case new courses were added to the curriculum. My question is could i be able to use OSG? Iam quite new in the field of OSG and would luv to learn more. Thanx Harold ___ Rise to the challenge for Sport Relief with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ ___ 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] game like movement
HI Seppo, The osgGA::UFOManipilator might be closest to what you want. However, just use this and other manipulators as guide, its your game and you need to decide how you want to control the view point, using general purpose off the shelf controls is unlikely to capture what is most appropriate for your games needs. Robert. 2008/3/15 Seppo [EMAIL PROTECTED]: Hi Robert, I mean First person shooter-like movement. In a way that I described there in my question: using mouse to look around, and then by pressing i.e. arrow up to move to direction where user is looking etc - using basically arrow keys for moving the camera and mouse for orientation. Also thanks for ÜMİT UZUN for your answer, I will try to look into those osghanglide and other examples for partial examples. Anyway if anyone knows an example (maybe outside of normal example package then) with much like this movement described here, please post here.. -Seppo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 15. maaliskuuta 2008 12:23 To: OpenSceneGraph Users Subject: Re: [osg-users] game like movement HI Seppo, There is a huge range of view interaction that you could use in a game so saying game-like movement is rather open ended. What type of game are you thinking of? Chess? Cards? Driving? First person shooter? Robert. On Fri, Mar 14, 2008 at 11:18 PM, Seppo [EMAIL PROTECTED] wrote: Hi, How can I create a game-like moving? This means, that I can use mouse to look around and move with arrow keys - forward arrow key moving to direction I am looking with mouse. From the example files I found only one kind of movement, and not this kind at all.. Thanks in advance! Seppo ___ 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] osgconv collada
HI, Have you installed the COLLADA DOM, and built the appropriate OSG plugin? Robert. On Sun, Mar 16, 2008 at 12:46 AM, skunkwerk [EMAIL PROTECTED] wrote: i'm new to openscenegraph. i tried to use osgconv to open/save a collada file, but couldn't find the correct osgdb for .dae files to allow it to work. any suggestions? is all i have to do to generate a texture atlas for the file, to do this from my command line: export OSG_OPTIMIZER=DEFAULT TEXTURE_ATLAS_BUILDER thanks ___ 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] osgShadow example and gerneral question
HI Sebastian, I see the artificate on Nvidia hardware so this rules out an ATI bug. So far it I looks like an osgShadow bug, exactly what's gone amiss I don't know though... Robert. On Sun, Mar 16, 2008 at 10:15 AM, Sebastian Messerschmidt [EMAIL PROTECTED] wrote: Hi Adrian, As I've pointed out in the osg-users list, there seems to be a bug in recent ATI drivers where the t-coordinate in the generated shadow texture is screwed up, i.e. inversed. Your screenshots don't look exactly like the artefacts I've seen but it might be related I reckon. To check this I recommend replacing the fixed function vertex shader by your own code which does the EYE_PLANE projection and play around with the coordinates. Cheers Sebastian Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Adrian Egli OpenSceneGraph (3D) Gesendet: Donnerstag, 13. März 2008 21:57 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgShadow example and gerneral question some screenshots of the bug /adi 2008/3/13, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED]: Since the OSG 2.2 or event some version before, osgShadow is broken. I don't yet know why. but it doesn't work on ATI based computers as far as i could test it. 2008/3/13, Raymond de Vries [EMAIL PROTECTED]: Hi, All I know that the PSSM implementation was not changed, the last I looked at the svn version (some weeks ago), compared to 2.2.0. I will test the svn version example also asap, and let you know. Now that you mention PSSM, I've send a (small) patch some months ago and suggested to change the interface a little so that parameters can be changed at runtime (where it is currently only possible at startup). Also I've send a bug report to the list in which I showed an artifact, incl source code. Within some weeks I would like to dive into PSSM again, so hopefully we can join forces. Cheers Raymond Jean-Sébastien Guay wrote: Hi Adrian, i have retested osgShadow and get some really strange behaviour. event PSSM doesn't work on my ATI x1600 based pc. was there changes and did we really test all options of osgshadow / implementation, or do i only have such a problem I remarked a while ago that osgshadow --pssm did not work for me on my nVidia card (even with the --NVidea (sic) switch, I see no shadows). No idea what's wrong, as I have no time to go into the details... I know I'm not much help, but at least you know you're not alone. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli -- Adrian Egli ___ 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] Issues with osgText in 2.3.x
Hi Gordon, On Sun, Mar 16, 2008 at 4:22 PM, Gordon Tomlinson [EMAIL PROTECTED] wrote: Could not wait until Monday so I came in to work test your suggestion ;) Setting the data variance to dynamic seems to have fix the issue, one to remember The requirement for setting Drawables and StateSets DataVariance to DYNAMIC when modifying them during the frame (i.e. via update or event callback) has been introduced as a means controlling the overlap between the rendering of the previous frame and the update,cull and draw traversals of the next so that rendering objects aren't modified at the same times as they are read from. This is only required in DrawThreadPerContex and CullThreadPerCameraDrawThreadPerContext threading models. Prior to osgViewer/2.x the scene graph + Producer never allowed this level of parallelism so the frames never overlapped - and there was never an issue with the scene graph being modified at the same time as its been read from. You can still use the old Producer style threading model by select CullDrawTheadPerContext which is equivalent to Producer's ThreadPerCamera. One thing to note is that Producer only did ThreadPerCamera when there was one Camera per RenderSurface, so in effect its ThreadPerRenderSurface or in OSG 2.x speak is (CullDraw)ThreadPerContext, however if you have more than one Camera per RenaderSurface in Producer it drops down to SingleThreaded, which osgViewer still keeps threading CullDrawThreadPerContext. The upshot of these different threading models is that 2.x/osgViewer by default more multi-threaded than the conterpart of 1.x/osgProducer, and as a consequence one does have to take care about the rules of modification have enhanced with it. There has been lots of discussion about osgViewer and its threading model over the past year so I'd recommend doing a search for some of the above threading models in the osg-users archives. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vertex Buffer Object (Multi Window)
Hi Selman, This is the way that OpenGL objects work - they aren't by default shared between separate graphics context. You'll either need to maintain separate VBO's for each context or share graphics contexts. There is a lot of support in the OSG for managing separate objects across multiple graphics contexts so is you use classes like osg::Geometry it'll manage this all for you. Robert. On Sun, Mar 16, 2008 at 4:11 PM, selman duatepe [EMAIL PROTECTED] wrote: Hi everyone, I have implemented Terrain library using Geometry Clipmap algorithm. In my project, I have to display terrain two different windows. And, I have used vertex buffer object to render the terrain. When I use to second display, float* cachedData = static_castfloat*(mExtension-glMapBuffer(GL_ARRAY_BUFFER_ARB,GL_READ_WRITE_ARB)); function always returns NULL and I can't map GPU buffer. But it works for one window. Anyone idea about this problem. Thanks a lot. ___ 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] A simulation project
Hi Harold, The OSG could certainly handling the visual part of the simulation. Key things are getting your model in and managing the animations. As for doing things optimally, well there is a huge open ended task. One needs to know real specifics of whats required to know how to things optimally. Personally I'd just go for good enough - so work out what is good enough, i.e. 30Hz, 60Hz? There is so much one can put in a simulation I can't really give you guidance in a simple email. Robert. On Sun, Mar 16, 2008 at 9:16 PM, wanyama harold [EMAIL PROTECTED] wrote: Hi Robert, Yes i mean a visual simulation that can respond to inputs and get an output(my problem is whether a user can play with inputs on an osg model).The model is abt a building with a finite number of classrooms and labaratories and is supposed to determine how they can be used optimumlly Harold Hi Harold, When you say Simulation do you mean a visual simulation? The OSG is just a 3d graphics toolkit, it doesn't do anything beyond visual simulation. As for whether its appropriate for what you want to do I have no clue as its hard to work out what you actual require. If its visuals then yes the OSG can help. ___ Rise to the challenge for Sport Relief with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ ___ 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] OpenSceneGraph-2.3.5 and VirtualPlanetBuilder-0.9.6 dev release tagged.
Hi Rahul, I haven't yet written the docs for the new VPB features. I am planning to start this this month. Unfortunately I've been swept off my feet with work so lower priority stuff like online docs for the wider community has had to wait. As soon as docs are available I'll notify the community. Robert. On Mon, Mar 17, 2008 at 9:23 AM, Rahul Jain [EMAIL PROTECTED] wrote: Hi All, Is there any tutorial or document explaining how to use the new features of VPB. Also there are lot many applications shipped with VPB, but I am not able to found any document or thread, where these application have been explained. I also looked at http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem but it has not been updated. It will be really helpful if some one can provide me with the pointers to the new features. best regards RJ Robert Osfield wrote: Hi All, Details on the new release (rather short on detail, you'll need to look at the ChangeLog which is pretty full if you want all the details): http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases * OpenSceneGraph-2.3.5, released on 14th March 2008. Changes include : New osgthirdpersonview example that demonstrate use of CompositeViewer? to create a 3rd person view on the main windows view, and a new osgmultitexturecontrol example that demonstrate how to implement smooth blending between different layers in a whole earth paged database using multi-texturing. Various bug, cross platform build, typo fixes and minor feature enhancements. source package : OpenSceneGraph-2.3.5.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.5 OpenSceneGraph I've also tagged the VirtualPlanetBuidlder 0.9.6 release: http://www.openscenegraph.org/projects/VirtualPlanetBuilder -- Both these projects are nearing the point that I could probably do OSG-2.4 and VPB-1.0 release quite soon, feature wise I feel they both are pretty near feature complete enough to go with a stable release, so its really about making sure they are robust enough and compile properly across platforms. If these dev releases look reasonable then we could possible go for a stable release of both projects in the next week or two. Thoughts on stable releases? 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with LightPoint
Hi Lars,
I haven't heard reports of problem before, but perhaps no one has
looked close enough. Could you send me the whole modified file so I
can review it side by side against the original.
Thanks,
Robert.
On Mon, Mar 17, 2008 at 2:43 PM, Nilsson Lars
[EMAIL PROTECTED] wrote:
Hi
When I tested airport lighting with OpenSceneGraph, the directional light
did not work the way I expected.
The light was visible a bit outside the defined sector. Especially for the
PAPI (Precision Approach Path Indicator),
it is important that the angles are correct.
After rewriting a small piece of code in osgSim/Sector.cpp it seemed to work
as I wanted.
The change made was in the function computeMatrix() as shown below.
void DirectionalSector::computeMatrix()
{
double heading = atan2(_direction[0], _direction[1]);
double pitch = atan2(_direction[2], sqrt(_direction[0]*_direction[0] +
_direction[1]*_direction[1]));
double roll= _rollAngle;
_local_to_LP = osg::Matrixd::identity();
_local_to_LP.preMult(osg::Matrix::rotate(heading, 0.0, 0.0, -1.0));
_local_to_LP.preMult(osg::Matrix::rotate(pitch, 1.0, 0.0, 0.0));
_local_to_LP.preMult(osg::Matrix::rotate(roll, 0.0, 1.0, 0.0));
}
I am certainly not sure if this change is correct in all aspects, but it
solved at least the problem for me.
Has anyone else discovered similar problem about light points?
Regards,
Lars Nilsson
___
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] osgShadow example and gerneral question
HI Wojtek, Excellent detective work. I'll have to raise my hand as the culprit of the change to CullVisitor::apply(Camera), done is response to a discussion between Mathias Froehlich and myself about inheritance of settings. I believe the inheritance of settings is now correct, but obviously in my testing after applying this change I didn't spot the regression in osgshadow and the unforseen consequences. Since I think the actual rules of inheritance of settings are correct, and things worked before because of bug in the inheritance of settings, so its a matter of either changing the defaults in CullSettings so that less of the inherited state comes down into the local Camera, or we override the defaults locally. I'd suggest we change the defaults locally and review the defaults in light of how many changes we make. Robert. On Tue, Mar 18, 2008 at 9:18 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Robert, I think I have found the cause of the problem. Problem is not only related to osgShadow::ShadowMap. All Shadow mapping techniques exhibit similar issue (SM, SSM, PSSM). And it looks like problem could be wider and affected other examples as well. Problem appeared when SVN changelist 7912 was added . This submission changes Cameras cull settings inheritance policy during Cull traversal. After this modification Shadow camera DO_NOT_COMPUTE_NEAR_FAR flag gets overriden with main camera COMPUTE_NEAR_FAR setting . This in effect desynchronizes texgen and depth map. Texgen is calculated using not adjusted Shadow camera projection. Shadow depth map is rendered using Shadow camera projection that was additionaly near/far adjusted. Problem could be avoided by adding following line to shadow camera initialization. _camera-setInheritanceMask( _camera-getInheritanceMask() ~osg::Camera::COMPUTE_NEAR_FAR_MODE ); But this topic brings another question: up till 7912 changelist, we were simply using setComputeNearFar( false ) to avoid clamping of projection matrix. Does it mean that from now we will also need to add above aditional line to protect it from inheritance overriding ? If yes then we got a lot of code to review and adjust ...;-( Cheers, Wojtek - Original Message - From: Wojciech Lewandowski [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 12:29 PM Subject: Re: [osg-users] osgShadow example and gerneral question Robert, I replicated the problem with osgShadow::ShadowMap. I will try to find the cause... Cheers, Wojtek - Original Message - From: Wojciech Lewandowski [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 11:57 AM Subject: Re: [osg-users] osgShadow example and gerneral question Hi Robert, There are few versions from 2000-2002. I found earlier 2000 version on NVidia site. But 2002 version has the PolygonOffset section extended in comparison to 2000. It looks like siggraph 2002 presentation could be found under this link: http://www1.cs.columbia.edu/~ravir/6160/papers/shadowmaps.ppt Slides 20-27 refer to PolygonOffset topic. Cheers, Wojtek - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 11:26 AM Subject: Re: [osg-users] osgShadow example and gerneral question Hi Wojtek, Could you post a link, or the actual presentation, or put it up on the wiiki, of Mark Kilgrads paper discussing PolygonOffset. It would nice to isolate the actual differences in implementation of PolygonOffset across hardware so we can pick appropriate settings for different hardware. There are already some factors set in PolygonOffset itself to try and cope with this but the values where just set from basic experience with osgText, and not done is rigorous way. I would to roll this back and do a rigorous testing of different hardware so we can get more consistent results across and models sizes. Robert. On Mon, Mar 17, 2008 at 9:47 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Robert and All, I am back from vacations. Ready to take the responsibility for my changes in osgShadow::ShadowMap ;-). Does the problem Adrian refers happen only with PSSM or standard ShadowMap as well ? Its not obvious from forum emails and I am unable to replicate it with standard ShadowMap. I looked once again at the my submitted osgShadow::ShadowMap code and I have NOT changed polygon offset. PolygonOffset remains untoched in several latest revisions. However, I do have my objections against default ShadowMap cullface/polygon offset settings. I remember that former (pre 2.0 osgShadow nodekit) DepthShadowMap example was using frontface culling and polygon offset factor=1.1
Re: [osg-users] osgShadow example and gerneral question
Hi Wojciech, On Tue, Mar 18, 2008 at 12:13 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: In other words from now when we want a fixed projection matrix we need to make two calls: camera-setComputeNearFarMode( osg::Camera::DO_NOT_COMPUTE_NEAR_FAR ); camera-setInheritanceMask( camera-getInheritanceMask() ~osg::Camera::COMPUTE_NEAR_FAR_MODE ); If we don't change the default setting then this is true. This sounds like backward compatibility problems. I suspect there is a number of examples and users code that call setComputeNearFar method only. Maybe Camera::setComputeNearFarMode() method could also change inheritance mask ? Or maybe adding additional default adjustInheritanceMask = true parameter could be added to setComputeNearFarMode to keep actual inheritance policy and not break compatibility ie: osg::Camera::setComputeNearFarMode( ComputeNearFarMode cnfm, adjustInheritanceMask = true ); ? I'm open to this approach, but having the two decoupled is cleaner interface wise. This is a general problem with inheritance of properties, if we set the value then it would imply that its important that we retain this value and to not inherit it, this in turn would suggest that we should have the inheritance mask set off by default. Items like back ground colour is certainly something that can be useful to inherit, but... perhaps if the coder wants this then its fair enough to actually require them to set it. Clearly wel need to have a good think about inheritance of settings in viewer and scene graph Cameras, and SceneView which also uses CullSettings behind the scenes in osgViewer. Right now I think the thing to do is apply the fix to osgShadow, then move on to a wider review of inheritance of CullSettings. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
On Tue, Mar 18, 2008 at 2:18 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Items like back ground colour is certainly something that can be useful to inherit, but... perhaps if the coder wants this then its fair enough to actually require them to set it. Clearly wel need to have a good think about inheritance of settings in viewer and scene graph Cameras, and SceneView which also uses CullSettings behind the scenes in osgViewer. If I understand correctly you opt for default NULL inheritance mask. Right ? I agree that this should solve this particular issue. Don't know how this would affect other cull settings, though. Other effects is what we need to be careful about and why making top level changes right now is probably a bit too quick. Without looking into further my guess is that SceneView needs to inherit all CullSettings, slave Cameras should inherit their CullSettings, but scene graph Cameras might be better off not inheriting settings. Or perhaps we always inherit unless one sets a variable locally - this would require an approach like in your extra parameter suggestion. Right now I think the thing to do is apply the fix to osgShadow, then move on to a wider review of inheritance of CullSettings. I think I understand your motives. Do you want me to add this second line and send a fix for osgShadow::ShadowMap ? I may try to update PSSM and SSM as well but I won't guarantee I will be able to fully test them. It may even be worth doing a setInheritanceMask(0x0) on all these osgShadow implements. The right of the Camera usages needs look at as well. I'm just tying up some other work, once this is done I'll do a quick review of Camera usage. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
On Tue, Mar 18, 2008 at 3:45 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: I'm just tying up some other work, once this is done I'll do a quick review of Camera usage. Thanks for explanations, I no longer disturb. Let me know if I could help. You've already been a great help, pinpointing the problem was the hardest part of this jigsaw :-) I've been reviewing the inheritance mask, it covers a wide range of features, including items like lighting, cull masks etc, the types of stuff that is often useful to inherit. The Viewer use of master Camera, slave Camera and SceneView for internal rendering implementation all rely upon top down inheritance of settings, so I believe it makes sense for these to retain the default InheritanceMask of ALL_VARIABLES. However, the needs of InheritanceMask of RTT Camera's is somewhat different, when you actively change the clear colour, or the computing of the projection matrix you really don't want to go inheriting this same value. The old buggy implementation in CullVisitor::apply(Camera) meant that in effect as an inheritance mask set to 0x0, which as this worked better than the current system then to replicate it we'd want to set the inheritince mask to 0x0. Since osg::Camera's are just constructed the same no matter whether they are viewer ones or ones in the scene graph it isn't possible to just choose a different default inheritince mask in each context. Such a scheme would also obscure what is going on under the hood. What we really need it keep a consistent system with clear rules of inheritance that are applied across all types of Cameras, no matter if they are in scene graph or in viewer. The awkward bit is that we need to keep backwards compatibility as well. The solutions I can think of right now are: 1) Change have the CullSetting::InhertacenMask default to 0x0 and have all Viewer code to related Camera's and SceneView to explicitly set the InheritanceMask to ALL_VARIABLES 2) Leave CullSetting::InheritanceMask as ALL_VARIABLE default, and change all RTT/in scene graph Cameras to explictly disable the InhertianceMask they do not need. 3) Leave CullSetting::InheritanceMask as ALL_VARIABLE default and have the CullSettings::setVariable() calls all optional disable the associated part of the InhertianceMask to off. This disabling would be done by default. i.e CullSettings::setComputeNearFarMode(mode, bool disableInhertianceOfComputeNearFarMode=true); I think option 3 would probably give us reasonable backwards compatibility, but... it would hide a bit of what is going on w.r.t InheritanceMask and be inconstistent with the way the rest of the OSG works w.r.t set/get methods. Can anyone else think of any other options? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Earth Model with height relief (BlueMarble)
Hi Umit, Try add a -d in from of the DEM file. i.e osgdem -s build.source --whole-globe -d topo.tif For -l 4 you'll find that you want see an terrain. I'd also recommend using --terrain as the build is well over a hundred times faster. Robert. On Tue, Mar 18, 2008 at 4:11 PM, ümit uzun [EMAIL PROTECTED] wrote: Hi All. I try to make earth model with height relief. I am using this command on Ubuntu 7.10, OpenSceneGraph Library 2.3.4 and VirtualPlanetBuilder/osgdem 0.9.5 ; // Create the build.source file osgdem --bluemarble-west -t ../land_shallow_topo_west.tif \ --bluemarble-east -t ../land_shallow_topo_east.tif \ --geocentric \ -o earth/earth.ive \ --so build.source //creating whole earth elevation data subroutines I download srtm_ramp2.world.21600x10800.jpg from http://visibleearth.nasa.gov/view_detail.php?id=8391 web site. Then I use gdal utility commands; //traslating jpg to geotiff gdal_translate srtm_ramp2.world.21600x10800.jpg topo.tif //adding overview to topo.tif gdaladdo -r average topo.tif 2 4 8 16 32 64 128 //run the build.source osgdem -s build.source --whole-globe topo.tif -v 1000.0 -l 4 But when the process finished I see a globe which is not expected. The height relief and the earth lands surface can't overlap on same coordinate place. what can I do for to create original earth model with height relief. ÜMİT UZUN _ Windows Live Messenger'ın için Ücretsiz 30 İfadeyi yükle http://get.live.com ___ 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] Placing Text Labels in Geodetic Projection
On Tue, Mar 18, 2008 at 4:42 PM, Jason Beverage [EMAIL PROTECTED] wrote: Overall though, does the approach I'm suggesting with using the UpdateCallback and the Hud Camera to get around my intersection problems sound reasonable or am I overcomplicating things? It sounds like overcomplicating to me, the more complicated the more difficult it'll be to debug, and even harder for anyone else to be able to try and get their head around what you are doing. Given you are using an older version of the OSG it makes it a next to impossible task to support. OSG-1.2 does support double Matrices by default, so I would have though as MatrixTransform above the text labels would get you most of the way. You could try look for where the precision issue is arising and tweaking the OSG to use doubles to help out. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
On Tue, Mar 18, 2008 at 4:55 PM, Mathias Fröhlich [EMAIL PROTECTED] wrote: Move the inheritance mask from CullSettings to the camera. As you can see from your own suggestions abive the other users of the inheritance mask and CullSettings will just need a copy from its 'parent' settings. SceneView inherits from CullSettings as well osg::Camera, and the InheritinceMask is used as well. It's also require for backwards compatibility. CullSetting inheritance also is related to CullSettings variables, so the appropriate place is CullSettings. The only thing you gain by putting setInheritanceMask into osg::Camera is more visibility, but... you break encapsulation with it. Personally I find such a solution a poor OO choice. Initialize this mask in the camera to inherit all. This is what the previous implementation that ignored the mask completely did. You would preserve backwards compatibility with existing code with this. It does inherit all settings right now, and this is what has broken things, so the fix to CullVisitor::apply(Camera) is what has broken backwards compatibility. The status quo doesn't maintain backwards compatibility. The reader of the code would better understand what happens and you could implement what you told me for the first cut how it *should* work instead of something you need to dig for in the sources. I'm afraid I don't follow you. The current implementation does as things as it should, save for fact that honouring the InheriinaceMask is what has broken backwards compatibility. Well, I did not see that this past change brakes in the shadow thing, when I offered you codework for that old suggestion, but I saw that it will probably cause problems that would be better solved right. Also I expect every usage of a Camera being used in the wrong way since the inheritance mask has never worked in any way before our past change. The inheritanace mask did actually work correctly for the Viewer Camera's and SceneView, its only the in scene graph Camera's that were broken before and hence why the inheritance mask didn't work correctly in this case. I also think that a Camera that now makes use of the mask that was previously ignored will break much more of the compatibility than moving the mask to where it is used. The mask hasn't moved one bit for a long time. It's only CullVistor::apply(Camera) that has changed, and the inheritance of in scene graph cameras with it. Moving setInhertianceMask from CullSettings to osg::Camera doesn't solve any technical problems, and its certainly not clearer in terms of encapsulation. Also it is better to get a 'heads up there has something changed' from the compiler than just some subtle errors ... Still offering time to implement that ... I'm not sure what you could do on the front of breaking the build for old usage. While it'd be nice to let the compiler tell the user something is up, I think its impractical - one would be making changes not because they are needed but because they can give you a warning. If anything then a runtime warning might be possible. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
Hi Mark, Wojtek et. al,
On Wed, Mar 19, 2008 at 1:17 AM, Mark Sciabica [EMAIL PROTECTED] wrote:
I think #3 is a good option, but I would like to suggest using an
interface similar to that used for state attributes. I.e. use an
enumeration for the possible values instead of a bool, even if only
two values are needed initially. Having a more uniform interface for
handling inheritance in the scene graph will lessen the learning
curve.
I have also been thinking about option #3 an use a enum. And also
been thinking about another option related to option #3. A glimpse of
the enum:
enum InheritanceMaskActionOnAttributeSetting
{
DISABLE_ASSOCIATED_INHERITANCE_MASK_BIT,
DO_NOT_MODIFY_INHERITANCE_MASK
};
And the set methods would be like:
void setImpostorsActive(bool active,
InheritanceMaskActionOnAttributeSetting
action=DISABLE_ASSOCICATED_INHERITANCE_MASK_BIT);
I take I'm not the only one that finds this a little too much of a
mouthful, and kinda obscures the important bit - the set method name
and its primary parameter. One could go for a simpler enum name, but
in the end the bool is far less intrusive.
The other approach is to do modify the setAttribute() signature, but
instead have a separate method so setting the action i.e
void
setInheritanceMaskActionOnAttributeSetting(InheritanceMaskActionOnAttributeSetting
action);
InheritanceMaskActionOnAttributeSetting
getInheritanceMaskActionOnAttributeSetting() const;
Then in the set methods we'd have:
void setImpostorsActive(bool active)
{
_impostorActive = active;
if
(_inheritanceMaskActionOnAttributeSetting==DISABLE_ASSOCICATED_INHERITANCE_MASK_BIT)
{
_inheritanceMask = _inheritanceMask (~IMPOSTOR_ACTIVE);
}
}
We'd let _inheritanceMaskActionOnAttributeSetting default to
DISABLE_ASSOCICATED_INHERITANCE_MASK_BIT.
This forth approach is currently my favoured as its least intrusive
w.r.t setAttribute() method parameters, but... I'm not overly happy
with the behind the scenes automatic setting of other parameters.
Doxygen comments can come in to solve this one though.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
Hi All,
On Wed, Mar 19, 2008 at 9:55 AM, Robert Osfield
[EMAIL PROTECTED] wrote:
This forth approach is currently my favoured as its least intrusive
w.r.t setAttribute() method parameters, but... I'm not overly happy
with the behind the scenes automatic setting of other parameters.
Doxygen comments can come in to solve this one though.
I've go ahead and implemented this approach. The addition to CullSettings are:
enum InheritanceMaskActionOnAttributeSetting
{
DISABLE_ASSOCIATED_INHERITANCE_MASK_BIT,
DO_NOT_MODIFY_INHERITANCE_MASK
};
void
setInheritanceMaskActionOnAttributeSetting(InheritanceMaskActionOnAttributeSetting
action) { _inheritanceMaskActionOnAttributeSetting = action; }
InheritanceMaskActionOnAttributeSetting
getInheritanceMaskActionOnAttributeSetting() const { return
_inheritanceMaskActionOnAttributeSetting; }
/** Apply the action, specified by the
InheritanceMaskActionOnAttributeSetting, to apply to the inheritance
bit mask.
* This method is called by CullSettings::set*() parameter
methods to ensure that CullSettings inheritance mechanisms doesn't
overwrite the local parameter settings.*/
inline void applyMaskAction(unsigned int maskBit)
{
if
(_inheritanceMaskActionOnAttributeSetting==DISABLE_ASSOCIATED_INHERITANCE_MASK_BIT)
{
_inheritanceMask = _inheritanceMask (~maskBit);
}
}
A set*() method now has the applymaskAction() method call it it:
/** Switch the creation of Impostors on or off.
* Setting active to false forces the CullVisitor to use the Impostor
* LOD children for rendering. Setting active to true forces the
* CullVisitor to create the appropriate pre-rendering stages which
* render to the ImpostorSprite's texture.*/
void setImpostorsActive(bool active) { _impostorActive =
active; applyMaskAction(IMPOSTOR_ACTIVE); }
The _inheritanceMaskActionOnAttributeSetting defaults to
DISABLE_ASSOCIATED_INHERITANCE_MASK_BIT.
I've revert the temporary fix to osgShadow that I made yesterday, and
with the above changes in place osgShadow still works as it originally
did.
I have checked in this changes and am looking for assistance on
testing these changes out in the wild. Key things to look for are any
code that uses Camera's and sets the CullSettings on them, are these
now behaving as expected?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Testing of SVN version please
Hi All, I've checked in a few bugs fixes to OSG and VPB over the last few days so would like to get another dev release out the door. I'd appreciate and SVN update and build on OSG and VPB to see if everything looks safe for tagging another dev release. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QT issue
HI Tomas, I can't think of what might be amiss without trying it out. Could modify the osgviewerQT example so that it has another optional code path in creating a viewer based on your code. This will allow others to try out your usage model and see first hand what is wrong. I can also merge these changes so we can use it as a unit test in future - and getting it working too obviously :-) Robert. On Thu, Mar 20, 2008 at 11:07 AM, Tomas Hnilica [EMAIL PROTECTED] wrote: Hello all OSG users, I found few issues by intergration OSG(2.2.0) with QT (4.3.3) : The ViewerQT class from OSG-2.2.0 works well in the osqviewerQT.cpp example. But when I add it to existing QT window, I have these problems: - no keyboard actions are emitted to OSG, mouse works ok - when resizing the MDI window to minimum (like with minimize button, but done as resizing) the scene disappears by resizing back. I changed the osgviewerQT example by replacin the viewerWindow-show(); with these code: --- ViewerQT* viewerWindow = new ViewerQT; viewerWindow-setCameraManipulator(new osgGA::TrackballManipulator); viewerWindow-setSceneData(loadedModel.get()); QMainWindow* mw = new QMainWindow(); QMdiArea* mdiArea = new QMdiArea(mw); mw-setCentralWidget(mdiArea); QMdiSubWindow *subWindow = mdiArea-addSubWindow(viewerWindow); subWindow-resize(200,100); subWindow-showNormal(); subWindow-setWindowTitle(New Window); mw-show(); --- I hope these problems are more OSG than QT related... Many thanks, Tomas ___ 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] osgShadow example and gerneral question
On Thu, Mar 20, 2008 at 11:58 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Ok, I did not mean to test the recent changes explicitly, I just did the test that I did recently, since the issue is hot now. Please look at the attached modified osgshadow.cpp. It is good to notice that the svn osgshadow.cpp explicitly sets the threading model to SingleThreaded. I believe that setting threading model to SingleThreaded was not deliberate but was done as a default. Consecutive lines of code check arguments and switch to other Threading modes accordingly. In the early days of osgShadow it certainly wasn't thread safe. This is why the SingleThreaded option is there. Now I haven't recently reviewed all the osgShadow implemententations too see if they are thread safe so can't confirm if we can safely do it yet. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Resetting particle systems
Hi Guys,
I am as not familiar with osgParticle internals and different usages
as I'd like to be so can't give a quick answer. I can say that if
there isn't already then a particle system reset method seems like an
appropriate method to have. Feel free to propose an implementation.
Robert.
On Thu, Mar 20, 2008 at 12:15 PM, Serge Lages [EMAIL PROTECTED] wrote:
Hi Rudolf,
I had exactly the same problem as you, I have an application with particles
where you can change the current time (coming back to the start, going to a
given time...).
To not have problems with particles not destroyed, I needed to :
- First destroy manually all the particles.
- Then stop the emiter by setting a RandomRateCounter with a rate range
between 0 and 0 for example.
- Change the simulation time.
- Set back a normal RandomRateCounter.
Good luck !
On Thu, Mar 20, 2008 at 12:50 PM, Vincent Bourdier
[EMAIL PROTECTED] wrote:
Hi,
It looks normal for me that when you stop emmiting particle, the ones
which have been shot will continue to move... until the end of the
lifetime... so if you want to cut it on one frame to the next one... I think
killing each particle could be the better way to do it...
maybe another better solution exist... but I don't know it.
Regards
Vincent.
2008/3/20, Wiedemann, Rudolf, OPS3 [EMAIL PROTECTED]:
Hi Vincent,
I have a particle system in my scene, which starts emitting particles at
simulation time = 0 (endless).
Then, at an arbitrary simulation time, I want the scene starting at
simulation time 0 again.
This works well except for the particle system, because it begins now
with another shape as in the first run, by and by getting the expected shape
with increasing simulation time.
I tried setting several parameter combinations (life time, reset time,
re-reading the scene before every run...) and with some combinations I had
the problem, that the particle system started correctly out-of-the-box
again, but the old particles did still exist. So one idea was to destroy the
particles manually...
... which works in the way Serge suggests, but then no new particles
seemed to be created in the following run.
I would be grateful for any hint!
Rudi
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Vincent
Bourdier
Gesendet: Donnerstag, 20. März 2008 11:58
An: OpenSceneGraph Users
Betreff: Re: [osg-users] Resetting particle systems
Hi,
I don't understand why you want to destroy the particle...
A particle System works great without killing particle manually... what
do you expect from it ?
Vincent.
2008/3/20, Serge Lages [EMAIL PROTECTED]:
Hi,
The best way I found is :
for (int i = 0; i _emitter-getParticleSystem()-numParticles();
i++)
{
_emitter-getParticleSystem()-destroyParticle(i);
}
Yeah, it's a bit tricky, but it works... :)
On Thu, Mar 20, 2008 at 9:12 AM, Wiedemann, Rudolf, OPS3
[EMAIL PROTECTED] wrote:
Hi,
how can I reset a particle system, so when rendering the next frame
no old particles exist any more, but only new particles are emitted?
Thanks in advance!
Rudi
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
http://www.tharsis-software.com
___
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
--
Serge Lages
http://www.tharsis-software.com
___
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] .ive backward compatibility
Hi Rahul, I'm afraid you've hit up against a problem with .ive files not being forward compatible, its only backwards compatible. So changes to .ive format made between 2.0 and 2.3.x will mean that a 2.0 app won't be able to read 2.3.x generated .ive files. However, 2.3.x can still read 2.0 files. Thankfully .osg format is far more flexible, so you can read 2.3.x generated .osg files in OSG 2.0. Robert. On Thu, Mar 20, 2008 at 12:20 PM, Rahul Srivastava [EMAIL PROTECTED] wrote: Hi, I was testing out VPB 0.9.6 with OSG 2.3.5 and generated a sample terrain. The terrain is viewed OSG 2.3.5 osgviewer without any problems but I ran into several issues when trying to use the osgviewer of OSG2.0. I got the error that the file version was newer than the library being used to open it(OSG2.0 libraries). Has there been a change in the .ive format between various OSG versions? Is there backward compatibility between the .ive files of various OSG versions? Regards, Rahul Srivastava ___ 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] OSG VERSION
Hi, It might seem like the OSG is hugely in flux, but the vast majority of the core OSG doesn't change from day to day, or version to version that matter. Developer versions do come out often, I try to make them every week when possible, the changes between developer version tend to be very small, the majority of changes will be bug or build fixes. Developer releases are have odd points numbers, so 1.9.x, 2.1.x and 2.3.x are all developer releases. Stable release come out about 2-4 times a year, and are the even numbers, so 2.0 and 2.2 as stable, the next stable release will be made quite soon, and will be 2.4. With lots of releases comes lots of small incremental changes, rather than loading users with massive changes to handle all at once. Even with a jump from 1.x to 2.x the majority of the OSG API was the same, the big differences came in items like osgViewer. If you have started using the OSG since 2.0 then you should find the changes between version pretty minor and incremental. Rather than worry about the number of releases come out, you should see it as a sign of healthy open source community and software. Robert. 2008/3/20 FlySky [EMAIL PROTECTED]: Hello,robert～ The update speed of OpenSceneGraph is so fast that many people can't adapted themselves to OSG. I think that it can develop in a stable version like OpenGL.If it nend too many changes, we can develop a new version.How do you think about it? Thank you～ 中 国 最 强 网 游 --- 网 易 梦 幻 西 游 ，166 万 玩 家 同 时 在 线 ___ 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] osgDB::Archive - cannot add objects that lack a writer plugin
Hi Glenn, The .osga plugin relies on OSG plugins supporting writing and reading from istreams, not all loaders support write, let alone write to istream. Due to this limitation .osga is really not a general purpose container, its real purpose is to archive native formats. Robert. On Thu, Mar 20, 2008 at 12:59 PM, Glenn Waldron [EMAIL PROTECTED] wrote: I am trying to store images (GIF, JPG etc) in .osga archive files. This works for image types whose plugin implements a writeImage() method, but for those that don't, there is no pathway by which to get the image into the archive. This is straightforward to demonstrate: osgarchive --archive test.osga --insert image.gif osgarchive --archive test.osga --list The GIF file will not be present in the listing. I'd like to get peoples' thoughts on the best way to handle this (short of implementing writers for every plugin). One idea would be: if no writer is available, fall back to simply doing a straight byte-copy of the image's source file (if available) into the archive. I am happy to contribute the implementation once we can agree on one. Thanks! Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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] osgShadow example and gerneral question
Hi J-S, On Thu, Mar 20, 2008 at 1:22 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: IMHO, all examples should have the standard event handlers (Threading mode, stateset manipulator, stats, window size/fullscreen, etc.). Most do, but not all. (I can help with that soon) And if an example doesn't play well with an event handler, the problem should be fixed instead of just omitting the handler... The intention of the OSG examples is to illustrate different bits of OSG functionality, the viewer parts are intentionally kept simple so as not to take lots of lines doing stuff that is not relevant to what the example is trying to illustrate.My ideal example has just three lines setting up the viewer (construtor,assignment,run) with the rest dedicated to lines of code about creating scene graph elements or callbacks. The secondary role of OSG examples is also to act as a unit test, here adding extra viewer functionality can help with testing, but this is something we should only add if there is a real need for this extra functionality, and done on a case by case decision. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Re:]How to make multiple linear projection
Hi Mickaël, I'm afraid the provide image means nothing to me. Do you have a URL or photo of the actual physical display system? Is it a hemisphere? Robert. On Thu, Mar 20, 2008 at 2:08 PM, Mickaël [EMAIL PROTECTED] wrote: Hi robert, I'm sorry, i'm french, and i haven't understand everything. what is your display system you are trying support? i just want to display it on a screen. i have post a little picture here : http://i48.servimg.com/u/f48/11/98/25/64/projec10.jpg I hope it could hep us. In osgdistortion, how does the _/addSlave/_ works with the viewer ? Thanks ___ 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] Mac OpenGL integration / CGLMacro.h
On Thu, Mar 20, 2008 at 3:46 PM, Raphael Sebbe [EMAIL PROTECTED] wrote: I think Apple works pretty well with standards and open-source generally. And OpenGL is no exception. I even think that Apple supporting OpenGL is a good thing for both OpenGL and Apple dev communities. Like the way Apple support OpenGL under Quicktime only under Apple, but only DirectX under Quicktime under Windows.. Is this just a favour to MS? Why the allergy to supporting cross platform multi-media apps based on OpenGL??? Also like deprecating C api's over Objective C ones... Apple is great at creating a whole environment that its totally tied to just OSX. To me standards adopted by Apple are the ones that are adopted when its convenient means of bringing new developers in rather promoting true portability. In this OpenGL example we have a case of embracing OpenGL, then extending it in non standard and non portable ways. Its a one way process, making it easy to port to OSX, but far harder to port back out once you start adopting the platform specific extensions. One really does need a healthy scepticism when writing any software that is going to be successful. Successful software *wants* to live forever, successful software *begs* to be used by a wide range of users. With the twist and turns of the computer industry you need to be light footed, and not step in any boggy ground otherwise you're feet get stuck and you end up able to move, and unable to adapt to changing needs of hardware, software and users. If you want you software to be successful one of the skills is to looking for boggy ground, might my next step be such a step that in few weeks, months, years I might regret it? As for this particular extension, it really doesn't meet the criteria of potential gain for the effort and collateral damage it make. The collateral damage is added complexity, greater maintenance burden and heavier developer load. The potential gain? We'll these days we are hardly dispatch limited are we? There are very few OSG apps that will be dispatch limited, even less know that we can thread update and cull in parallel with draw dispatch. The likelyhood is you'd see no difference in performance for the vast majority of application, including on the Mac. Far better to spend you time optimizing bits of the OSG or come up with more efficient rendering algorithms/scene graph organizations. These are optimizations that can make real differences to bottlenecks that apps are likely to have and they can benefit all platforms, and all users. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Re:]How to make multiple linear projection
Hi Mikael, On Thu, Mar 20, 2008 at 5:37 PM, Mickaël [EMAIL PROTECTED] wrote: If you can just explain to me how does the osgdistortion --dome works it could help me. How much about distortion correction do you want me to teach you? Just the OSG's rendering to texture Camera's? How to compute the distortion mesh for a sphere??? At what point am I doing your job and not mine??? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vertex Buffer Object (Multi Window)
HI Selman, You are using lots of non straight OpenGL and Producer calls in your mix, it really is rather moving out of OSG realm so I'm not sure what we can do in terms of support. Robert. On Fri, Mar 21, 2008 at 7:50 AM, selman duatepe [EMAIL PROTECTED] wrote: Hi Robert, Thanks a lot for the quick response. I have solved this problem with your help. I do with this following call, Producer::RenderSurface::shareAllGLContexts(true); But, this time, when I create more than one VBO, float* cachedData = static_castfloat*(mExtension-glMapBuffer(GL_ARRAY_BUFFER_ARB,GL_READ_WRITE_ARB)); function always returns NULL and I can't map GPU buffer. But it works for one VBO for multiple window. On Sun, Mar 16, 2008 at 6:42 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Selman, This is the way that OpenGL objects work - they aren't by default shared between separate graphics context. You'll either need to maintain separate VBO's for each context or share graphics contexts. There is a lot of support in the OSG for managing separate objects across multiple graphics contexts so is you use classes like osg::Geometry it'll manage this all for you. Robert. On Sun, Mar 16, 2008 at 4:11 PM, selman duatepe [EMAIL PROTECTED] wrote: Hi everyone, I have implemented Terrain library using Geometry Clipmap algorithm. In my project, I have to display terrain two different windows. And, I have used vertex buffer object to render the terrain. When I use to second display, float* cachedData = static_castfloat*(mExtension-glMapBuffer(GL_ARRAY_BUFFER_ARB,GL_READ_WRITE_ARB)); function always returns NULL and I can't map GPU buffer. But it works for one window. Anyone idea about this problem. Thanks a lot. ___ 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] Get Parent as Transform in Absolute ?
Hi Vincent, I'm a bit confused about what you are trying to do, is it just get the accumulated world matrix at a specific node? If so then node::getWorldMatrices() is what you want. This will return a MatrixList, which will contain none, one or many matrices given that any node many have none or many parental paths containing transforms. Robert. On Fri, Mar 21, 2008 at 11:03 AM, Vincent Bourdier [EMAIL PROTECTED] wrote: Hi all, I'm trying to get a node's parent as Transform (PAT or MatrixTransform) but I have to get the transformation in ABSOLUTE_RF... For the moment, I've done a recursive method to get Parent as Transform. It return me the first parent as Tranform it encounter. I've tried this : osg::ref_ptrosg::MatrixTransform tmp_pt = new osg::MatrixTransform; tmp_pt-setReferenceFrame(osg::Transform::ABSOLUTE_RF); tmp_pt-setMatrix(p_mt-getMatrix()); (where p_mt is my RELATIVE MatrixTransform) But the method return to me a MatrixTransform in RELATIVE. It is possible to get the Matrix in Absolute ? without traverse all the scenegraph ? Thanks. Regards, Vincent. ___ 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] Feeling on replacing .net plugin with a libcurl based one
Hi Serge, I would be good to collaborate on a single libcurl based plugin that can meet the variety of different types of usage models users will through at it. I have thrown together a very simple one right now. So far it can load databases, including hierarchical ones. I haven't implemented cache support, but I'm tempted to push cache support into osgDB and make it available to a range of plugins. W.r.t going a mulit-threaded route where a request is made and then the data is loaded later. How do you go about implementing this? Using ProxyNode? Using your own database pager? My thought has been to change osgDB::DatabasePager so that is has one or more database threads, so push the multi-threading here, rather than into any specific plugin. Robert. On Fri, Mar 21, 2008 at 9:11 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi Robert, For our needs we already developped a libcurl based plugin, and we must say that it works great. Currently we don't share it because it's really dedicated to our needs (we have specific scripts directly called into the server side to group requests for example). The major feature of our version is that the plugin doesn't block the calls (except if it is asked with an option). The plugin is multi-threaded to handle lots of requests and returns the asked object only after several calls, before that it returns an error. As PagedLOD or ProxyNode requests nodes as long as it doesn't have any return it works great. We are disposed to drop our dedicated version if the new one is flexible enough, and off course we are disposed to help on the new plugin development. On Thu, Mar 20, 2008 at 8:41 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi All, I have done a bit of work using libcurl, and have already got a very basic ReaderWriterCURL written, and it looks like it'll be easy to add this directly into the core OSG as a new OSGPL'd plugin. Right now osgDB::Registry is hard-wired to use the existing .net plugin whenever there is call involving http:// in its filename. With a new libcurl we'd either need to change osgDB so that is detects the presence of the libcurl based plugin and chooses this as the plugin to use or replace the existing .net plugin. Retaining both would would complicate osgDB::Registry a little but not hugely. The other route would of replacing the existing and move the .net plugin out into the deprecated annex of the OSG. The upside of this is that it would resolve the issue of the .net plugin containing GPL'd code, something that doesn't sit well with the OSG's more liberal license, and certainly not with usage with non GPL'd applications (although technically runtime loading of GPL'd plugins within a non GPL'd harness doesn't break the GPL, in spirit of how many contribute to GPL'd projects its a no no.) The downside of replacing the .net plugin with a libcurl based on is that it adds libcurl as an external dependency. CMake handles part of this thanks to its ability to automatically detect libraries and compile the relevant parts into build system. The extra dependencies is easy for unices, especially linux, but for windows it'll probably require libcurl to be added to the 3rd party dependency package, for this I have to rely on the generosity of Mike Weiblen and fellow Windows helpers. The upside with libcurl is that is supports multiple protocols, including ftp, ftps, https, password handling etc. My thought was to forward declare CURL in osgDB and allow it to be passed in via osgDB::ReaderWriter::Options so that users can do custom libcurl ops and then let the OSG plugin do the reading. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ 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] Vec3/Vec3d question in LineSegmentIntersector
Hi Roni, Precision isn't normally required for normals, as they always are of of unit length without any precisions issues. Its only position data on large models, such as whole earth, that have issues with point data and precision, so double precision is required. Robert. On Sun, Mar 23, 2008 at 8:53 AM, Roni Rosenzweig [EMAIL PROTECTED] wrote: Hello I noticed that in LineSegmentIntersector::Intersection the function that returns the local intersection point returns osg::Vec3d, but the local normal point returns osg::Vec3. Is there a reason? I'm trying to change my entire application to use double and Vec3d instead of floats (because of precision problems) and was wondering why the normal is in floats. roni ___ 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] [VPB] Combining two models
On Sun, Mar 23, 2008 at 6:35 PM, Rahul Srivastava [EMAIL PROTECTED] wrote: Hi Robert, Thanks for clearing that out. In VPB, is it possible to build levels beyond the highest resolution of the dem/imagery by extrapolating the data? VPB on creates as many levels as the source data justifies, it doesn't divide any further, there isn't any point as it'd only waste time, storage and not provide any more accurate results. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SmoothVisitor bug
Hi I presume your name is something other than IceSkark On Mon, Mar 24, 2008 at 9:19 AM, IceSharK [EMAIL PROTECTED] wrote: Hi~ All when using osg::Vec3 , smoothingVisitor.smooth( *geometry ); goes well. when using osg::Vec3d , smoothingVisitor.smooth( *geometry ); can not work. The OSG is primarily geared around osg::Vec3 for vertex data, as is OpenGL. Support for Vec3d is only a recent addition to osg::Geometry, so utilities that operate on geometries haven't all be added. I don't expect all features to be extended either, as Vec3d usage in osg::Geometry is something that I'd only recommend for data conversion, and not for general scene graph work as its just so inefficient for doing any rendering work. Now if you want to go ahead and add Vec3d support SmoothingVisitor feel free. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ScalarBar bug
Hi What is your real name? On Mon, Mar 24, 2008 at 9:20 AM, IceSharK [EMAIL PROTECTED] wrote: Hi~ All scalarBar-setTitle( ) /** Set the title for the ScalarBar, set for no title. */ void setTitle(const std::string title); why not support osgText::String ? THIS IS NOT A BUG, to call it such is frankly talking crap and only undermines what you say. It's a question and at most a feature request. Why? Because std::string is sufficient for most purposes. osgSim is largely orthogonal to osgText so in general it's good to keep reasonable independence between the different NodeKits. And so far no one has reported an issue with it being a std::string, so for the most part it seems to be sufficient. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateAttribute inheritance
Hi Virginia, The inheritance of state is done dynamically during the cull traversal, its not embedded in the scene graph. If you want the effect of state inheritance you'll need to accumulate the state yourself. StateSet has a merge function that can help you with this. Robert. On Mon, Mar 24, 2008 at 4:47 PM, Virginia Holmstrom [EMAIL PROTECTED] wrote: I am trying to export osg to a vrml2 file. I am using a node visitor and am trying to retrieve the material properties from the node. I am using StateSet-getAttribute to retrieve the state attribute for a specific node. However, to the best of my understanding, this attribute does not incorperate any settings inherited from its ancestors. Is it always necessary to collect information as the ancestors are traversed to find the current combined state attribute for a specific node? Or is there a better way? Thank you, Virginia ___ 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] StateSet optimization - how it works?
Hi another how I wish they'd use their real name as that's we do in
the real world and it's much nicer and more civil,
The state sorting in the OSG is done as part of the cull traversals
when the various Drawables and Stateset's are placing in the rendering
backend, composed of RenderBin/RenderStages and a StateGraph. When a
RenderBin is state sorted sorting is done via an STL map container,
sorting purely on the ptr to the StateSet. In the default state
sorting no fine grained start sorting is done - so contents of
StateSet aren't compared. Its possible to enable fine grained state
sorting but I've found that the cost of such sorting generally
outweighs the benefits, what is done by default appears to be a good
compromise between low CPU overhead and efficient use of the GPU.
Robert.
On Mon, Mar 24, 2008 at 5:13 PM, Night Hawk
[EMAIL PROTECTED] wrote:
Hello All,
I was reading the OSG quick guide and it was mentioned that OSG tries
to optimize the StateSet changes to be minimal.
So I am trying to understand how exactly the render loop is done.
Would be done per StateSet as below:
For each StateSet
{
Get all the nodes that have this state-set and render them
}
Or is there some other mechanism?
Also, does any one know what is the cull-mechanism implemented in OSG?
I read that there are multiple culling mechanisms possible (such as
BSP heirarchical culling etc...) - not sure though. If someone can
give some hint, then I will try to look up more on that method to get
good understanding.
Thank you for any pointers.
___
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] Appeal for use of human names
Hi All, It might be a undersirable character trait in myself but I find it unpleasant trying to hold email conversations with posters who don't use a proper name. I can't help myself, I find it immature at best, and my own personal reaction is the word Twat jumps in my head every time I see an email with sad attempt at a cool name and no actual proper name signed. Perhaps you might think it gives you a bit more street cred, but in reality it just does the exact opposite. So please, please make the effort, being curtious and honest is part of what makes a community like this healthy and vibrant. Sign your name, even if it's just your first name. Robert Osfield ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VirtualPlanetBuilder vertical scale being ignored
Hi Jason, There isn't any setting to control whether the vertical scale should be used to override any one read from GDAL, so if wanted to add another bit of control logic using whether the vertical scale has been set you'd first need to add such an option. Perhaps a better route would be to scale any scale read from GDAL with the DataSet scale. Since both are normally one everything should be sane. It'd also work with the concept that the DataSet scale, scales all heights in the scene, rather than replacing a scale. Feel free to code up a solution. Robert. On Mon, Mar 24, 2008 at 7:00 PM, Jason Beverage [EMAIL PROTECTED] wrote: Hi Robert, I was just playing with the new version of VirtualPlanetBuilder from SVN and I noticed that the vertical scale is ignored when it is set via the commandline or automatically in the prepareForDestinationGraphCreation method in Dataset.cpp when the destination coordinate system is GEOGRAPHIC and you are not exporting a geocentric database (scaling meters to degrees). The issue stems from the block of code in readHeightField in SourceData.cpp that first attempts to get the scale from the GDALRasterBand and then tries to fall back to the DataSet's vertical scale if there is no scale in the GDALRasterBand. I believe that most GDAL drivers will just return 1 with success being true, so the code to check the vertical scale from the DataSet is never called. This means you get the typical spiky osgdem output in which X and Y are in degrees and Z is in meters. One way that this could be fixed is to first check the Dataset to see if a vertical scale has been set and then fall back to the GDALRasterBand scale. Thanks! Jason ___ 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] osgText Character/Glyph Enumeration
Hi Jeremy,
This type of usage isn't one that has been coded into osgText::Text,
which is why your not finding it easy to extract the data in a way you
need. The route you have picked seems reasonable, but I haven't tried
such a task myself so can't say.
Robert.
On Mon, Mar 24, 2008 at 7:19 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
Is there a standard/preferred way to iterate over every character in
an osgText instance in order to query information about it's location,
etc? I'll need to be able to do this for osgWidget--in particular, to be
able to position a cursor properly within a bit of text. I have the
following code:
--
const osgText::Text::TextureGlyphQuadMap tgqm =
_text-getTextureGlyphQuadMap();
const osgText::Text::TextureGlyphQuadMap::const_iterator tgqmi =
tgqm.begin();
const osgText::Text::GlyphQuads gq = tgqmi-second;
for(unsigned int i = 0; i gq.getGlyphs().size(); i++) {
osg::Vec2 c2 = gq.getCoords()[i];
osg::Vec3 c3 = gq.getTransformedCoords(0)[i];
}
--
In the above code, should c2 and c3 be sufficient for this purpose? They
don't appear to contain the values I expect, but this is almost
certainly because I'm misusing it...
Also, this may be one of the things you'll be recoding in osgText when
the time comes, so perhaps it may be best for me to simply wait until
then before tackling this issue.
___
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] Appeal for use of human names
Hi Coleman, On Mon, Mar 24, 2008 at 6:39 PM, Night Hawk [EMAIL PROTECTED] wrote: I can understand your point and don't want to start a debate on it, but just want to say that those who use the cool names has a good reason for doing so (at-least some, if not all, of us). More professional reasons than a just cool name attempt. A professional reason for not showing common curtesy? As I said a first name is perfectly fine, but no name at all is not, its just disrespectful. I'm sure I'm not the only one who feels this way. I personally have to exchange emails with dozens of people each day, I try to be polite and helpful. I also have to jump between many different threads and this requires one to attach different bits of information/discussion to different people. This is hard trick to do already, but made much harder when people don't even use standard curtesy of providing a proper name to address them by. So... in my book not providing at least a first name is both rude and awkward, and thoroughly unprofessional. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Appeal for use of human names
On Mon, Mar 24, 2008 at 8:14 PM, Night Hawk [EMAIL PROTECTED] wrote: Thank you. I don't mean to be rude, but you have the option to ignore/not reply the mails you don't feel like answering (or hard to find addressing). Well ignoring mails that I find rude is an option. It's not one I want to take, this is why I raise this topic, to fix it. Otherwise I will just start ignoring posts. Then you don't get the support your want. So, I think we can take it easy. As I said, people have good reasons for things they do. People also often don't they are offending people unless its pointed out. And also thanks for the others who has chimed-in some good fun in previous replies. It was good time reading them, though I won't be having much left to spare for any more replies on this topic. As I said I don't like debates. PS: By the way, who ever said Rice or Bush or Bill are more human names than Night or Hawk :-) The point I'm trying to make is that you need to sign your posts, it doesn't matter what you decide, you can't just go adopt a silly name and then think people will be happy to address you by it. Now if you want to be addressed by Col, Night, Hawk, make your choice. If you don't make a choice, then it'll be a that rude bloke who gets ignored because he can't be bother engaging in basic way that most humans find polite. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the idea of CoordinateSystemNode?
HI Umit, The CoordinateSystemNode decorate a scene graph assigning a coordinate system string and ellipsoid for it. Its really useful for whole earth databases where you can use it to get lat and logs, heights above ellipsoid and up vector. Robert. On Mon, Mar 24, 2008 at 8:36 PM, ümit uzun [EMAIL PROTECTED] wrote: Hi All; Actually I can't understand CoordinateSystemNode meaning. What does it do? Which condition should I use this node? Is there any usage sample like osgSimulation? Thanks. ÜMİT UZUN _ Aileye katılmanın tam zamanı! Windows Live Messenger'ın 2008 versiyonunu yükleyin! Ücretsiz! http://get.live.com ___ 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] Settings for the GPU Challenged?
Hi Rick, Have a look at the osg::GraphicsContext::WindowingSystemInterface. The setScreenResolution method is what you want. Its implemented under Windows, and under Linux if you enable the support, I don't recall the details off the cuff though. Robert. On Mon, Mar 24, 2008 at 8:35 PM, Rick Pingry [EMAIL PROTECTED] wrote: Hello all, Is there a way to set the resolution of the screen itself for gaming? Lets say you have your viewer window full screen, but the player is on a machine that does not have quite the hot graphics card, so they want to dump their resolution to keep the frame rate up. Are there any other things they can tweak in addition to this? I had already thought of providing lower level of detail models, turning off extra lights, turning off anti-aliasing, and using lower res images. Anything else I can do for my players that are GPU challenged? Thanks, -- Rick ___ 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] Should RELEASE event have a button mask?
Hi Paul and Paul :) On Mon, Mar 24, 2008 at 10:11 PM, Paul Speed [EMAIL PROTECTED] wrote: I can't be sure because my memory is fuzzy... but as I recall, osgGA events only tell you the current state of the buttons. This is true for down or up and is evident when you are pressing more than one button at a time. At least, I'm pretty sure our application had to track button state separately so that we could detect which button was pressed or released for a given event. Yes this is correct, the getButtonMask returns the current state of the mouse, while getButton() returns the actual button related to the event. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors when integrating vterrain into existing app
Hi Bryan,
I think there the best place to ask support questions about compiling
VTP examples is VTP lists. There are people who staddle the OSG and
VPB communities, so you may be lucky in catching the attention of one
of these that just so happens to also know about VTP + MFC
integration, but your chances of a useful reply and much higher on VTP
lists.
Robert.
On Mon, Mar 24, 2008 at 11:00 PM, Bryan Berg [EMAIL PROTECTED] wrote:
Hi all,
I'm currently working with vterrain, and offshoot of osg
(http://vterrain.org/index.html), which uses osg libraries.
I'm trying to incorporate it into an existing application, looking at the
mfcSimple app, but currently only using the CreateScene() method from that
project.
If you're not familiar with this method it might not matter, I'm mainly
seeking assistance in building my new app.
The mfcSimple app builds fine, but when I import vtlib, vtdata, and vtosg
into my existing app and try to build I get the following errors (at the
bottom).
I reckon there is some #include not put somewhere, but haven't seemed to be
able to locate what I missed.
To clear up confusion, the vterrain app uses osg2.0 binaries and headers,
which were downloaded as prepackaged.
Thanks so much !
-Bryan : * )~
(and to clear up any confusion, I wish to be addressed as Bryan, but Bryan :
* )~ will do : * )~
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Structure3d.h(85):
error C2143: syntax error : missing ';' before '*'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Structure3d.h(85):
error C2433: 'vtStructure3d::vtGeom' : 'virtual' not permitted on data
declarations
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Structure3d.h(85):
error C2501: 'vtStructure3d::vtGeom' : missing storage-class or type
specifiers
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Structure3d.h(85):
error C2501: 'vtStructure3d::GetGeom' : missing storage-class or type
specifiers
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Structure3d.h(85):
warning C4183: 'GetGeom': missing return type; assumed to be a member
function returning 'int'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Structure3d.h(150):
error C2143: syntax error : missing ';' before '*'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Structure3d.h(150):
error C2501: 'vtStructInstance3d::vtGeom' : missing storage-class or type
specifiers
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Structure3d.h(150):
error C2501: 'vtStructInstance3d::m_pHighlight' : missing storage-class or
type specifiers
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\TerrainLayers.h(63):
error C2143: syntax error : missing ';' before '*'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\TerrainLayers.h(63):
error C2501: 'vtImageLayer::vtMultiTexture' : missing storage-class or type
specifiers
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\TerrainLayers.h(63):
error C2501: 'vtImageLayer::m_pMultiTexture' : missing storage-class or type
specifiers
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(20):
error C2065: 'vtMesh' : undeclared identifier
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(20):
error C2059: syntax error : ''
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(22):
error C2143: syntax error : missing ';' before '}'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(73):
error C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(84):
error C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(85):
error C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(86):
error C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(116):
error C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(118):
error C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\AbstractLayer.h(160):
error C2143: syntax error : missing ';' before '}'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Engine.h(36): error
C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Engine.h(39): error
C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Engine.h(48): error
C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Engine.h(50): error
C2143: syntax error : missing ';' before '{'
c:\vterrain\vtp-src-080114\VTP\TerrainSDK\vtlib\core\Engine.h(50): error
C2065: 'ptr' : undeclared identifier
Re: [osg-users] What is the idea of CoordinateSystemNode?
Hi Umit, VPB, when generating a geocentric database, decorates it with a CoordinateSystemNode, so just find this node when you load your database then use you camera position as the XYZ to input into the EllipsoidModel::convertXYZToLatLongHeight(..) method. You get the EllipsoidModel from the CoordinateSystemNode. Robert. On Mon, Mar 24, 2008 at 9:53 PM, ümit uzun [EMAIL PROTECTED] wrote: Hi Robert, I have whole earth database which is created with bluemarble original georeferenced data and I want to flight on it. So how can I get the lat/lot information while the plane is flying on the earth model? Thanks so much, ÜMİT UZUN Date: Mon, 24 Mar 2008 21:24:36 + From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] What is the idea of CoordinateSystemNode? HI Umit, The CoordinateSystemNode decorate a scene graph assigning a coordinate system string and ellipsoid for it. Its really useful for whole earth databases where you can use it to get lat and logs, heights above ellipsoid and up vector. Robert. On Mon, Mar 24, 2008 at 8:36 PM, ümit uzun wrote: Hi All; Actually I can't understand CoordinateSystemNode meaning. What does it do? Which condition should I use this node? Is there any usage sample like osgSimulation? Thanks. ÜMİT UZUN _ Aileye katılmanın tam zamanı! Windows Live Messenger'ın 2008 versiyonunu yükleyin! Ücretsiz! http://get.live.com ___ 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 _ Windows Live Messenger'ın yeni 2008 versiyonunu buradan ÜCRETSİZ yükleyin! http://get.live.com/messenger/overview ___ 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] Detailed description of VPB osgdem options
Hi Scott, There isn't a more detailed list of the options yet. I'm still fighting to make time to do this. In the meantime please just ask specific questions and well try to explain them. Robert. On Tue, Mar 25, 2008 at 3:45 AM, Hulet, Scott S [EMAIL PROTECTED] wrote: I am looking for a more detailed description of the VPB osgdem command line options. The --help option descriptions are fairly abbreviated. I have checked the VPB and OSG sites. I have also performed several unsuccessful searches in an attempt to find more information. If desired, I can provide a specific list of the options in which I am interested. Thanks! Scott S. Hulet * Simulation Training and Support They never forget who they're dying for... We can never forget who we're working for... Lockheed Martin Corp - STS Akron 1210 Massillon Road Mailpoint C2E, AB-33 Akron, OH 44315-0001 ( Phone Numbers: 330.796.6616 (Desk) 330.796.1059 (Lab) 330.242.2385 (Cell) 6 Fax: 330.796.4050 ___ 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] Settings for the GPU Challenged?
On Mon, Mar 24, 2008 at 11:16 PM, Stephan Huber [EMAIL PROTECTED] wrote: Robert Osfield schrieb Its implemented under Windows, and under Linux aaand OS X ;) couldn't resist, Stephan Thanks for the correction, like J-S even I forgot stuff that rattles it way into the OSG ;-) Robet. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ScalarBar bug (Robert Osfield)
Hi Steven, On Tue, Mar 25, 2008 at 12:42 AM, IceSharK [EMAIL PROTECTED] wrote: - So that , scalarBar's Title can not display chinese by std::string freetype235. In OSG , one way to show chinese word is using wchar_t , freetype235 chinese local font. This limitation is one that hasn't been reported before, the OSG is developed rapid development style - on as needed basis, rather than guess ahead of the game when and where it might be used as doing so tends to over engineer things. When limitations are hit up against bits of the OSG that are limiting things are often refactored - and often by those hitting up against the limit. You can use 8 bit encoding with standard strings, osgText::String supports this, but my guess is that you won't be able to use this route through given the text will just be set the usual default methods. Refactoring ScalarBar to use osgText::String is a possibility. I'm afraid I'm rushed off my feet as usual so if you would like this change you'll need to chase it up yourself. If you do find a sensible fix then just send the changes into a osg-submissions and I can then review to see if they are in keeping with the basic design/implementation of ScalarBar and the wider OSG. This is how much of the OSG has evolved. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Appeal for use of human names
Hi Rizzen, Rizzen is far from my real name. It is a random generated fictional name. From past replies to my posts on this mailing list, Robert has had no problems referring to me as Rizzen, showing that even fictional names do work. :) Yes, the key is *use* you psuedo name in place of true name, rather than just not using a name at all. The real problem is posts that address no one, and have no signature, where there is absolutely no indication how one is addressed. Its rude communitcation that all too easily can stem from hiding behind anonymity. Polite discussions go like this: Hi X, Some text Post from X: Some other points Regards, Z Drop the address and your have: Some text: Some other point Now which of these is likely to be taken the wrong way, and to lead to deterioration in communications? This is basics of human communication. Personally I find anonymity a slippery slow, its communication that from the outset is based on one party being deceitful. As Nicolas pointed out, anonymity can be used to avoid accountability, which in turn can all too easily lead to peoples conduct dropping. As someone who's working life is very entwined with the osg-users community I am very exposed this conduct dropping. Sadly poor conduct in one poster can then rub off on to others, and all too soon its a rabble and thoroughly unpleasant place for everybody to hang out. As project lead and mailing list administrator its my role to try and sheppard things in a better direction. This does occasionally mean calling out behaviour which I feel is not acceptable to myself and others. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
