Re: [osg-users] OSG Design pattern
Hi Mike, Thinking out loud, be real nice if the old wiki's page master template could be modified (like put a notice in the header, or make the background red, eg) to indicate its deprecated status. Totally agree. I don't remember who has control over the web site and wiki(s), but could he please do that? :-) Most likely we'll have to wait for Robert to get back so he can get in touch with the appropriate person. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Microsoft .NET 2008 OSG
Hello Kim, A copy of .net 2008 landed on my desk today and I was thinking about giving it a go. However, since I am working primarily with OSG I would like to check if the two play nicely together.. Has anybody used it in conjunction with OSG, particularly building the source with it. Does CMake throw a fit or is the transition straight forward? There have already been a few threads about this in the recent past. I use it at home (on Vista no less... I'm adventurous) and it works well. A few notes: 1. You need to upgrade to CMake 2.4.8 or 2.5.x (one of the nightly builds) for it to be able to generate projects for VS9. 2. Up until now, Mike's 3rd Party binaries for VS8 have worked for me. But I have not been using it that much so you may run into problems. Please report here if you do. All in all, I don't see much difference between 8 and 9, and they even seem to be binary-compatible except for the project/solution files (of course... they had to change something so old projects wouldn't work without a conversion...). That situation may change though. If you have other questions, I'll be glad to answer. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.4 dev and VirtualPlanetBuilder-0.9.5 dev releases tagged.
Hi all, Sorry for not replying to the testing thread, OSG was still building when I left work. There were no foreseeable problems though, so hopefully 2.3.4 should be alright. And other people have been keeping an eye on you for VPB, so that should be ok as well. If not we'll survive a few weeks :- Just to confirm that OSG 2.3.4 and VPB 0.9.5 both build fine on Vista 32-bit, VC++ 2005. I'll build on VC++ 2008 tonight, but I don't expect the results to be any different. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with shaders in osg on geforce 7800
Hello Roni,
I don't have an error message, and the image is not black, I just get
the same picture I would get without running shaders.
You say you don't get any error messages, but did you set
OSG_NOTIFY_LEVEL=DEBUG when running your app? Any GLSL compiler
warnings/errors will show up then.
In my experience, the GLSL compilers are pretty picky, and even warnings
will force the pipeline back to fixed-function, which is what you're
seeing. So check that.
Any ideas? Maybe a driver issue? Maybe the card doesn't support the
shaders used in osg 2.2?
Apart from the above, a driver issue is always possible (if it's a new
machine, the first thing you should do is update your video card drivers!).
A GeForce 7800 is by no means old, so most shaders should work fine on
it. I have a 7900 at home and it works fine. The things that are
supported by the 8800 and not by the 7900 are (in a nutshell) Shader
Model 4 and Geometry Shaders, but I doubt your trivial
gl_FragColor=vec4(1,0,0,1) shader uses any of that! :-)
One thing I have sometimes seen is the shader being replaced by an empty
osg::Program lower down in the scene graph. The empty osg::Program will
effectively disable shaders and the subgraph will thus be rendered by
the fixed pipeline. One way to see if that's happening is to output your
scene graph to an .osg file and inspect it in a text editor.
#include osgDB/WriteFile
int main(int argc, char** argv)
{
osg::ref_ptrosg::Group root = new osg::Group;
//... build scene graph ...
osgDB::writeNodeFile(*root, output.osg);
// Make sure the write is the last thing you do before running the
viewer, so
// you're pretty sure you're writing the final scene graph to the file.
viewer.setSceneData(root.get());
return viewer.run();
}
Good luck,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem install Make/dependencies File does not exist
Hello Andi, I compiled and installed OpenSceneGraph on Linux successfully. Now I would like to compile and install osgdem because I would like to load some elevation data into osg. I followed the steps which are described on http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem but I can´t find the Make/dependencies File because the Folder Make doesn´t exist. What version of OSG did you install? osgdem has been moved into the VirtualPlanetBuilder project since after 1.2 (meaning 1.2 was the last official version of OSG that contained osgdem). To get it with a recent version of OSG, please see http://www.openscenegraph.org/projects/VirtualPlanetBuilder and pay heed to the table of required versions at the bottom of the page, which will tell you which version of VPB you need for your version of OSG. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with shaders in osg on geforce 7800
Hi Jeremy, As a side note, I wonder if Robert could be convinced to remove these messages: cull_draw() 0x805a808 end cull_draw() 0x805a808 ...from DEBUG or INFO level output, as I get about 6 zillion of them every second, making setting the notify level pretty useless. Am I the only one that sees this? I see it too. Perhaps a separate DEBUG_CULL_DRAW or DEBUG_THREADING or whatever notify level could be implemented? Or perhaps these could be disabled unless doing a specific type of debugging (with a #if 0 for example)... I don't know. You should keep this in mind and bring it up when Robert gets back. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with shaders in osg on geforce 7800
Hello Bryan, You could move them to notify level DEBUG_FP; DEBUG uses DEBUG_INFO, so they would then be left out of any but the most verbose output. I'll submit a change to this effect. Jeremy already submitted a change to remove the messages completely... Since no change will be checked in until Robert comes back, I suggest you hold back, see if he'll agree with removing the messages, and if not then you can submit a change to move them to DEBUG_FP. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange Behaviour of Virtual Planet Builder (VS c++ 2007)
Hello Adrian, after long time no using VP Builder i try do rebuild it on my dev system. i get strange behaviour what can be wrong ? Which version of VPB is this? I have tested the latest SVN head on VC8 and it builds and runs OK. I don't have a VC7 environment to test on, but I don't see why it should make that much of a difference... Sorry to say but I can't help you. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange Behaviour of Virtual Planet Builder (VS c++ 2007)
Hello Adrian, after testing and playing around with VS2007 i have not yet get a running version. what can i do, no longer supported for VS2007? or what can you propose? I guess you mean VS 7 (7.0/7.1) as 2007 does not exist (7.0 = .NET, 7.1 = .NET 2003, 8.0 = .NET 2005, 9.0 = .NET 2008) It's really hard to troubleshoot with so few details... OSG itself builds fine with VS 7, so I would not think that VPB would be much different. But it's hard to say. Can you perhaps check if it's just a missing header in some files, or something like that? What are the specific errors you get? Since I don't have the environment to reproduce this, it's really hard for me to help you. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] old wiki
Hello Brede, Sorry for the late reply. I wasn't able to find this information on the new wiki. http://www.openscenegraph.org/osgwiki/pmwiki.php/KnowledgeBase/OpenFlight Here you are: http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/OpenFlight (straight copy-paste of the original page - please edit if it needs updating...) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Displaying cables
Hello, I imagine this is pretty common, I'm just looking for a few hints of how to optimize things. Our apps need to display cables (and most of the time, a large number of them). The cables themselves are controlled by a physical simulation which gives us a set of transforms for the ends of each segment of a cable. For now, we are creating some geometry (quad strips, specifically) to display the cables, and assigning texture coordinates to that geometry, on the fly. This is needed because if, for example, a cable is lengthened (because it's being spooled out of a pulley system for example) the texture shouldn't stretch over it. Similarly, if the physical simulation subdivides the cable into more segments than it was in the last frame, we need to have correct texture coordinates to (hopefully) make the fact that the cable now has more, shorter segments invisible to the user. I know the cable display needs to be optimized because if I just set the cables' nodemasks to 0, the draw times go from 6.6ms to 2.2ms (for the same view). And there are not *that* many cables... There's a lot of other geometry in the scene which is still drawn in the 2.2ms time... So I would appreciate some pointers. I would have assumed quad strips are pretty fast, so perhaps something else is the problem? There's the fact that the geometry is dynamic, which could mean that OSG is trying to recreate display lists each frame, but I tried setUseDisplayList(false) on the geometry and the cables just did not display anymore... Is there something else I need to do in that case? Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
Hi Mike, Thanks for the pointer about the GPU pipeline, I'll check it out. So you're drawing 6x as many quads as necessary; that's seems a good rationale to learn geometry shaders! :-) That and moving texcoord generation off the CPU and into the vertex shader. I'm pretty anxious to try them out myself, but in this case, I don't think it would make that much difference. Sure, in percentage terms 6x more is a lot, but in absolute terms it's still not very much (20 cables with 20 segments of 6 quads each - 2400 quads... and even in terms of vertices it's not that many...), so I guess I'm doing something wrong. It's not the first time someone's displayed cables, and using geometry shaders was not an option until recently, so there's obviously something amiss. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
Hello Mike, Thanks a lot, good questions and suggestions here. - any ideas on exactly where you're bottlenecked? As I said, if I set nodemask to 0 on the cables the draw time goes way down. So I'm pretty sure the bottleneck is there (in other words, it's not how I build the geometry, because that's being done anyways; it's not the physics either). Though more specifically than that I can't say. - if perception of cable width is critical, how are you ensuring the quads are orthogonal to the viewer? Billboards, adjusting the quad verts, viewer/quad relationship is fixed, etc? Sorry, I wasn't very clear. It isn't billboards, and I can see that it sounded like that the way I described it. We're building cylinders with quad strips. So we'll give a subdivision level (number of quads for a segment, for example 6). And then the cable is a set of segments, each of which consists of 6 quads in this case. Since in this case, the cable with the most segments has about 20 of them (120 quads), I don't quite see why it's so slow. Of course, it might be the display list rebuild time, but I can't switch them off for some reason... - quadstrips are converted to tristrips in the driver; perhaps there's advantage in dispatching tristrips directly. I thought of this too, but didn't think it could be significant. If you think it might be something to try, I'll try it out and see. - Ideally, and your target hardware supports it, suggest dispatch linestrip and tessellate each linesegment into a pair of tris in a geometry shader. A vertex shader could take care of texcoord computation given cable/segment lengths. I haven't had much chance of using geometry shaders yet, unfortunately. I'd really have to demonstrate a large incentive to use them (though the hardware we ship to clients will likely support them anyways). It could also be used if the hardware supports it, with other fallbacks if not. We'll see in the next few months. Anyways, thanks a lot, I'm at least making progress and have a few things to try out. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Framerate vs stats?
Hello all, I'm seeing something peculiar in one of our apps using OSG 2.2, and I was wondering if someone else had seen something like this or would have an idea what would cause it. The app starts and seems sluggish. Pressing 's' once shows it's running at around 15-20 FPS. But then, if I press 's' a second time, the framerate shoots up to 75 FPS (capped by my refresh rate) and the app is suddenly very smooth. And it stays like that too (I can hide the stats again or whatever, it has no significant effect on the frame rate). So, what could cause this? Why would showing the detailed stats screen have that effect? I've seen cases where showing detailed stats _slowed_ the frame rate, but this is the first time it makes it faster! Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
Hello Anders, I did something similar a while back. http://www.vrlab.umu.se/research/colosseum3d/images/cables2.avi Wow, very nice! Also I did not spend that much time on the calculation of texture coordinates, which is as far as I know a fairly hard problem. We're pretty satisfied with just using the world-space distance between the two ends of a segment to determine the texture coordinates. It's not perfect but sufficient... I was more or less drawing a skewed cylinder between the interpolated points. That's what we're doing. Did you use OSG for your implementation? Care to share some details on how your geometry is being built? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem using uniform arrays
Hello Roni,
For example indexing an array like this:
arr[ind]
works fine for the vertex shader, but doesn't compile on the fragment
shader, saying that the index has to be constant, so that arr[ind] is
not
allowed, but arr[3] is ok.
However, since I'm using long arrays (70 elements), I don't know how
to
work
around this limitation.
Any ideas
Stupid suggestion, perhaps you can do this? (not sure you can pass an
array to a function, but worth a try...)
vec4 indexArray(vec4[n] array, int i)
{
if (i == 0) return array[0];
if (i == 1) return array[1];
// ...
// error add more indices to the function!
}
Then call
vec4 value = indexArray(arr, ind);
Just to work around the limitation...
Let me know if you try this, I'd be interested to know if it works.
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
Bonjour Rémy, Just a stupid question : if the bottleneck is the update of the hose, what would you think about using VBOs ? Well, on a hunch yesterday before leaving I did something that actually improved things quite a bit: Before, when I wanted to switch off display lists, I would use both these lines: geometry-setUseDisplayList(false); geometry-setUseVertexBufferObjects(true); The result was that the geometry was not visible for some reason (which leads to a separate question of what is necessary to get VBOs working right, but that's not really important for now). In one try, I accidentally did this: geometry-setUseDisplayList(false); //geometry-setUseVertexBufferObjects(true); (i.e. DLs off but VBOs _not_ on - not sure what state that leaves the geometry in...) And that gave a really *huge* improvement! The cables are almost not significant now in the draw time. So I guess it really was the display list recompilation that was killing my draw time. Thanks everyone for the tips and ideas for investigation. I'd say problem solved at this point. :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to read VRML file in OSG
Hello Syeb and Bob, You'll need to build the Coin3D library and rebuild osg. The result will be able to display simple vrml files, not all functionality is supported. Another solution is to use the OpenVRML2 reader. For Windows see http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio/VisualStudioPlugins Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 keyboard bug (+ ugly fix)
Hello Franz, To reproduce start the osgkeyboard example, press a few modifier keys (let's say Ctrl and Shift) and while keeping them pressed switch the desktop (e.g. on KDE) or minimize the window. Release the modifier keys. Now, when you switch back or open the minimized window, you'll see Ctrl and Shift still activated. And it's not only an visual problem. These keys are actually not released, and pressing 'a' will now really be seen as 'A'. That's very annoying in FlightGear. One has to press and release the respective modifier keys to get the missing release event. For reference, the same thing happens on Windows, and is often an issue when debugging (if an action which is triggered by a modified keypress activates a breakpoint, when you go back to the app the modifier is still active and you have to press/release the key to get rid of it). As you said, it's really a window manager issue, and I've seen it in other apps to. Not sure if OSG should try to work around it or not... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap and TEXTURE_COMPARE_MODE
Hello Sebastian, I've been struggling with the implementation of osgShadow::ShadowMap in osg 2.2.0. It seems to me the shadow texture compare mode is not set, which results in strange results. My project requieres per pixel illumination, which is why I have to calculate all projections in the vertex shader. I can't say specifically as I haven't seen these particular artifacts, but then again I haven't used osgShadow as you are. It's very possible there are tweaks to be made. osgShadow in general needs some work, though the basics are there. If you work on this and there is anything you can contribute, it would be very appreciated. I guess it also depends on the shader you're using, since you're probably replacing the osgShadow::ShadowMap shader to do your per-pixel lighting, right? J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
Hello Andy, So is anyone counting on this being floats for performance? Would anyone else welcome this calculation in doubles? If you submit a patch, I can test it out in my Masters project which uses LineSegmentIntersector pretty heavily (not-quite-realtime raytracing :-) ) so that will tell us if there is really a performance difference. Off hand I can't really say, so I'd prefer to do some benchmarking. I don't mind adding some code in our own source if other people don't want this in doubles, but I'd have to make my own IntersectVisitor as well as my own LineSegment, when all I really want to replace is the LineSegment. Having an almost-but-not-quite copy of a class and having to watch the original for updates doesn't sound like any fun. I totally understand... It'll be a matter of the performance vs correctness tradeoff I guess, so as I said I can provide some answer to the performance side of that question and see what Robert thinks when he comes back. So please, submit your changes and we'll see. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] generation of file .exe
Hello Aurora, how can I produce a file .exe, that can also be performed on a computer on which osg is not installed? is this possible? Yes it is possible, it's just a matter of including the right DLLs with your executable. The Dependency Walker tool (http://www.dependencywalker.com/) can be of some help to tell you which DLLs you executable depends on. Please search the archives for more information (http://dir.gmane.org/gmane.comp.graphics.openscenegraph.user), as this has been discussed before. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
Hi Andy, In your work, could you give me an idea of how often you intersect with a particular line segment object? I'm trying to decide if it is worth it to keep a Vec3d in the class (marking whether it is valid), or keeping double versions of _s and _e. In general terms, my program will do n^2 intersections from each vertex in directions around a sphere, where n=20 to 100 (so 400 to 10,000 intersections per vertex). And right now, I'm working with scenes which have roughly 5,000 to 100,000 vertices. So say for the simplest scene at n=20, that would be 2 million intersection tests. And in terms of time, I'll take what I can get, but with Adrian Egli's kdtree I'm currently getting about 20 seconds (IIRC) for that, so that's about 100,000 intersections per second. With the LineSegmentIntersector, I was getting about 10,000 to 20,000 intersections per second. But I don't keep the line segment objects since none of my tests are have the same start _and_ end values... I guess I could precompute them and store them and then just use them each time, but since my goal is to do this for dynamic scenes, it would be one more thing to recalculate if something changes... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap and TEXTURE_COMPARE_MODE
Hello Sebastian,
I reckon that my assumption regarding the texture compare mode were wrong.
But indeed the whole problem seems to be with my shaders. I'm willing to
provide the per-pixel modifications.
I guess I'm doing something very wrong in my vertex shader. Upon
completion and testing these shaders could be integrated into the
osgShadow::ShadowMap implementation (if I get this working ;-))
Before writing your shader, did you look at the shader in
src/osgShadow/ShadowMap.cpp? It does things a bit differently than
classic shadow map implementations (in particular it does not need a
vertex shader), so I'd also suspect something is wrong in your vertex
shader. Also, I think you need to use the same uniform sampler names in
your fragment shader that ShadowMap sets, otherwise you're not using the
same sampler, right?
//
// fragment shader
//
static const char fragmentShaderSource_withBaseTexture[] =
uniform sampler2D osgShadow_baseTexture; \n
uniform sampler2DShadow osgShadow_shadowTexture; \n
uniform vec2 osgShadow_ambientBias; \n
\n
void main(void) \n
{ \n
vec4 color = gl_Color * texture2D( osgShadow_baseTexture,
gl_TexCoord[0].xy ); \n
gl_FragColor = color * (osgShadow_ambientBias.x + shadow2DProj(
osgShadow_shadowTexture, gl_TexCoord[1] ) * osgShadow_ambientBias.y); \n
}\n;
Unfortunately I cannot dive into this right now, but I think you have
some leads... Keep us updated on how it goes.
Hope this helps,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
Hello Adrian, :-) only the first version of my kd.tree. latest i still extermly slow with about 700K-800K intersection test per second. there are latest kd-Tree ray check with more than ++ 6M rays per second. www.ompf.org http://www.ompf.org :-) Don't take it personally, I didn't mean it's slow at 100k intersections per second! Remember each application will be different, so you cannot compare 100k in my program to 700-800k in yours. My program probably does more processing between intersection tests than yours, since it traces in a sphere at each vertex and then stores that as vertex attributes in the Spherical Harmonics basis... Your program is just raytracing from the viewpoint and displaying that, which is simpler... And I recently integrated the last version of your kdtree in my application, and it works well... If you have a newer one, you can send it to me if you want... :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap and TEXTURE_COMPARE_MODE
Hi Sebastian, I derived my shader from the shader in the sources. Ok, that's what I was wondering about. I really need the vertex shader in order to calculate lighting on per pixel base. Of course, I didn't mean to remove the vertex shader, I just meant that if you're doing things that are not as they are done in the fixed function vertex processing stage, that could cause problems. If you don't have a vertex shader then the fixed function pipeline does the vertex processing, so if you want equivalent results you have to do the same things as the fixed function pipeline in your vertex shader. So there are a lot of things that could go wrong there... Sampler names should not matter, as the texture objects are rebound to my names (which should take all texgens etc into account). As long as you bind them at the root node (the shadowed scene) so that the uniforms are applied to all the nodes of your graph, that should be ok. It's still a possible point of failure, so why not just use the same names and save yourself the trouble? Sadly I suspect that the only thing that might be wrong is the comparison :-( If you suspect that, you could modify osgShadow::ShadowMap.cpp to try it out... Sorry I can't help you any more than that... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap and TEXTURE_COMPARE_MODE
Hello Sebastian, Indeed ... I once spent half a day figuring out that the texture matrix wasn't applied ;-) Hehe, that happens to all of us! Me culpa! ... it was the uniform name. I accidentally added them somewhere else with the PROTECTED-flag. That has also happened to me more often than I'd like to admit... I once spent 3 days debugging why shadows were being done by the fixed pipeline, only to find out that the top node of my graph was getting an empty osg::Program with a PROTECTED flag, but that was so deep down in the framework code that I hadn't found it until I decided to do a complete dump of the graph... So thank you for pointing to the problem! If I want to contribute, how may I submit suggestions/ patches? http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org Note that Robert (project lead, and also the one who merges changes) is on vacation right now, so you might not get a response right now. Also see http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol And also, if your submission is a per-fragment lighting shader for ShadowMap, you might want to either add parameters to control whether per-vertex or per-fragment lighting is applied, or ask Robert about adding the shader to OpenSceneGraph-Data instead... I think for a while now most people will still want per vertex lighting by default. But if the submission is for fixes or other things, go ahead and submit it! I really appreciate your fast and exact response ... saved me some gray hair ;-) My pleasure! J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
Hello Andy, I've submitted a change to the submission list. Please take a look and tell me if and how much it affects timing. Great, I'll try and check it out tonight and get back to you. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent sphere
Hi Paul, Probably a more interesting question is how to render the transparent sphere so that the back half is rendered first and the front half is rendered second, for proper blending. Best way to do that is to multi-parent the sphere to two Geodes. In one Geode cull front faces, and in the other cull back faces. Then set the render bin details so that the back half gets rendered before the front half -- and both get rendered after the opaque sphere, of course. Nice catch, I hadn't thought of this. I generally don't use transparency that much, and then mostly in test programs, so I normally just accept what I get with artifacts and all... :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Win32 VS8.0 crash on exit in debugger, related to freetype
Hello Thibault, I have tried to comment out the 2nd line, and the program exits correctly. Great! Excellent! Thanks for getting to the bottom of this! It will be great to finally be free of this, as it would pop up each time I would try a test program in the debugger and displayed the stats... Thanks again, looking forward to seeing this on osg-submissions (and in SVN :-) ) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] View matrix center
Hi Paul, Thanks for the lookAt background, very useful. Yep, read the code. Look for something like getCenter in MatrixManipulator, that would be a good start. I'm already going down that road. Trouble is MatrixManipulator doesn't have getCenter(). TrackballManipulator does, and using that works, but I'd prefer not to assume the manipulator will be of any particular type (other than the base MatrixManipulator). I'm left with using getMatrix(), but if this is also a lookat matrix, I'll have the same problem... Any other leads? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] View matrix center
Hello, A quick question about the camera view matrix. I have a viewer which is close to the default osgviewer, with the default camera manipulator. I can see that at startup, the camera is at, say, (0,-40,0) (looking down the positive Y axis, with the +Z up convention). I can also see that I am orbiting around the origin (0,0,0). So I would expect that using camera-getViewMatrixAsLookAt(eye, center, up) would give eye = (0,-40,0) center = (0,0,0) The eye point is as expected, but instead I get center = (0,-39,0). Why is this? Is that a result of the manipulator? Do I need to get one of the manipulator's properties in order to get the value I need? I really need both the correct eye point and the actual point the camera is orbiting around... Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Win32 VS8.0 crash on exit in debugger, related to freetype
Hello Thibault, I am using VS 2008 and Mike's DLL compiled for 7.1. I have had no problem so far, so I guess the problem is inside the OSG, and not exactly related to FreeType. First of all, if you're using VS 2008 you really should use the 8.0 precompiled binaries at a minimum, and I don't think we've done enough testing yet to even confirm if that's a good idea or not. Up until now, it seems fine, but it could lead to problems in the future. Ideally, we should have binaries for 9.0, as historically using libs/dlls compiled with a version of VC++ different from the one you're using to compile your executable would lead to weird problems/crashes. In this case it's too early to tell. Adrian, you mentioned something about multi-threading earlier in this topic. Do you think such a program is suffer from MT problems ? Actually, I don't know osgDB well enough to tell. The current theory is that it's related to how OSG tries to unload the freetype plugin. From such a simple test case, I would say that multithreading is unrelated to this particular crash at exit, as no viewer is ever instantiated (and thus, no draw/cull/update threads fired). Thanks for the test case, it's a step in the right direction. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent sphere
Hello Ahmed, I need to draw a sphere inside a Transparent one. Can anyone tell me how to set the material and color of the Transparent one. If you're using ShapeDrawables for your spheres, you can do it like this: // Sphere of radius 1, red and semi-transparent. osg::ref_ptrosg::ShapeDrawable sphere = new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0,0,0), 1)); sphere-setColor(1, 0, 0, 0.5);// red, with 50% opacity. sphere-getOrCreateStateSet()-setMode(GL_BLEND, osg::StateAttribute::ON); // Activate blending. osg::ref_ptrosg::Geode geode = new osg::Geode; geode-addDrawable(sphere.get()); // Sphere of radius 0.5, blue. osg::ref_ptrosg::ShapeDrawable sphere2 = new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0,0,0), 0.5)); sphere2-setColor(0, 0, 1, 1);// blue osg::ref_ptrosg::Geode geode2 = new osg::Geode; geode2-addDrawable(sphere2.get()); osg::ref_ptrosg::Group root = new osg::Group; root-addChild(geode.get()); root-addChild(geode2.get()); That should give you a semi-transparent red sphere with an opaque blue sphere inside. (untested...) If you're using normal geometry, you need to set a color array with the opacity you want, and remember to enable blending on it too. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Congratulations ag! OpenSceneGraph Chinese Mirror have been finished , try it.
Hello Wang Rui, Codes from 14.1 Shaders Introduction to 18.1 Node Mask Demo(7 files) and all the texts are modified by me. Some of the chapters have been completely rewrote, e.g 12. Two cameras. I will be very glad to help update the English versions. Should I send a tarball to someone? If you want to update them yourself (if you have time), on the English wiki, the section Documentation - Tutorials (the upper part of the page) should be the NPS tutorials. To be able to edit the wiki, you can login with user osg and password 05G (without quotes, password is zero-five-capital G). It seems some of the tutorials have been updated, no idea if all of them have... As for the complete code, I don't even think we have a tarball with all the code on the wiki. You could attach that to the tutorials page. Thanks! J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Play MP3 sounds
Hello Pedro, I am making an application and I would like to play MP3 sounds. Do you know how can it be done? Thanks in advance. Please start a new thread by starting a new message addressed to osg-users@lists.openscenegraph.org instead of replying to another message next time. It makes things easier to follow in the mailing list. As to your question, OSG does not have anything to do with sound itself. There are some nodekits that allow playing positional sounds (osgAL I think, for example), but if you just want to play sounds with no other requirements, you can use any sound library (OpenAL, fmod, etc.). Look up their documentation and choose what is best for your needs. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] what is better
Hello Ahmed, What is better for performance (and/or) memory? 1- Share a sphere geometry between more than one node after transform and scale. Or build a new sphere with the correct size and place. In general it is preferable to share geometry and use transforms if the objects are identical, since this will mean that the vertex data can be sent to the video card once and used for both objects. Transforms are generally not much of a performance problem since the OpenGL pipeline will transform all vertices anyways, so if you add a few transforms, it just translates into a few additional matrix multiplications, which the hardware is very optimized for. Though unless your spheres are extremely tessellated (osgOQ demo anyone? :-) ) it won't make much difference in this simple case on modern hardware. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Congratulations ag! OpenSceneGraph Chinese Mirror have been finished , try it.
Hello Wang Rui, I want to first say good work to all involved in this Chinese mirror of the OSG site, I had a look though I cannot read it, it looks like a faithful transition. Great work Yang Shixing and the osgChina team! The NPS tutorials in Support/Tutorials have all been modified and translated. (OSG version 2.2 for most of the chapters) I think it better than the English ones, which are partly written in OSG 1.2~~ :) Yes indeed! Would it be possible for the person(s) who did the conversion to contribute back the changes so we can update the English versions as well? I imagine most modifications were mostly in the code samples, so this should not require much additional translation I hope... Thanks, and again good work to all involved! J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
Hello Andy, J-S, did you get to do any timing with my proposed use of doubles in the intersection code? Sorry, I was out of town finally this weekend. I will try it out tonight. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] eventState problem in CompositeViewer?
Hello again,
I finally looked into this, and it seems that commenting out the lines
that set the input range in CompositeViewer.cpp fixes the issue. I don't
know why that would cause a problem. While debugging, it always entered
the branch of the if() that set it according to the traits, but it seems
it's still not correct.
Well, turns out that just commenting those lines made the problem appear
when using a single camera per view. So I needed instead to check if the
camera is not a slave camera, and then set the input range.
Corrected file attached. I checked that it works with
setUpViewAcrossAllScreens() and setUpViewOnSingleScreen().
Let me know if that fixes your picking problems, or if you find other
problems.
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osg/GLExtensions
#include osgUtil/GLObjectsVisitor
#include osgGA/TrackballManipulator
#include osgViewer/CompositeViewer
#include osgViewer/Renderer
#include osgDB/Registry
#include osg/io_utils
using namespace osgViewer;
CompositeViewer::CompositeViewer()
{
constructorInit();
}
CompositeViewer::CompositeViewer(const CompositeViewer cv,const osg::CopyOp
copyop):
ViewerBase()
{
constructorInit();
}
CompositeViewer::CompositeViewer(osg::ArgumentParser arguments)
{
constructorInit();
std::string filename;
bool readConfig = false;
while (arguments.read(-c,filename))
{
readConfig = readConfiguration(filename) || readConfig;
}
while (arguments.read(--SingleThreaded))
setThreadingModel(SingleThreaded);
while (arguments.read(--CullDrawThreadPerContext))
setThreadingModel(CullDrawThreadPerContext);
while (arguments.read(--DrawThreadPerContext))
setThreadingModel(DrawThreadPerContext);
while (arguments.read(--CullThreadPerCameraDrawThreadPerContext))
setThreadingModel(CullThreadPerCameraDrawThreadPerContext);
osg::DisplaySettings::instance()-readCommandLine(arguments);
osgDB::readCommandLine(arguments);
}
void CompositeViewer::constructorInit()
{
_endBarrierPosition = AfterSwapBuffers;
_startTick = 0;
// make sure View is safe to reference multi-threaded.
setThreadSafeRefUnref(true);
_frameStamp = new osg::FrameStamp;
_frameStamp-setFrameNumber(0);
_frameStamp-setReferenceTime(0);
_frameStamp-setSimulationTime(0);
_eventVisitor = new osgGA::EventVisitor;
_eventVisitor-setFrameStamp(_frameStamp.get());
_updateVisitor = new osgUtil::UpdateVisitor;
_updateVisitor-setFrameStamp(_frameStamp.get());
setStats(new osg::Stats(CompsiteViewer));
}
CompositeViewer::~CompositeViewer()
{
osg::notify(osg::INFO)CompositeViewer::~CompositeViewer()std::endl;
stopThreading();
Scenes scenes;
getScenes(scenes);
for(Scenes::iterator sitr = scenes.begin();
sitr != scenes.end();
++sitr)
{
Scene* scene = *sitr;
if (scene-getDatabasePager())
{
scene-getDatabasePager()-cancel();
scene-setDatabasePager(0);
}
}
Contexts contexts;
getContexts(contexts);
// clear out all the previously assigned operations
for(Contexts::iterator citr = contexts.begin();
citr != contexts.end();
++citr)
{
(*citr)-close();
}
osg::notify(osg::INFO)finished
CompositeViewer::~CompsiteViewer()std::endl;
}
bool CompositeViewer::readConfiguration(const std::string filename)
{
osg::notify(osg::NOTICE)CompositeViewer::readConfiguration(filename)std::endl;
return false;
}
void CompositeViewer::addView(osgViewer::View* view)
{
bool threadsWereRuinning = _threadsRunning;
if (threadsWereRuinning) stopThreading();
_views.push_back(view);
view-_viewerBase = this;
view-setFrameStamp(_frameStamp.get());
if (threadsWereRuinning) startThreading();
}
void CompositeViewer::removeView(osgViewer::View* view)
{
for(RefViews::iterator itr = _views.begin();
itr != _views.end();
++itr)
{
if (*itr == view)
{
bool threadsWereRuinning = _threadsRunning;
if (threadsWereRuinning) stopThreading();
Re: [osg-users] DLL versioned MSVC and NMAKE problem, relative paths are wrong
Hello René, If it is possible to use Visual Studio Express Edition and command line build, let me know, as far as I know the command line files are not in the express edition. It is definitely possible, that's what I use at home. They just renamed devenv.exe to vcexpress.exe, but the command line options are still available. See http://msdn2.microsoft.com/en-us/library/xee0c8y7.aspx The main command line option for you is /Build of course. :-) You can specify to build the INSTALL target, which will do the right thing. Be sure to run the vcvarsall.bat script beforehand so it will set up your environment correctly (but you know that, you're using nmake! :-) I also use nmake, because it triggers cmake before building, if this happens in visual studio you will have to reopen all you projects (the project has been changed from outside...). This makes testing cmake scripts more time consuming. If you have nothing else modifying your project files, they will not need to be reloaded, so it's no problem... Plus, if you run the build from the command line as above, you shouldn't have that problem, it should work fine. (if someone knows how to avoid closing/opening visual studio or reloading the projects one by one let me know). That annoys me too, but it isn't very often that I tweak the CMake config files, so I don't mind that much. I have used this build system with osg for over two years now, it worked perfectly until the current cmake hack (adding../../bin to move files) was created. I think a better (cmake) solution is possible. I don't know, I seem to recall that was a workaround for some other problem, though I can't remember which one. Maybe if you search the archives for ../../bin you would find that discussion. I think Luigi Calori was the one who did that modification for versioning the DLL files, so that might help your search as well. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] eventState problem in CompositeViewer?
Hello Roni,
I recently changed my application from using Viewer to CompositeViewer with
one view (currently...).
Everything seems to work as before, except for picking.
I think you may have stumbled onto the same problem I mentioned on the list last
Friday:
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/23244
But I think you're further along in the investigation... I would love to see
this fixed, but as I mentioned in the thread linked above, I'm not avaliable
for most of next week. If you're able to track this down, please let us know!
I finally looked into this, and it seems that commenting out the lines
that set the input range in CompositeViewer.cpp fixes the issue. I don't
know why that would cause a problem. While debugging, it always entered
the branch of the if() that set it according to the traits, but it seems
it's still not correct.
The problem was actually very easy to reproduce: just running
osgcompositeviewer -1 and then trying to drag to orbit the camera made
the problem apparent (the camera would orbit extremely slowly).
Here is a version of CompositeViewer.cpp with those lines commented
(search for JSG). Check it out, and when Robert comes back we'll check
with him.
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osg/GLExtensions
#include osgUtil/GLObjectsVisitor
#include osgGA/TrackballManipulator
#include osgViewer/CompositeViewer
#include osgViewer/Renderer
#include osgDB/Registry
#include osg/io_utils
using namespace osgViewer;
CompositeViewer::CompositeViewer()
{
constructorInit();
}
CompositeViewer::CompositeViewer(const CompositeViewer cv,const osg::CopyOp
copyop):
ViewerBase()
{
constructorInit();
}
CompositeViewer::CompositeViewer(osg::ArgumentParser arguments)
{
constructorInit();
std::string filename;
bool readConfig = false;
while (arguments.read(-c,filename))
{
readConfig = readConfiguration(filename) || readConfig;
}
while (arguments.read(--SingleThreaded))
setThreadingModel(SingleThreaded);
while (arguments.read(--CullDrawThreadPerContext))
setThreadingModel(CullDrawThreadPerContext);
while (arguments.read(--DrawThreadPerContext))
setThreadingModel(DrawThreadPerContext);
while (arguments.read(--CullThreadPerCameraDrawThreadPerContext))
setThreadingModel(CullThreadPerCameraDrawThreadPerContext);
osg::DisplaySettings::instance()-readCommandLine(arguments);
osgDB::readCommandLine(arguments);
}
void CompositeViewer::constructorInit()
{
_endBarrierPosition = AfterSwapBuffers;
_startTick = 0;
// make sure View is safe to reference multi-threaded.
setThreadSafeRefUnref(true);
_frameStamp = new osg::FrameStamp;
_frameStamp-setFrameNumber(0);
_frameStamp-setReferenceTime(0);
_frameStamp-setSimulationTime(0);
_eventVisitor = new osgGA::EventVisitor;
_eventVisitor-setFrameStamp(_frameStamp.get());
_updateVisitor = new osgUtil::UpdateVisitor;
_updateVisitor-setFrameStamp(_frameStamp.get());
setStats(new osg::Stats(CompsiteViewer));
}
CompositeViewer::~CompositeViewer()
{
osg::notify(osg::INFO)CompositeViewer::~CompositeViewer()std::endl;
stopThreading();
Scenes scenes;
getScenes(scenes);
for(Scenes::iterator sitr = scenes.begin();
sitr != scenes.end();
++sitr)
{
Scene* scene = *sitr;
if (scene-getDatabasePager())
{
scene-getDatabasePager()-cancel();
scene-setDatabasePager(0);
}
}
Contexts contexts;
getContexts(contexts);
// clear out all the previously assigned operations
for(Contexts::iterator citr = contexts.begin();
citr != contexts.end();
++citr)
{
(*citr)-close();
}
osg::notify(osg::INFO)finished
CompositeViewer::~CompsiteViewer()std::endl;
}
bool CompositeViewer::readConfiguration(const std::string filename)
{
osg::notify(osg::NOTICE)CompositeViewer::readConfiguration(filename)std::endl;
return false;
}
void CompositeViewer::addView(osgViewer::View* view)
{
bool threadsWereRuinning = _threadsRunning;
if
[osg-users] Viewer on single screen - other screen black?
Hello, If I use the osgViewer::View::setUpViewOnSingleScreen() method, the view is on the single screen but the other one is black. I would have expected that if there is nothing specifically set to occupy the second screen, my application would not occupy it so I would see (for example) my debugger on it. I can reproduce this by simply adding viewer.setUpViewOnSingleScreen(); before viewer.realize() in the osgviewer application's osgviewer.cpp file. Not sure if this is a known issue. I thought it was related to something we did incorrectly on our side, but it doesn't seem so. We are using OSG 2.2 here, but it still does the same thing in OSG from SVN. Has anyone encountered the same issue, and is there any workaround? Could it be related to fullscreen vs windowed mode? I would like setUpViewOnSingleScreen to just use the one screen (unless I have another view on the other screen of course) and setUpViewAcrossAllScreens to use both screens. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
Hello Sebastian,
I'm quite confused regarding the osgShadow implementation.
My scene and my light-positions are static. My idea was to capture the
shadow-map only once
and apply it consecutively in all frames. I'm a bit lost where to start.
Neither update nor cull seems to be the right place.
Any hints?
As you have seen, it was not designed to do that. It's designed to
recalculate the shadow map each frame. I guess you could add a boolean
to it to say that it has been calculated, and then not redo it again...
Maybe just something like:
class myShadowMap : public osgShadow::ShadowMap
{
public:
myShadowMap() : _done(false) {}
virtual void update(osg::NodeVisitor nv)
{
if (!_done)
osgShadow::ShadowMap::update(nv);
}
virtual void cull(osgUtil::CullVisitor cv)
{
if (!_done)
{
osgShadow::ShadowMap::cull(cv);
_done = true;
}
}
private:
bool _done;
};
Note that I didn't try this, but it might give you something to start
with? Let us know how it goes.
Hope this helps,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New to OSG, some questions (selection buffer, parametric curves)
Hello Raphael, Welcome! Hope you enjoy your time working with OSG, and the community around it! - OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? I'll let others answer this one, I don't know myself. I have always found OpenGL selection buffers cumbersome to use, but with a good wrapper it should be possible to make something that works well and is easy to use I imagine. So I don't know why that was not done. - Support for parametric curves / surfaces (Bezier, NURBs and the likes). Are there any plan to support this directly (through GLU or other), or should I export those as polygonal data instead? I would like to eventually help in adding support for parametric curves and surfaces in OSG. I have used the GLU interface before and would have used that as the first step, followed by an implementation using Geometry Shaders, with the ability to select the implementation you want to use at runtime and a fallback mechanism. I think it would be really cool to support that. But I haven't gotten to it thus far... :-( If you want to start doing something in this direction, I will be glad to test and comment. And search the archives, there was a discussion related to this not too long ago, so there was obviously interest in this. Hope that helps, and again welcome. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
Hello Wojtek, I have spent couple months banging my head against the wall, implementing perspective shadow mapping algortihms and that is the only rason I know how osgShadow::ShadowMap works ;-). Hehehe, I suspect I am on the same road, so only a few months to go if your assessment is correct :-) Any chance you would contribute the PSM implementation? It would make one more on the list. :-) Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
Hello Wojtek, ShadowMap::cull invokes culls traversal for both main camera (ShadowReceiving) graph shadow camera (ShadowCasting) graphs. So if you block whole cull on ShadowMap level - it won't draw the scene as well. The trick is to block only the portion that culls ShadowCasting graph. Cool, thanks for clearing that up! I didn't know, haven't looked at the code long enough it seems :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DLL versioned MSVC and NMAKE problem, relative paths are wrong
Bonjour René, I am using commandline build system nmake on windows, since the OSG_MSVC_VERSIONED_DLL hack this does not work anymore, because there are hard-coded paths to move the dll's, but nmake has different locations for the files. I don't quite see why versioned DLLs would be a problem with nmake but not with the IDE, as both just call cl.exe (the VC++ command line compiler). So I think you just have to adjust the build files you use with nmake to do the right thing with the versioned DLLs. I really think removing the versioning is not desirable, since its goal is to remove DLL hell on Windows platforms. Since you're using nmake on Windows, this is still a desirable goal :-) BTW, DLLs do not need to be in your lib directory when you compile, they only need to be somewhere where your program can find them when it starts. Either in the program's current directory, on your PATH or in the Windows System32/other predefined location. So I do not understand what you mean above by hard-coded paths to move the dll's. If you have suggestions to improve the CMake config for nmake, it will be appreciated, but I really think you have to approach it from the other angle: adapting the build files generated for nmake to make it accept the versioned DLLs, instead of removing the versioning. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
Hello Wojtek, then I compute intersection of this convex scene hull with main camera frustum and coarse light (shadow) camera frustum. This produces my minimal scene bound polytope which I then use to further narrow shadow camera projection. This is the part I'm having trouble with. I actually don't mind using the scene bound I get with the ComputeBoundingBoxVisitor, but getting a usable camera frustum (both for main and light cameras) and then intersecting those is the hard part for me. Any tips there? How do you create the convex objects? How do you do the intersection itself? Any guidance in this would be useful. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
Hi Andy, J-S, did you get to do any timing with my proposed use of doubles in the intersection code? I did some tests last night. Full results below. The executive summary is this: For 2,244,800 samples (individual ray tests), Floats: 113.121566 seconds (original) Doubles: 113.954178 seconds (your patch) Difference: ~0.730655 % Floats: 19844.138 samples / second Doubles: 19699.146 samples / second So with doubles, it is less than one percent slower, which I don't think is significant over that many samples... I did not have the time to do multiple tests though (because that 0.7% might even be due to some other activity on my machine) but I think we can safely say it's not a significant difference. You can quote me on that :-) BTW, for reference, using the kdtree took 13.366302 seconds to do the same thing :-) See below. Hope this helps, J-S Detailed results: === LineSegmentIntersector, float (original) === - Parsing command-line arguments. Using 5 bands (25 coefficients) and 400 samples per vertex. Deleting previously calculated data files to recalculate them. - Loading model file data/PRT_test_scene_9b.ive. - Optimizing model data/PRT_test_scene_9b.ive. - Loading/Computing SH coefficients for lighting [L] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/lighting_25_400.prt: Not found. Computing. 0.534819 seconds. (747.917 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt: Not found. Computing. (1017 vertices) 15.1999 seconds. (26763.4 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt: Not found. Computing. (930 vertices) 13.9724 seconds. (26624 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt: Not found. Computing. (1596 vertices) 21.7206 seconds. (29391.5 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt: Not found. Computing. (1040 vertices) 40.901 seconds. (10170.9 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt: Not found. Computing. (1029 vertices) 21.3278 seconds. (19298.8 samples/sec) Total time for loading transfer functions: 113.121566 seconds. Total loading/computing time: 113.657229 seconds. Precalculation done, exiting. === LineSegmentIntersector, double (Andy Skinner's modification) === - Parsing command-line arguments. Using 5 bands (25 coefficients) and 400 samples per vertex. Deleting previously calculated data files to recalculate them. - Loading model file data/PRT_test_scene_9b.ive. - Optimizing model data/PRT_test_scene_9b.ive. - Loading/Computing SH coefficients for lighting [L] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/lighting_25_400.prt: Not found. Computing. 0.524556 seconds. (762.55 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt: Not found. Computing. (1017 vertices) 15.6853 seconds. (25935.1 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt: Not found. Computing. (930 vertices) 14.2079 seconds. (26182.6 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt: Not found. Computing. (1596 vertices) 21.8676 seconds. (29193.9 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt: Not found. Computing. (1040 vertices) 40.8934 seconds. (10172.8 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt: Not found. Computing. (1029 vertices) 21.3 seconds. (19324 samples/sec) Total time for loading transfer functions: 113.954178 seconds. Total loading/computing time: 114.479672 seconds. Precalculation done, exiting. === Adrian Egli's kdtree === - Parsing command-line arguments. Using 5 bands (25 coefficients) and 400 samples per vertex. Deleting previously calculated data files to recalculate them. - Loading model file data/PRT_test_scene_9b.ive. - Optimizing model data/PRT_test_scene_9b.ive. - Loading/Computing SH coefficients for lighting [L]
Re: [osg-users] Test www.osgChina.org . Normal?
Hello, Hello all : Somebody found that He(at Singapore) cann't visit www.osgChina.org (located HangZhou China. I don't know this site can be visited normally or not at other country. Thanks All. Yang ShiXing very slow but it works from europe Seems to work from Canada as well. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
Hello Wojtek, Actually most of the time was spent on algorithms finding minimal shadowed scene bounds under OSG. It was a key to good shadow mapping results. Well, that's what I'm working on right now too! If you are planning on contributing this sometime, would it be possible for you to help me with this? It would save me lots of time. I have something that works pretty well, but only if the camera manipulator is a Trackball Manipulator (for the getCenter() method) - I essentially get the smallest of either the scene bound or the camera view volume. If I could have something that works well in more cases, it would be very useful. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
Hello Wojtek, And thats it. Thank you Robert ! Thank you Wojtek, I'll check that out! I'm really very grateful to you for contributing this. I've been banging my head on this and we're still on OSG 2.2 here so I didn't think of going to see in the new additions if there was something that would help me out. Thanks again, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Update scene while moving window
Hello André, There might be a way to avoid this by using a separate thread for message dispatching in the GraphicsWindowWin32 class, but that remains to be explored. And in fact, I imagine that's what video players like Windows Media Player do, since you can move the window while video is playing and it will not pause. Not suggesting anything be done about it, just adding a point to consider... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tiled textures on osg::Box
Hello Frans,
m_osg_shape = new osg::ShapeDrawable( new osg::Box(
osg::Vec3f( 0, 0, -0.005f ), 29.7f, 21.0f, 0.01f ) );
osg::Image* image = osgDB::readImageFile( gras.jpg );
osg::Texture2D* tex2d = new osg::Texture2D( image );
tex2d-setWrap( osg::Texture::WRAP_S, osg::Texture::REPEAT );
tex2d-setWrap( osg::Texture::WRAP_T, osg::Texture::REPEAT );
m_osg_shape-getOrCreateStateSe
t()-setTextureAttributeAndModes( 0, tex2d, osg::StateAttribute::ON );
but the setWrap() command doesn't seem to have any effect for me. I
guess I have to specify the relative alignment for the texture manually
but I have no clue how I do this for a osg::Box. The examples only deal
with manuallly built geoms.
The wrap modes only take effect if your geometry has texture coordinates
outside the 0.0 - 1.0 range. In the case of the osg::Box shapedrawable,
it generates texcoords that go from 0.0 to 1.0 on each face, in both the
s and t directions. So you'll never see wrapping on that.
You'll have to make your own box, and specify the texture coordinates
you want. For example 0.0 - 2.0 on each axis for each face will give you
a texture repeated twice (assuming you set up your texture as above).
It's not hard... Oh heck, I have the code here to create a basic box, so
here it is:
osg::Geometry* createBox()
{
osg::Geometry* box = new osg::Geometry;
// Vertices
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-push_back(osg::Vec3(-.5, -.5, -.5)); // 0
vertices-push_back(osg::Vec3( .5, -.5, -.5)); // 3
vertices-push_back(osg::Vec3( .5, -.5, .5)); // 5
vertices-push_back(osg::Vec3(-.5, -.5, .5)); // 1
vertices-push_back(osg::Vec3(-.5, -.5, .5)); // 1
vertices-push_back(osg::Vec3( .5, -.5, .5)); // 5
vertices-push_back(osg::Vec3( .5, .5, .5)); // 7
vertices-push_back(osg::Vec3(-.5, .5, .5)); // 4
vertices-push_back(osg::Vec3(-.5, -.5, -.5)); // 0
vertices-push_back(osg::Vec3(-.5, -.5, .5)); // 1
vertices-push_back(osg::Vec3(-.5, .5, .5)); // 4
vertices-push_back(osg::Vec3(-.5, .5, -.5)); // 2
vertices-push_back(osg::Vec3( .5, -.5, -.5)); // 3
vertices-push_back(osg::Vec3( .5, .5, -.5)); // 6
vertices-push_back(osg::Vec3( .5, .5, .5)); // 7
vertices-push_back(osg::Vec3( .5, -.5, .5)); // 5
vertices-push_back(osg::Vec3( .5, .5, -.5)); // 6
vertices-push_back(osg::Vec3(-.5, .5, -.5)); // 2
vertices-push_back(osg::Vec3(-.5, .5, .5)); // 4
vertices-push_back(osg::Vec3( .5, .5, .5)); // 7
vertices-push_back(osg::Vec3( .5, -.5, -.5)); // 3
vertices-push_back(osg::Vec3(-.5, -.5, -.5)); // 0
vertices-push_back(osg::Vec3(-.5, .5, -.5)); // 2
vertices-push_back(osg::Vec3( .5, .5, -.5)); // 6
box-setVertexArray(vertices);
// Normals
osg::Vec3Array* normals = new osg::Vec3Array;
normals-push_back(osg::Vec3( 0, -1, 0));
normals-push_back(osg::Vec3( 0, -1, 0));
normals-push_back(osg::Vec3( 0, -1, 0));
normals-push_back(osg::Vec3( 0, -1, 0));
normals-push_back(osg::Vec3( 0, 0, 1));
normals-push_back(osg::Vec3( 0, 0, 1));
normals-push_back(osg::Vec3( 0, 0, 1));
normals-push_back(osg::Vec3( 0, 0, 1));
normals-push_back(osg::Vec3(-1, 0, 0));
normals-push_back(osg::Vec3(-1, 0, 0));
normals-push_back(osg::Vec3(-1, 0, 0));
normals-push_back(osg::Vec3(-1, 0, 0));
normals-push_back(osg::Vec3( 1, 0, 0));
normals-push_back(osg::Vec3( 1, 0, 0));
normals-push_back(osg::Vec3( 1, 0, 0));
normals-push_back(osg::Vec3( 1, 0, 0));
normals-push_back(osg::Vec3( 0, 1, 0));
normals-push_back(osg::Vec3( 0, 1, 0));
normals-push_back(osg::Vec3( 0, 1, 0));
normals-push_back(osg::Vec3( 0, 1, 0));
normals-push_back(osg::Vec3( 0, 0, -1));
normals-push_back(osg::Vec3( 0, 0, -1));
normals-push_back(osg::Vec3( 0, 0, -1));
normals-push_back(osg::Vec3( 0, 0, -1));
box-setNormalArray(normals);
box-setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
// Faces
box-addPrimitiveSet(new osg::DrawArrays(GL_QUADS, 0,
vertices-size()));
// Colors
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(osg::Vec4(1,1,1,1));
box-setColorArray(colors);
box-setColorBinding(osg::Geometry::BIND_OVERALL);
return box;
}
Just add the returned geometry as drawable to a geode. This code does
not specify texcoords, so I have left you a bit of work... :-) But you
should be able to figure it out. Check the doxygen for
Geometry::setTexCoordArray(unsigned int unit, Array* array). You need
one texcoord (Vec2) per vertex, btw.
Hope this helps,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
Re: [osg-users] osgpick strange behavior
Hello Carlo, 1 - osgText (osgfreetype plugin): The plugin doesn't free memory correctly, I think there are a massively memory leak. There is a submission in the queue for a crash on exit related to the freetype plugin. It's not a memory leak, it's a use of a pointer after it's been freed. Not sure it's the same issue you're seeing, but maybe you should wait until this fix is in SVN and then re-test. Though this probably has no relation to your osgpick problem. I never used osgpick on a terrain model, so I can't help you there. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Back from holidays...
Hi Robert, welcome back! You'll be seeing a scattering of emails from me today as I slowly make my way through my email backlog. I'm a bit jet lagged am not fully functioning so if I write more nonsense than I usually do then put it down to 5 hour shift in time of day... Please don't overwork yourself trying to get back on track in a single day... Take it easy for the first few days :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HELP: Pick point in Point Cloud
Hello Samuele, i am newbie for OSG; my initial goal is write a program to load point could file and pick a point. I tried to use the example osgpick with .3dc file format. The program osgpick reads the file and displays the point cloud but does not select any point. In addition to what Adrian said (that osgpick focuses on triangles), I believe (but have never done it, so I might be wrong) that you can pick points using a PolytopeIntersector. Unfortunately this is not very documented. Have a look at how the osgpick example's source sets up a LineSegmentIntersector, and try to do the same thing for a PolytopeIntersector (setting up a valid polytope for what you want). Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Overriding the SwapBuffers call
Hello Robert et al,
I have a very specific application in which I need to wrap the
SwapBuffers call with two other function calls. So for example, in
GraphicsWindowWin32:
void GraphicsWindowWin32::swapBuffersImplementation()
{
if (!_realized) return;
// function call 1 here
if (!::SwapBuffers(_hdc))
{
// ...
}
// function call 2 here
}
What I would like to know is:
- If I subclass GraphicsWindowWin32, how do I tell
osgViewer::CompositeViewer to use my subclass instead of the real
GraphicsWindowWin32 when creating a graphics window?
- Will this catch all cases of calling SwapBuffers? I haven't seen it
called directly anywhere else, but I could have missed something? Even
SwapBuffersOperation seems to call this (indirectly) or am I wrong?
Thanks in advance,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] View dependent shadows and multithreading
Hello Robert et al, Wojtek and I have been discussing on and off list about making shadow mapping view-dependent. Wojtek says he has a few implementations but it is not possible for him to release them at the moment. On my side, I also have something working pretty well (thanks Wojtek!) but I have one problem. osgShadow::ShadowMap uses two member variables, _camera and _texGen. When the viewer is running in multithreaded mode, with multiple views, and the shadow mapping is made view-dependent, the views' threads compete for these variables, so the shadows in both views flicker between one view's shadows and the other's. Weird effect, but not what we want :-) What would you suggest to fix this issue? I can see two possibilities, one of which is not viable IMHO, and the other which I wouldn't know how to implement. Please mention any others that might be better. - Add a mutex to control access to the variables. The problem here is that the shadow map is computed in the cull stage, and drawn in the draw stage, so the mutex would need to be held across both stages. I imagine that would mean that only one shadow map could be updated each frame - not a good solution. - Have one camera and one texgen per thread/view. How would I do this? Maybe use a map indexed by the view's main camera (pointer), so if there's only one view it'll be ok, but if there are multiple views we create and get the correct camera and texgen for the view's camera? Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Framerate vs stats?
Hello Wojtek, We noticed another issue. When statistics bars are on - framerate slowly degrades. This happens with osgviewer dumptruck.osg for example. When stats are on draw time slowly grows and framerate starts to decrease. I've seen that, but only when compiled in debug mode... Check to see if you're in debug. Never do performance timing in debug mode :-) If you're in release, then I haven't seen this, might be a driver bug... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer on single screen - other screen black?
Hello Robert, Which platforms have you seen this problem on? Windows XP/Vista. What happens when you setUpViewInWindow(...)? It's in a window :-) I've found a workaround, which is to use setUpViewInWindow(), and once it's done, turn off window decorations. I have to adjust the (x,y) and (w,h) to account for removing the decorations, but this gives me a nice fake fullscreen window on one screen, and I can see my debugger on the other. So I really think that it's normal behaviour. setUpViewOnSingleScreen still sets up the traits with decorations off, which when creating the GraphicsWindowWin32 is assumed to mean full screen mode, which will take up your two displays. Since you have only a master view on one screen, the other one stays black. It was just not what I expected, but now that I know, it doesn't really matter that much. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modify Object After Picking
Hello Romain, I use the Scribe effect all the time (both at work and in my Masters project) and I've never seen that particular issue. But do you add the scribe effect in real time ? Yes. Just be sure to do it in the update thread and make sure you don't do it while traversing (to not invalidate iterators) and you should be fine. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer on single screen - other screen black?
Hi Robert, I don't think it should be a case of shrugging ones shoulders and excepting that Windows doesn't work properly and documenting this. osgViewer should behave the same on all platforms as far as we can possibly make it. I'm not saying Windows does not work properly, just it does things differently. Policies and driver implementations are different, nothing we can do about it. Though we can hide it, and I agree osgViewer should do the same thing (visually) on all platforms. If full screen under windows trips windows up so that it grabs all screens then its something we can only use when osgViewer is running over all screens, when this isn't the case a borderless full screen window will probably have to be used. Before we go and put in a workaround in osgViewer itself for this, let me have a look at some documentation and see how GraphicsWindowWin32 is implemented. Maybe there's something there that can give some clues. It seems that the flag windowDecorations in the traits structure is what's triggering this. Even if I want to do my borderless window workaround, I need to pass the traits with windowDecorations=true when creating the window, and then disable them (gw-setWindowDecorations(false)) afterwards, otherwise still I get the black screen on the other screen. Also, the fact no one else on Windows has come forward to comment on this makes me doubtful. I'm not that familiar with implementing windowing on Windows, so it may be some detail I'm not familiar with. I'll get back to you. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Framerate vs stats?
Hello Judd, I can confirm that when we run on two monitors and the stats are up that the framerate slowly degrades in OSG 2.2 binaries from the website. It went from 60fps to 8fps in about 2 minutes. We are running WinXP with a GeForce 8600 GTS. What would be interesting would be to try other driver versions. I have personally not seen this on my 8800GTX (running Vista, driver 169.25) so possibly the Vista drivers don't have this bug. What's your driver version? It would be interesting to see what specifically in the stats display is triggering this, but I think it's not OSG's policy to work around driver bugs, just wait for them to be fixed. In the mean time you'll probably want to roll back to a version that doesn't have this problem. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Overriding the SwapBuffers call
Hi again, Am I missing anything? As I said, the prints are in the console, but the screen stays black. After further investigation, pressing 's' to display the stats displays them, but they don't get cleared so they just draw overtop the old image. Seems some clearing is not happening, in addition to the scene not getting displayed... I'm pretty lost, but then again I've never done this kind of stuff before either. Any advice would be appreciated... Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Overriding the SwapBuffers call
Hi Robert, Windows gurus,
Simply assign your custom GraphicsWindow implementation to the
viewer's osg::Camera's directly, rather than rely upon
View::setUpView*() methods.
I've gotten this to work partially. My method is getting called, but I
get only black onscreen. My overridden swapBuffersImplementation looks like:
virtual void MyGraphicsWindowWin32::swapBuffersImplementation()
{
std::cout Before SwapBuffers std::endl;
osgViewer::GraphicsWindowWin32::swapBuffersImplementation();
std::cout After SwapBuffers std::endl;
}
Am I missing anything? As I said, the prints are in the console, but the
screen stays black.
Thanks in advance,
P.S. For anyone who would need to do this in the future, for Win32 the
Win32WindowingSystem does some work in its createGraphicsContext()
method, and if this is not done, any call to
GraphicsWindowWin32::createWindow() will fail. So you need to call
osg::GraphicsContext::createGraphicsContext(traits.get());
once (even if you don't keep the return value), which sets things up so
the custom window can be created directly afterwards.
I hope this can save someone else the frustration I experienced trying
to get my custom GraphicsWindow to be created correctly... :-)
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Overriding the SwapBuffers call
Hello André,
Looks like the constructor of the base class (GraphicsWindowWin32) is not
being called by your derived class (_realized is false).
Here is my whole class (no joke!):
class MyGraphicsWindowWin32 : public osgViewer::GraphicsWindowWin32
{
public:
MyGraphicsWindowWin32 (osg::GraphicsContext::Traits* traits)
: osgViewer::GraphicsWindowWin32(traits)
{
}
virtual void swapBuffersImplementation()
{
std::cout Before SwapBuffers std::endl;
osgViewer::GraphicsWindowWin32::swapBuffersImplementation();
std::cout After SwapBuffers std::endl;
}
};
So I would assume the base class constructor is being called?
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Overriding the SwapBuffers call
Hello André, This looks fine. Try setting a breakpoint in GraphicsWindowWin32::swapBuffersImplementation() to see in what state the object is. Either _realized is false or the handle to the device context is invalid (and this is not trapped by the ::SwapBuffers call as an error). I'll try that on Monday. I already traced through the GraphicsWindowWin32::createWindow() method and all looked fine (after getting the window classes registered as I mentioned before). I assume you do not see anything reported on the console after the call (other than you own traces). That's correct. I'll investigate more on Monday. Thanks for the help. BTW, I don't know if you've seen the thread, but could you bring your insight (as Win32 implementer) in the Viewer on single screen - other screen black? thread? I think we've hit an inconsistency between how Windows and Linux handle full screen on a single screen, but before we go implementing workarounds, I'd like to be sure we're not just overlooking something. Thanks. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading an image file
Hello Per,
I too need to show images. Since osg is (and should be) 3d-based, the
way to do is seemed to be to display a rectange Geometry infront of an
orthographic camera, and set the rectangle texture to be the image.
To that end, there is a utility function in the Geometry header.
#include osg/Geometry
osg::Geode* createNodeWithMyImageOnIt(const std::string filename)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geometry =
osg::createTexturedQuadGeometry(osg::Vec3(0,0,0),
osg::Vec3(1,0,0),
osg::Vec3(0,0,1),
0, 0, 1, 1);
geode-addDrawable(geometry);
osg::Texture2D* texture =
new osg::Texture2D(osgDB::readImageFile(filename));
geode-getOrCreateStateSet()-setTextureAttributeAndModes(0,
texture, osg::StateAttribute::ON);
geode-getOrCreateStateSet()-setTextureMode(0, GL_TEXTURE_2D,
osg::StateAttribute::ON);
return geode;
}
Note this is off the top of my head, untested, possibly incomplete. But
it should give you an idea. Look up the doxygen for
osg::createTexturedQuadGeometry for details.
Hope this helps,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Framerate vs stats?
Hello Guy, How could it be a driver bug if it's debug/release issue?!? Don't both versions use the same driver? Not sure we're talking about the same issue here. Re-read my message: I said if you're in release mode, then it might be a driver bug. The premise is that you should never do any performance analysis in debug mode anyways, as in debug mode, weird things can happen to your framerate, and you might suspect an application or driver bug where there is none. But if the issue is present in release (no matter whether it's present in debug or not), then it might be caused by a driver bug since not everyone sees the issue (therefore it might be dependent on driver version). I did not say that the bug might be present in release but not in debug or inversely... Note that we've gotten a bit further in the investigation of this particular issue... Please read the thread to the end. :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading an image file
Hello Guy, This method also creates geometry, I think those guys are trying to avoid geometry creation. I think the class osg::DrawPixels can do the trick, but I never tried it. It's a tradeoff. You can create geometry (ooh, one whole quad!) and then set it to absolute reference frame or use some other way to make it always face the camera. Drawing the image each frame using glDrawPixels can be a few orders of magnitude slower than a quad with a texture, as long as the texture does not change too often. Just to say there are lots of ways to skin a cat, and you can't choose the best one for your situation unless you know about them. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer::View::setUpViewAcrossAllScreens and screen arrangement
Hi Robert, Quick question about screen arrangement. As I understand it, WindowingSystemInterface currently has no way of reporting the arrangement of the screens (physically), so there is no real way to support, for example, a single view spread over 4 screens arranged in a 2x2 square. Is that right? If I read the code right, the only thing you do in setUpViewAcrossAllScreens is to add a horizontal translation to each screen (translate_x). Such a setup would require a translate_y as well. Does that sound right? I guess to support 4 screens in such an arrangement, it would be up to the application to set it up correctly, having prior knowledge of the physical screen setup... I'm battling this a bit right now, as I'm trying to get a very general system to set up viewports across screens, and I'm having a bit of trouble with this. It just seems each case I need to support is totally different, and as I see it, you can only go so far (only so many assumptions you can make) without knowing the actual physical screen arrangement. Any thoughts on this? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::View::setUpViewAcrossAllScreens and screen arrangement
Hi Robert, The defaults settings in osgViewer can't cope with novel display arrangements, and this is well beyond the scope of WindowSystemInterface as once you start going beyond nx1 displays things can very rapidly get very complicated. Nothing novel in this case, just trying to get something as general as I can (so it can be used with little to no modification in most of our projects). The right way to handle complex screen arrangements is to use a configuration file that is set up to describe the displays you have and the view and projection matrix offsets that are appropriate for them. That's what I was thinking too, and it's a bit cumbersome. I would have liked to be able to get the info I need from the display driver (since it obviously has it, in order to set up the desktop correctly). But I haven't had the time or the energy to get into this yet. In the meantime you could use the .cfg plugin to read a Producer style configuration file to describe your display layout and then just load this into your viewer. i.e. osgviewer cow.osg -c twobytwo.cfg I haven't been able to get much documentation about the Producer configuration file format, nor any good examples. Do you have any pointers on this? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::View::setUpViewAcrossAllScreens and screen arrangement
Hi Robert, Trust in configuration files, they are very powerful for this type of stuff. For instance you can have it work on one screen of your four using one file, then another configuration file can set up all four. etc. etc. Well we already have config files for the views (similar to your .view files) but I just thought if the OS/driver can give us the info for the physical screen setup we could avoid having that in the config file too. But I'll probably do it anyways as it'll be less work I imagine. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem to consider: Shadow maps and LOD computation
Hi Wojtek, When rendering shadow map LODs are drawn based on distance computed from shadow camera. But this is plain wrong: LODs should be always selected based on distance from main camera. Oh, nice problem there... It's probably just an oversight, and the fact that osgShadow tries to be as transparent and as unobtrusive as possible will make it harder to overcome... I don't have any suggestions for this, perhaps Robert will have some thoughts as it comes down more to how to design the interaction between shadowing and LODs. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting Home position in OSG Viewer
Hello John, Can anyone help me out with this? Robert answered some time ago, the osgviewer application itself is not designed to do this, but it can be done programmatically. So if you're not willing to roll up your sleeves or get someone to do it for you, it looks like you're out of luck. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/23925/focus=24053 J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::View::setUpViewAcrossAllScreens and screen arrangement
Hi Robert, all, ... but I just thought if the OS/driver can give us the info for the physical screen setup we could avoid having that in the config file too. I just looked at src/osgViewer/GraphicsWindowWin32.cpp and noticed that the Win32WindowingSystem (subclass of osg::GraphicsContext::WindowingSystemInterface) has a method getScreenPosition(si, x, y, w, h) which gives me the information I need (i.e. the relative position of each screen, hence their physical arrangement). In other words, for 2 side-by-side screens, it will return screen 1 = 0, 0, 1280, 1024 screen 2 = 1280, 0, 1280, 1024 and for 2 screens one above the other, it will return screen 1 = 0, 0, 1280, 1024 screen 2 = 0, 1024, 1280, 1024 The only problem is that this class is not exposed, so I cannot use that method. I could copy the code into my project, but that's unclean, plus I wouldn't get any support for other OSes... Assuming the same thing is possible for X and/or MacOS, would it be possible to expose this method in osg::GraphicsContext::WindowingSystemInterface? It would then be possible to get osgViewer to support screen arrangements other than a basic horizontal linear setup, plus it would be nice for applications to use as well :-) Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::View::setUpViewAcrossAllScreens and screen arrangement
Hi Robert, In other words, for 2 side-by-side screens, it will return screen 1 = 0, 0, 1280, 1024 screen 2 = 1280, 0, 1280, 1024 and for 2 screens one above the other, it will return screen 1 = 0, 0, 1280, 1024 screen 2 = 0, 1024, 1280, 1024 Have you tested and confirmed that this is the case? i.e. is it something we can rely upon? If so then it would be very useful. Yes, I tested it and works (as long as it is set that way in the driver - i.e. just placing your monitors one above the other won't change anything if you don't change their arrangement in the driver :-) ). Adding a virtual getScreenPosition to the WindowSystemInterface base class would be straight forward. I don't know yet how one would implement it under X11, but it should be possible. OK, I'll submit something soon. Note that it will only have a concrete implementation for Win32 in the beginning... Given the above then the next tweak of View::setUpViewAcrossAllScreens() could then take this info, but... only if its actually implemented so we'd need a fallback. The fallback would probably be that screen n's x position would be the sum of all the previous screens' widths, which would give a linear setup (so no change compared to current behaviour). J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgcompositeviewer -1 issues
Hi Paul, Second, and more worrisome, the TrackballManipulator appears to be ignored with the -1 argument. In other words: 1) Run osgcompositeviewer -1 cow.osg on a dual-screen Windows system. 2) Two fullscreen windows open, displaying fountain.osg. 3) Use left or right mouse motion in either window; the camera position does not change. The view remains static (though the fountain particle animation is playing). Do you see this on Linux? Is this a known issue? Look closely - the scene moves, just *very very* little. It's a bug in osgViewer/CompositeViewer.cpp which I submitted a fix for about a week ago. When a single view is on multiple displays (so the slave camera mechanism in osgViewer::View is used) the viewport extents are not set correctly in the eventTraversal, so when the mouse events are translated they have wrong values and the mouse movement has very little effect. I haven't gotten any news about it being integrated into SVN yet, and your report seems to confirm it hasn't... Any reason for that Robert? Is there anything I need to do to get it integrated? J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgcompositeviewer -1 issues
Hi Robert, There is a bug and bug fix relating to picking and CompositeViewer, but I haven't yet had the time to investigate if this bug or review the bug fix. There is chance its related to the above. It is. :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgcompositeviewer -1 issues
Hi Robert, I haven't reviewed it yet. I did mostly clear my backlog on my return, but since then have had to get on with other tasks, and the backlog has grown back again... W.r.t merging submissions it tends to be first submitted gets reviewed first unless the submission itself requires more time to review and make a decision - these complex ones I tend to leave until I have a proper block of time to review them. That's fine, I totally understand, I was just wondering if there was something wrong but if it's just for lack of time I totally understand. (note that I'm not totally sure I did the right thing in the fix, I just did what worked for me - I don't know the related code that well so I couldn't see if there was some other way of dealing with the problem) Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Distributed rendering of scene graph
Hello Benjamin, we want to use OpenSceneGraph for a parallel rendering system. The scene graph should be located on a central computer which gets the user input, modifies the scene graph (with draggers) and displays the rendered image. The rendering should be done on other computers. We want to use a sort-last approach, where the geometry is distributed to these other computers and they send back an image with depth information that is composed on the central computer. Perhaps not the answer you want, but before doing all this work yourself, have you looked at Chromium? From what I can see, it can do this out of the box. I have never used it (attempts to get it working on Windows have failed) but it could be a good idea to try. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] warning C6246 UpdateVisitor
Hi Robert,
OSG 2.3.4
UpdateVisitor
#91
osg::NodeCallback* callback = geode.getUpdateCallback();
if (callback) (*callback)(geode,this);
// Call the app callbacks on the drawables.
for(unsigned int i=0;igeode.getNumDrawables();++i)
{
osg::Drawable::UpdateCallback* callback =
geode.getDrawable(i)-getUpdateCallback();
if (callback) callback-update(this,geode.getDrawable(i));
handle_callbacks(geode.getDrawable(i)-getStateSet());
}
Ahh you gotta love when a complier complains about perfectly legal and
correct C++ code. The code *is* correct, its the warning that is
being stupid whilst trying to be extra clever. What compiler are
you using?
It's most probably some version of Visual C++ (the warning C
message gives it away).
The code might be correct, but I would call it confusing. Just giving a
different name to the inner variable (like drawableCallback) would
make it clearer. Otherwise, reading the code quickly, one might get
confused as to which callback variable is being used.
Anyways, as most code style issues, it's really up to preference, and I
agree that it isn't the compiler's place to comment on style. :-)
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixes for VRML2 plugin
Hello Franz, AFAIK the first is right and the second is wrong. I don't know how the C: is handled (as a dir or as a prefix to the first dir name), but apart from that the syntax is supposed to look like this: file://hostname/C:data/blah ... whereby a localhost can be left away: file:///C:data/blah... which can be shortened to: file:/C:data/blah But file://C:data/blah is most certainly wrong. Can you quote some documentation for that? I'm not trying to be difficult, but as I said I remember going through this with Jan a while ago, so I just think we should make sure we have the real facts instead of AFAIKs before we change it again. As a reference, in Visual Studio (of course, MS could have just messed up, but it's kind of the only reference I have right now) I see this when I build: Build log was saved at file://c:\dir1\dir2\dir3\BuildLog.htm When I paste that into Firefox, it's changed to: file:///c:/dir1/dir2/dir3/BuildLog.htm So 3 slashes before the drive, and then a slash after the colon. Which one do we believe? I would tend to believe Firefox, but I'd like to have some concrete facts either way... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixes for VRML2 plugin
Hi Franz, try Firefox :-) I do, daily :-) as you saw further down in my message. Sorry about this whole thread, I guess I was remembering my conversation with Jan wrong. Gino, could you add a comment saying that the URI needs to comply to RFC2396 along with your change? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shadow Map and threading mode
Hello, I was wondering if there were any known problems related to using osgShadow::ShadowMap and changing the threading mode. In the osgshadow example (SVN), if I change the threading mode (I added a threading handler to it) my graphics driver crashes. In our own software based on OSG 2.2 and using a CompositeViewer, on some machines the problem is more interesting (after a fashion): when the threading mode is changed, the shadow stops moving with the mobile object which causes it (i.e. it stays where it was when the threading mode changed, apparently not updating anymore). On my own machine it just crashes as well, like the SVN version, but on others that's what happens. I haven't double-checked on those machines what happens with the osgshadow example though. So, I just want to know if I should expect it to work or if that's something that's expected not to work for now. This is on Windows (XP / Vista), nVidia 7900 and 8800 cards. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow Map and threading mode
Hi all, So since no one has replied, I gather no one else has had any problems changing the threading mode when shadows are enabled (for example, in the osgshadow example)? J-S Hello, I was wondering if there were any known problems related to using osgShadow::ShadowMap and changing the threading mode. In the osgshadow example (SVN), if I change the threading mode (I added a threading handler to it) my graphics driver crashes. In our own software based on OSG 2.2 and using a CompositeViewer, on some machines the problem is more interesting (after a fashion): when the threading mode is changed, the shadow stops moving with the mobile object which causes it (i.e. it stays where it was when the threading mode changed, apparently not updating anymore). On my own machine it just crashes as well, like the SVN version, but on others that's what happens. I haven't double-checked on those machines what happens with the osgshadow example though. So, I just want to know if I should expect it to work or if that's something that's expected not to work for now. This is on Windows (XP / Vista), nVidia 7900 and 8800 cards. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow Map and threading mode
Hello Raymond, Do you have an example which I can try. Then I can give it a try here, on a couple of machines. You can just add viewer.addEventHandler( new osgViewer::ThreadingHandler() ); to the osgshadow example (around where the other handlers are added) and comment this line: //viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded); You'll see that even when the viewer starts in a mode other than SingleThreaded, it runs fine. Press 'm' - in my case that makes my graphics driver crash (graphics driver has stopped responding and has recovered message in the system tray). Does it do that for you? I appreciate your testing. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow Map and threading mode
Hello Alberto, Works fine in Linux, nVidia 7600 GS [169.07] (Linux 2.6.22-3-amd64 #1 SMP x86_64): Threading model 'CullThreadPerCameraDrawThreadPerContext' selected. Threading model 'SingleThreaded' selected. Threading model 'CullDrawThreadPerContext' selected. Threading model 'DrawThreadPerContext' selected. Threading model 'CullThreadPerCameraDrawThreadPerContext' selected. Threading model 'SingleThreaded' selected. Threading model 'CullDrawThreadPerContext' selected. Threading model 'DrawThreadPerContext' selected. Threading model 'CullThreadPerCameraDrawThreadPerContext' selected. Threading model 'SingleThreaded' selected. Threading model 'CullDrawThreadPerContext' selected. Interesting. I'll wait to see if someone can test on Windows too. Thanks for testing, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] no Images folder
Hi Bryan, So I'm playing with the example osg apps, but I don't seem to have an Images folder, which many of the examples assume I do. Did I miss something with the download? Did you download the OpenSceneGraph-Data distribution? http://www.openscenegraph.org/projects/osg/wiki/Downloads/SampleDatasets Unzip that wherever you want it, and then set OSG_FILE_PATH to point to it. That contains sample .osg files, an Images subdirectory with stuff, some fonts, etc. If you downloaded the Windows installer, I think it includes OpenSceneGraph-Data already, but you may need to set OSG_FILE_PATH to the base directory (data I think) for it to find the textures. Then you can just run osgviewer cow.osg and it'll find the model and the texture by using OSG_FILE_PATH. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Turn On/Off the Display HUD
Hello, I am looking for more elegant way of doing this. My Display HUD is directly under the root (just as in the example). Is there a way I can turn off its visibility or make it non-renderable? You were asking about node masks and picking a few days ago, right? You can use node masks for that too. Set the node mask of your HUD's root Group/Transform to 0. This will cause it not to be rendered (and not be pickable as well). In OSG, the rendering is a traversal as well, so it has a traversal mask (default 0x). It logical-ANDs that to the current node's mask (also 0x by default) and if the result is nonzero, it goes into the subgraph (until it gets to the leaves, which are drawn if the result is nonzero). So by setting the mask of a node (or subclass of Node, like Group) to 0, you are forcing a result of 0, since (anything) 0 = 0. You can get into clever uses of node masks to make something pickable but not renderable, or renderable but not pickable, etc. Just remember that it isn't an equality test, it's a logical AND, so you have to put your binary hat on (assuming you're one of the 0001 out of 0010 who understand binary). :-) Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] no Images folder
Hi Bryan, Warning: Could not find plugin to read objects from file Images/lz.rgb Do you have the OSG binaries on your PATH? Where you installed, you should have a osgPlugins-(version) subdirectory. In there you should have an osgdb_rgb.dll file, which is the plugin it's looking for. Note that the *parent* of the osgPlugins-(version) directory should be on your PATH, not the directory itself. When debugging this kind of problem, set OSG_NOTIFY_LEVEL=DEBUG and re-run the app. It will print messages to the console which should help you. Also, if you're on Windows, when building from source you should always build the INSTALL target unless you really know what you're doing (make sure you set CMAKE_INSTALL_PREFIX to where you want your binaries when you generated the project files in CMake). See http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio for the general procedure to follow... Also, 2.0 is pretty old, you could at least upgrade to 2.2 if not to one of the dev releases or SVN. There have been build fixes on Windows since 2.0 which you will not have. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
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 -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow Map and threading mode
Hi Wojtek, I was on vactions. But if you are still interested I did the test you wanted. Of course I am interested. :-) Thanks for testing. Seems like the more recent nVidia drivers give problems when switching threading modes, and older ones are OK. Unfortunately I am on Vista so using old drivers usually gives me other problems :-( Anyways, I think we'll chalk it down to a driver bug until more information is available. Thanks again for testing. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-conv collada
Hello, could someone please tell me how to create the collada db so osgconv can load collada files? i can't find any documentation on this. I assume you're on Windows. From this page on the wiki: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio you'll see a link Help for compiling specific optional plugins which leads you to this page: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio/VisualStudioPlugins Which has info for compiling a few plugins with Visual Studio, including the COLLADA plugin. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
Hi Maciej, Yes but its fetched from vpb namespace - TaskManager.cpp line 32 :). Hmmm, but I'm getting a link error: (when building vpb.lib) 2TaskManager.obj : error LNK2019: unresolved external symbol char * __cdecl vpb::_getcwd(char *,int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: __thiscall vpb::TaskManager::TaskManager(void) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) (when building osgdem) 6osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) char * __cdecl vpb::_getcwd(char *,int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function _main It looks as if it doesn't see the '::' prefix to _getcwd, because it's looking for vpb::_getcwd (notice the underscore)... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
Hi Norman, AFAIK all MSoft compilers support char *_getcwd( char *buffer, int maxlen ); int _chdir( const char *dirname ); Read the rest of the thread, that's not the issue. The issue is that another header somewhere has #define getcwd _getcwd which in turn changes even vpb::getcwd() to vpb::_getcwd() which we don't want. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
Hi Wojtek, 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. Well, it sets the threading model to SingleThreaded and does not add a ThreadingHandler... So once the example is started, you're stuck in the threading mode that was set (SingleThreaded by default) and cannot change it at runtime. I think that's the more telling element. 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... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
Hello Robert, 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. I can see your motivation, but I would argue the case by case part. In the spirit of unit testing, I think it would be useful to know, for all examples: a) what the performance impact of a feature is (StatsHandler) b) if it's thread-safe (ThreadingHandler) c) if it plays well with state changes (StateSetManipulator) d) if it has problems when the window size changes or when the app goes fullscreen (WindowSizeHandler) and then fix all issues (if there are any). I think it's kind of a minimum set of cases where an example must work correctly for it to be usable in other contexts (more complex apps). In addition, a user evaluating OSG would appreciate a consistent set of viewer features across all examples, and these features would help in evaluating if OSG will work for them. And adding each handler is one line of code, so say 4 lines total, and is self-documenting. Even the argument parser stuff which is in every example dwarfs this in number of lines of code, and is also harder to read. But beyond any philosophical arguments, adding the handlers and testing them would have brought up the issue when changing the threading mode in osgShadow a bit sooner. Who knows what other examples also have an issue when changing the threading mode? J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
