[osg-users] Many light0 in the same scene ?
Hi everyone, I have a problem with light. Later, my scene should be consist of a multitude of planetary system each lit by a light, and for this reason that I would have several light0. I have also seen the project osgmanylights but this method doesn't suit me. For now, I have done a very simple osg file which display four spheres, two on the left side of the scene and two on the right side. My two lights are also located on both sides of the scene, each in a sphere. I would like use many light0 in my scene but osg display only the last. Here is a screenshot with two light0 : a href=http://imageshack.us;img src= http://img185.imageshack.us/img185/4232/light0sj6.png; border=0 alt=Image Hosted by ImageShack.us//abr/a href= http://g.imageshack.us/img185/light0sj6.png/1/;img src= http://img185.imageshack.us/img185/light0sj6.png/1/w652.png; border=0/a Only the last light0 (one the right) is displayed. I have tried to understand the RenderStage and RenderBin class but for now, still nothing... Regards. miniUnivers.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::ApplicationUsage::setDescription() causes exception 0xC0000005 on Vista
Hi Matt,
I presume you use arguments. rather than arguments- in your code
as the code in your email won't compile and if it somehow did then the
compiler is totally screwed... and the case of the problem.
With the assumption that this is just a typo, the crash is very odd
indeed. The code is all pretty straight forward. The
arguments.getApplicationUsage() should return the
ApplicationUsage::instance(), that is attached in the ArgumentParser
constructor. This has never been reported as an issue before, but
perhaps some how on your system the instance() function is working.
It's worth noting that osg::ApplicationUsage and osg::ArgumentParser
have changed little since 1.2, and the usage example you provide is
similar to the standard OSG examples so is something that is compiled
and run very often by many hundreds of developers working under Vista
without problem.
Given this, I'd guess that the problem is down to issues at your end,
perhaps a problem with mixed OSG lib/dll's, or not setting the correct
options in VS such as mulit-threaded dll's etc.
Robert.
On Thu, Oct 23, 2008 at 6:53 PM, Matt McPheeters [EMAIL PROTECTED] wrote:
Greetings,
Hopefully someone else has already experienced this and has a fix:
We have a command-line viewer program that runs perfectly fine on XP but
crashes almost immediately in main() on a Vista build.
Here is the offending code:
int main( int argc, char **argv )
{
osg::setNotifyLevel( osg::WARN );
osg::ArgumentParser arguments( argc, argv );
arguments-setApplicationName( arguments.getApplicationName() );
arguments-getApplicationUsage()-setDescription(
arguments.getApplication() + is the standard… );// This is the line
that causes the exception.
}
This program is using OSG version 1.2. All of the OSG examples run fine.
In the autos window of Visual Studio 2005 (has already been updated with
Vista-related Service Packs) the local variable arguments contains good
data. If
I declare an instance of osg::ApplicationUsage * and set it equal to
arguments.getApplicationUsage() instead of using it inline it also points
to valid
data, except that its _description member variable is equal to the empty
string because this is where the program crashes.
Also, when the crash occurs, the call stack is in ntdll.dll but there is a
message that reads [Frames below may be incorrect and/or missing, no symbols
loaded for ntdll.dll].
None of this may be relevant, but when you don't know what you are missing
every clue might help. The answer may be as simple as a preprocessor
directive
but I have searched to no avail.
Thanks.
-Matt
___
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] Optimization and lots of objects
Hi Mike, Um... I guess you haven't read the thread about managing ten's of thousands of osg::Box's yesterday So go read the last two days emails as a back ground. In the case of sphere's I'd see if you can get away with point sprites, if you can then this will be the most efficient way forward. Personally I'd create a set of osg::Geometry containing as many points as you have targets, or perhaps even just one to be lazy, and then use point sprites to make this points/or textured targets. Then just update the positions of the points per frame when required. Robert. On Thu, Oct 23, 2008 at 8:40 PM, Mike Greene [EMAIL PROTECTED] wrote: I guess I need to be a little more detailed in my project: I am simulating a vehicle driving down a test range with a sensor looking for targets. As a target is found, I add a geode-shapeDrawable(sphere) for each discovered target. As more hits are made by the sensor, the orientation, position, and scale of each of these spheres can change dynamically. So I have a PAT as the parent of each geode to facilitate the transforms for each target. The problem is frame rate drops significantly as I add more and more targets (I may need up to 1 of them!). I tried using the detailRatio on the sphere to reduce the number of polygons which helped a little, but not significantly. I have also tried using just a six-sided box as representative instead of the sphere, but still saw drastic frame rate drops. The osgStats show that most of the time is spent in the CULL process. My question - is there a better way of handling a large number of objects that must each be individually manipulated dynamically for the duration of the program (i.e., not static)? Im using a fairly Mike Greene ___ 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] Sequence and Problems with the osgsequence Example
HI Alan, Thanks for the update. It doesn't sound like the package is amiss. Robert. On Fri, Oct 24, 2008 at 12:17 AM, Alan Ott [EMAIL PROTECTED] wrote: I don't have access to the configuration I was using last week, so I tried to reproduce the problem on a different computer (running the same OS) but to no avail. I tried the Debug, Release, and even the configurtion in between (where you don't specify either, and get no debug symbols and no optimization), and in every case, it works fine. Last week I was using packages I got from arakhne.org, and in what I did today I compiled from source. I did not try to use the packages today at all. Since it's the last variable, I'm going to blame the packages at this point. Maybe I'll get some time to try them tomorrow to make sure. Thanks for your help, Alan. Alan Ott wrote: Robert, To reproduce the problem, I simply ran the osgsequence example from OSG 2.6.0 in Linux. The sequence example just sticks at the first frame on both sequences. The 2.4.0 version of this example executes the sequences as would be expected. I'll try the 2.6.1 version today and let you know. Alan. Robert Osfield wrote: Hi Alan, osgsequence is working for me. Could you explain your exact steps in recreating the problem in osgsequence so that others can reproduce the problem. If we can get others to reproduce the problem then hopefully we'll be able to see a pattern emerge that can help use home in on what the problem is. W.r.t state needing to be dirtied, this isn't relevant to osg::Sequence as it doesn't have an state, it's just a self contain node, that only affects traversal of the scene graph, not any OpenGL state. Robert. On Wed, Oct 22, 2008 at 6:04 PM, Alan Ott [EMAIL PROTECTED] wrote: Hello, First, I'd like to say Thank You to Robert, Simba, and Chris Denham for helping me with my last problem with the DatabasePager. Chris's suggestion worked great. I just recently upgraded from OSG 2.4 to 2.6 because I needed multisample support for my FrameBuffer Objects. When I did this, everything worked fine execpt for two things which may be related. The first was with osgEphemeris, and I found someone in an archive who was able to fix that problem by making sure that the computed sky texture was marked dirty() when changed. Robert said on the list that it [had] been relying upon an inefficiency in the osg::Texture2D::setImage() method that has now been fixed, so only really worked previously by fluke. This leads me to believe that maybe more efficiency changes were made between OSG 2.4 and 2.6 which could be causing my next problem. The second problem I have is that none of my Sequences seem to work right. I tried a lot of things outside OSG to make it work, and eventually did a diff on the OSG 2.4 version of osg/Sequence.cpp and the OSG 2.6 version to find out that they are identical. The problem goes like this. When I load a model with an Sequence in it, the sequence runs one time. I cannot restart it ever. If I load the model, then find the sequence node and stop it before it's drawn, I can never start the sequence. This worked great in OSG 2.4. So I built the osgsequence example in 2.4 and 2.6, and as I suspected, the 2.4 version of osgsequence works great, but the 2.6 version does not. I'm not sure what the problem is, since like I said, Sequence.cpp hasn't changed at all. My suspicion is that, like the osgEphemeris problem described above, something in 2.6 has been fixed so that it requires notification of a change of state in the Sequence (something like a dirty() being called?). Of course this is only suspicion, and I have not been able to debug it very well. I'm hoping someone who knows the code better than I do will be able to find the problem quickly. So I guess that's it. I think that if the osgsequence example could be made to work, that my sequence problems would be fixed. Thanks for all your help, and again, thank you for Open Scene Graph, Alan. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Many light0 in the same scene ?
HI Kevin, RIght now the way to do multiple lights is to use the OpenGL hardware lights GL_LIGHT0... GL_LIGHT7, must this is limited just one entry per light per RenderStage. To scale up to more lights than 8 then you have use tricks with multiple RenderStage. This topics is rather complex and has been discussed on osg-users alot previously so please search the archives for info on it. Robert. On Fri, Oct 24, 2008 at 8:59 AM, Kévin FAURE [EMAIL PROTECTED] wrote: Hi everyone, I have a problem with light. Later, my scene should be consist of a multitude of planetary system each lit by a light, and for this reason that I would have several light0. I have also seen the project osgmanylights but this method doesn't suit me. For now, I have done a very simple osg file which display four spheres, two on the left side of the scene and two on the right side. My two lights are also located on both sides of the scene, each in a sphere. I would like use many light0 in my scene but osg display only the last. Here is a screenshot with two light0 : a href=http://imageshack.us;img src=http://img185.imageshack.us/img185/4232/light0sj6.png; border=0 alt=Image Hosted by ImageShack.us//abr/a href=http://g.imageshack.us/img185/light0sj6.png/1/;img src=http://img185.imageshack.us/img185/light0sj6.png/1/w652.png; border=0/a Only the last light0 (one the right) is displayed. I have tried to understand the RenderStage and RenderBin class but for now, still nothing... Regards. ___ 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] choppiness on 2nd graphics card with 4 monitors
Hi Joe, I don't personally have any vista machines so I can't test this, or vouche for how well multiple graphics cards will work under Vista, others have got it work, but I don't know whether this includes frame drops. From your description it does sound like a driver issue. Perhaps use the NVidia swap groups extensions might help solve this. What I can say is that I've got a linux system with two graphics cards and four monitors working on linux with good performance and not hiccups like you explain. So you could just dual boot your machine and do a sanity test. Robert. On Thu, Oct 23, 2008 at 10:15 PM, Joe Lyga [EMAIL PROTECTED] wrote: Thanks for the response Robert, I turned V-sync on, and I took some screenshots with the program running full screen. The first image is with the program running on the first or second monitor (hooked up to the first graphics card), and the second image is with the program running on the third or fourth monitor (hooked up to the second graphics card). All 4 monitors are set to the same resolution and refresh rate. I'm not sure how much it's showing up in the stats, but the program running on the third or fourth monitors is noticeably choppy. The frame markers are also in an inconsistent pattern, not always occuring every 16.67 ms vsync. When I'm watching the stats interactively, they appear to be very jumpy. When the program is running on either of the monitors hooked up to the first graphics card, there appears to be a steady 16.67 frame. Any advice? ___ 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] bug report : conflict between osgParticle::Program and osg::Program in osg file
Hello, there is a bug when we use an osg file to create a scene including osgParticle system and a geode using a shader. If the geode and shader code are read before the particle system, it's ok. But if the particle system is read before the geode and the shader, the shader is not read. In fact, the problem seems located in osgdb registry.cpp file. In the function bool Registry::writeObject(const osg::Object obj,Output fw) , we can see a call to loadLibrary(pluginLibraryName) (line 1256) to load all IO informations about osgParticle library which updates _objectWrapperMap. But in this map osg::Program informations is replaced by osgParticle::Program's. So, in the osg file, if osg::program description is read after the particle system, osg can't call the right read function and the shader is not loaded. I join 2 osg files to show the bug. Any idea to solve that ? Thanks in advance Pierre Haritchabalet testConflictShaderOk.osg Description: Binary data testConflictShaderFail.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing movie on OSG for novice
Hi, Ümit Uzun schrieb: QuickTime 7.3 and QuickTime Player 7.3 I am sorry, I don't know what's the problem on your side. I tested the quicktime plugin with Quicktime 7.2 and the newest 7.5 and it works as advertised. Can you test your app/osgmovie on another computer? Stephan. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] choppiness on 2nd graphics card with 4 monitors
Joe, Just out of interest, do you get the same issue with just one monitor connected to each graphics card? ( I'm interested because I _think_ I get something similar in this configuration, but it might be a separate issue). I have the same setup as you (dual 8800, VIsta, etc.) Are you running dwm/Aero? David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Dear Wojciech, J-S, All classes belonging to ViewDependentShadow group derive shaders from StandardShadowMap. If you look at these shaders you will notice that they are split into main vertex and fragment shader and shadow vertex and fragment shader. I saw this. Maybe I'm being daft, but presumably this only helps when you have the SAME shader for the entire shadowed scene? I have a situation where the shadowed objects have a variety of different shaders. If I'm missing something obvious, my apologies. LODs should be properly handled by ViewDependentshadows. Shadow camera uses the same viewpoint as main camera. Shadow Camera ref frame is set to ABSOLUTE_RF_INHERIT_VIEWPOINT. Ah yes. Thanks for pointing that out. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bug report : conflict between osgParticle::Program and osg::Program in osg file
Hi Pierre, Thanks for the simple file examples, with these I'm able to reproduce the problem. I've tracked the bug down to the lack of osgParticle:: qualifiers in from of the Program entry in the osgParticle plugin, adding the qualifier fixes the problem. I have checked the fix into svn/trunk, could you please try it out. Robert. On Fri, Oct 24, 2008 at 9:41 AM, pierre haritchabalet [EMAIL PROTECTED] wrote: Hello, there is a bug when we use an osg file to create a scene including osgParticle system and a geode using a shader. If the geode and shader code are read before the particle system, it's ok. But if the particle system is read before the geode and the shader, the shader is not read. In fact, the problem seems located in osgdb registry.cpp file. In the function bool Registry::writeObject(const osg::Object obj,Output fw) , we can see a call to loadLibrary(pluginLibraryName) (line 1256) to load all IO informations about osgParticle library which updates _objectWrapperMap. But in this map osg::Program informations is replaced by osgParticle::Program's. So, in the osg file, if osg::program description is read after the particle system, osg can't call the right read function and the shader is not loaded. I join 2 osg files to show the bug. Any idea to solve that ? Thanks in advance Pierre Haritchabalet ___ 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] Advice on interacting with osgShadow
David, I saw this. Maybe I'm being daft, but presumably this only helps when you have the SAME shader for the entire shadowed scene? I have a situation where the shadowed objects have a variety of different shaders. If I'm missing something obvious, my apologies. Thats true. But opposite scenario is also possible. You can link your main shaders in your object statesets with shadow shaders from StandardShadowMap. Just grab them from StandardShadowMap via getShadowVertexShader() getShadowFragmentShader(). Make sure to call DynamicShadow functions in proper places of your main vertex shaders to compute shadow texture coords and call DynamicShadow in main fragment to get shadowing term. You may look at StandardShadow main shaders for reference. StandardShadowMap do not apply its shadow program with override attribute so if you actually have the shaders below ShadowedScene your shaders will be used. If you simply make sure call DynamicShadow function from your main you should be well and happy. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The best way to make some object in a scene render after and infront everything else.
Yep, putting the extra post render camera just above the Dragger gives exactly the right visual effect. Yippe! I might try adding a stencil to give it a stipply effect, then it'll look just like Maya, lol. However (note to self: stop using the word 'However'), this gives rise to a new problem. Tthe picking does not seem to work correctly for the Dragger object below the camera. I'm using osgViewer::computeIntersections(). It seems as though it is detecting the intersections with the dragger geometry but not at the screen location where it is drawn, more like around the origin. Just a guess, but it seemed as though computeIntersections was not including the transforms above the camera in the scene? SUMMARY: How do I make osgViewer::computeIntersections work properly for subgraphs below my postrender camera? Chris. - Original Message - From: Chris Denham [EMAIL PROTECTED] To: Robert Osfield [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, October 23, 2008 5:31 PM Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. Robert, Just read you message again realizing that you were suggesting putting the extra camera in the scene immediately above the Dragger node? Yes? I will try it. thanks again. Chris. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping
Hi AC3D plugin users :-) Recently we've had a few submissions of modifications to the ac3d plugin that try to fix texture repeat/clamping behaviour or their own sets of models that they encounter. The problem is that we now have multiple interpretations of what the ac3d plugin should do w.r.t texture repeat/clamping and these conflict, apply one patch and your fix models from source A, but break models from source B, apply another patch and your fix the models B, but break models A. Arggg. So what I'd like to properly resolve this matter. Ideally online descriptions of the format would answer this once and for all: http://www.inivis.com/ac3d/man/ac3dfileformat.html But the following: *texrep %f %f Optional - default 1.0,1.0 . The texture repeat values for the tiling of a texture on an object's surfaces. But it doesn't really say anything about the how the texture wrap modes map to this, if at all. And here lies the problem, the ac3d format doesn't really tell us enough about what OpenGL state to set for textures, one has to guess at what the settings are in ac3d and how they relate to items like texrep, or perhaps there are extra docs hidden away that provide the definitive settings for it. On the ac3d website's sources page it does have an example loader/viewer, perhaps it might be definitive? http://www.inivis.com/resources.html I suggest that we collect together a set of .ac files that demonstrate models where texture repeat is certainly intended and also models where clamp wrapped modes are intended. The mailing list has a limit of 300k per post, so if you can keep your post underneath this then you could post them here, but it'd be better if you can post them online for others to download and test. It'd be great if you could also provide screenshot of how the models should looked if perfectly rendered. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
Hi Cedric, it looks like a very interesting project. What would be the best place to send user related questions? In the gna! page two mailing lists are displayed, but one is for development (animtk-commits) and the other (Animtk-devs) seems like a patch sending list only. El Jueves 23 Octubre 2008ES 22:25:18 Cedric Pinson escribió: Hi all, I am happy to release a new version of animtk, Animtk is an animation toolkit for OpenSceneGraph. Have a look it could interest some of you. Thanks a lot to Jeremy (author of osgPango and osgWidget) who contribe often on this project. The 0.0.9 release drastically simplifies usage for users familiar with OpenSceneGraph http://www.openscenegraph.org by consolidating all of the existing code into a single, standalone NodeKit. Furthermore, all AnimTK-specific data is stored alongside traditional OSG data within a standard OpenSceneGraph http://www.openscenegraph.orgfile (.osg), although support for writing to IVE is not yet complete. The exporter has also been significantly overhauled to fully support this integration of AnimTK and OSG, and is sophisticated enough to replace the old Blender http://blender.org osgexport24.py script, with which many users (particularly Linux users) are accustomed. With time, the Animtk developers are confident that it will morph into a very strong, native OpenSceneGraph http://www.openscenegraph.org Animation Toolkit, filling a space that has long existed in OSG. List of improvements: * new osg Blender http://blender.org exporter (export animation, light, mesh, rigmesh, empty, animation) * new EaseMotion http://www.robertpenner.com/easing/easing_demo.html * improve code to read .osg file with animation inside Animtk EaseMotion http://www.robertpenner.com/easing/easing_demo.html in action with osgPango: * http://animtk.plopbyte.net/osgPango-animtk.wmv Files: * http://download.gna.org/animtk/animtk-0.0.9.tar.gz * http://download.gna.org/animtk/animtk-data-0.0.9.tar.gz The latest version is hosted on a mercurial repository http://hg.plopbyte.net/animtk see more on 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] animtk release 0.0.9
Hi Cedric, It's great to see the project coming along. I've just downloaded and started it to compile, but alas it failed on the osgWidget I have in OpenSceneGraph svn/trunk. Which version of the OSG are you compiling against? I had a look at the COPYING file and the licence is GPL which rather limits it's usage in the OSG community to just the subset that use GPL. Would it be possible to migrate to LGPL or OSGPL license to allow the full community to leverage your work? Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bug report : conflict between osgParticle::Program and osg::Program in osg file
It's ok now, thank you Pierre Haritchabalet 2008/10/24 Robert Osfield [EMAIL PROTECTED] Hi Pierre, Thanks for the simple file examples, with these I'm able to reproduce the problem. I've tracked the bug down to the lack of osgParticle:: qualifiers in from of the Program entry in the osgParticle plugin, adding the qualifier fixes the problem. I have checked the fix into svn/trunk, could you please try it out. Robert. On Fri, Oct 24, 2008 at 9:41 AM, pierre haritchabalet [EMAIL PROTECTED] wrote: Hello, there is a bug when we use an osg file to create a scene including osgParticle system and a geode using a shader. If the geode and shader code are read before the particle system, it's ok. But if the particle system is read before the geode and the shader, the shader is not read. In fact, the problem seems located in osgdb registry.cpp file. In the function bool Registry::writeObject(const osg::Object obj,Output fw) , we can see a call to loadLibrary(pluginLibraryName) (line 1256) to load all IO informations about osgParticle library which updates _objectWrapperMap. But in this map osg::Program informations is replaced by osgParticle::Program's. So, in the osg file, if osg::program description is read after the particle system, osg can't call the right read function and the shader is not loaded. I join 2 osg files to show the bug. Any idea to solve that ? Thanks in advance Pierre Haritchabalet ___ 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] Advice on interacting with osgShadow
Wojtek, Just grab them from StandardShadowMap via getShadowVertexShader() getShadowFragmentShader(). Ah. I missed that. Perils of browsing source via the website, I guess... Thanks, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
Hi Robert, Animtk should compile with osg-2.6 release, i did not test with the svn so i would need to update the code to work with the svn version. I know that the Licence can block some of users, the project was started in GPL. It could change if animtk becomes a part of OpenSceneGraph. There will be a bit code to rewrite, but it's possible. I know that it's a young project, so it's maybe not the time yet to do it, but I guess there will be a way if animtk continue to progress. Cheers, Cedric Robert Osfield wrote: Hi Cedric, It's great to see the project coming along. I've just downloaded and started it to compile, but alas it failed on the osgWidget I have in OpenSceneGraph svn/trunk. Which version of the OSG are you compiling against? I had a look at the COPYING file and the licence is GPL which rather limits it's usage in the OSG community to just the subset that use GPL. Would it be possible to migrate to LGPL or OSGPL license to allow the full community to leverage your work? Cheers, Robert. ___ 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] animtk release 0.0.9
Hi Alberto, I created a user mailing list https://mail.gna.org/listinfo/animtk-users Then it will be for users Cheers, Cedric Alberto Luaces wrote: Hi Cedric, it looks like a very interesting project. What would be the best place to send user related questions? In the gna! page two mailing lists are displayed, but one is for development (animtk-commits) and the other (Animtk-devs) seems like a patch sending list only. El Jueves 23 Octubre 2008ES 22:25:18 Cedric Pinson escribió: Hi all, I am happy to release a new version of animtk, Animtk is an animation toolkit for OpenSceneGraph. Have a look it could interest some of you. Thanks a lot to Jeremy (author of osgPango and osgWidget) who contribe often on this project. The 0.0.9 release drastically simplifies usage for users familiar with OpenSceneGraph http://www.openscenegraph.org by consolidating all of the existing code into a single, standalone NodeKit. Furthermore, all AnimTK-specific data is stored alongside traditional OSG data within a standard OpenSceneGraph http://www.openscenegraph.orgfile (.osg), although support for writing to IVE is not yet complete. The exporter has also been significantly overhauled to fully support this integration of AnimTK and OSG, and is sophisticated enough to replace the old Blender http://blender.org osgexport24.py script, with which many users (particularly Linux users) are accustomed. With time, the Animtk developers are confident that it will morph into a very strong, native OpenSceneGraph http://www.openscenegraph.org Animation Toolkit, filling a space that has long existed in OSG. List of improvements: * new osg Blender http://blender.org exporter (export animation, light, mesh, rigmesh, empty, animation) * new EaseMotion http://www.robertpenner.com/easing/easing_demo.html * improve code to read .osg file with animation inside Animtk EaseMotion http://www.robertpenner.com/easing/easing_demo.html in action with osgPango: * http://animtk.plopbyte.net/osgPango-animtk.wmv Files: * http://download.gna.org/animtk/animtk-0.0.9.tar.gz * http://download.gna.org/animtk/animtk-data-0.0.9.tar.gz The latest version is hosted on a mercurial repository http://hg.plopbyte.net/animtk see more on http://www.plopbyte.net ___ 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] Advice on interacting with osgShadow
Hi David, Btw. Shadow shaders are extremaly simple. Vertex shader simply performs texgen operation on stage 1 to produce shadow tex coords. Fragment shader simply performs texture from shadow map. So generally you may even hardcode these operation into your main shaders. In my company we use some sort of poor man virtualization of OSG GLSL program. At the top of hierarchy we use dummy Shadow shaders which implement nullop DynamicShader (vertex does nothing, fragment returns 1.0 as shadow term) . When Shadowing kicks in these, Shadow shaders are substituted with StandardShadowMap shaders and programs are automatilly rebuilt. That way we can fairly easily activate/ deactivate Shadowing based on user request. Cheers, Wojtek - Original Message - From: David Spilling To: OpenSceneGraph Users Sent: Friday, October 24, 2008 2:59 PM Subject: Re: [osg-users] Advice on interacting with osgShadow Wojtek, Just grab them from StandardShadowMap via getShadowVertexShader() getShadowFragmentShader(). Ah. I missed that. Perils of browsing source via the website, I guess... Thanks, David -- ___ 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] Optimization and lots of objects
Robert Osfield wrote: /Hi Mike, Um... I guess you haven't read the thread about managing ten's of thousands of osg::Box's yesterday So go read the last two days emails as a back ground. In the case of sphere's I'd see if you can get away with point sprites, if you can then this will be the most efficient way forward. Personally I'd create a set of osg::Geometry containing as many points as you have targets, or perhaps even just one to be lazy, and then use point sprites to make this points/or textured targets. Then just update the positions of the points per frame when required. Robert. /Actually, I did read the previous posts. My problem is that I have to dynamically scale the spheres (ellipsoids) as they are representing actual 3D error covariance values that change depending on the number of hits made by the sensor (they typically start out large and get smaller as more accurate measurements are made). And, I have both a in the truck view and a God's Eye view, so the appeance of the ellipsoids will change depending on viewing angle. Would sprites work for this case? I may be out of luck in speeding this up, but just wanted to make sure that there was not a more efficient way that I'm missing. Mike Greene ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
On Fri, 2008-10-24 at 12:55 +0100, Robert Osfield wrote: Hi Cedric, It's great to see the project coming along. I've just downloaded and started it to compile, but alas it failed on the osgWidget I have in OpenSceneGraph svn/trunk. Which version of the OSG are you compiling against? I can resolve this for you if you want, Robert. I help Cedric some with AnimTK and I'm often having to poke at the osgWidget code to get it to compile with my osgWidget branch. ;) I'm glad you're taking a look at it though, it really is cool software. Having skeletal animation (and more!) facilitated through native OSG objects and embedded right into an OSG file just simply rocks. I had a look at the COPYING file and the licence is GPL which rather limits it's usage in the OSG community to just the subset that use GPL. Would it be possible to migrate to LGPL or OSGPL license to allow the full community to leverage your work? Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
Hi Cedric, On Fri, Oct 24, 2008 at 2:06 PM, Cedric Pinson [EMAIL PROTECTED] wrote: Animtk should compile with osg-2.6 release, i did not test with the svn so i would need to update the code to work with the svn version. Thanks for the clarification. Since 2.6 I had to modify a few bits of osgWidget to get the wrappers to compile . The wrappers weren't complete for osgWidget in 2.6. I can make the mods to get things to compile if your wish. I know that the Licence can block some of users, Rather than say block some users, I'd say it's a block for the majority of OSG users. This cuts both ways, not only are the less people who can use your work, they will be less people able to test and contribute to it as well. the project was started in GPL. It could change if animtk becomes a part of OpenSceneGraph. I would love to see a capable animation library as part of the core OSG. But a GPL'd NodeKit would not be possible to merge so either we'd need to duplicate your efforts, just as efforts of Cal + OSG integration had to be duplicated due to one variant being GPL'd. There will be a bit code to rewrite, but it's possible. I know that it's a young project, so it's maybe not the time yet to do it, but I guess there will be a way if animtk continue to progress. Are there parts of GPL'd that you don't have coyright over? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
HI Jeremy, On Fri, Oct 24, 2008 at 2:32 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I can resolve this for you if you want, Robert. I help Cedric some with AnimTK and I'm often having to poke at the osgWidget code to get it to compile with my osgWidget branch. ;) This would be apprecaited. At some point soon I'll need to merge your osgWidget branch into the svn/trunk too, so perhaps this could be coordinated so that AnimTK doesn't end up trying to chase three different variations of osgWidget code. I'm glad you're taking a look at it though, it really is cool software. Having skeletal animation (and more!) facilitated through native OSG objects and embedded right into an OSG file just simply rocks. Another bonus is that one can start important more information from modellers like Maya/Max/Blender as well support for animation features found in Collada. Alround it would be very useful to have a animation NodeKit in the core OSG :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimization and lots of objects
Hi Mike, My guess is you could probably use a vertex shader to combine you compute your scaling required for sprites. Robert. On Fri, Oct 24, 2008 at 2:26 PM, Mike Greene [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Mike, Um... I guess you haven't read the thread about managing ten's of thousands of osg::Box's yesterday So go read the last two days emails as a back ground. In the case of sphere's I'd see if you can get away with point sprites, if you can then this will be the most efficient way forward. Personally I'd create a set of osg::Geometry containing as many points as you have targets, or perhaps even just one to be lazy, and then use point sprites to make this points/or textured targets. Then just update the positions of the points per frame when required. Robert. Actually, I did read the previous posts. My problem is that I have to dynamically scale the spheres (ellipsoids) as they are representing actual 3D error covariance values that change depending on the number of hits made by the sensor (they typically start out large and get smaller as more accurate measurements are made). And, I have both a in the truck view and a God's Eye view, so the appeance of the ellipsoids will change depending on viewing angle. Would sprites work for this case? I may be out of luck in speeding this up, but just wanted to make sure that there was not a more efficient way that I'm missing. Mike Greene ___ 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] Qt 3 problems
Dear all, I have a problem constructing the QOSGWidget from osgviewerQT as a child widget. I'm using Qt 3.3 on Ubuntu 8.04 and OSG trunk. I get the following error: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x368 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 Minor opcode: 0 Resource id: 0x368 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 Minor opcode: 0 Resource id: 0x368 While the window shows up properly, it seems the geometry is rendered on a one pixel wide strip in the middle instead of using the whole width. The same happens with Ubuntu's OSG package, which is 2.4. If I run the QOSGWidget as a top level widget, it works just fine. Any ideas? Cheers, Max Pfingsthorn ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animtk release 0.0.9
On Fri, 2008-10-24 at 14:42 +0100, Robert Osfield wrote: HI Jeremy, On Fri, Oct 24, 2008 at 2:32 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I can resolve this for you if you want, Robert. I help Cedric some with AnimTK and I'm often having to poke at the osgWidget code to get it to compile with my osgWidget branch. ;) This would be apprecaited. At some point soon I'll need to merge your osgWidget branch into the svn/trunk too, so perhaps this could be coordinated so that AnimTK doesn't end up trying to chase three different variations of osgWidget code. Yeah, lets do that soon. I'm in the middle of a ton of changes, and I'll be sure and let you know when they're done. I'm working on finishing the Input example (which finally works now, yay!) and implementing an alternate rendering mode in which the GUI isn't sorted by it's Z value (and then flattened by the orthographic view so that you can't tell) but instead has it's RenderBin number set so that it is rendered appropriately and in the right order. This complicates picking, somewhat, but once I work that out I'll be done with that particular issue. I'm glad you're taking a look at it though, it really is cool software. Having skeletal animation (and more!) facilitated through native OSG objects and embedded right into an OSG file just simply rocks. Another bonus is that one can start important more information from modellers like Maya/Max/Blender as well support for animation features found in Collada. Alround it would be very useful to have a animation NodeKit in the core OSG :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Lighted baked models....
Hi all, i have some model to test with light baked textures, the model is in the .MAX file format, and now i would like to convert it into a openscenegraph model. unfort. the model was created with MAX 2009 and so the osg max plugin may doesn't work. so i can export the model to collada : 3ds : wavefront obj : what would be the best format with the most different texture supported. i have baked textures (light and color), then reflections maps. with wavefront obj i get some bug, not supported texture layer for the reflection map. what are your experiences with such models -adrian -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] multiple texture mix with glsl
Hi,
I assign two geometry (same vertex) with two texture and want to blend them by
glsl. The problem is even I get the texture sampler and use function mix to mix
them, Then still cannot be blended together.
as:
uniform sampler2D baseTexture;\n
uniform sampler2D shadowTexture;\n
void main(void)\n
{\n
vec3 ct;\n
vec3 basetexel, texel, color;\n
basetexel = vec3(texture2D(baseTexture,gl_TexCoord[0].st).r);\n
texel = texture2D(shadowTexture,gl_TexCoord[1].st).rgb;\n
color = mix(texel, basetexel, basetexel.r);\n
gl_FragColor = vec4(color, 1.0);\n
}\n
Thanks for any help.
Hui
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple texture mix with glsl
Hi Hui,
I am not sure but try to use same gl_TexCoord[0].st for all texture2D
operation. I mean use gl_TexCoord[0].st again instead of gl_TexCoord[1].st
Or try to put 0.5 instead of basetexel.r. Maybe basetexel.r value always
approximates to 1.0 and then you can't see the mixed texture.
HTH
Umit Uzun
2008/10/24 hui [EMAIL PROTECTED]
Hi,
I assign two geometry (same vertex) with two texture and want to blend them
by glsl. The problem is even I get the texture sampler and use function mix
to mix them, Then still cannot be blended together.
as:
uniform sampler2D baseTexture;\n
uniform sampler2D shadowTexture;\n
void main(void)\n
{\n
vec3 ct;\n
vec3 basetexel, texel, color;\n
basetexel = vec3(texture2D(baseTexture,gl_TexCoord[0].st).r);\n
texel = texture2D(shadowTexture,gl_TexCoord[1].st).rgb;\n
color = mix(texel, basetexel, basetexel.r);\n
gl_FragColor = vec4(color, 1.0);\n
}\n
Thanks for any help.
Hui
___
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] choppiness on 2nd graphics card with 4 monitors
Yes, with one monitor hooked up to each graphics card I'm still getting the same effect. The same goes with one monitor hooked up to the first and two on the second. However, if I only have monitors hooked up to the second graphics card, then the performance is as good as when I'm running it on just the first graphics card monitors. On Fri, Oct 24, 2008 at 4:56 AM, David Spilling [EMAIL PROTECTED]wrote: Joe, Just out of interest, do you get the same issue with just one monitor connected to each graphics card? ( I'm interested because I _think_ I get something similar in this configuration, but it might be a separate issue). I have the same setup as you (dual 8800, VIsta, etc.) Are you running dwm/Aero? David ___ 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] animtk release 0.0.9
Hi Robert, Robert Osfield wrote: Hi Cedric, On Fri, Oct 24, 2008 at 2:06 PM, Cedric Pinson [EMAIL PROTECTED] wrote: Animtk should compile with osg-2.6 release, i did not test with the svn so i would need to update the code to work with the svn version. Thanks for the clarification. Since 2.6 I had to modify a few bits of osgWidget to get the wrappers to compile . The wrappers weren't complete for osgWidget in 2.6. I can make the mods to get things to compile if your wish. I know that the Licence can block some of users, Rather than say block some users, I'd say it's a block for the majority of OSG users. This cuts both ways, not only are the less people who can use your work, they will be less people able to test and contribute to it as well. the project was started in GPL. It could change if animtk becomes a part of OpenSceneGraph. I would love to see a capable animation library as part of the core OSG. But a GPL'd NodeKit would not be possible to merge so either we'd need to duplicate your efforts, just as efforts of Cal + OSG integration had to be duplicated due to one variant being GPL'd. Putting animtk in osg is not a big amount of work. There are only a a few lines to rewrite if needed. Tell me if you are agree, and i will prepare the code for it. Cedric There will be a bit code to rewrite, but it's possible. I know that it's a young project, so it's maybe not the time yet to do it, but I guess there will be a way if animtk continue to progress. Are there parts of GPL'd that you don't have coyright over? Robert. ___ 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] animtk release 0.0.9
On Fri, 2008-10-24 at 12:55 +0100, Robert Osfield wrote:
Hi Cedric,
It's great to see the project coming along. I've just downloaded and
started it to compile, but alas it failed on the osgWidget I have in
OpenSceneGraph svn/trunk. Which version of the OSG are you compiling
against?
Here is a version of the file that will compile against SVN (the only
problem was the change from Object::cloneAs to the template clone()
method).
Also, you'll need to change the IMAGE_PREFIX to something so that the
viewer can find the images it needs; maybe /tmp, or something like that.
We'll work a better solution for that later, as it is largely my own bug
(not one Cedric introduced :))
I had a look at the COPYING file and the licence is GPL which rather
limits it's usage in the OSG community to just the subset that use
GPL. Would it be possible to migrate to LGPL or OSGPL license to
allow the full community to leverage your work?
Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
/* -*-c++-*-
* Copyright (C) 2008 Cedric Pinson [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program 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
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Authors:
*
* Cedric Pinson [EMAIL PROTECTED]
* jeremy Moles [EMAIL PROTECTED]
*
*/
#include AnimtkViewer
#include AnimtkViewerGUI
#include osgWidget/WindowManager
#include osgATK/EaseMotion
#define IMAGE_PREFIX /home/cubicool/local/share
const std::string IMAGE_PATH = IMAGE_PREFIX /AnimtkViewer/;
template class T
struct Sampler: public osg::Drawable::UpdateCallback {
T _motion;
Sampler() {
}
};
typedef SamplerosgATK::LinearMotion WidgetSampler;
struct ButtonFunctor: public WidgetSampler {
float _direction;
float _previous;
const float _speed;
ButtonFunctor(): _speed(5) { _direction = -_speed; _previous = 0;}
bool enter(osgWidget::Event ev)
{
_direction = _speed;
return true;
}
bool leave(osgWidget::Event ev)
{
_direction = -_speed;
return true;
}
void update(osg::NodeVisitor* nv , osg::Drawable* geom)
{
const osg::FrameStamp* f = nv-getFrameStamp();
float dt = f-getSimulationTime() - _previous;
_previous = f-getSimulationTime();
update(dt,dynamic_castosgWidget::Widget*(geom));
}
void update(float t, osgWidget::Widget* w)
{
if (!w) return;
_motion.update(t*_direction);
float val = _motion.getValue()*0.5;
val += 0.5;
if (val = 1.0)
val = 1.0;
w-setColor(osg::Vec4(val, val, val, 1));
}
};
struct LabelFunctor: public WidgetSampler {
float _previous;
bool _active;
const float _fadeOutTime;
osgATK::OutCubicMotion _scaleSampler;
LabelFunctor():
_fadeOutTime(1.5f) {
_previous = 0.0f;
_active = false;
_scaleSampler = osgATK::OutCubicMotion(0.5, 1.0, 1.0);
}
void setActive(bool active) {
_active = active;
if(active) _motion.reset();
_scaleSampler.reset();
}
void update(osg::NodeVisitor* nv , osg::Drawable* geom) {
const osg::FrameStamp* f = nv-getFrameStamp();
float st = f-getSimulationTime();
float dt = st - _previous;
_previous = st;
if(!_active) return;
update(dt, dynamic_castosgWidget::Label*(geom));
updateScale(dt, dynamic_castosgWidget::Label*(geom));
}
void update(float t, osgWidget::Label* w) {
if(!w) return;
_motion.update(t / _fadeOutTime);
float val = _motion.getValue();
if(val = 1.0f) {
_motion.reset();
_active = false;
}
w-setFontColor(osg::Vec4(0.0f, 0.0f, 0.0f, (1.0f - val) * 0.7f));
}
void updateScale(float t, osgWidget::Label* w) {
_scaleSampler.update(t);
float val = _scaleSampler.getValue();
osgWidget::Window* win = w-getParent();
win-setScale(val);
win-update();
}
};
struct ListFunctor: public osg::NodeCallback {
float _previous;
int _direction;
osgATK::LinearMotion _transformSampler;
ListFunctor() {
_direction = 1;
_previous = 0;
_transformSampler.update(1.0f);
}
void toggleShown() {
if(_direction == 1) _direction = -1;
else _direction = 1;
}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv) {
const osg::FrameStamp* f = nv-getFrameStamp();
float st = f-getSimulationTime();
float dt = st - _previous;
_previous = st;
_transformSampler.update((dt * _direction) / 0.5f);
Re: [osg-users] animtk release 0.0.9
Hi Cedric,
On Fri, Oct 24, 2008 at 3:36 PM, Cedric Pinson [EMAIL PROTECTED] wrote:
Putting animtk in osg is not a big amount of work. There are only a a few
lines to rewrite if needed. Tell me if you are agree, and i will
prepare the code for it.
I'm certainly open to this prospect. I first need to get animtk
compiled up, tested and fully reviewed. I'd also be very useful for
the community to dive and help test the library.
A quick code review there a couple of items that could do with
resolving prior to any merge.
1) I can't spot any export symbols for classes + functions, this
will certainly break the Windows build
2) osgATK is a bit cryptic a name, I'd guess it is means something
osgAnimationToolKit.
Previously I've talked on osg-users about an mythical
osgAnimation NodeKit that would be nice to have,
and a reviewing of osgATK suggests that it's no longer mythical,
but something very real ;-)
3) On merge with the OSG I'd have to reformat the source code to fit
in with the core OSG style, items like
four spaces for tabbing, and placing opening { on a newline to
help space out the code to make it easier
to read.
4) Contains even less doxygen comments that the core OSG.
These are all pretty easy to change/fix, an in general the code looks
like it would be very straight forward to merge.
Robert.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighted baked models....
Hi Adrian, I've had numerous problems getting models from Max into the OSG. The OSGs 3DS loader gives very different results depending on how you've created the model in Max. I'm not sure whether that's the loaders fault or Max but either way it's very unreliable. Furthermore I found that the built in Collada exporter in Max is just as temperamental with the ColladaDOM loader that the OSG uses. So... after much clawing and gnashing of teeth I found this little beauty: http://www.feelingsoftware.com/content/view/65/79 It's a freeware Collada exporter for MAX 2008 and that works every time. I believe someone has compiled a version that works with 2009 which you can find here. However, I've not tried it. http://techarttiki.blogspot.com/2008/08/colladamax-for-3ds-max-2009-64-b it.html Hope that's of some use. Kim. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: 24 October 2008 15:41 To: OpenSceneGraph Users Subject: [osg-users] Lighted baked models Hi all, i have some model to test with light baked textures, the model is in the .MAX file format, and now i would like to convert it into a openscenegraph model. unfort. the model was created with MAX 2009 and so the osg max plugin may doesn't work. so i can export the model to collada : 3ds : wavefront obj : what would be the best format with the most different texture supported. i have baked textures (light and color), then reflections maps. with wavefront obj i get some bug, not supported texture layer for the reflection map. what are your experiences with such models -adrian -- Adrian Egli * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighted baked models....
Kim C Bale wrote: So... after much clawing and gnashing of teeth I found this little beauty: http://www.feelingsoftware.com/content/view/65/79 It’s a freeware Collada exporter for MAX 2008 and that works every time. I believe someone has compiled a version that works with 2009 which you can find here. However, I’ve not tried it. I was going to suggest the Collada route via the Feeling Software exporter as well. It's far and away the best Collada exporter for MAX that I've used (I've tried a few). I'm 90% confident that all of the information you need will make it into the .dae file from MAX. I'm not sure how well OSG's Collada loader will deal with it, but at least you have the code to fix it, if necessary :-) Just a heads-up... When you go to export from MAX, make sure you use the Feeling Software exporter, and not the Autodesk FBX/Collada exporter. That cost me about an hour one time. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problems with RTT-cameras when changing window size
Hi, I have a little problem with some Render-To-Texture-cameras in connection with a WindowSizeHandler. I took a bit of code out of an application I wrote earlier to put it into a lib and make the functions usable for other apps. When testing this lib with a simple example program consisting of a simple viewer I suddenly have issues when changing the window size of the viewer window - something that didn't happen in the old application. I tried to adjust the parameters of my example viewer to the ones used in the original application but I still get the error so I cannot really find out what caused the problem. It only occurs when making the window bigger then the original size - the originally set size the RTT-cameras where initialized with. I get the following error repeatly: Warning: detected OpenGL error 'invalid value' after applying attribute Viewport 01A56A88 I use the standard WindowSizeHandler. It's really strange that I didn't get the error in the original application. What also is weird is that it isn't connected to simply enlarging the window but only occurs if the window gets bigger than it was originally. Making the window smaller works fine. Has anyone experience with this error message and knows what may be the reason? I know that it must be connected with my RTT-cameras since it disappears if I take them out. Any hint would be appreciated. Thanks, Steffen __ Run, Fatboy, Run sowie Rails Ties kostenlos anschauen! Blockbuster-Gutscheine sichern unter http://www.blockbuster.web.de ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with RTT-cameras when changing window size
Hi Steffen, Could you provide more info about your viewer/scene graph setup. For instance are RTT Camera's part of the Viewer or part of the scene graph? Also are the RTT Camera's FBO or Pbuffer or frame buffer based? Robert. On Fri, Oct 24, 2008 at 5:11 PM, Steffen Kim [EMAIL PROTECTED] wrote: Hi, I have a little problem with some Render-To-Texture-cameras in connection with a WindowSizeHandler. I took a bit of code out of an application I wrote earlier to put it into a lib and make the functions usable for other apps. When testing this lib with a simple example program consisting of a simple viewer I suddenly have issues when changing the window size of the viewer window - something that didn't happen in the old application. I tried to adjust the parameters of my example viewer to the ones used in the original application but I still get the error so I cannot really find out what caused the problem. It only occurs when making the window bigger then the original size - the originally set size the RTT-cameras where initialized with. I get the following error repeatly: Warning: detected OpenGL error 'invalid value' after applying attribute Viewport 01A56A88 I use the standard WindowSizeHandler. It's really strange that I didn't get the error in the original application. What also is weird is that it isn't connected to simply enlarging the window but only occurs if the window gets bigger than it was originally. Making the window smaller works fine. Has anyone experience with this error message and knows what may be the reason? I know that it must be connected with my RTT-cameras since it disappears if I take them out. Any hint would be appreciated. Thanks, Steffen __ Run, Fatboy, Run sowie Rails Ties kostenlos anschauen! Blockbuster-Gutscheine sichern unter http://www.blockbuster.web.de ___ 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] animtk release 0.0.9
Hi Robert,
Yes i guess i would need to add export in order it compiles on windows.
But i dont have this system, i can't test.
Yes osgATK mean osg animation toolkit, maybe we could rename for
osgAnimation ? it sounds better and feels
with what it is.
Yes i hope osgATK could be osgAnimation :)
Just tell me how do you prefer we proceed. I will start to change the
code for osg style first.
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
On Fri, Oct 24, 2008 at 3:36 PM, Cedric Pinson [EMAIL PROTECTED] wrote:
Putting animtk in osg is not a big amount of work. There are only a a few
lines to rewrite if needed. Tell me if you are agree, and i will
prepare the code for it.
I'm certainly open to this prospect. I first need to get animtk
compiled up, tested and fully reviewed. I'd also be very useful for
the community to dive and help test the library.
A quick code review there a couple of items that could do with
resolving prior to any merge.
1) I can't spot any export symbols for classes + functions, this
will certainly break the Windows build
2) osgATK is a bit cryptic a name, I'd guess it is means something
osgAnimationToolKit.
Previously I've talked on osg-users about an mythical
osgAnimation NodeKit that would be nice to have,
and a reviewing of osgATK suggests that it's no longer mythical,
but something very real ;-)
3) On merge with the OSG I'd have to reformat the source code to fit
in with the core OSG style, items like
four spaces for tabbing, and placing opening { on a newline to
help space out the code to make it easier
to read.
4) Contains even less doxygen comments that the core OSG.
These are all pretty easy to change/fix, an in general the code looks
like it would be very straight forward to merge.
Robert.
Robert.
___
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] animtk release 0.0.9
Hi Robert,
Ok i changed the code to fit the osg coding style. if you want to look at it
http://hg.plopbyte.net/animtk/file/0acae4280750
or get the repo:
hg clone http://hg.plopbyte.net/animtk
Cheers,
Cedric
Cedric Pinson wrote:
Hi Robert,
Yes i guess i would need to add export in order it compiles on
windows. But i dont have this system, i can't test.
Yes osgATK mean osg animation toolkit, maybe we could rename for
osgAnimation ? it sounds better and feels
with what it is.
Yes i hope osgATK could be osgAnimation :)
Just tell me how do you prefer we proceed. I will start to change the
code for osg style first.
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
On Fri, Oct 24, 2008 at 3:36 PM, Cedric Pinson
[EMAIL PROTECTED] wrote:
Putting animtk in osg is not a big amount of work. There are only a
a few
lines to rewrite if needed. Tell me if you are agree, and i will
prepare the code for it.
I'm certainly open to this prospect. I first need to get animtk
compiled up, tested and fully reviewed. I'd also be very useful for
the community to dive and help test the library.
A quick code review there a couple of items that could do with
resolving prior to any merge.
1) I can't spot any export symbols for classes + functions, this
will certainly break the Windows build
2) osgATK is a bit cryptic a name, I'd guess it is means something
osgAnimationToolKit.
Previously I've talked on osg-users about an mythical
osgAnimation NodeKit that would be nice to have,
and a reviewing of osgATK suggests that it's no longer mythical,
but something very real ;-)
3) On merge with the OSG I'd have to reformat the source code to fit
in with the core OSG style, items like
four spaces for tabbing, and placing opening { on a newline to
help space out the code to make it easier
to read.
4) Contains even less doxygen comments that the core OSG.
These are all pretty easy to change/fix, an in general the code looks
like it would be very straight forward to merge.
Robert.
Robert.
___
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
[osg-users] Problems flattening static transforms
Hi all -- I have a scene graph containing multiple static transforms. My application runs the osgUtil::Optimizer on this scene graph. This should flatten all the static transforms. Unfortunately, the result is that all the transforms flatten _except_ for the top level transform. If I do an osgconv on this same scene graph, all the static transforms flatten -- they are converted to Group nodes, and their transformations are folded into the geometry. Clearly, the issue isn't with the scene graph itself, but it's something my app is doing wrong when it invokes the Optimizer. My dilemma: why doesn't this work properly for osgconv, but not for my app? I have dug into this for quite some time now, trying to uncover the difference between osgconv (which works) and my code (which doesn't work). Here's what I know so far: * I've written a small test app to try to reproduce the problem. It loads the scene graph, runs the Optimizer, and writes the scene graph back out. Unfortunately, it works properly, just like osgconv. It flattens all the transforms. I'm unable to reproduce the problem in anything other than my (larger) application. This must be a bug in my code, I must be doing something wrong. * I have verified that the problem is not non-STATIC transforms, multiple parents, or ProxyNodes. The same scene graph works fine in osgconv and my little test app, so it isn't a scene graph issue. I believe my app handles the scene graph the same as in these other two apps, which work. * Yes I'm invoking the Optimizer the same way, with no flags. I'm sure that the OSG_OPTIMIZER variable is not set in the environment. I get the same behavior if I just pass the FLATTEN_STATIC_TRANSFORMS flag (top level node fails to flatten). If I set OSG_OPTIMIZER=FLATTEN_STATIC_TRANSFORMS and run osgconv, it still works properly and flattens all transforms. * ObjectStruct has a Boolean called _moreThanOneMatrixRequired. In my app, this gets set to true at Optimizer.cpp line 826. This doesn't happen when running osgconv or my small test code. This seems to be part of the problem, but the root cause that triggers this event is still unknown to me. I'll attach the scene graph in question, though I doubt it will do anyone much good, because it works fine in osgconv and my simple test app. It only fails in my larger app. Note the top level Node named CenterOfMassOffset; this is the transform that refuses to flatten. I'm wondering if anyone has encountered the same issue before, has any info on how to resolve the issue, or might know how to proceed with debugging it. Notify level DEBUG_INFO does not produce any enlightening information. I admit I'm stumped on this one. It's extremely out of the ordinary when OSG doesn't just do what I expect it to. I appreciate any info. Thanks, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 out1.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] choppiness on 2nd graphics card with 4 monitors
Hi Robert, I'll look into the Nvidia swap groups extensions. Unfortunately, I'm stuck with Vista since it is a custom machine under warranty. I'll try loading up a linux live cd to see if I can produce similar results with osg-viewer. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems flattening static transforms
Hi Paul, I'm just online briefly so I'll give you my first thought as what is amiss. Optimizer::optimize() method takes a reference to the scene graph to optimize, this means that it can't change it's type, so it can't flatten it. If you place a Group above it and then optimize it'll be able to optimize the node away. One could possibly write an additional method that takes a pointer to a scene graph node and then return the new scene graph with potentially a new root node. For compatibility we'd need to keep the present one. Robert. On Fri, Oct 24, 2008 at 8:24 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- I have a scene graph containing multiple static transforms. My application runs the osgUtil::Optimizer on this scene graph. This should flatten all the static transforms. Unfortunately, the result is that all the transforms flatten _except_ for the top level transform. If I do an osgconv on this same scene graph, all the static transforms flatten -- they are converted to Group nodes, and their transformations are folded into the geometry. Clearly, the issue isn't with the scene graph itself, but it's something my app is doing wrong when it invokes the Optimizer. My dilemma: why doesn't this work properly for osgconv, but not for my app? I have dug into thisu for quite some time now, trying to uncover the difference between osgconv (which works) and my code (which doesn't work). Here's what I know so far: * I've written a small test app to try to reproduce the problem. It loads the scene graph, runs the Optimizer, and writes the scene graph back out. Unfortunately, it works properly, just like osgconv. It flattens all the transforms. I'm unable to reproduce the problem in anything other than my (larger) application. This must be a bug in my code, I must be doing something wrong. * I have verified that the problem is not non-STATIC transforms, multiple parents, or ProxyNodes. The same scene graph works fine in osgconv and my little test app, so it isn't a scene graph issue. I believe my app handles the scene graph the same as in these other two apps, which work. * Yes I'm invoking the Optimizer the same way, with no flags. I'm sure that the OSG_OPTIMIZER variable is not set in the environment. I get the same behavior if I just pass the FLATTEN_STATIC_TRANSFORMS flag (top level node fails to flatten). If I set OSG_OPTIMIZER=FLATTEN_STATIC_TRANSFORMS and run osgconv, it still works properly and flattens all transforms. * ObjectStruct has a Boolean called _moreThanOneMatrixRequired. In my app, this gets set to true at Optimizer.cpp line 826. This doesn't happen when running osgconv or my small test code. This seems to be part of the problem, but the root cause that triggers this event is still unknown to me. I'll attach the scene graph in question, though I doubt it will do anyone much good, because it works fine in osgconv and my simple test app. It only fails in my larger app. Note the top level Node named CenterOfMassOffset; this is the transform that refuses to flatten. I'm wondering if anyone has encountered the same issue before, has any info on how to resolve the issue, or might know how to proceed with debugging it. Notify level DEBUG_INFO does not produce any enlightening information. I admit I'm stumped on this one. It's extremely out of the ordinary when OSG doesn't just do what I expect it to. I appreciate any info. Thanks, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems flattening static transforms
Thanks for the quick reply, Robert. It's really the flattening that I require, and not necessarily the type change. For example, I see that osgconv doesn't change the type of the top level Transform node, but it does flatten it so that its transform is the identity. In my app, however, this top level transform is simply not flattened; the matrix is still non-identity. To be pedantic, I added a top level Group above my (previous) top level Transform. In my app, this Transform remains unflattened. My app maintains other ref_ptrs into this scene graph, could this be the problem? To check, I set a breakpoint in Referenced::referenceCount() just before calling optimize(). Aside from the explicit calls in FSTV::apply(Geode) for the vertex and normal arrays, FSTV does not appear to query the referenceCount of any Node. So I suspect this is not the issue. So I'm really quite stumped. I know it's difficult to debug remotely, but this app is rather large and impractical to share. Guidance on debugging would be appreciated. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, October 24, 2008 1:35 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Problems flattening static transforms Hi Paul, I'm just online briefly so I'll give you my first thought as what is amiss. Optimizer::optimize() method takes a reference to the scene graph to optimize, this means that it can't change it's type, so it can't flatten it. If you place a Group above it and then optimize it'll be able to optimize the node away. One could possibly write an additional method that takes a pointer to a scene graph node and then return the new scene graph with potentially a new root node. For compatibility we'd need to keep the present one. Robert. On Fri, Oct 24, 2008 at 8:24 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- I have a scene graph containing multiple static transforms. My application runs the osgUtil::Optimizer on this scene graph. This should flatten all the static transforms. Unfortunately, the result is that all the transforms flatten _except_ for the top level transform. If I do an osgconv on this same scene graph, all the static transforms flatten -- they are converted to Group nodes, and their transformations are folded into the geometry. Clearly, the issue isn't with the scene graph itself, but it's something my app is doing wrong when it invokes the Optimizer. My dilemma: why doesn't this work properly for osgconv, but not for my app? I have dug into thisu for quite some time now, trying to uncover the difference between osgconv (which works) and my code (which doesn't work). Here's what I know so far: * I've written a small test app to try to reproduce the problem. It loads the scene graph, runs the Optimizer, and writes the scene graph back out. Unfortunately, it works properly, just like osgconv. It flattens all the transforms. I'm unable to reproduce the problem in anything other than my (larger) application. This must be a bug in my code, I must be doing something wrong. * I have verified that the problem is not non-STATIC transforms, multiple parents, or ProxyNodes. The same scene graph works fine in osgconv and my little test app, so it isn't a scene graph issue. I believe my app handles the scene graph the same as in these other two apps, which work. * Yes I'm invoking the Optimizer the same way, with no flags. I'm sure that the OSG_OPTIMIZER variable is not set in the environment. I get the same behavior if I just pass the FLATTEN_STATIC_TRANSFORMS flag (top level node fails to flatten). If I set OSG_OPTIMIZER=FLATTEN_STATIC_TRANSFORMS and run osgconv, it still works properly and flattens all transforms. * ObjectStruct has a Boolean called _moreThanOneMatrixRequired. In my app, this gets set to true at Optimizer.cpp line 826. This doesn't happen when running osgconv or my small test code. This seems to be part of the problem, but the root cause that triggers this event is still unknown to me. I'll attach the scene graph in question, though I doubt it will do anyone much good, because it works fine in osgconv and my simple test app. It only fails in my larger app. Note the top level Node named CenterOfMassOffset; this is the transform that refuses to flatten. I'm wondering if anyone has encountered the same issue before, has any info on how to resolve the issue, or might know how to proceed with debugging it. Notify level DEBUG_INFO does not produce any enlightening information. I admit I'm stumped on this one. It's extremely out of the ordinary when OSG doesn't just do what I expect it to. I appreciate any info. Thanks, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466
Re: [osg-users] Problems flattening static transforms
Interesting... Multiple references _does_ seem to be the cause! I modified my simple test app to make a second ref_ptr to the loaded scene graph. So the pseudocode is: Load scene graph into first ref_ptr. Create a second ref_ptr and make it reference the first ref_ptr's child 0. Run the Optimizer Write the scene graph (Code attached. Run it with my previous opt1.osg file to reproduce the problem.) With the second ref_ptr pointing to the child of the top level Transform, the top level Transform does not flatten. Is this a bug? Why does the Optimizer (apparently) not flatten a transform if it has a child with reference count greater than 1? -Paul Thanks for the quick reply, Robert. It's really the flattening that I require, and not necessarily the type change. For example, I see that osgconv doesn't change the type of the top level Transform node, but it does flatten it so that its transform is the identity. In my app, however, this top level transform is simply not flattened; the matrix is still non-identity. To be pedantic, I added a top level Group above my (previous) top level Transform. In my app, this Transform remains unflattened. My app maintains other ref_ptrs into this scene graph, could this be the problem? To check, I set a breakpoint in Referenced::referenceCount() just before calling optimize(). Aside from the explicit calls in FSTV::apply(Geode) for the vertex and normal arrays, FSTV does not appear to query the referenceCount of any Node. So I suspect this is not the issue. So I'm really quite stumped. I know it's difficult to debug remotely, but this app is rather large and impractical to share. Guidance on debugging would be appreciated. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, October 24, 2008 1:35 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Problems flattening static transforms Hi Paul, I'm just online briefly so I'll give you my first thought as what is amiss. Optimizer::optimize() method takes a reference to the scene graph to optimize, this means that it can't change it's type, so it can't flatten it. If you place a Group above it and then optimize it'll be able to optimize the node away. One could possibly write an additional method that takes a pointer to a scene graph node and then return the new scene graph with potentially a new root node. For compatibility we'd need to keep the present one. Robert. On Fri, Oct 24, 2008 at 8:24 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- I have a scene graph containing multiple static transforms. My application runs the osgUtil::Optimizer on this scene graph. This should flatten all the static transforms. Unfortunately, the result is that all the transforms flatten _except_ for the top level transform. If I do an osgconv on this same scene graph, all the static transforms flatten -- they are converted to Group nodes, and their transformations are folded into the geometry. Clearly, the issue isn't with the scene graph itself, but it's something my app is doing wrong when it invokes the Optimizer. My dilemma: why doesn't this work properly for osgconv, but not for my app? I have dug into thisu for quite some time now, trying to uncover the difference between osgconv (which works) and my code (which doesn't work). Here's what I know so far: * I've written a small test app to try to reproduce the problem. It loads the scene graph, runs the Optimizer, and writes the scene graph back out. Unfortunately, it works properly, just like osgconv. It flattens all the transforms. I'm unable to reproduce the problem in anything other than my (larger) application. This must be a bug in my code, I must be doing something wrong. * I have verified that the problem is not non-STATIC transforms, multiple parents, or ProxyNodes. The same scene graph works fine in osgconv and my little test app, so it isn't a scene graph issue. I believe my app handles the scene graph the same as in these other two apps, which work. * Yes I'm invoking the Optimizer the same way, with no flags. I'm sure that the OSG_OPTIMIZER variable is not set in the environment. I get the same behavior if I just pass the FLATTEN_STATIC_TRANSFORMS flag (top level node fails to flatten). If I set OSG_OPTIMIZER=FLATTEN_STATIC_TRANSFORMS and run osgconv, it still works properly and flattens all transforms. * ObjectStruct has a Boolean called _moreThanOneMatrixRequired. In my app, this gets set to true at Optimizer.cpp line 826. This doesn't happen when running osgconv or my small test code. This seems to be part of the problem, but the root cause that triggers this event is still unknown to me.
Re: [osg-users] Call for feedback : AC3D loader behavior w.r.t texture repeat and clamping
* Robert Osfield -- Friday 24 October 2008: But it doesn't really say anything about the how the texture wrap modes map to this, if at all. I can't say that either, but the current situation is bad. Because 'texrep 1 1' is default anyway (according to spec and reference implementation) AC3D itself doesn't even write it to its files! AC3D users who want the default do now have to manually(!) insert oodles of 'texrep 1 1' with an editor, only because OSG does no longer respect the documented default. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing movie on OSG for novice
Hi Stephan, I will try another computer. There is no way except it. Thanks for your helps. Best Regards. Ümit Uzun 2008/10/24 Stephan Maximilian Huber [EMAIL PROTECTED] Hi, Ümit Uzun schrieb: QuickTime 7.3 and QuickTime Player 7.3 I am sorry, I don't know what's the problem on your side. I tested the quicktime plugin with Quicktime 7.2 and the newest 7.5 and it works as advertised. Can you test your app/osgmovie on another computer? Stephan. ___ 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] Problems flattening static transforms
Hi Paul, I'm not sure it's a bug. I think the Optimizer is playing it safe when there are two scene graphs sharing a common graph. You have two scene graphs sharing a graph even though one graph doesn't have a parent as in your second ref_ptr. The result would be optimize one graph and the other graph changes when it shouldn't. If you don't think the above is correct and the decision to optimize should be based on whether there is more than one parent, create a custom Optimizer. I think what you will find is the second ref_ptr which was pointing to a graph with lots of geometry may end up as an empty group node. Something that might be unexpected if it was the top node of something you're rendering. That may not be a problem in your application. -Original Message- From: Paul Martz [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2008 3:32 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Problems flattening static transforms Interesting... Multiple references _does_ seem to be the cause! I modified my simple test app to make a second ref_ptr to the loaded scene graph. So the pseudocode is: Load scene graph into first ref_ptr. Create a second ref_ptr and make it reference the first ref_ptr's child 0. Run the Optimizer Write the scene graph (Code attached. Run it with my previous opt1.osg file to reproduce the problem.) With the second ref_ptr pointing to the child of the top level Transform, the top level Transform does not flatten. Is this a bug? Why does the Optimizer (apparently) not flatten a transform if it has a child with reference count greater than 1? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems flattening static transforms
Thanks, I see the light now. I wrote my own FlattenStaticTransforms NodeVisitor to just fold the transform into the geometry and set the transformation to identity; It works great as long as all Transforms are MatrixTransforms. (It'd be nice if there were a virtual osg::Transform::setIdentity() method to easily allow code to set any Transform Node to the identity. For example, see Optimizer.cpp starting at line 1080. It makes sense for PATs and DOFTransforms, but maybe not for Camera...) -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jolley, Thomas P Sent: Friday, October 24, 2008 3:09 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Problems flattening static transforms Hi Paul, I'm not sure it's a bug. I think the Optimizer is playing it safe when there are two scene graphs sharing a common graph. You have two scene graphs sharing a graph even though one graph doesn't have a parent as in your second ref_ptr. The result would be optimize one graph and the other graph changes when it shouldn't. If you don't think the above is correct and the decision to optimize should be based on whether there is more than one parent, create a custom Optimizer. I think what you will find is the second ref_ptr which was pointing to a graph with lots of geometry may end up as an empty group node. Something that might be unexpected if it was the top node of something you're rendering. That may not be a problem in your application. -Original Message- From: Paul Martz [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2008 3:32 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Problems flattening static transforms Interesting... Multiple references _does_ seem to be the cause! I modified my simple test app to make a second ref_ptr to the loaded scene graph. So the pseudocode is: Load scene graph into first ref_ptr. Create a second ref_ptr and make it reference the first ref_ptr's child 0. Run the Optimizer Write the scene graph (Code attached. Run it with my previous opt1.osg file to reproduce the problem.) With the second ref_ptr pointing to the child of the top level Transform, the top level Transform does not flatten. Is this a bug? Why does the Optimizer (apparently) not flatten a transform if it has a child with reference count greater than 1? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::ApplicationUsage::setDescription() causesexception 0xC0000005 on Vista
Hi Robert,
Thank you for your reply. It was supposed to be arguments., just a
typo.
I did finally get the viewer to run and it was indeed caused by
mixed OSG lib/dll's running with our software and dependencies.
Basically, rebuilding osg1.2 from source on the vista machine and
linking with all components also freshly built in the same environment
made the exceptions like the one described stop completely.
Thanks,
-Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Friday, October 24, 2008 1:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osg::ApplicationUsage::setDescription()
causesexception 0xC005 on Vista
Hi Matt,
I presume you use arguments. rather than arguments- in your code
as the code in your email won't compile and if it somehow did then the
compiler is totally screwed... and the case of the problem.
With the assumption that this is just a typo, the crash is very odd
indeed. The code is all pretty straight forward. The
arguments.getApplicationUsage() should return the
ApplicationUsage::instance(), that is attached in the ArgumentParser
constructor. This has never been reported as an issue before, but
perhaps some how on your system the instance() function is working.
It's worth noting that osg::ApplicationUsage and osg::ArgumentParser
have changed little since 1.2, and the usage example you provide is
similar to the standard OSG examples so is something that is compiled
and run very often by many hundreds of developers working under Vista
without problem.
Given this, I'd guess that the problem is down to issues at your end,
perhaps a problem with mixed OSG lib/dll's, or not setting the correct
options in VS such as mulit-threaded dll's etc.
Robert.
On Thu, Oct 23, 2008 at 6:53 PM, Matt McPheeters
[EMAIL PROTECTED] wrote:
Greetings,
Hopefully someone else has already experienced this and has a fix:
We have a command-line viewer program that runs perfectly fine on XP
but
crashes almost immediately in main() on a Vista build.
Here is the offending code:
int main( int argc, char **argv )
{
osg::setNotifyLevel( osg::WARN );
osg::ArgumentParser arguments( argc, argv );
arguments-setApplicationName( arguments.getApplicationName() );
arguments-getApplicationUsage()-setDescription(
arguments.getApplication() + is the standard... );// This is
the line
that causes the exception.
}
This program is using OSG version 1.2. All of the OSG examples run
fine.
In the autos window of Visual Studio 2005 (has already been updated
with
Vista-related Service Packs) the local variable arguments contains
good
data. If
I declare an instance of osg::ApplicationUsage * and set it equal to
arguments.getApplicationUsage() instead of using it inline it also
points
to valid
data, except that its _description member variable is equal to the
empty
string because this is where the program crashes.
Also, when the crash occurs, the call stack is in ntdll.dll but there
is a
message that reads [Frames below may be incorrect and/or missing, no
symbols
loaded for ntdll.dll].
None of this may be relevant, but when you don't know what you are
missing
every clue might help. The answer may be as simple as a preprocessor
directive
but I have searched to no avail.
Thanks.
-Matt
___
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] Problems flattening static transforms
Hi Paul, I ran into this dillemna recently while working on an app and then again while working on the code for FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS. My solution was the same as Robert's: place your graph under a temporary Group node, then flatten it, then retrieve the child of the Group node whatever it may be. Just setting the root Transform node to identity didn't appeal to me. The point of the optimization in all cases I have seen is to remove transforms from the modelview stack since they can cause a big performance hit in sufficient numbers. Even if the matrix is identity you would still have the performance hit unless OSG is smart enough to treat such a Transform like a Group. I hope this is useful, but it sounds like your situation might be more complicated than mine. - Terry Message: 14 Date: Fri, 24 Oct 2008 15:53:47 -0600 From: Paul Martz [EMAIL PROTECTED] Subject: Re: [osg-users] Problems flattening static transforms To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Thanks, I see the light now. I wrote my own FlattenStaticTransforms NodeVisitor to just fold the transform into the geometry and set the transformation to identity; It works great as long as all Transforms are MatrixTransforms. (It'd be nice if there were a virtual osg::Transform::setIdentity() method to easily allow code to set any Transform Node to the identity. For example, see Optimizer.cpp starting at line 1080. It makes sense for PATs and DOFTransforms, but maybe not for Camera...) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
