[osg-users] Threading and such, Was: Re: [osg-submissions] Platformindependentmatrixmultiplicationoptimization
Hi James, I have moved that to osg-users. No longer in any way a submission related thing ... On Wednesday 24 September 2008 00:15, James Killian wrote: I have had an opportunity to work with a case where I need a many-to-one relationship. So for example lets say there are several threads working in tandem, and they simply make a function/method call, and at any given timeslice a single thread will process all the calls that happened in its own thread. There is a win32 way to handle this without the need of any critical sections, mutex, semaphore, setevent, etc... This would be done VIA passing function pointers (i.e. these could be cpp methods too) in the APC queue. What then happens is during the context switch the OS processes all method calls passed in (this can work with parameters too) and calls the methods in the same single thread. This works best for cases where there is work to be done from a single point. Ideally the client code would be easier to write, and with all atomic operations make the synchronization more efficient than using other synchronization techniques. The downside of course is trying to have some generic form of this technique for other platforms, but there may be a possibility of this happening. So this is the idea. The thing which I am not sure about is if this could be useful when culling works together with opengl (or other similar serialization processes). I also do not know if the gain would be significant for these cases. One thing is for certain... the absence of critical sections is good in that it decreases the chance for deadlocks. The client code would have a method to handle outside thread calls. This method simply invokes some ThreadCall(bool wait_for_return,thread,instance,func ptr, ... parms) and then the actual method would auto-magically be called on the thread (whatever parameter which was passed in as thread) timeslice interval . If this sounds like a cool technique to pursue then I could see what I can do to provide more info. What you are talking about is some kind of queue that can be filled by many threads and emptied by a single thread at a specified time. So what you basically need to do is, have either a lockless queue implementation or a mutex that protects that queue. Note that even if you do not see that fact behind the win32 api, that must happen inside that APC queue anyway. So you have exactly the same serialization points than you have in any case ... For lockless queues/lists, google for RCU/list/queue to see how this can be done. It is relatively simple using atomic compare and swap operations. But anyway, I do still not see where you want that serialized events to be processed? And where this sould happen in osg and for what reason? I am sure I miss something important... May be you put that in your application library for your use??? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build problems with osgviewerFLTK (OSG 2.6.0)
HI Cliff, This type of error comes from gcc now being tighter w.r.t inclusion of C style headers so that if you want access to the functions in these C headers you now need to explictly include them. It's not a bug in gcc, and not a bug in the OSG, it just one of those moving targets that we as developers need to keep track of - and the OSG svn/trunk is a bit further along this path so you could try updating to svn/trunk to see if the problem is any different. Adding cstring as an include will break the MipsPro compile so isn't portable enough for the OSG, but including the C header will be. I couldn't work out precisely where you need to add a header and don't have Suse to test against so I'll leave it to you divine what needs to be done, one you do could post the changes to osg-submissions. Cheers, Robert. On Tue, Sep 23, 2008 at 5:57 PM, Cliff Taylor [EMAIL PROTECTED] wrote: Hey guys, I moved to a new development box with openSUSE 11.0 (x86_64), so I had to rebuild OpenSceneGraph. This time, I decided to use ccmake and edit the configuration to build the documentation and support for some more libraries. I ran into some trouble when it tries to build osgviewerFLTK.o. I could have removed the library paths for FLTK in my config, but I thought it might be a build issue you'd like to know about. The problem seems to stem from the include/osg/Math file. Adding #include cstring makes it build correctly on my system, but that's probably not completely portable. I am building from the stable release 2.6.0 (zip) from the osg project page with g++-4.3 as my CXX. I also had the same problem as this posting on osg-submission, which manually adding Robert's changes fixed: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/2008-September/002216.html I assume this issue stems from the same strictness in gcc/g++. Info for debugging follows if you need it -- Cliff T. -- Here's my gcc config: # Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) ## I know it's prerelease, but I don't think it's an error in gcc. Here's the compiler output for the failed build (sorry it's so long, but I want to be thorough): ## [ 98%] Building CXX object examples/osgviewerFLTK/CMakeFiles/example_osgviewerFLTK.dir/osgviewerFLTK.o In file included from /home/ctaylor/lib/osg/include/osg/Vec2f:17, from /home/ctaylor/lib/osg/include/osg/Vec2:17, from /home/ctaylor/lib/osg/include/osg/Array:19, from /home/ctaylor/lib/osg/include/osg/Uniform:22, from /home/ctaylor/lib/osg/include/osg/StateSet:21, from /home/ctaylor/lib/osg/include/osg/Node:19, from /home/ctaylor/lib/osg/include/osg/NodeVisitor:17, from /home/ctaylor/lib/osg/include/osgGA/EventVisitor:17, from /home/ctaylor/lib/osg/include/osgViewer/Viewer:18, from /home/ctaylor/lib/osg/examples/osgviewerFLTK/osgviewerFLTK.cpp:23: /home/ctaylor/lib/osg/include/osg/Math: In function 'float osg::round(float)': /home/ctaylor/lib/osg/include/osg/Math:194: error: 'floorf' was not declared in this scope /home/ctaylor/lib/osg/include/osg/Math:194: error: 'ceilf' was not declared in this scope /home/ctaylor/lib/osg/include/osg/Math: In function 'double osg::round(double)': /home/ctaylor/lib/osg/include/osg/Math:195: error: 'floor' was not declared in this scope /home/ctaylor/lib/osg/include/osg/Math:195: error: 'ceil' was not declared in this scope /home/ctaylor/lib/osg/include/osg/Math: In function 'bool osg::isNaN(float)': /home/ctaylor/lib/osg/include/osg/Math:206: error: 'isnan' was not declared in this scope /home/ctaylor/lib/osg/include/osg/Math: In function 'bool osg::isNaN(double)': /home/ctaylor/lib/osg/include/osg/Math:207: error: 'isnan' was not declared in this scope In file included from /home/ctaylor/lib/osg/include/osg/Vec2:17, from
Re: [osg-users] setLODScale affecting near far planes?
Hi Jose, Getting 10fps is pretty bad, I personally wouldn't be happy till get that up to 60Hz+. The first step is to work out what is the bottleneck - you say that you have too many triangles in your scene, and cutting this down gets you back your frame rate. There are lots of ways to manage the number of triangles, if you have fog to hide what is in the distance you can get away with enabling culling on the far plane, but if you do enable this then you have to disable the compute near/far as the two will be dependant on each other and you'll end up with a feedback loop that might not behave well. Far plane culling isn't the only techinique - using LODScale is another technique, as is use of osgTerrain::Terrain::setSampleRatio() if you are using osgdem --terrain generated databases. See osgmultitexturecontrol example for code that controls these parameters. I've talked about these in last month so have a trawl through the mailing list archives. Robert. On Tue, Sep 23, 2008 at 8:59 PM, Joseanibal Colon Ramos [EMAIL PROTECTED] wrote: Hi all, Good, I am happy it is all clearer now, and I am sorry it wasn't enough at first. So back to the original issue: I observe my problem of auto-changing near/far planes when I modify the LODScale via camera-setLODScale(float). This *always* happens whether or not culling is enabled, but of course I am not affected by this problem when culling is disabled because no matter what values my near/far planes have, my objects do not get culled. I enable culling via: camera-setCullingMode(getCurrent() | osg::CullSttings::near | osg::cullS::far) - I don't have the code in front of me but that is the idea. The problem I encounter is that since I am culling the near/far planes, some objects get culled from my scene if the near/far planes shift positions automatically. Robert already explained that with my current near/far computing settings I will get some slight changes to the near/far planes when changing the LODScale. Although this is undesirable for my application, it makes sense given Robert's earlier explanation. So Paul asks, what if I just keep the original culling mode? Well, that would be great, it looks great and I don't have the culling problem of the changing near/far planes, but there is one *crucial* issue: frame-rate. My terrain is too large and I need a decent level of detail, but it winds up drawing way too many triangles. I am attempting to find the optimal LODScale for my app, which can get me up from 10fps to about 25-30fps at a decent LODScale, and I also want to cull all those extra triangles, which can pump me up to 40-50 fps, at the cost of culling objects when not desired. I think I'll be alright, I need to play some more with the near/far compute settings. Thanks all for your interest in this topic, -Jose On Mon, September 22, 2008 10:52 am, Paul Martz wrote: FYI, Roland is correct, the OSG just does culling on sides of the frustum by default. OpenGL does no culling, is just does near and far *clipping*. The OSG of course doesn't change this so will do near/far clipping and the only way to switch this off is to disable GL_DEPTH_TEST. Even that won't work; DEPTH_TEST is a fragment op, and clipping against the clip planes is done before rasterization. It would seem that Paul and Gordon have confused the clipping and culling a little. Yes, I thought the original poster was talking about enabling OpenGL near/far clipping (probably because I have seen so many newbies ask how to disable this in the OpenGL forums and newsgroups). Clearly, the original poster said culling... My mistake, and thanks to all for the clarification. Back to the original issue: So, you see this problem when you enable OSG culling for near/far. What happens if you leave this disabled (as osgviewer does)? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] View Dependent Shadow maps (LispSM)
Thanks, it doesn't solve my problem. i will have a look into the code as soon as i have some time left adrian 2008/9/24 Wojciech Lewandowski [EMAIL PROTECTED] Thank You, Adrian Lispsm classes derive all methods from StandardShadowMap MinimalShadowMap. StandardShadowMap has setLight method. I believe this is what you want. Cheers, Wojtek -Original Message- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] Behalf Of *Adrian Egli OpenSceneGraph (3D) *Sent:* Tuesday, September 23, 2008 10:46 PM *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] [osg-submissions] View Dependent Shadow maps (LispSM) Sorry, answered to wrong list but here i am right :-) Hi all, great algorithm. i have just one question. my scene has a lof of lighs, but only one should cast shadows. so would it be possible to add a method like in parallel splitted shadow map to tell the algorithm witch light it should be used for shadow casting. please have a short look at : _ParallelSplitShadowMap- setUserLight(m_sun.get()); this method allow to tell the sun light. :-) for example adrian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fullscreen
Hi Tim, On Wed, Sep 24, 2008 at 12:33 AM, Tim Jaffe [EMAIL PROTECTED] wrote: Thanks for the response. I got the borderless window method to work and finished updating the code to 2.4. Is it possible to produce a true (exclusive mode) fullscreen view--perhaps by using an externally-created exclusive OpenGL context? The exclusive fullscreen modes are bit awkward to work with in terms of providing consistent behavior, but you can make the OSG work with this approach - but if you want to toggle into windowed mode you'd need to delete the full screen context and then recreate a new context in the window, which is right old pain. You could add the hardwired fullscreen mode into osgViewer::GraphicsWindow*.cpp methods, and to facilitate this one would probably best provide an extra hint in osg::GraphicsContext::Traits to tell these implementations that you want one of these no turning back full screen windows. Given you might not be the last to request this feature this is the route I'd suggest you follow. The other route would be to use SDL and GraphicsWindowEmbedded as per the osgviewerSDL example, but... this would preclude the use of multi-threading and multiple window support as SDL doesn't provide the controls necessary for this type of operation, so you'd be using the OSG in a rather hobbled way. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extracting embedded Textures
Hi Frank, On Tue, Sep 23, 2008 at 6:26 PM, Evans, Frank [EMAIL PROTECTED] wrote: Thanks once again for the incredibly fast response. Up to now I've been using the OsgDotNet wrappers, so writing a Custom Visitor class means maintaining and updating the wrappers as well. At least, if I understand the solution correctly. I will of course make every effort to leverage the native loader. Wrappers do have their disadvantages, but if you go this route then you do need to accept that their at times when you have to dig down to the metal to get the job done. If this means helping maintain the wrappers then this no bad thing - you'll get updates to the latest OSG features/bug features as well as ability to solve some of your problems. The alternatively of writing a whole loader for an undocumented and varying file format sounds like far more work now and in the long run. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] View Dependent Shadow maps (LispSM)
Hi, What is wrong ? It does not work ? Method accepts Light ptr. If you have LightNode simply use getLight() to pass right argument. Wojtek - Original Message - From: Adrian Egli OpenSceneGraph (3D) To: [EMAIL PROTECTED] ; OpenSceneGraph Users Sent: Wednesday, September 24, 2008 10:17 AM Subject: Re: [osg-users] [osg-submissions] View Dependent Shadow maps (LispSM) Thanks, it doesn't solve my problem. i will have a look into the code as soon as i have some time left adrian 2008/9/24 Wojciech Lewandowski [EMAIL PROTECTED] Thank You, Adrian Lispsm classes derive all methods from StandardShadowMap MinimalShadowMap. StandardShadowMap has setLight method. I believe this is what you want. Cheers, Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: Tuesday, September 23, 2008 10:46 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] View Dependent Shadow maps (LispSM) Sorry, answered to wrong list but here i am right :-) Hi all, great algorithm. i have just one question. my scene has a lof of lighs, but only one should cast shadows. so would it be possible to add a method like in parallel splitted shadow map to tell the algorithm witch light it should be used for shadow casting. please have a short look at : _ParallelSplitShadowMap- setUserLight(m_sun.get()); this method allow to tell the sun light. :-) for example adrian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi camera rendering and pick issues
:-(... I'm really going to cry now... Guys, I tried something else and I feel like I'm loosing my mind: Since I cannot pick anything when traversing a sub camera, I tried to build my scene this way: - the main View camera (with cull mask set to 0x1) - my root group - a sub camera (with node mask set to 0x1) - a PositionAttitudeTransform (with a scale set) - an object - An hidden group (with node mask set to 0x100) - a link to the SAME previous PositionAttitudeTransform object. ... With that I still have a proper display (the default node mask is 0x): only my sub camera is rendered and the hidden group is not visible as expected. then for my IntersectionVisitor I obviously use the traversal mask 0x100 : this way I was expecting to traverse my main camera and the hidden group, but none of the sub camera... and guess what ? It's just not working :-( It works if I don't hide my hidden group (giving it a node mask of 0x101, but of course this doesn't make sense considering the goal I have)... So the IntersectionVisitor traversal also depends on the cull mask or something like that ? I could really use some explanations on that... By the way I'm using OSG 2.6... regards, Manu. 2008/9/23 Emmanuel Roche [EMAIL PROTECTED] Okay... I think I tried everything I could think about, unsuccessfully... unfortunately, I'm currently on WinXP with Visual Studio and for some obscure reason, I just cannot get/use the debug symbols from some of the OSG libraries (maybe beacuse I'm accessing those functions introspectively though a Lua release binary ? not sure about all that...) an as a result I cannot go deeper into those tests :-( But I've just discovered a new fact: this is at least partially linked to the scale of my object, I tried the following scene graph: - the main View camera - my root group - a sub camera - a PositionAttitudeTransform (with a scale set) - an object --- then depending on the scale applied in the PositionAttitudeTransform I can pick parts of my object or not : the bigger the scale, the closer to the object I need to be to get some intersections (and I'm not even sure those intersections are correct...). So could there be a scale factor not applied somewhere ?? Or maybe, since my main camera renders no objects its near/far planes are set to minimal values and then those settings are not modified accordingly when going though a sub camera in an intersectionVisitor [this could explain why I cannot select objects if I'm not very very close to them (and depending on their scale)...] ? Is there an other way to render Univers scale + high precision scenes without using multiple cameras as children ??? I did a quick test using ClearNodes and setting the only camera left to DO_NOT_COMPUTE_NEAR_FAR, but the results are not good (it seems to me that the ClearNodes clear the color buffer even when I only set the DEPTH_BUFFER_BIT mask... I really don't get it...). regards, Manu. 2008/9/23 Emmanuel Roche [EMAIL PROTECTED] Hi Robert, unfortunately I don't think this an available option in my current project: our software is already relying quite heavily on our current CompositteViewer / View structure (a view per window [using wxWidgets], a camera manipulator, a single scene graph that should not be cut into pieces, etc... and any way, I think there is a real problem here (expect if there is still something I missed) so I think for me (in both cases) it's important to solve this issue instead of just bypassing it. I hope you will find some time to give a deeper look to this thread later ;-), meanwhile I'm not giving up: I checked the setSceneData(node) methods and it's basically the same just a camera-addChild(node) call... so I may have the finger on something [as I expected a noticable difference]. I'll keep you informed. regards, Manu. 2008/9/23 Robert Osfield [EMAIL PROTECTED] Hi Manu, I don't have the head for complex emails or logic right now, so I won't five into the details of thread. What does jump out from speed reading this email is why you don't use osgViewer::CompositeViewer with multipler Views as this would totally clear up an ambiguity about what camera each intersection test is made against. Robert. On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello again... I did other tests, my idea was: I have a single main camera displaying a root object [an osg::Group] and this root object contains 5 or 6 osg::Camera object as direct children. And those sub cameras contain pieces of the scene I want to display. Since (I don't know why, but) using an IntersectVisitor gives completely incorrect result on the main camera in that case, I decided to use my intersectionvisitor with each sub camera one by one... in that case everything should behave as if each of my sub camera was the root object when it's
[osg-users] Shaders, osg::notify and IP
Hi all, My colleague was recently doing some debugging and found that when OSG_NOTIFY_LEVEL is INFO or higher all of the shader code comes out as debug. Luckily because of the way the osg::notify code is written we can prevent any slightly osg savvy 3rd party getting hold of my shaders by setting the notify level in the application as the API call overrides the environment variable. However this prevents me from using the notify level as a means of debug in the future. I know that many people consider shaders to be a important part of their IP and so I was wondering what the community thought of this. Should there be a way of preventing this debug being printed out as part of the info? I wouldn't suggest removing it entirely as knowing the shader source ( especially if you have constructed it in code ) can be important to debugging. Cheers, Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shaders, osg::notify and IP
You should be aware that suppressing the debug output is by no means sufficient to protect your shader sources. Any decent OpenGL debugger library can protocol your shader sources from your running application. See http://www.gremedy.com/products.php as an example of an OpenGL debugger. Quotation: View allocated GLSL programs and shaders, their parameters, active uniforms' values and Shaders' source code. regards Ralph Middleton, Colin (GE EntSol, Intelligent Platforms) schrieb: Hi all, My colleague was recently doing some debugging and found that when OSG_NOTIFY_LEVEL is INFO or higher all of the shader code comes out as debug. Luckily because of the way the osg::notify code is written we can prevent any slightly osg savvy 3rd party getting hold of my shaders by setting the notify level in the application as the API call overrides the environment variable. However this prevents me from using the notify level as a means of debug in the future. I know that many people consider shaders to be a important part of their IP and so I was wondering what the community thought of this. Should there be a way of preventing this debug being printed out as part of the info? I wouldn't suggest removing it entirely as knowing the shader source ( especially if you have constructed it in code ) can be important to debugging. Cheers, Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Passing explicitly loaded model to DatabasePager for expiry management
Hi Everyone, I have quick question. We have added simple ReadCallback to osg::IntersectionVisitor to enforce loading of highest PAgedLODs from our terrain. We simply call osgDB::readNodeFile( PageLOD_file ). Intersection works, but it looks like these files are not stored in any cache nor they are actually attached to parent PagedLOD. Is there a way we can add them to DatabasePager loaded model list to avoid further loads of the same file ? Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shaders, osg::notify and IP
Hi Colin, The initial value of NotifyLevel is set from the OSG_NOTIFY_LEVEL env var, which users can set themselves, but your application can set the value via: osg::setNotifyLevel(osg::ALWAYS); Which will make the OSG notification system always ignore all calls to osg::notify(..), this way you can prevent users from changing things. The only way to get round this would be for a user to write a plugin that they force your application to load, then they reset the notification level back to DEBUG and then go trawling. Statically linking would avoid this possibility, as would strictly managing what plugins are loaded and from where. But any of these changes protects a user from tweaking the OpenGL library itself to catch the token stream, OpenGL-ES does provide compiled shaders but OpenGL itself doesn't so it's hard to protect against a determined hacker. Then there is always the law itself, it's legal to reverse engineer in most countries, but there is copyright to protect against actually copy binaries, data and source code, so even if someone did snoop and then reuse your work they would be open to a lawsuit. Robert On Wed, Sep 24, 2008 at 10:46 AM, Middleton, Colin (GE EntSol, Intelligent Platforms) [EMAIL PROTECTED] wrote: Hi all, My colleague was recently doing some debugging and found that when OSG_NOTIFY_LEVEL is INFO or higher all of the shader code comes out as debug. Luckily because of the way the osg::notify code is written we can prevent any slightly osg savvy 3rd party getting hold of my shaders by setting the notify level in the application as the API call overrides the environment variable. However this prevents me from using the notify level as a means of debug in the future. I know that many people consider shaders to be a important part of their IP and so I was wondering what the community thought of this. Should there be a way of preventing this debug being printed out as part of the info? I wouldn't suggest removing it entirely as knowing the shader source ( especially if you have constructed it in code ) can be important to debugging. Cheers, Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Passing explicitly loaded model to DatabasePager for expiry management
HI Wojtek, You could use the osg::Registry object cache for the subgraphs you've loaded. Robert. On Wed, Sep 24, 2008 at 11:45 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Everyone, I have quick question. We have added simple ReadCallback to osg::IntersectionVisitor to enforce loading of highest PAgedLODs from our terrain. We simply call osgDB::readNodeFile( PageLOD_file ). Intersection works, but it looks like these files are not stored in any cache nor they are actually attached to parent PagedLOD. Is there a way we can add them to DatabasePager loaded model list to avoid further loads of the same file ? Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Passing explicitly loaded model to DatabasePagerfor expiry management
Thanks, You could use the osg::Registry object cache for the subgraphs you've loaded. Thanks, We will try to do this. We will call readNodeFile with CACHE_ALL in options. Cheers, Wojtek Robert. On Wed, Sep 24, 2008 at 11:45 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Everyone, I have quick question. We have added simple ReadCallback to osg::IntersectionVisitor to enforce loading of highest PAgedLODs from our terrain. We simply call osgDB::readNodeFile( PageLOD_file ). Intersection works, but it looks like these files are not stored in any cache nor they are actually attached to parent PagedLOD. Is there a way we can add them to DatabasePager loaded model list to avoid further loads of the same file ? Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Passing explicitly loaded model to DatabasePager for expiry management
On Wed, Sep 24, 2008 at 6:45 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Everyone, I have quick question. We have added simple ReadCallback to osg::IntersectionVisitor to enforce loading of highest PAgedLODs from our terrain. We simply call osgDB::readNodeFile( PageLOD_file ). Intersection works, but it looks like these files are not stored in any cache nor they are actually attached to parent PagedLOD. Is there a way we can add them to DatabasePager loaded model list to avoid further loads of the same file ? One option is to implement a cache in the ReadCallback itself, as demonstrated in osgSim/LineOfSight.cpp. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi camera rendering and pick issues
Some more news: I reverted to OSG 2.2 (I have the same problems with that version), and retrieved a full debug support, first I'm trying to solve the latest problem I faced (with the hidden node described in my previous mail), I'm using a scene like that: - Main camera - Root group - Hidden group - Position Attitude Transform - Geode (with a sphere geometry inside). - On the main camera I use a cull mask of 0x1 - on the Hidden group I switch between node mask 0x100 [not visible] and 0x101 [visible] - And my intersectionVisitor still uses the traversal mask 0x100 I went through all the process step by step (now that I retrieved my debug support, thanks god :-) !!!), and the conclusion I have for the moment is: -- This is all a Projection Matrix story - In the BAD case (when I hide the hidden group) my proj matrix has a certain value when I start the call view-computeIntersection(x,y,hits,mask) and this matrix is used in the push_clone() function in IntersectionVisitor::apply(osg::Camera) to create a cloned Intersector (and thus this new LineSegmentIntersector gets an incorrect _start vector and the call IntersectionVisitor::enter(osg::Node) fails when trying to enter the Root group, and no intersection is found !). Now, I tried to put a breakpoint on both Camera::setProjectionMatrix(osg::Matrixf/d ) as this seems to be the only entry point to modify a camera projection matrix... But I just CAN'T get on the point when the good camera projection is *correctly* set !!! is that done some other way ??? I keep investigating, I have no choice any way... regards, Manu. 2008/9/24 Emmanuel Roche [EMAIL PROTECTED] :-(... I'm really going to cry now... Guys, I tried something else and I feel like I'm loosing my mind: Since I cannot pick anything when traversing a sub camera, I tried to build my scene this way: - the main View camera (with cull mask set to 0x1) - my root group - a sub camera (with node mask set to 0x1) - a PositionAttitudeTransform (with a scale set) - an object - An hidden group (with node mask set to 0x100) - a link to the SAME previous PositionAttitudeTransform object. ... With that I still have a proper display (the default node mask is 0x): only my sub camera is rendered and the hidden group is not visible as expected. then for my IntersectionVisitor I obviously use the traversal mask 0x100 : this way I was expecting to traverse my main camera and the hidden group, but none of the sub camera... and guess what ? It's just not working :-( It works if I don't hide my hidden group (giving it a node mask of 0x101, but of course this doesn't make sense considering the goal I have)... So the IntersectionVisitor traversal also depends on the cull mask or something like that ? I could really use some explanations on that... By the way I'm using OSG 2.6... regards, Manu. 2008/9/23 Emmanuel Roche [EMAIL PROTECTED] Okay... I think I tried everything I could think about, unsuccessfully... unfortunately, I'm currently on WinXP with Visual Studio and for some obscure reason, I just cannot get/use the debug symbols from some of the OSG libraries (maybe beacuse I'm accessing those functions introspectively though a Lua release binary ? not sure about all that...) an as a result I cannot go deeper into those tests :-( But I've just discovered a new fact: this is at least partially linked to the scale of my object, I tried the following scene graph: - the main View camera - my root group - a sub camera - a PositionAttitudeTransform (with a scale set) - an object --- then depending on the scale applied in the PositionAttitudeTransform I can pick parts of my object or not : the bigger the scale, the closer to the object I need to be to get some intersections (and I'm not even sure those intersections are correct...). So could there be a scale factor not applied somewhere ?? Or maybe, since my main camera renders no objects its near/far planes are set to minimal values and then those settings are not modified accordingly when going though a sub camera in an intersectionVisitor [this could explain why I cannot select objects if I'm not very very close to them (and depending on their scale)...] ? Is there an other way to render Univers scale + high precision scenes without using multiple cameras as children ??? I did a quick test using ClearNodes and setting the only camera left to DO_NOT_COMPUTE_NEAR_FAR, but the results are not good (it seems to me that the ClearNodes clear the color buffer even when I only set the DEPTH_BUFFER_BIT mask... I really don't get it...). regards, Manu. 2008/9/23 Emmanuel Roche [EMAIL PROTECTED] Hi Robert, unfortunately I don't think this an available option in my current project: our software is already relying quite heavily on our current CompositteViewer / View structure (a view
[osg-users] matrix transformation order
Hi, right now i have a matrix which contains N transformations. One of these is a scale, and i want to modify that scale i call the decompose method of the matrix matrix.decompose(traslation, rotation_quat, scale, scale_orientation); then i modify the scale with the new value and when i try to compose the matrix back i´m not sure about the order of matrix multiplying i should use to get the same transformated object than before with the new scale applied what looks ok to me is osg::Matrix(scale_orientation) * scale * osg::Matrix(rotation_quat) * traslation, but this is not working so if anyone have any idea it will be appreciated i´ve also tried with scale * osg::Matrix(rotation_quat) * traslation the rotation and scale should both be around the object space origin and the original object matrix was built using scale * rotation * translate thanks _ Llega la nueva temporada. Consulta las nuevas tendencias en MSN Estilo http://estilo.es.msn.com/moda/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shaders, osg::notify and IP
It seems that there isn't a good solution to prevent people seeing shader code then, I didn't think of the plugin thing. Even if OSG was made completely secure, it seems that you could get shader source code from OpenGL debuggers ( as Ralph Kern said earlier ). I guess it is just a matter of putting a few simple obstacles ( like not giving away obvious shader source code ) in people's way so that the casual hacker is disuaded. I suppose that all the source files should also have copyright notices for legal reasons too. Cheers, Colin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 24 September 2008 11:52 To: OpenSceneGraph Users Subject: Re: [osg-users] Shaders, osg::notify and IP Hi Colin, The initial value of NotifyLevel is set from the OSG_NOTIFY_LEVEL env var, which users can set themselves, but your application can set the value via: osg::setNotifyLevel(osg::ALWAYS); Which will make the OSG notification system always ignore all calls to osg::notify(..), this way you can prevent users from changing things. The only way to get round this would be for a user to write a plugin that they force your application to load, then they reset the notification level back to DEBUG and then go trawling. Statically linking would avoid this possibility, as would strictly managing what plugins are loaded and from where. But any of these changes protects a user from tweaking the OpenGL library itself to catch the token stream, OpenGL-ES does provide compiled shaders but OpenGL itself doesn't so it's hard to protect against a determined hacker. Then there is always the law itself, it's legal to reverse engineer in most countries, but there is copyright to protect against actually copy binaries, data and source code, so even if someone did snoop and then reuse your work they would be open to a lawsuit. Robert On Wed, Sep 24, 2008 at 10:46 AM, Middleton, Colin (GE EntSol, Intelligent Platforms) [EMAIL PROTECTED] wrote: Hi all, My colleague was recently doing some debugging and found that when OSG_NOTIFY_LEVEL is INFO or higher all of the shader code comes out as debug. Luckily because of the way the osg::notify code is written we can prevent any slightly osg savvy 3rd party getting hold of my shaders by setting the notify level in the application as the API call overrides the environment variable. However this prevents me from using the notify level as a means of debug in the future. I know that many people consider shaders to be a important part of their IP and so I was wondering what the community thought of this. Should there be a way of preventing this debug being printed out as part of the info? I wouldn't suggest removing it entirely as knowing the shader source ( especially if you have constructed it in code ) can be important to debugging. Cheers, Colin. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extracting embedded Textures
Thanks Paul. Yes, I see what you mean. The code does indeed serve as a format spec. I'm going work on Robert's visitor-node suggestion this weekend, but having insight into the underlying format makes things a lot easier. BTW, on the subject of Java/.NET wrappers I've had a lot of success with IKVM in the last year. http://www.ikvm.net/index.html That is, maintaining code in java and compiling the jars into CLR assemblies. I haven't tried it with JNI, but IKVM supports JNI, so it might be possible to maintaining a single OSG wrapper library for both runtimes. IKVM is a great tool, but its important to use it appropriately. I use it for class loaders, and helper classes. I wouldn't use it for rendering. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Speed Sent: Wednesday, September 24, 2008 1:11 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Extracting embedded Textures I almost hate to draw attention to this but just in case it ever matters... For various reasons, I ended up writing some IVE readers in Java. Mostly because I had some .ive files that no version of OSG I had available would load correctly. And partly because this is the sort of thing that feeds an odd manic part of my brain. At any rate, the stuff is implemented to allow code configurable profiles because I was pretty sure I was going to have to hack a non-standard version. The result of which is something that is almost like documentation... in code: http://meta-jb.cvs.sourceforge.net/meta-jb/sandbox/src/java/org/progeeks /osg/io/StandardIveConfiguration.java?revision=1.11view=markup Each supported object type has an individual object profile with field types added (with an optional version designator). I never finished it so there are some objects that aren't defined yet but I got it to the point that it could load all of my own IVE files and I was able to determine more about what was wrong with my bad ones. There have also been some changes in the IVE format that are harder to configure this way (byte ordering changes, etc.)... one day I may even get back to it. Not sure it's at all useful, but it does centrally describe (in a way) the IVE format... with a little translation. Other than that, it's probably only useful to me. :) -Paul Evans, Frank wrote: Thanks once again for the incredibly fast response. Up to now I've been using the OsgDotNet wrappers, so writing a Custom Visitor class means maintaining and updating the wrappers as well. At least, if I understand the solution correctly. I will of course make every effort to leverage the native loader. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, September 23, 2008 12:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Extracting embedded Textures On Tue, Sep 23, 2008 at 5:45 PM, Evans, Frank [EMAIL PROTECTED] wrote: Thanks Robert, grinding through the learning curve now. Getting to the vertices was easy (getVertexArray). Was looking for something similar for image/textures. It's straight forward, just look at the NodeVisitor examples I mentioned. Is there any documentation on the IVE format? A spec file? No there is no spec file, it is not meant to be read in a non native way like an interchanges format such Collada. Given you have a perfectly serviceable loader it'd be madness to try and read it by hand, please just use my suggestion. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Widget and Exception
On Tue, 2008-09-23 at 09:23 +, Julen García wrote: Hello, I have downloaded the 2.6 version and I'm trying to add widget components to my project. All is ok but when I pass the mouse on a 3D object of my scene, an exception occurs Sorry for the late response; I was out of the office yesterday and can only send e-mail from physically inside my office. This bug was fixed in the SVN trunk a week ago. I can e-mail you the patch directly, if you'd like, or you can use trunk. Just let me know. :) I use this function to start my project return osgWidget::createExample(viewer, wm, myScene-getScene()); That is ok? If I use return osgWidget::createExample(viewer, wm); my scene doesn't appears. I've tried to call first viewer.setSceneData(myScene-getScene()); but it doesn't work. Thanks in advance ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Passing explicitly loaded model to DatabasePagerfor expiry management
Hi Again, We tried object cache When Intersection Visitor loads PagedLOD through ReadCallback its used in vistor apply method local scope then ref counter drops to zero so object cache will also free the object just after it was used. (See IntersectionVisitor line 347). It looks like we should attach loaded PagedLOD to some parent to prevent object cache flush. But IntersectVisitor::ReadCallback does not know the parent. One would need to override IntersectVisitor to allow for this. On the other hand osgSim::DatabaseCacheReadCallback works like a local intersection only cache. DatabasePager does not know anything about it. So subsequent read request issued from Cull traversal will actually reload the file even if IntersectionVisitor just loaded it. So we figured out that using both Object cache with osgSim::DatabaseCacheReadCallback may do the trick. There is a chance that DatabaseCacheReadCallback cache will keep PagedLOD for some time in memory making its ref counter non zero what will cause Object cache to keep it as well. Finally when Object cache will keep it, there is a chance that next DatabasePager request will find it in the cache and will not reload from disk. Funny scenario, isn't it ? I wish it was a bit simpler ;-) Cheers, Wojtek - Original Message - From: Glenn Waldron To: OpenSceneGraph Users Sent: Wednesday, September 24, 2008 1:53 PM Subject: Re: [osg-users] Passing explicitly loaded model to DatabasePagerfor expiry management On Wed, Sep 24, 2008 at 6:45 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Everyone, I have quick question. We have added simple ReadCallback to osg::IntersectionVisitor to enforce loading of highest PAgedLODs from our terrain. We simply call osgDB::readNodeFile( PageLOD_file ). Intersection works, but it looks like these files are not stored in any cache nor they are actually attached to parent PagedLOD. Is there a way we can add them to DatabasePager loaded model list to avoid further loads of the same file ? One option is to implement a cache in the ReadCallback itself, as demonstrated in osgSim/LineOfSight.cpp. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi camera rendering and pick issues
Okay, I think I have something here:
I started from my first call on my CompositeViewer::frame()
then we get in renderingTraversals() -- runOperations() [for the Contexts]
-- renderer::cull_draw() --- SceneView::cull() and here we have:
_cullVisitor-setTraversalMask(_cullMask);
bool computeNearFar =
cullStage(getProjectionMatrix(),getViewMatrix(),_cullVisitor.get(),_rendergraph.get(),_renderStage.get());
if (computeNearFar)
{
CullVisitor::value_type zNear =
_cullVisitor-getCalculatedNearPlane();
CullVisitor::value_type zFar =
_cullVisitor-getCalculatedFarPlane();
_cullVisitor-clampProjectionMatrix(getProjectionMatrix(),zNear,zFar);
}
And that's where my latest problem comes from !!! This cull visitor uses the
Cull mask to somehow update the projection matrix... (and sorry, I put
breakpoint on setProjectionMatrix(...) but not on getProjectionMatrix() :-(
I didn't notice the reference this function returns...).
And if I'm lucking this may also explain why everything is messed up when I
use sub cameras: the sub camera graph don't get into this cullstage for the
main camera, do they ? and if not, the main projection gets corrupted the
same way and then since the Root group is not entered, the sub cameras are
not reached any way (or they can be sometimes because of those corrupted
projections) !!! So everything is clear now :-D [I've just made a simple
check with a sub camera instead of an hidden group].
Now that the problem is clarified, the big question is: What's the best
option to achieve the desired behavior (hide a node and still be able to
intersect with it, or use sub cameras) ???
I hope this little monologue may help other people stuck on that issue too
(if any :-) )
regards,
Manu.
2008/9/24 Emmanuel Roche [EMAIL PROTECTED]
Some more news:
I reverted to OSG 2.2 (I have the same problems with that version), and
retrieved a full debug support, first I'm trying to solve the latest problem
I faced (with the hidden node described in my previous mail), I'm using a
scene like that:
- Main camera
- Root group
- Hidden group
- Position Attitude Transform
- Geode (with a sphere geometry inside).
- On the main camera I use a cull mask of 0x1
- on the Hidden group I switch between node mask 0x100 [not visible] and
0x101 [visible]
- And my intersectionVisitor still uses the traversal mask 0x100
I went through all the process step by step (now that I retrieved my debug
support, thanks god :-) !!!), and the conclusion I have for the moment is:
-- This is all a Projection Matrix story
- In the BAD case (when I hide the hidden group) my proj matrix has a
certain value when I start the call view-computeIntersection(x,y,hits,mask)
and this matrix is used in the push_clone() function in
IntersectionVisitor::apply(osg::Camera) to create a cloned Intersector (and
thus this new LineSegmentIntersector gets an incorrect _start vector and the
call IntersectionVisitor::enter(osg::Node) fails when trying to enter the
Root group, and no intersection is found !).
Now, I tried to put a breakpoint on both
Camera::setProjectionMatrix(osg::Matrixf/d ) as this seems to be the only
entry point to modify a camera projection matrix... But I just CAN'T get
on the point when the good camera projection is *correctly* set !!! is
that done some other way ??? I keep investigating, I have no choice any
way...
regards,
Manu.
2008/9/24 Emmanuel Roche [EMAIL PROTECTED]
:-(... I'm really going to cry now...
Guys, I tried something else and I feel like I'm loosing my mind:
Since I cannot pick anything when traversing a sub camera, I tried to
build my scene this way:
- the main View camera (with cull mask set to 0x1)
- my root group
- a sub camera (with node mask set to 0x1)
- a PositionAttitudeTransform (with a scale set)
- an object
- An hidden group (with node mask set to 0x100)
- a link to the SAME previous PositionAttitudeTransform object.
... With that I still have a proper display (the default node mask is
0x): only my sub camera is rendered and the hidden group is not
visible as expected.
then for my IntersectionVisitor I obviously use the traversal mask 0x100 :
this way I was expecting to traverse my main camera and the hidden group,
but none of the sub camera... and guess what ? It's just not working
:-( It works if I don't hide my hidden group (giving it a node mask of
0x101, but of course this doesn't make sense considering the goal I
have)... So the IntersectionVisitor traversal also depends on the cull
mask or something like that ? I could really use some explanations on
that...
By the way I'm using OSG 2.6...
regards,
Manu.
2008/9/23 Emmanuel Roche [EMAIL PROTECTED]
Okay...
I think I tried everything I could think about, unsuccessfully...
unfortunately, I'm currently on WinXP
Re: [osg-users] 2.6.1 release
Hi Paul. I'd like to open this up for testing to anyone willing to help out. Check out 2.6.1 from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneG raph-2.6 snip snip Can you confirm the versions of the 3rd party libraries that you're using with this release please. For info, I've compiled the following from source with Windows XP, VS 2008, and CMake 2.6.1 zlib 1.2.3 lpng 1.2.8 jpeg 6b-4 libtiff 3.8.2 libungif 4.1.4 Freetype 2.3.5 glut 3.7.6 Compilation issues are... 1. The version of LibTiff I have doesn't create a debug version, so CMake issues a warning that says it will use the release version instead. Any suggestions to fix this would be welcome. 2. I get errors with ReaderWriterGif (see below) which suggests that I've either got the wrong version, or I need to edit libgif's makefile to generate something that OSG can use. 3. A tool genwrapper is not recognised (see below for the full error message) I've written up what I've done to compile the 3rd party libs. If it will help, I'll make the notes and the compiled libraries available once these issues are resolved. Gary. -- Build started: Project: Plugins gif, Configuration: RelWithDebInfo Win32 -- Compiling... ReaderWriterGIF.cpp Compiling manifest to resources... Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0 Copyright (C) Microsoft Corporation. All rights reserved. Linking... ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifCloseFile referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetLine referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetImageDesc referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetExtensionNext referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetExtension referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetRecordType referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifOpen referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@std@@ PAH11PAPAVGifImageStream@@@Z) D:\OSG\osg261rc1\bin\RelWithDebInfo\..\osgPlugins-2.6.1\osgdb_gif.dll : fatal error LNK1120: 7 unresolved externals Build log was saved at file://d:\OSG\osg261rc1\src\osgPlugins\gif\osgdb_gif.dir\RelWithDebInfo \BuildLog.htm Plugins gif - 8 error(s), 0 warning(s) -- Build started: Project: wrappers, Configuration: RelWithDebInfo Win32 -- 'genwrapper' is not recognized as an internal or external command, operable program or batch file. Project : error PRJ0002 : Error result 255 returned from 'C:\WINDOWS\system32\cmd.exe'. Build log was saved at file://d:\OSG\osg261rc1\wrappers.dir\RelWithDebInfo\BuildLog.htm wrappers - 1 error(s), 0 warning(s) Build Log Build started: Project: wrappers, Configuration: RelWithDebInfo|Win32 Command Lines Creating temporary file C:\DOCUME~1\U00034~1.WIN\LOCALS~1\Temp\BAT000E8310042088.bat with contents [ @echo off genwrapper -c D:/OSG/osg261rc1/src/osgWrappers/genwrapper.conf -t D:/OSG/osg261rc1/src/osgWrappers/Doxyfile.template -d D:/OSG/osg261rc1 | doxygen - genwrapper -c D:/OSG/osg261rc1/src/osgWrappers/genwrapper.conf -l D:/OSG/osg261rc1 if
[osg-users] bounding box issue
Hi All. I have this very strange issue related to bounding boxes. I derived a class MyDrawable, from osg::Drawable. And I'm trying to make some experiments with it. I have a model containing two objects: - a cylinder, made by a bunch of points, defined as an instance of MyDrawable; - an object made by just one vertex, defined as an instance of MyDrawable. When I try to draw the model, just the cylinder is shown. I implemented the method GetBoundingBox()in MyDrawable. So, obviously, it returns a void BB for the second drawable. Does it depend on the void BB? I mean, does OSG check the dimension of the BB of an object before drawing it, and discard the object if its BB, in screen coords, becomes less than some threshold (expressed in pixels)? I suspect this behavior because, if I try to artificially enlarge the BB of the second drawable, once I zoom in I can see it on the screen. And disappear when I zoom out again. Thank you in advance. Regards, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.6.1 release
You should use the same version as you used with OSG v2.6.0. On Windows, I'm using Mike Weiblen's prebuilt 3rdParty binaries, at svn rev 531. -Paul Hi Paul. I'd like to open this up for testing to anyone willing to help out. Check out 2.6.1 from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/ OpenSceneG raph-2.6 snip snip Can you confirm the versions of the 3rd party libraries that you're using with this release please. For info, I've compiled the following from source with Windows XP, VS 2008, and CMake 2.6.1 zlib 1.2.3 lpng 1.2.8 jpeg 6b-4 libtiff 3.8.2 libungif 4.1.4 Freetype 2.3.5 glut 3.7.6 Compilation issues are... 1. The version of LibTiff I have doesn't create a debug version, so CMake issues a warning that says it will use the release version instead. Any suggestions to fix this would be welcome. 2. I get errors with ReaderWriterGif (see below) which suggests that I've either got the wrong version, or I need to edit libgif's makefile to generate something that OSG can use. 3. A tool genwrapper is not recognised (see below for the full error message) I've written up what I've done to compile the 3rd party libs. If it will help, I'll make the notes and the compiled libraries available once these issues are resolved. Gary. -- Build started: Project: Plugins gif, Configuration: RelWithDebInfo Win32 -- Compiling... ReaderWriterGIF.cpp Compiling manifest to resources... Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0 Copyright (C) Microsoft Corporation. All rights reserved. Linking... ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifCloseFile referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED] td@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetLine referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED] td@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetImageDesc referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED] td@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetExtensionNext referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED] td@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetExtension referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED] td@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifGetRecordType referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED] td@@@std@@ PAH11PAPAVGifImageStream@@@Z) ReaderWriterGIF.obj : error LNK2019: unresolved external symbol __imp__DGifOpen referenced in function unsigned char * __cdecl simage_gif_load(class std::basic_istreamchar,struct std::char_traitschar ,int *,int *,int *,class GifImageStream * *) (?simage_gif_load@@[EMAIL PROTECTED]@[EMAIL PROTECTED] td@@@std@@ PAH11PAPAVGifImageStream@@@Z) D:\OSG\osg261rc1\bin\RelWithDebInfo\..\osgPlugins-2.6.1\osgdb_ gif.dll : fatal error LNK1120: 7 unresolved externals Build log was saved at file://d:\OSG\osg261rc1\src\osgPlugins\gif\osgdb_gif.dir\RelW ithDebInfo \BuildLog.htm Plugins gif - 8 error(s), 0 warning(s) -- Build started: Project: wrappers, Configuration: RelWithDebInfo Win32 -- 'genwrapper' is not recognized as an internal or external command, operable program or batch file. Project : error PRJ0002 : Error result 255 returned from 'C:\WINDOWS\system32\cmd.exe'. Build log was saved at file://d:\OSG\osg261rc1\wrappers.dir\RelWithDebInfo\BuildLog.htm wrappers - 1 error(s), 0 warning(s) Build Log Build started: Project: wrappers, Configuration: RelWithDebInfo|Win32 Command Lines Creating
Re: [osg-users] bounding box issue
Hi Gianluca, The OSG by defaults has small feature culling enabled, try disabling this: viewer.getCamera()-setCullingMode( viewer.getCamera()-getCullingMode() ~ osg::CullSettings::SMALL_FEATURE_CULLING); Robert. On Wed, Sep 24, 2008 at 2:52 PM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi All. I have this very strange issue related to bounding boxes. I derived a class MyDrawable, from osg::Drawable. And I'm trying to make some experiments with it. I have a model containing two objects: - a cylinder, made by a bunch of points, defined as an instance of MyDrawable; - an object made by just one vertex, defined as an instance of MyDrawable. When I try to draw the model, just the cylinder is shown. I implemented the method GetBoundingBox()in MyDrawable. So, obviously, it returns a void BB for the second drawable. Does it depend on the void BB? I mean, does OSG check the dimension of the BB of an object before drawing it, and discard the object if its BB, in screen coords, becomes less than some threshold (expressed in pixels)? I suspect this behavior because, if I try to artificially enlarge the BB of the second drawable, once I zoom in I can see it on the screen. And disappear when I zoom out again. Thank you in advance. Regards, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bounding box issue
Thank you Robert, I will try. Gianluca. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: mercoledì 24 settembre 2008 16.02 To: OpenSceneGraph Users Subject: Re: [osg-users] bounding box issue Hi Gianluca, The OSG by defaults has small feature culling enabled, try disabling this: viewer.getCamera()-setCullingMode( viewer.getCamera()-getCullingMode() ~ osg::CullSettings::SMALL_FEATURE_CULLING); Robert. On Wed, Sep 24, 2008 at 2:52 PM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi All. I have this very strange issue related to bounding boxes. I derived a class MyDrawable, from osg::Drawable. And I'm trying to make some experiments with it. I have a model containing two objects: - a cylinder, made by a bunch of points, defined as an instance of MyDrawable; - an object made by just one vertex, defined as an instance of MyDrawable. When I try to draw the model, just the cylinder is shown. I implemented the method GetBoundingBox()in MyDrawable. So, obviously, it returns a void BB for the second drawable. Does it depend on the void BB? I mean, does OSG check the dimension of the BB of an object before drawing it, and discard the object if its BB, in screen coords, becomes less than some threshold (expressed in pixels)? I suspect this behavior because, if I try to artificially enlarge the BB of the second drawable, once I zoom in I can see it on the screen. And disappear when I zoom out again. Thank you in advance. Regards, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.1/1687 - Release Date: 9/23/2008 6:32 PM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi camera rendering and pick issues
Now, a conclusion on this thread: here is how I solved that issue: I'm
registering all the cameras where I have contain to intersect with, and
then I take them one by one to perform an intersection test, but you need to
modify the view amtrix, projection matrix and viewport (using those from the
main camera), and then I use a modified IntersectionVisitor to correct the
projection matrix before entering a camera. So here it the most important
code parts if someone is interested in introducing that in the core OSG libs
one day (sorry I'm really late on my job, so I don't have time for a
submission right now :-( ).
main function to do some intersection tests:
bool Tools::handleViewIntersections(osgViewer::View * view, double x, double
y)
{
// Bouml preserved body begin 00043B04
if(!view) {
vLog::logError(invalid view object in
tools::handleViewIntersections());
return false;
}
osgUtil::LineSegmentIntersector::Intersections hits;
float local_x, local_y = 0.0;
view-getCameraContainingPosition(x, y, local_x, local_y);
osg::Camera* camera = view-getCamera();
osg::Matrixd pm,vm;
osg::ref_ptrosg::Viewport vp;
osgUtil::LineSegmentIntersector::CoordinateFrame cf =
camera-getViewport() ? osgUtil::Intersector::WINDOW :
osgUtil::Intersector::PROJECTION;
osg::ref_ptr osgUtil::LineSegmentIntersector picker = new
osgUtil::LineSegmentIntersector(cf, local_x, local_y);
vDisplay::DisplayManager::CameraDeq cams =
vDisplay::DisplayManager::getRegisteredCameras(view);
for(vDisplay::DisplayManager::CameraDeq::iterator it = cams.begin(); it
!= cams.end(); ++it) {
//osgUtil::IntersectionVisitor iv(picker.get());
vOGL::ExtendedIntersectionVisitor iv(picker.get());
iv.setFrameStamp(vDisplay::DisplayManager::getViewer()-getFrameStamp());
iv.setTraversalMask(vOGL::PICKABLE);
vm = (*it)-getViewMatrix();
pm = (*it)-getProjectionMatrix();
vp = (*it)-getViewport();
(*it)-setViewMatrix(camera-getViewMatrix());
(*it)-setProjectionMatrix(camera-getProjectionMatrix());
(*it)-setViewport(camera-getViewport());
(*it)-accept(iv);
(*it)-setViewMatrix(vm);
(*it)-setProjectionMatrix(pm);
(*it)-setViewport(vp.get());
if (picker-containsIntersections())
{
hits = picker-getIntersections();
vLog::logInfo(Got %d intersections,hits.size());
return true;
}
}
vLog::logInfo(Got 0 intersections);
return false;
// Bouml preserved body end 00043B04
}
the modified function in my ExtendedIntersectionVisitor:
void ExtendedIntersectionVisitor::apply(osg::Camera camera) {
// Bouml preserved body begin 00043C84
// Use a simplified cull traversal here to correct the projection:
osg::RenderInfo _renderInfo;
_renderInfo.setState(new osg::State);
_renderInfo.setView(camera.getView());
osg::ref_ptrosgUtil::CullVisitor cv = osgUtil::CullVisitor::create();
cv-setTraversalMask(getTraversalMask()); // Use the same mask to
retrieve the good extend of the pickable objects.
osg::ref_ptrosgUtil::RenderStage renderStage = new
osgUtil::RenderStage();
osg::ref_ptrosgUtil::StateGraph rendergraph = new
osgUtil::StateGraph();
cv-setStateGraph(rendergraph.get());
cv-setRenderStage(renderStage.get());
cv-reset();
cv-setFrameStamp(const_castosg::FrameStamp*(getFrameStamp()));
if (getFrameStamp())
{
cv-setTraversalNumber(getFrameStamp()-getFrameNumber());
}
//cv-inheritCullSettings(*this);
cv-setClearNode(NULL); // reset earth sky on each frame.
cv-setStateGraph(rendergraph.get());
cv-setRenderStage(renderStage.get());
cv-setRenderInfo( _renderInfo );
renderStage-reset();
rendergraph-clean();
renderStage-setViewport(camera.getViewport());
renderStage-setClearColor(camera.getClearColor());
renderStage-setClearMask(camera.getClearMask());
renderStage-setCamera(camera);
cv-pushViewport(camera.getViewport());
cv-pushProjectionMatrix(new
osg::RefMatrix(camera.getProjectionMatrix()));
cv-pushModelViewMatrix(new
osg::RefMatrix(camera.getViewMatrix()),osg::Transform::ABSOLUTE_RF);
for(unsigned int childNo=0;
childNocamera.getNumChildren();
++childNo)
{
camera.getChild(childNo)-accept(*cv);
}
cv-popModelViewMatrix();
cv-popProjectionMatrix();
cv-popViewport();
renderStage-sort();
rendergraph-prune();
// Projection correction:
osg::Matrixd proj = camera.getProjectionMatrix();
osgUtil::CullVisitor::value_type zNear = cv-getCalculatedNearPlane();
osgUtil::CullVisitor::value_type zFar = cv-getCalculatedFarPlane();
cv-clampProjectionMatrix(proj,zNear,zFar);
// Normal process:
if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
pushProjectionMatrix( new osg::RefMatrix(proj) );
pushViewMatrix( new
[osg-users] mouse move problem
hi all, I added a pickhandler to vivewer,when something is picked ,I showed a dialog.The problem is when the dialog is closed,the osg scene moved with mouse move.I must click left mouse button to stop it.You know,normally when we move our mouse ,the osg scene will not move.So,how to fix this? thank you! best wishes forest ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shaders, osg::notify and IP
Colin, At last! A genuine requirement for obfuscated C skills! ( http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest) Time to start misusing the GLSL preprocessor... David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mouse move problem
Hello Forest, I added a pickhandler to vivewer,when something is picked ,I showed a dialog.The problem is when the dialog is closed,the osg scene moved with mouse move.I must click left mouse button to stop it.You know,normally when we move our mouse ,the osg scene will not move.So,how to fix this? This is because when your dialog pops up, the focus changes to the dialog, and the mouse button release message is never sent to the graphics window. So when your mouse comes back to it, it still thinks that the left mouse button is pressed. I am having similar issues but have not yet investigated how to fix them. I'm thinking it will be similar to a recent fix in GraphicsWindowWin32 where the keyboard release messages weren't gotten when focus changed. The solution there was to check the keys when focus came back, so I would guess that we also need to check the mouse buttons to make sure correct state is maintained. If you want to look into it yourself, feel free to do so of course :-) I'm not sure when I'll be able to get to it. 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] 2.6.1 release
Sorry if that last email from me appeared a bit curt; I had an appointment and wanted to at least get something off to you before I left my computer. Here's more details... I mentioned I use Mike's prebuilt binaries for Windows. Attached is a batch file from Mike's svn tree that contains the package version numbers. You can compare against your version numbers and see where you might be off. There have been no changes to Mike's tree since OSG's 2.6.0 release. Compilation issues are... Do you have these same issue when you build OSG v2.6 with these dependencies? If so, then these issues aren't specific to 2.6.1 and should not hold up its release. 1. The version of LibTiff I have doesn't create a debug version, so CMake issues a warning that says it will use the release version instead. Any suggestions to fix this would be welcome. I'm not sure why you aren't getting a Debug version of libTiff. Assuming you're on Windows... Many will warn you to not mix Release libs with Debug builds. However, I have found that you can mix them if the library meets two criteria: 1) the library interface must not use STL, and 2) don't mix the heap (don't alloc memory in Release code and free it in Debug, for example). libTiff appears to meet these criteria, as far as I know, so you should be able to mix a Release libTiff with your Debug OSG. 2. I get errors with ReaderWriterGif (see below) which suggests that I've either got the wrong version, or I need to edit libgif's makefile to generate something that OSG can use. See my first comment above. I'm curious if you see this with an OSG v2.6 build. Check the attached file for the version Mike used for his GIF dependency. 3. A tool genwrapper is not recognised (see below for the full error message) Thanks, I'll look into this. I haven't updated or rebuilt the wrappers at all, so they might need to be updated. -Paul REM list of exact 3rdParty source packages REM where products will be installed... set INSTALL_ROOT=%CD%\.. set INSTALL_BIN=%INSTALL_ROOT%\bin set INSTALL_INC=%INSTALL_ROOT%\include set INSTALL_LIB=%INSTALL_ROOT%\lib REM the upstream sources... set DIR_REDIST=C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86 set DIR_REDIST_CRT=%DIR_REDIST%\Microsoft.VC80.CRT set DIR_REDIST_MFC=%DIR_REDIST%\Microsoft.VC80.MFC set DIR_ZLIB=zlib set PKG_ZLIB=%DIR_ZLIB%123.zip set URL_ZLIB=http://www.zlib.net/%PKG_ZLIB% set DIR_PNG=lpng1229 set PKG_PNG=%DIR_PNG%.zip set URL_PNG=http://downloads.sourceforge.net/libpng/%PKG_PNG% set DIR_JPEG=jpeg-6b set PKG_JPEG=jpegsr6.zip set URL_JPEG=ftp://ftp.simtel.net/pub/simtelnet/msdos/graphics/%PKG_JPEG% set DIR_LUA=lua-5.1.3 set PKG_LUA=%DIR_LUA%.tar.gz set URL_LUA=http://www.lua.org/ftp/%PKG_LUA% REM upstream project renamed from libungif to giflib REM set DIR_UNGIF=libungif-4.1.4 REM set PKG_UNGIF=%DIR_UNGIF%.tar.gz REM set URL_UNGIF=http://downloads.sourceforge.net/libungif/%PKG_UNGIF% set DIR_FREETYPE=freetype-2.3.7 set PKG_FREETYPE=ft237.zip set URL_FREETYPE=http://downloads.sourceforge.net/freetype/%PKG_FREETYPE% set DIR_GLUT=glut-3.7.6 set PKG_GLUT=%DIR_GLUT%-src.zip set URL_GLUT=http://www.xmission.com/~nate/glut/%PKG_GLUT% set DIR_TIFF=tiff-3.8.2 set PKG_TIFF=%DIR_TIFF%.zip set URL_TIFF=ftp://ftp.remotesensing.org/pub/libtiff/%PKG_TIFF% set DIR_VRPN=vrpn_07_17 set PKG_VRPN=%DIR_VRPN%.zip set URL_VRPN=ftp://ftp.cs.unc.edu/pub/packages/GRIP/vrpn/%PKG_VRPN% REM TODO - set DIR_CURL=curl-7.18.2 set PKG_CURL=%DIR_CURL%.zip set URL_CURL=http://curl.haxx.se/download/%PKG_CURL% set DIR_GIFLIB=giflib-4.1.6 set PKG_GIFLIB=%DIR_GIFLIB%.tar.gz set URL_GIFLIB=http://downloads.sourceforge.net/giflib/%PKG_GIFLIB% set DIR_PROJ=proj-4.6.0 set PKG_PROJ=%DIR_PROJ%.zip set URL_PROJ=ftp://ftp.remotesensing.org/proj/%PKG_PROJ% set DIR_GDAL=gdal-1.5.2 set PKG_GDAL=gdal152.zip set URL_GDAL=http://download.osgeo.org/gdal/%PKG_GDAL% set DIR_GEOTIFF=libgeotiff-1.2.4 set PKG_GEOTIFF=libgeotiff124.zip set URL_GEOTIFF=ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/%PKG_GEOTIFF% set DIR_GLSLFE=OpenGLCompilerSept202005 set PKG_GLSLFE=%DIR_GLSLFE%.zip set URL_GLSLFE=http://mew.cx/glsl/%PKG_GLSLFE% REM EOF ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question about plane intersections
Gentlemen, Can anyone point me to something that would be useful in OSG for solving the problem of making a set of contour lines similar to those seen on maps? I'd like to provide osg with a plane and get the shape created by the intersection with the plane. Your advice is greatly appreciated. Thanks, John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about plane intersections
Hi John, Can anyone point me to something that would be useful in OSG for solving the problem of making a set of contour lines similar to those seen on maps? I'd like to provide osg with a plane and get the shape created by the intersection with the plane. I'm sure others can provide more mathematically-inclined answers (perhaps even something already in OSG), but I could see doing that by making a shader that draws lines when the world-space Z coordinate is a given value (or a given multiple of a given value, or whatever). Not sure how familiar you are with shader programming, but it should be pretty easy. Of course, if you need the result for other calculations rather than just for display (or if you need it to be arbitrary planes, or other things) this won't work. 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] Question about plane intersections
On Wed, Sep 24, 2008 at 1:02 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Gentlemen, Can anyone point me to something that would be useful in OSG for solving the problem of making a set of contour lines similar to those seen on maps? I'd like to provide osg with a plane and get the shape created by the intersection with the plane. Your advice is greatly appreciated. Thanks, John Argentieri Have you looked into osgUtil::PlaneIntersector? It will return the results of an intersection at a set of polylines. You can then create osg::Geometry from the polylines to visualize it. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about plane intersections
Both very nice ideas. Thanks guys! From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Waldron Sent: Wednesday, September 24, 2008 1:25 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Question about plane intersections On Wed, Sep 24, 2008 at 1:02 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Gentlemen, Can anyone point me to something that would be useful in OSG for solving the problem of making a set of contour lines similar to those seen on maps? I'd like to provide osg with a plane and get the shape created by the intersection with the plane. Your advice is greatly appreciated. Thanks, John Argentieri Have you looked into osgUtil::PlaneIntersector? It will return the results of an intersection at a set of polylines. You can then create osg::Geometry from the polylines to visualize it. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Thanks to OSG !
Hi all, Just a quick message to show you two applications we've just made thanks to OSG : http://www.youtube.com/watch?v=r-ydFPHL2z0 http://www.youtube.com/watch?v=P1VipShcuc0 PS : yeah, it's me on the first video... :) PS2 : for the frenchies here, you can see the walls in real at the CNES Paris (near Chatelet). -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thanks to OSG !
Hi Serge, Just a quick message to show you two applications we've just made thanks to OSG : Wow, really cool stuff! 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] Thanks to OSG !
Pretty amazing Serge! When are you having an iPhone release?;) Jason On Wed, Sep 24, 2008 at 1:38 PM, Serge Lages [EMAIL PROTECTED] wrote: Hi all, Just a quick message to show you two applications we've just made thanks to OSG : http://www.youtube.com/watch?v=r-ydFPHL2z0 http://www.youtube.com/watch?v=P1VipShcuc0 PS : yeah, it's me on the first video... :) PS2 : for the frenchies here, you can see the walls in real at the CNES Paris (near Chatelet). -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thanks to OSG !
Yeah, Serge, really good work! I would also say: thanks to the ImageStreamer functionality ;))) cheers, art --- Serge Lages [EMAIL PROTECTED] schrieb am Mi, 24.9.2008: Von: Serge Lages [EMAIL PROTECTED] Betreff: [osg-users] Thanks to OSG ! An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Datum: Mittwoch, 24. September 2008, 19:38 Hi all, Just a quick message to show you two applications we've just made thanks to OSG : http://www.youtube.com/watch?v=r-ydFPHL2z0 http://www.youtube.com/watch?v=P1VipShcuc0 PS : yeah, it's me on the first video... :) PS2 : for the frenchies here, you can see the walls in real at the CNES Paris (near Chatelet). -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thanks to OSG !
On Wed, 2008-09-24 at 19:38 +0200, Serge Lages wrote: Hi all, Just a quick message to show you two applications we've just made thanks to OSG : http://www.youtube.com/watch?v=r-ydFPHL2z0 http://www.youtube.com/watch?v=P1VipShcuc0 PS : yeah, it's me on the first video... :) PS2 : for the frenchies here, you can see the walls in real at the CNES Paris (near Chatelet). Wow, really cool stuff. Being me, I'm mostly interested in what you used for the UI? Something custom? -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thanks to OSG !
Hi, Nice movie, i will see it at the CNES :) Cedric Serge Lages wrote: Hi all, Just a quick message to show you two applications we've just made thanks to OSG : http://www.youtube.com/watch?v=r-ydFPHL2z0 http://www.youtube.com/watch?v=P1VipShcuc0 PS : yeah, it's me on the first video... :) PS2 : for the frenchies here, you can see the walls in real at the CNES Paris (near Chatelet). -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] loading vrml segfault
This page indicates that OpenInventor only supports VRML 1.0 files. (http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/Plugins) And from my own experience, OpenVRML only supports VRML 2.0 files. Can OSG handle both of these libraries at the same time? I am a little doubtful since the VRML file must be parsed before it can be determined if it is VRML 1.0 or VRML 2.0. And OpenVRML segfaults when trying to load a VRML 1.0 file. Does anyone have any experience supporting both VRML 1.0 and VRML 2.0 file types? Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Huebert Sent: Thursday, September 18, 2008 6:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] loading vrml segfault Hi Ben, I tried your wrl files using osg with the coin3d plugin (alternate for some of what openvrml does) and got predictable results, given your post. When bombing on the Bad.wrl file, coin kindly provided the following: % osgviewer Bad.wrl Coin read error: Unknown field mesh in VRMLShape Occurred at line 5 in Bad.wrl osgviewer: No data loaded Maybe this will help? -bob On Thu, 18 Sep 2008, Ben Axelrod wrote: When I try to load a VRML 1.0 file in OpenSceneGraph, it segfaults. I am using OpenSceneGraph 2.6, and OpenVRML 0.14.3. I have attached the file that causes the segfault, as well as the same file with some minor changes to make it run properly. The segfault happens inside: osgDB::readNodeFile(filename). It would be great if OSG could detect the error, and return properly with an invalid node. But I understand if the fault is inside of OpenVRML. Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about plane intersections
John, If you just want it visually in a map style format, you can texture the hill with a banded texture, generate the texcoordinates based on a texgen node, and then view it in ortho from the top. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgCairo, osgPango
On Thu, 2008-09-18 at 20:54 -0400, Jean-Sébastien Guay wrote: Hi Jeremy, In the hope that my wandering will help someone in the future... Incidentally, I thought this info would be useful to other potential users of your nodekits on Windows, but I can't find an add page button for the wiki on osgpango.googlecode.org... Do new pages need to be added by the project administrator? I never responded to this last week, so I will very shortly. However, I was curious J-S, how far did you get with Windows compilation? I just checked in some substantial changes to SVN 15 minutes ago that improve the quality and API about a million times over... J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
