[osg-users] Problems with osg::Text in anaglyph stereo with 3.6
Hi, first of all: Happy new year everybody! I am porting an application of mine from osg 3.4 to 3.6 . I have a strange problem with text objects in anaglyph stereo. Some of them are not correctly separated to red / cyan, they stay in their original color (and thus produce heavy artifacts when viewed through red-cyan-glasses). The problem did not occur with version 3.4. I can provide an .ive-file that shows the error (with osgviewer when viewed in stereo), but this is 33 MB in size, so I thought it would not be welcome to send it to a mailing list. Strangely the problem does not show on all of my text objects, so maybe someone has a pointer for me what I can to on my side to prevent this. You can find the testfile here: http://www.raumgeometrie.de/Mathebilder/test.ive It contains a co-ordinate system, the numbers on the axes show the symptoms whereas the two point-labels (which I have included for reference) do not. Best regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LOD for drawing lines of a co-ordinate system
Am 13.10.2016 um 16:26 schrieb Andreas Goebel: > Hi, > > I had the idea to use an osg::LOD for drawing a co-ordinate system in a > geometry program. > > The closer you get, the more fine-grained lines you see. > > This works fine as long as you zoom in to (0,0,0). If you zoom to a > different point, it doesn´t work, as the distance from eye to center is > still too big. Ok, I´ve splitted it up to pieces. You have to use a LOD for each of the pieces, as a LOD has only one center, I missed that at first. Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LOD for drawing lines of a co-ordinate system
Hi, I had the idea to use an osg::LOD for drawing a co-ordinate system in a geometry program. The closer you get, the more fine-grained lines you see. This works fine as long as you zoom in to (0,0,0). If you zoom to a different point, it doesn´t work, as the distance from eye to center is still too big. I tried to use PIXEL_SIZE_ON_SCREEN, but then I see nothing all the time (probably because I use glLines for the coordinate-system which are very fine). I could solve this by breaking the coordinate-system into several nodes, thus the center would be more accurate. But before doing that: Is there an easier way? Thanks for your comments, Andreas PS: Is it allowed to post pictures here, small ones of course? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Weird linker error while building an osg-based app on a virtual machine
Ok, in case someone runs into the same problem: The linker error disappears when you switch off 3d accelleration for the virtual machine. After linking, you can turn it on again, and then even the application works. I have no idea what linking has to do with 3d accelleration while the program is not even run. Andreas Am 10.10.2016 um 18:13 schrieb Andreas Goebel: > Hi, > > sorry, as this is slightly off-topic, but in case someone here has seen > an error like this, this would be really helpful for me. > > I develop my osg-based app on windows, but I also compile on linux. > > For this I use virtual box with OpenSuSE 13.2 installed in it (with > guest additions for hardware-accelerated graphics). > > At the very end of my build-process I get the following linker-error: > > *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to > `RTAssertMsg1Weak' > *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to > `RTErrConvertFromErrno' > *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to > `RTMemAllocTag' > *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to > `RTAssertShouldPanic' > *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to > `RTR3InitDll' > *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to > `RTOnceSlow' > *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to > `RTMemFree' > > I haven´t even used libEGL (but as far as I understand, gtk uses it, > which I use). While this seems to be a bug in virtual box, maybe someone > of you who builds cross-platform like this, too, has seen that error and > knows a solution. > > Thanks for reading, > > Andreas > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Weird linker error while building an osg-based app on a virtual machine
Hi, sorry, as this is slightly off-topic, but in case someone here has seen an error like this, this would be really helpful for me. I develop my osg-based app on windows, but I also compile on linux. For this I use virtual box with OpenSuSE 13.2 installed in it (with guest additions for hardware-accelerated graphics). At the very end of my build-process I get the following linker-error: *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to `RTAssertMsg1Weak' *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to `RTErrConvertFromErrno' *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to `RTMemAllocTag' *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to `RTAssertShouldPanic' *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to `RTR3InitDll' *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to `RTOnceSlow' *** /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined reference to `RTMemFree' I haven´t even used libEGL (but as far as I understand, gtk uses it, which I use). While this seems to be a bug in virtual box, maybe someone of you who builds cross-platform like this, too, has seen that error and knows a solution. Thanks for reading, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stereo View and makeLookAt()
Hi Robert, thanks for your answer. The reason I´m using sceneview is that I started with my application when Producer was still around, which was very complicated to integrate into GUI applications. As this worked and my users got used to the way the scene was manipulated, I stayed with it. But I´m starting to use osgViewer, for secondary views on the same scene, a viewer window is opened. For my main window, I haven´t made the switch yet. There is a lot of gui-interaction to be taken care of (for instance, menus or dialogs or tooltips on top of the openGL window) which won´t work out of the box with osgViewer, as osgViewer isn´t happy when it´s not updated permamently. At least this was the case when I last tried. Setting the fusion distance manually improved my situation quite a lot, thank you for the hint! I liked the way the trackball manipulator handles this, so I´ll probably try to set it to work like this. Thanks for your help, Andreas Am 06.10.2016 um 18:04 schrieb Robert Osfield: > Hi Andreas, > > Is there a reason why you are using SceneView? This class hasn't been > a preferred end user class since around OSG-1.0... Personally I'd > recommend user osgViewer, it's interface is much more suitable for > putting together flexible viewers. > > As for mixing and matching ways of setting the view matrix while still > supporting the built in support stereo, well this all depends upon how > you go about it. Normally you'd simply modify the viewer's master > Camera's view matrix anyhow you want and then the stereo will work > behind the scenes for you. The built in Camera manipulators also set > the FusionDistanceValue automatically, this helps set the effective > convergence point of the left and right eyes, perhaps this is what the > difference relative to your case. > > One thing to be aware is that certain types of camera manipulators > favour scaling the FusionDistance to the distance between the eye > point and center of rotation, the trackball is good example of this, > while others like the drive or flight manipulators have a fixed > FusionDistance that one should set to the distance between the eye and > display system to get a proper 1:1 scaling of the virtual world to > real world. > > Robert. > > Robert. > > On 6 October 2016 at 16:16, Andreas Goebel <a-goe...@gmx.de> wrote: >> Hi, >> >> to set up my view matrix I use a very simple approach with makeLookAt(). >> >> Like this: >> >> centerPos = osg::Vec3(0,0,0); >> osg::Vec3 viewPos( >> cos(viewElev) * sin(viewRot), >> cos(viewElev) * cos(viewRot), >> sin(viewElev)); >> osg::Vec3 up; >> if ( (viewElev > -1.0*osg::PI_2) && (viewElev < osg::PI_2) ) >> up = osg::Z_AXIS; >> else >> up = osg::Z_AXIS*-1.0; >> osg::Matrixd look; >> viewPos *= 10.0; >> look.makeLookAt(viewPos, centerPos, up); >> sceneView->setViewMatrix(look); >> >> >> Recently I´ve discovered that in stereo mode all my objects are behind >> the screen, whereas when I use an osgviewer, for example, it´s possible >> to pull objects before the screen. >> >> I think that usually objects before (0,0,0) appear before the screen. >> >> Is it generally impossible to set up the view matrix with makeLookAt in >> connection with stereo (I use the osg builtin stereo features)? >> >> If so, what route should I take? I manipulate view rotation and view >> elevation with the mouse. >> >> >> >> Thanks, >> >> Andreas >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stereo View and makeLookAt()
Hi, to set up my view matrix I use a very simple approach with makeLookAt(). Like this: centerPos = osg::Vec3(0,0,0); osg::Vec3 viewPos( cos(viewElev) * sin(viewRot), cos(viewElev) * cos(viewRot), sin(viewElev)); osg::Vec3 up; if ( (viewElev > -1.0*osg::PI_2) && (viewElev < osg::PI_2) ) up = osg::Z_AXIS; else up = osg::Z_AXIS*-1.0; osg::Matrixd look; viewPos *= 10.0; look.makeLookAt(viewPos, centerPos, up); sceneView->setViewMatrix(look); Recently I´ve discovered that in stereo mode all my objects are behind the screen, whereas when I use an osgviewer, for example, it´s possible to pull objects before the screen. I think that usually objects before (0,0,0) appear before the screen. Is it generally impossible to set up the view matrix with makeLookAt in connection with stereo (I use the osg builtin stereo features)? If so, what route should I take? I manipulate view rotation and view elevation with the mouse. Thanks, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg shadow minimal shadow map and auto-rotating text objects
Hello, with the minimal shadow map technique text-objects cast shadows (which is what I want). But it seems that the text objects are auto-rotated towards the light during shadow rendering. Is there a flag to disable the auto-rotation as long as the shadow-camera is making it´s shot? If not, what would be a good way to implement that? Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG plugin for browsers
Hi Thibault, Am 07.04.2011 11:30, schrieb Thibault Genessay: Hi folks, published some day. - The so-called OSG Viewer Firefox Plugin 1.0. I can't find where this one originates from, so I didn't install it This was written by me. At the time I didn´t succeed in uploading it to a firefox-plugin-site. You can look for posts with my name and will find the complete source on this list, too. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change in osgText from 2.8.3 to 2.9.8?
Hi Robert, thanks for explaining that issue. I suspect a problem with z precision, as the flickering is worse for big nodes with big bounding boxes (the long line). I´ll have a look if I can hack the hack. I have also taken a look at osgPango, but this would need quite some refactoring of my own code which I do not have the time for at the moment. The problem did indeed occur before with older versions of osg, but only on cheap hardware. I then suspected a problem with textures on the cheap hardware and did not investigate further. With 2.9.8 I got flickering with my not so cheap hardware, too, so I thought that there had been a change. Greetings, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change in osgText from 2.8.3 to 2.9.8?
Hi Robert,
I´ve digged a bit and found a change concerning the polygon offset.
In 2.8.3 there is:
for( ; backdrop_index max_backdrop_index; backdrop_index++)
{
const GlyphQuads::Coords3 transformedBackdropCoords =
glyphquad._transformedBackdropCoords[backdrop_index][contextID];
if (!transformedBackdropCoords.empty())
{
state.setVertexPointer( 3, GL_FLOAT, 0,
(transformedBackdropCoords.front()));
glPolygonOffset(0.1f *
osg::PolygonOffset::getFactorMultiplier(),
2.0f *
osg::PolygonOffset::getUnitsMultiplier() *
(max_backdrop_index-backdrop_index) );
glDrawArrays(GL_QUADS,0,transformedBackdropCoords.size());
}
}
whereas in 2.9.8 there is
for( ; backdrop_index max_backdrop_index; backdrop_index++)
{
const GlyphQuads::Coords3 transformedBackdropCoords =
glyphquad._transformedBackdropCoords[backdrop_index][contextID];
if (!transformedBackdropCoords.empty())
{
state.setVertexPointer( 3, GL_FLOAT, 0,
(transformedBackdropCoords.front()));
glPolygonOffset(0.1f *
osg::PolygonOffset::getFactorMultiplier(),
osg::PolygonOffset::getUnitsMultiplier() *
(max_backdrop_index-backdrop_index) );
state.drawQuads(0,transformedBackdropCoords.size());
}
}
which leaves out the factor 2.0f. On the other hand I thought that the
y-coordinate was used to change the placement of the backdrop and should
not result in z-fighting.
Andreas
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change in osgText from 2.8.3 to 2.9.8?
Am 31.08.2010 10:54, schrieb Robert Osfield: HI Andreas, Try adding back in the 2.0 factor to see how it effects things. Hi Robert, I´ve first done some useless tests, as I saw later on that POLYGON_OFFSET isn´t the default backdrop implementation. Using POLYGON_OFFSET als backdrop implementation an re-introducing the 2.0 factor gave me the results I was used too. I am confused though that polygon_offset wasn´t the default in 2.8.3, too, so I should have gotten flickering there, too. Mysterious. I think that I´ll have to make the choice of backdrop implementation and of that factor available to my users, as - as I read in the docs - users with ATI-Cards probably will have problems with the polygon_offset method. I´ll implement a static method and variable DefaultBackdropType so one can choose the backdrop type for all osgText objects. I´d have to review all of my code to give users a choice otherwise. Maybe you´ll want to check that into osgText. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change in osgText from 2.8.3 to 2.9.8?
Hi Robert, One addition: I was able to reproduce the problem too when using a geometry instead of a shapeDrawable for the long thin cylinder. So this has nothing to do with the ShapeDrawable. I´m completely lost here. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Change in osgText from 2.8.3 to 2.9.8?
Hi, yesterday I´ve tried the 2.9.8 developer release. I encounter problems with osgText-objects, see attached image (all characters should be white with black outline). Could someone give me a pointer if there is a switch or something to get back the old behaviour? Regards, Andreas attachment: osgText.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Outline Fonts
Hi, I´m using outlined Fonts to ensure readability with varying Backgrounds. I encounter artefacts with some characters (see attachement). Is there a known workaround? Regards, Andreas inline: FontExample.gif___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trouble porting to vs2008, heap corruption
Hi, you get heap corruption on windows if (not only if, but if) you mix different system libraries, static runtime and dynamic runtime, or debug dlls and release dlls. Make really sure that your release build uses release libraries only, and vice versa. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows on two-sided polygons
Hi Wojtek, thanks a lot for your detailed answer. I will work through the example within one of the next holydays, as I am not a professional programmer (I´m a math teacher) and will need some quiet time for a demanding task like this. My software is a math-software to illustrate vector geometry, and thus displays planes and so on simply as polygons. That´s the reason I need two-sided materials (or at least I decided to do so, the alternative would have been to use more massive planes). For the time being it is a comfort for me that I didn´t make a simple mistake and that it is quite some work to adjust the StandardShadowMap to two-sided polygons. Who maintains ShadowMap? I´d like the maintainer to do some tests with my shader. If you think it´s better than the standard one, I´ll refactor it into the Shadow-Map code. For a first impression, see the images in the last mail. Regards thanks for the example, Andreas Wojciech Lewandowski schrieb: Hi Andreas, If you want to use dual sided materials I believe you will have to review and probably modify the shaders in StandardShadowMap.cpp. I am certain Vertex shader computes ligthing using front lighting and assigns the same colors to backfacing polygons. Another issue would be usage of back faces for shadow map rendering. I guess if you want to use dual face materials you will need to override this. So many people have so many varying requests for shadows that my recomendation for them would be to create their own ShadowTechnique class based on one of LispSM or MinimalShadowMap or even StandardShadowMap. But comparing results, this last one does not really differ that much from ShadowMap which is much easier to override. When overriding any of above classes its important to override inner ViewData class which provides View related resources storage and management. By overriding ViewData::init method you get access to all statesets used by base classes and you can easily override all state attributes. I have prepared an example class (MyViewDependentShadowMap) which shows how to override any of classes stemming from ViewDepenedentShadowTechnique. This class illustrate how to add soft shadows to MinimalDrawBoundsShadowMap class (should be appropriate for you). Have a look at it and modify to your needs. HTH, Wojtek Lewandowski -- From: Andreas Goebel a-goe...@gmx.de Sent: Saturday, November 21, 2009 1:57 PM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Shadows on two-sided polygons Hi Jean-Sébastien, I have turned off those things, and now it works good for me. Should I refactor that in a way that the application programmer can choose the behaviour and submit that? You could, but I think setting those things via overridden state is also acceptable, since if you need that you'll probably know what to set... You mean by setting the StateAttribute CullFaces to off and override for my shadowed scene? This would probably work (even though it is set with override in the ShadowMap? Which will override which?), but not for the polygon-offset, as this is not controlled with state. I mean this line: // negative polygonoffset - move the backface nearer to the eye point so that backfaces // shadow themselves float factor = _polyOffset[0]; float units = _polyOffset[1]; Another thing: I have written a vertex and a fragment shader that work together in a way that allows the shadows to be rendered exactly in the ambient color. This means that shadowed surfaces look the same as surfaces that face away from the light. This gives a much more natural feeling, and you don´t get false shadows on the backs of polygons. I needed the vertex shader to get the correct ambient color, I think it is not possible to do this with a fragment shader alone. I assume you're talking about osgShadow::ShadowMap? The shaders used for the ViewDependentShadow classes (LightSpacePerspectiveShadowMapDB, CB, VB) already do this. Note that osgShadow::StandardShadowMap is the equivalent of osgShadow::ShadowMap but under the ViewDependentShadow architecture, so you could have used that and you would have gotten the right shadow ambient color. It´s great to hear that, I haven´t used the new classes yet, as they are not (at least in 2.8.2) part of the shadow-Example and I could not easily play with them. However, I have made an option in my program to use the StandardShadowMap, and it does not work for me (yet). Here are the problems: - the side facing away from a light is not dark, example: http://raumgeometrie.de/NeueBilder/testbilder/IncorrectBack.png - the backside of a shadowed plane shows the shadow, too: http://raumgeometrie.de/NeueBilder/testbilder/IncorrectShadowOnBack.png The correct images (with my shaders) look like this: http://raumgeometrie.de/NeueBilder/testbilder/CorrectBack.png
Re: [osg-users] Shadows on two-sided polygons
Hi Jean-Sébastien, I have turned off those things, and now it works good for me. Should I refactor that in a way that the application programmer can choose the behaviour and submit that? You could, but I think setting those things via overridden state is also acceptable, since if you need that you'll probably know what to set... You mean by setting the StateAttribute CullFaces to off and override for my shadowed scene? This would probably work (even though it is set with override in the ShadowMap? Which will override which?), but not for the polygon-offset, as this is not controlled with state. I mean this line: // negative polygonoffset - move the backface nearer to the eye point so that backfaces // shadow themselves float factor = _polyOffset[0]; float units = _polyOffset[1]; Another thing: I have written a vertex and a fragment shader that work together in a way that allows the shadows to be rendered exactly in the ambient color. This means that shadowed surfaces look the same as surfaces that face away from the light. This gives a much more natural feeling, and you don´t get false shadows on the backs of polygons. I needed the vertex shader to get the correct ambient color, I think it is not possible to do this with a fragment shader alone. I assume you're talking about osgShadow::ShadowMap? The shaders used for the ViewDependentShadow classes (LightSpacePerspectiveShadowMapDB, CB, VB) already do this. Note that osgShadow::StandardShadowMap is the equivalent of osgShadow::ShadowMap but under the ViewDependentShadow architecture, so you could have used that and you would have gotten the right shadow ambient color. It´s great to hear that, I haven´t used the new classes yet, as they are not (at least in 2.8.2) part of the shadow-Example and I could not easily play with them. However, I have made an option in my program to use the StandardShadowMap, and it does not work for me (yet). Here are the problems: - the side facing away from a light is not dark, example: http://raumgeometrie.de/NeueBilder/testbilder/IncorrectBack.png - the backside of a shadowed plane shows the shadow, too: http://raumgeometrie.de/NeueBilder/testbilder/IncorrectShadowOnBack.png The correct images (with my shaders) look like this: http://raumgeometrie.de/NeueBilder/testbilder/CorrectBack.png And this: http://raumgeometrie.de/NeueBilder/testbilder/NoShadowOnBackOfPlane.png Is it possible to render a more correct shadow for models like mine with StandardShadowMap? It seems a promising technology to me, I would like to use it, and the results (where they are correct) look really good. Regards, Andreas You can always submit those shaders (as part of modified ShadowMap.cpp files so that they work by default), I'm sure anyone still using osgShadow::ShadowMap will be glad you do. I think it´s nicer to have the shaders as separate files, one can easily load them and use them, no need to modify the source. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows on two-sided polygons
Andreas Goebel schrieb: Hi, I use two-sided polygons (as I display no real objects but mathematical ones like planes this makes sense) and use shadows on them. After upgrading to 2.8.2, this does no longer work. I get the correct shadow on one side of a plane, but if the shadow should be on the other side, I get strange artifacts but no shadow. Is there a setting to change the shadow to two-sided? Thanks for your help. Hi, I have now found out why that is. a) Backfaces are culled (via cull face) b) In case you look at a backface from front, changing the sign of the polygon offset produces artifacts (very strong artifacts). I have turned off those things, and now it works good for me. Should I refactor that in a way that the application programmer can choose the behaviour and submit that? Another thing: I have written a vertex and a fragment shader that work together in a way that allows the shadows to be rendered exactly in the ambient color. This means that shadowed surfaces look the same as surfaces that face away from the light. This gives a much more natural feeling, and you don´t get false shadows on the backs of polygons. I needed the vertex shader to get the correct ambient color, I think it is not possible to do this with a fragment shader alone. If someone is interested in those shaders, I can make them available here. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shadows on two-sided polygons
Hi, I use two-sided polygons (as I display no real objects but mathematical ones like planes this makes sense) and use shadows on them. After upgrading to 2.8.2, this does no longer work. I get the correct shadow on one side of a plane, but if the shadow should be on the other side, I get strange artifacts but no shadow. Is there a setting to change the shadow to two-sided? Thanks for your help. Regards, Andreas Correct shadow: http://raumgeometrie.de/NeueBilder/testbilder/Shadow1.png Incorrect shadow: http://raumgeometrie.de/NeueBilder/testbilder/Shadow2.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Renderer and SceneView classes
Doug McCorkle schrieb: Hello Robert, On Nov 9, 2009, at 3:22 AM, Robert Osfield wrote: Hi Paul, On Sun, Nov 8, 2009 at 2:44 PM, Paul Martz pma...@skew-matrix.com wrote: Hi Robert -- There are large projects out there based on SceneView and getting along just fine without osgViewer. Removing SceneView would, at best, require them to migrate SceneView out of OSG and into their own app (where it would continue to work, barring future incompatible changes in OSG). And at worst, cost them an expensive port and re-verification of their product. I support marking SceneView as deprecated and replaced by Renderer, but think it would be wise to avoid changes to OSG that render SceneView inoperable. This has been my plan. To steadily move more functionality into osgViewer::Renderer and make SceneView redundant w.r.t modern OSG usage. SceneView needn't change too much, as CullVisitor/RenderStage/RenderBin etc. will still be in osgUtil. Once SceneView is redundant we'd need to make decision of when to move it out of the core OSG into the deprecated section of the subversion repository along with items like the old OpenFlight plugin. Prior to SceneView being moved out we'll need a period where we encourage OSG users still relying on SceneView to migrate to using osgViewer::Viewer in conjunction with osgViewer::GraphicsWindowEmbedded, as it offers the same easy ability to embed but offers a whole heap more flexibility and functionality. Do you have an example of how to use this class with an existing windowing toolkit? There was an FAQ on this subject related to SceneView that does not seem to be present anymore. If you have an example related to osgViewer that would be great. osgViewerGlut does this, for instance. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] rotating a geometry?
Thomas Maier schrieb: Hi, it seemed that all translations/transformations are done with a PAT, but when i rotate the PAT object which does not sit at position 0,0,0 of the world-coordinates, but it rotates around the world-coordinate-axis, but i want to rotate around a axis of the object itself? I tried code like the following, but it always turns around world-coordinate-axis. pos-set(rectangleTwoXForm-getPosition().x(), rectangleTwoXForm-getPosition().y()+1, rectangleTwoXForm-getPosition().z()); //rectangleTwoXForm-getPosition().set(rectangleTwoXForm-getPosition().x(), rectangleTwoXForm-getPosition().y(), rectangleTwoXForm-getPosition().z() ); rectangleTwoXForm-setAttitude(osg::Quat(osg::DegreesToRadians(i), *pos ) ); Hi, you´ll need to compose your transform: First do a translation that brings your axis to the origin, then rotate, then translate back. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Replaying saved animatio path
Hi, I have saved an animation path in osgViewer with z , z, after that the animation path is replayed correctly. However, if I want to restart the model with the path via osgviewer -p saved_animathion.path, nothing happens. Am I doing something wrong? Regards, Andreas P.S.: The reason for doing this is that I want do post a demo for the FirstPersonManipulator by Simon, which, I think, is quite cool. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in LineSegmentIntersector or ShapeDrawable
Hi,
I have used OpenSceneGraph 2.2.x for quite some time and have now
upgraded to 2.8.2.
I found that picking shape Drawables has become very very unprecise.
This can be reproduced with the osgpick-example. The drawable is still
picked even if the mouse is miles away. This error did not occur with
the 2.2.x series, if that helps to find out where this behaviour might
come from.
I attach a sample osg-file that can be used with the 2.8.2. osgpick
example to reproduce the bug. It is a very long and thin cylinder, maybe
this strange shape makes the bug appear whereas more normal shaped
cylinders are picked correctly.
Regards,
Andreas
Group {
name TheGroup
nodeMask 0x
cullingActive TRUE
num_children 3
Group {
UniqueID Group_0
name P
nodeMask 0x
cullingActive TRUE
StateSet {
UniqueID StateSet_1
rendering_hint OPAQUE_BIN
renderBinMode USE
binNumber 0
binName RenderBin
GL_ALPHA_TEST ON
GL_BLEND ON
AlphaFunc {
comparisonFunc GREATER
referenceValue 0
}
ShadeModel {
mode SMOOTH
}
LightModel {
ambientIntensity 0.2 0.2 0.2 1
colorControl SINGLE_COLOR
localViewer FALSE
twoSided TRUE
}
}
num_children 3
Geode {
nodeMask 0x
cullingActive TRUE
num_drawables 1
osgText::Text {
UniqueID Text_2
StateSet {
UniqueID StateSet_3
rendering_hint TRANSPARENT_BIN
renderBinMode USE
binNumber 10
binName DepthSortedBin
}
supportsDisplayList FALSE
useDisplayList FALSE
useVertexBufferObjects FALSE
fontResolution 80 80
characterSize 0.6 1
characterSizeMode OBJECT_COORDS
alignment LEFT_BASE_LINE
autoRotateToScreen TRUE
layout LEFT_TO_RIGHT
position 2.17262 -3.21246 5.21694
drawMode 1
text P
font arial.ttf
color 1 1 1 1
backdropType OUTLINE
backdropHorizontalOffset 0.07
backdropVerticalOffset 0.07
backdropColor 0 0 0 1
backdropImplementation DEPTH_RANGE
colorGradientMode SOLID
colorGradientTopLeft 1 0 0 1
colorGradientBottomLeft 0 1 0 1
colorGradientBottomRight 0 0 1 1
colorGradientTopRight 1 1 1 1
}
}
Geode {
UniqueID Geode_4
nodeMask 0x0
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_5
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LINE_STIPPLE ON
LineStipple {
factor 1
pattern 0xf
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays LINES 0 2
}
VertexArray UniqueID Vec3Array_6 Vec3Array 2
{
2.17262 -3.21246 5.21694
1.97262 -3.41246 5.01694
}
NormalBinding OVERALL
NormalArray Vec3Array 1
{
0 -1 0
}
ColorBinding OVERALL
ColorArray Vec4Array 1
{
0 0 0 1
}
}
}
Geode {
UniqueID Geode_7
nodeMask 0x
cullingActive TRUE
num_drawables 1
ShapeDrawable {
UniqueID ShapeDrawable_8
Box {
UniqueID Box_9
Center 1.97262 -3.41246 5.01694
HalfLengths 0.15 0.15 0.15
Rotation 0 0 0 1
}
useDisplayList TRUE
useVertexBufferObjects FALSE
color 1 0 0 1
TessellationHints {
detailRatio 0.5
createFaces TRUE FALSE
createNormals TRUE
createTextureCoords FALSE
createParts TRUE TRUE TRUE
}
}
}
}
Group {
UniqueID Group_10
name P2
nodeMask 0x
cullingActive TRUE
StateSet {
UniqueID StateSet_11
rendering_hint OPAQUE_BIN
renderBinMode USE
binNumber 0
binName RenderBin
GL_ALPHA_TEST ON
GL_BLEND ON
AlphaFunc {
comparisonFunc GREATER
referenceValue 0
}
ShadeModel {
mode SMOOTH
}
LightModel {
ambientIntensity 0.2 0.2 0.2 1
colorControl SINGLE_COLOR
localViewer FALSE
twoSided TRUE
}
}
num_children 3
Geode {
nodeMask 0x
cullingActive TRUE
num_drawables 1
osgText::Text {
UniqueID Text_12
Use StateSet_3
supportsDisplayList FALSE
useDisplayList FALSE
useVertexBufferObjects FALSE
fontResolution 80 80
characterSize 0.6 1
characterSizeMode OBJECT_COORDS
alignment LEFT_BASE_LINE
autoRotateToScreen TRUE
layout LEFT_TO_RIGHT
position -1.83053 1.468 2.07904
drawMode 1
text P2
font arial.ttf
Re: [osg-users] Bug in LineSegmentIntersector or ShapeDrawable
Robert Osfield schrieb: Hi Andreas, Thanks for the test file. I can confirm the bug at my end. My guess it's a bug in the geometry code for the cylinder in ShapeDrawable::accept(PrimtiveFunctor). I'm not in a position to dive in a fix this bug right away. Can yourself or someone else help out? I´ll have a look within this week. Thanks for the pointer, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in LineSegmentIntersector or ShapeDrawable
Robert Osfield schrieb:
Hi Andreas,
Thanks for the test file. I can confirm the bug at my end. My guess
it's a bug in the geometry code for the cylinder in
ShapeDrawable::accept(PrimtiveFunctor). I'm not in a position to
dive in a fix this bug right away. Can yourself or someone else help
out?
Robert.
Hi,
I´ve found and fixed the error. It´s in that function of ShapeDrawable.cpp:
void PrimitiveShapeVisitor::createCylinderBody(unsigned int numSegments,
float radius, float height, const osg::Matrix matrix)
{
const float angleDelta = 2.0f*osg::PI/(float)numSegments;
const float r = radius;
const float h = height;
float basez = -h*0.5f;
float topz = h*0.5f;
float angle = 0.0f;
_functor.begin(GL_QUAD_STRIP);
for(unsigned int bodyi=0;
bodyinumSegments;
++bodyi,angle+=angleDelta)
{
float c = cosf(angle);
float s = sinf(angle);
_functor.vertex(osg::Vec3(c*r,s*r,topz) * matrix);
_functor.vertex(osg::Vec3(c*r,s*r,basez) * matrix);
}
// do last point by hand to ensure no round off errors.
_functor.vertex(osg::Vec3(r,0.0f,topz) * matrix);
_functor.vertex(osg::Vec3(r,0.0f,basez) * matrix);
_functor.end();
}
In the done by hand-point you forgot to multiply with matrix.
I attach the whole file with the correction. OsgPick and my own software
now work as expected.
Regards,
Andreas
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osg/ShapeDrawable
#include osg/GL
#include osg/Notify
using namespace osg;
// arbitrary minima for rows segments
const unsigned int MIN_NUM_ROWS = 3;
const unsigned int MIN_NUM_SEGMENTS = 5;
///
//
// draw shape
//
class DrawShapeVisitor : public ConstShapeVisitor
{
public:
DrawShapeVisitor(State state,const TessellationHints* hints):
_state(state),
_hints(hints)
{
#if 0
if (hints)
{
notify(NOTICE)Warning: TessellationHints ignored in present osg::ShapeDrawable implementation.std::endl;
}
#endif
}
virtual void apply(const Sphere);
virtual void apply(const Box);
virtual void apply(const Cone);
virtual void apply(const Cylinder);
virtual void apply(const Capsule);
virtual void apply(const InfinitePlane);
virtual void apply(const TriangleMesh);
virtual void apply(const ConvexHull);
virtual void apply(const HeightField);
virtual void apply(const CompositeShape);
State _state;
const TessellationHints*_hints;
protected:
DrawShapeVisitor operator = (const DrawShapeVisitor) { return *this; }
enum SphereHalf { SphereTopHalf, SphereBottomHalf };
// helpers for apply( Cylinder | Sphere | Capsule )
void drawCylinderBody(unsigned int numSegments, float radius, float height);
void drawHalfSphere(unsigned int numSegments, unsigned int numRows, float radius, SphereHalf which, float zOffset = 0.0f);
};
void DrawShapeVisitor::drawCylinderBody(unsigned int numSegments, float radius, float height)
{
const float angleDelta = 2.0f*osg::PI/(float)numSegments;
const float texCoordDelta = 1.0f/(float)numSegments;
const float r = radius;
const float h = height;
float basez = -h*0.5f;
float topz = h*0.5f;
float angle = 0.0f;
float texCoord = 0.0f;
bool drawFrontFace = _hints ? _hints-getCreateFrontFace() : true;
bool drawBackFace = _hints ? _hints-getCreateBackFace() : false;
// The only difference between the font back face loops is that the
// normals are inverted and the order of the vertex pairs is reversed.
// The code is mostly duplicated in order to hoist the back/front face
// test out of the loop for efficiency
glBegin(GL_QUAD_STRIP);
if (drawFrontFace) {
for(unsigned int bodyi=0;
bodyinumSegments;
++bodyi,angle+=angleDelta,texCoord+=texCoordDelta)
{
float c = cosf(angle);
float s = sinf(angle);
glNormal3f(c,s,0.0f);
glTexCoord2f(texCoord,1.0f);
glVertex3f(c*r,s*r,topz);
Re: [osg-users] FirstPersonManipulator
Simon Loic schrieb: Hi christian, I'm glad to hear feedback on this manipulator. The problem you mention about the home position is exactly those I have to face right now. Ideally the camera should fall down to the terrain. Anyway I can send you the osg example I set up so far (with the bug) and you see if you can do something. Just tell me if you are interested. Cheers Loïc Simon Hi Simon, I´d be interested in this manipulator, too. Do you have a complete example now? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about OpenSceneGraph and deformable objects
Michel Audette schrieb: Hello, I am interested in determining the capabilities of OpenSceneGraph for displaying dynamically deformable objects, such as in interactive surgery simulation in conjunction with real-time haptic and visual rendering. Does your software support this kind of scene? Thanks for your kind attention. Best wishes, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi Michel, I am doing dynamic geometry with OSG. See a gif-animation here: http://raumgeometrie.de/drupal/de/node/48 (the original is much more fluent). But, as far as I know, you will have to code the deformations yourself (at least I do so). The reals strength of a scenegraph is, I think, large scenes which stay at least partially static. Thus you will not get a real speedup by using a scenegraph, but you might profit from using osg just as a realtime graphics library, which makes coding much easier than using pure OpenGL. When I started using osg, I just used it like some object oriented GLUT. In your case, multiple cameras might be of interest, and lots of other stuff. But, as I said, highly dynamic scenes are not the main purpose of a scenegraph. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is everyone doing for GUIs?
Simon Hammett schrieb: If you want a proper cross platform gui with all the bells and whistles, the three main choices are probably Qt, WxWidgets or Gtk. Qt is probably the most powerful and fully featured, but you have to use that dam MOC thing and the Qt framework. WxWidgets seems to give quite small programs, but it's not very pretty. Hi, maybe you confuse that with fltk, which gives small programs, but looks unfamiliar. WxWidgets uses native controls, so looks just as the platform you use it on. I use wxWidgets together with OpenSceneGraph, see www.raumgeometrie.de for an example. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deploying on Vista vs. Deploying on XP
Thomas Hogarth schrieb: Hi I've deployed a few apps across platforms now, and the best advise I can give is to make sure that if you change dev environment (i.e. vs2003 to vs2005) make sure you recompile everything with the new dev env (even stuff like alut :( ) On a worse note. I did once deploy a simple proof of concept app on XP then got asked to quickly ( lol) get it working on vista. It kept on crashing, in the end I never found out the real cause, but building my scene graph in a slightly different way made it work (no idea). So good luck, but vista appears to be a beast in itself (bring on windows 7 :) ) Hi, I agree. I had thought that I could avoid setting up a Vista machine and get on to Windows 7 directly, but I might have to reconsider this. I have now carefully checked again all libs, and I am sure that they all link against the same runtime. I will perhaps ship a mingw-built executable as an alternative. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Deploying on Vista vs. Deploying on XP
Hello, I use WinXP, Microsoft Visual Studio Express 8.0 Service Pack 1 and - of course - osg. I ship the runtime-dlls as private assemblies, and this works good on Windows XP and used to work for vista-users, too. Some months ago I updated Visual Studio with Service pack 1 and had to change the runtime-dlls, too. On winXP all still works fine, but not on Vista (at least on some machines, I cannot tell more precisely as I do not have Vista installed). It would be of great help for me if someone experienced with deploying osg-apps here could perhaps bring some light into this issue, it´s driving me crazy. If there are vista-users here which would like to play with the installer (and perhaps have a look at it with depends.exe or some other tool), it´s here: http://raumgeometrie.de/installer/ArchimedesGeo3DSetup1_3.exe Regards Thanks, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deploying on Vista vs. Deploying on XP
Radioman schrieb: your manifest uses 8.0.50727.762 but in dependecy viewer i actualy see loaded 8.0.50727.3053 so there is definitely some plugin/lib which is compiled using old version [Wink] Tanks a lot! Do you have a good idea (or does you dependency viewer show) which one this might be? I´d have to search all the dlls for the embedded manifest otherwise. If there´s no other way, I´ll do that. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deploying on Vista vs. Deploying on XP
Hi, my program loads on my machine without problems with the modified manifest. Also I wonder if the 8.0.50727.3053 version is really older, or newer, as 762 3053 (I don´t know how this is counted). Regards, Andreas Radioman schrieb: can you try replace Microsoft.VC80.CRT.manifest content with this and test it where your program don't loaded Code: ?xml version=1.0 encoding=UTF-8 standalone=yes? assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0 noInheritable/ assemblyIdentity type=win32 name=Microsoft.VC80.CRT version=8.0.50727.762 processorArchitecture=x86 publicKeyToken=1fc8b3b9a1e18e3b / file name=msvcr80.dll/ file name=msvcp80.dll/ file name=msvcm80.dll/ /assembly -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10640#10640 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how can i get a MINGW based source code?
Zhu liangxiong schrieb: hi my project need osg, and we use eclipse+QT+mingw. so i am not sure, whether i can compile the osg by mingw. and you guys know, please tell me ,and also how to. appreciate for any comment . abe.zhu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org You can. You need MSys, and set CMake to generate Makefiles for MSys/Mingw. Read the howto in the osg-wiki. I haven´t done so for some time, but it used to work without problems. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Money!
Sukender schrieb: Thanks Paul, I already googled around of course but I did not found revelant information (well not enough for me!). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 29 Dec 2008 04:41:30 +0100, Paul Martz pma...@skew-matrix.com a écrit: There have been web pages with such information (pay by job classification and postal code) for several years now. It's been a while since a looked. www.salaries.com comes to mind. Try a search with a tool like Google. 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 Hi, in the last issue of the german magazine 'ct (computer technology) there was an in-depth-article about that. I don´t know if you can get that magazine in france, and if you are fluent enough in german to understand it. I might be able to give you a summary within the next few days. Maybe there are journals like 'ct in other countries, too. Oh, I am just reading the article: It´s about self-employed people only. The average of people taking part in the survey was 59 905 € a year. When you are not self-employed, wages are usually lower, as in germanty your employer pays part of your fees to health-care-ensurance and other ensurances. On the other hand an experienced engenier will easily get more than 50 000 € a year, as I know from enginiers I know. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerWX example fails to build with debug
Mark Acosta schrieb: Hi guys, I'm running Fedora 10 and trying to build OSG from the latest svn version. Everything compiles fine except for the osgviewerWX example. I'm getting these errors: CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o: In function `wxStringBase': /usr/include/wx-2.8/wx/string.h:351: undefined reference to `wxOnAssert(wchar_t const*, int, char const*, wchar_t const*, wchar_t const*)' CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o:(.rodata._ZTV8wxOsgApp[vtable for wxOsgApp]+0x130): undefined reference to `wxApp::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*)' CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o:(.rodata._ZTV8wxOsgApp[vtable for wxOsgApp]+0x138): undefined reference to `wxAppConsole::OnAssert(wchar_t const*, int, wchar_t const*, wchar_t const*)' I looked into this a bit and the routines listed above are only defined if __WXDEBUG__ is defined. Looking at /usr/include/wx-2.8/wx/debug.h, it's not clear to me how __WXDEBUG__ is getting defined. I noticed that if I define NDEBUG that it will undefine __WXDEBUG__. The example compiles if I do this, but it's more of a kluge than a solution. I'm no wx expert. Maybe someone on the list has an idea of what's going on here and what the proper fix is. Mark ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi, it looks as if you didn´t link to the debug-libs of wx. Check your cmake-settings, if there is a difference between release and debug for the wx dependency. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Ralph Kern schrieb:
Hi Robert and others,
I now made an install of the OpenSceneGraph sources.
The FireFox plugin now works insofar it can show Andreas' website examples.
But I have two issues:
- there's some BadMatch XError Event generated (which I just ignore for now)
- when leaving the page, FireFox crashes with an segmentation violation,
and that's a big problem
Stack trace says:
#0 0xaff0ace0 in ?? ()
#1 0xb0734a60 in glXMakeCurrent () from /usr/lib/libGL.so.1
#2 0xb08d8324 in osgViewer::GraphicsWindowX11::makeCurrentImplementation ()
from /usr/local/lib/libosgViewer.so.48
#3 0xb0b9fd34 in osg::GraphicsContext::makeCurrent ()
from /usr/local/lib/libosg.so.48
#4 0xb0ba1147 in osg::GraphicsContext::close ()
from /usr/local/lib/libosg.so.48
#5 0xb08c1f59 in osgViewer::Viewer::~Viewer ()
from /usr/local/lib/libosgViewer.so.48
#6 0xb1e775d0 in osg::Referenced::unref (this=0xa400134)
at ../OpenSceneGraph/include/osg/Referenced:184
#7 0xb1e7763f in osg::ref_ptrosgViewer::Viewer::operator=
(this=0x9afe590,
ptr=0x0) at ../OpenSceneGraph/include/osg/ref_ptr:54
#8 0xb1e75e46 in nsPluginInstance::shut (this=0x9afe580) at plugin.cpp:320
#9 0xb1e78ff3 in NPP_Destroy (instance=0xa1acd48, save=0xbffef4c4)
at npp_gate.cpp:86
#10 0xb78c054d in ?? () from /usr/lib/xulrunner-1.9.0.4/libxul.so
#11 0xb747e092 in ?? () from /usr/lib/xulrunner-1.9.0.4/libxul.so
#12 0xb747e174 in ?? () from /usr/lib/xulrunner-1.9.0.4/libxul.so
[...]
I already switched to SingleThreaded, but with no avail.
Hi Ralph,
thanks for porting the plugin. To me the stack-trace sounds as if
osgViewer tried to make the gl-context current that is no longer
existant. Maybe Firefox first deletes the window-context and then calls
the plugins destructor.
Maybe you could destroy the GL context actively here:
void nsPluginInstance::shut()
{
// We add DisableOpenGL
DisableOpenGL( mhWnd, hDC, hRC );
// subclass it back
SubclassWindow(mhWnd, lpOldProc);
mhWnd = NULL;
mInitialized = FALSE;
}
instead of waiting for the Viewers destructor to do it.
Regards,
Andreas
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Ralph Kern schrieb: hi Andreas, I made some first improvements by removing the viewer-setupViewerAsEmbeddedInWindow() and instead leaving the OpenGL initialization to osgViewer::GraphicsWindowWin32(). This is a first step towards an easier Linux transition. You find attached the modified plugin.cpp/plugin.h By the way: can you change the License in plugin.cpp to the standard OSG Public License or at least LGPL? I am not in favor of GPL because it is quite strict against any commercial usage pattern. regards Ralph Thanks Ralph. I hereby formally entitle you to change the license, it was an error of mine. Regards, Andreas Andreas Goebel schrieb: Not yet. I took a look over the weekend on the part of porting to linux. It should be just some easy changes to the plugin code, but the mozilla developper pages are a bit puzzling with regard to plugin development. There are many developpers out there making FF extensions, but only some dealing with plugins, besides the big ones (Flash/PDF/...) It seems that the includes used by Andreas to produce the win32 part are not the ones currently used for FF linux dev. So it might take some more effort to dig in the headers. I guess I might have some time in January to dig deeper in this subject. For javascript support there would be some more extensions needed to the plugin. It also truly needs some keyboard interface for switching manipulators I'd propose Andreas should just publish its current efforts to the community, and the community can do the necessary enhancements. regards Ralph ___ Hi, due to the illness of my son I don´t know if I will be able to do integration work before christmas. So please find attached the current source with Visual C++ project file of the plugin. I worked with the given basic windows-example. It occured to me that the api for plugins seems to have changed, but still supports the old api. So either documentation, examples or both are in a bad state. I would be very pleased if someone would port this to other platforms / browsers or enhance it. Personally I only need a very simple plugin, so I won´t improve it further at the moment. Note that it must be packed together with the 3rd party deps into an xpi file, with plugins and plugin-dll in the same folder as the msvcrt and manifest (see my xpi as reference). Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ref_ptr needed for this?
Ulrich Hertlein schrieb:
On 15/12/08 6:45 PM, Andreas Goebel wrote:
TheGeometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POLYGON,0,numCoords));
...
I ask myself if this will give a memory-leak, or if this is ok, as the
pointer is directly passed to the TheGeometry-object (which lives in a
ref_ptr).
Exactly. Because it's passed to a ref_ptr it won't leak. You could
also assign it to a local non-ref_ptr and it still would be OK.
The more likely error case is stale objects (holding a non-smart
pointer to a deleted object), not memory leaks because the object is
held (and eventually deleted) in a ref_ptr inside OSG.
Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Thanks.
As the topic is related: Do you know where I have to set a breakpoint to
see if an object like a node really gets deleted?
I want to free some memory. Therefore I remove the node (and some other
stuff) from the scene-graph like this:
if (TheNode.get() ){
osg::Node::ParentList parents = TheNode-getParents();
for(osg::Node::ParentList::iterator pitr=parents.begin();
pitr!=parents.end();
++pitr)
{
(*pitr)-removeChild(TheNode.get());
}
}
And then remove the reference like this:
TheNode= NULL;
So if I really got all references removed, it should delete the node, right?
I have the impression that the node doesn´t get deleted (I created some
hundred nodes for testing and removed them this way, memory-consumption
didn´t go down), so either my approach is wrong, or I forgot some
reference somewhere.
Regards,
Andreas
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Robert Osfield schrieb: Hi Adrian, It's windows only right now. I haven' used it as I'm using Linux but I doubt that it does support javascript as this would require some kind of publishing of interface to the viewer which I didn't spot on review of the code. Robert. Right. As my son is ill right now and cannot go to the kindergarten, I cannot really work at the moment. I´ll integrate the plugin with cmake within this week, and then interested people can add linux support and scripting. There is an example on how to do the scripting in the firefox source-tree. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ref_ptr needed for this?
if (TheNode.get() ){
osg::Node::ParentList parents = TheNode-getParents();
for(osg::Node::ParentList::iterator pitr=parents.begin();
pitr!=parents.end();
++pitr)
{
(*pitr)-removeChild(TheNode.get());
}
}
And then remove the reference like this:
TheNode= NULL;
So if I really got all references removed, it should delete the node,
right?
I have the impression that the node doesn´t get deleted (I created
some hundred nodes for testing and removed them this way,
memory-consumption didn´t go down), so either my approach is wrong, or
I forgot some reference somewhere.
I´ve got this working now. It seems that osg nodes have a small memory
footprint, so I have to remove a big lot of them to see an effect.
Regards,
Andreas
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ref_ptr needed for this?
Hi, I have a construction like this: TheGeometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POLYGON,0,numCoords)); which is inspired by an osg- example. I ask myself if this will give a memory-leak, or if this is ok, as the pointer is directly passed to the TheGeometry-object (which lives in a ref_ptr). Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Hi, as the plugin started to work after using SetDllDir, this made me confident that I could package it not to require the additional download of the MSRedist. I have now done so, and on my test-machine withoug redist, it works. So could you please uninstall the plugin, download again from raumgeometrie.de/testplugin/osgviewer.xpi, and test it with raumgeometrie.de/testplugin/gallery.html In case you downloaded the redist first, please uninstall it (unless you need it for something else). The background - if others encounter this problem: When you start a program (!), the dir the program lies in is automatically added to the dll-search-path. When you load a dll during runtime from another program, the dl-dir is not automatically added to the dll-search-path. By adding the toolkit-dir to the osgFilePath, the plugins were found, but the plugins themselves didn´t find their dependencies. Thus, if you pack your osg-program into a dll, you will probably always have to use the SetDllDir windows command, or set your path. or install the dlls in a system-directory. I think mine is the cleanest solution, as one does not have to pollute system-dirs with dlls, and use exactly the dlls needed for the program. Regards, Andreas P.S.: You can, of course, use this plugin to display all file-formats that osg supports. For this, the other plugins would have to be packed into the xpi, too. If one needs this, just put the plugins there, or mail me, if you don´t have this compiled with msvc 8.0 sp1) PPS: This plugin has been downloaded 343 times so far. As I will Open-Source it and give it away for free, it would be really nice if you reported if it works. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap is wiping out ambient light
Richard Baron Penman schrieb: hello, when I add a shadow map to my scene it wipes out the ambient lighting. Searching the archives I noticed a thread from May with the same problem: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2008-May/011559.html But the discussion in that thread ended without resolution. Has there been progress on this issue? Or is there a neat work around? v2.6.1 Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi, I programmed a workaround. See the results here: http://upload.wikimedia.org/wikipedia/en/d/d7/ParaboloidWithShadow.png It was quite complicated, I needed to program a custom vertex shader for this to work. I might make a submit to osg within the next few weeks. When I did this I made quite some nasty hacks to osgShadow, that were not ready to submit, I´d have to rework it. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
Hi, I think that the CMake build-system is a very good one. Maybe a simple solution would be: - integrate a 3rd-party-plugins-directory - those plugins are turned off by default in the CMake-build, like the wrappers at the moment At wxWidgets they do that, too. The scintilla-wxWidgets component, for instance, is not built by default, but is distributed with wx, so one can build it easily. A 3rd party-programmer who wants to write a plugin should have a step-by-step guide on how to integrate the plugin with osg and cmake. Then he or she sends it to Robert, he reviews that, and adds it to 3rd party directory or not. What I would need, for instance, to do this with the small firefox-plugin, is an example-based guide on how to integrate this into osg. I am not a professional programmer, I have my regular job I earn money with, so I don´t have the time to read the whole cmake-manual. What I would also like to have is the 3rd-party-libs in the osg-core distribution. Like wxWidgets has ... This would, for instance, have made it easy for me to test if linking statically against the c-runtime would work when all 3rd party bins did that. But I don´t have time to assemble all the 3rd party libs (which is especially hard on windows, would be much easier on linux) to go and try this. So if this was easy enough, I sure would like to integrate my plugin into the 3rd-party folder. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Ralph Kern schrieb: Hi Andreas, now all 6 models show on my XP SP3 machine. But I'd guess it's more to do you now include osgSim and osgTerrain in your package. Good progress. regards Ralph No, this alone didn´t do the trick. The ive plugin doesn´t find it´s dependencies if they are not in the dll search path. Godd that it works, though. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Ralph Kern schrieb: hi Andreas, and more wonderful news: I repackaged your xpi with minVersion set to 2.0 and it runs and displays all 6 models on - Vista 32 Bit with FF 2.0.0.18 - Vista 64 Bit with FF 2.0.0.17 Es geht voran! regards Ralph Great! I´ll change it in my install.rdf, too, and upload it again. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
I'm afraid I have no expertise with VisualStudio linking requirements, so I have to defer to others with that expertise for moulding our CMake build system and any 3rd party binaries for windows. I presume Lilinx has come across these same issue and resolve them somehow, so perhaps he might be able to provide some guidance/fixes to the CMake build/dependencies to get this working. Robert. I guess that Lilinx has used the CMake default-setting, which is to link against the runtime-libs dynamically. I think that this is not useful, as a static build should depend on - if possible - nothing. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Text at fixed position on screen
Hi Renan, the tip was to look at the osgHud example. What you need are multiple cameras. One moves when navigating in the scene, the other doesn´t. This is done in osgHud. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Hi Ralph, Ralph Kern schrieb: Hi Andreas, worked well on my XP SP 3 System with Firefox 3.0. But the lower 3 panes start empty. Could you try that again? I changed something with the models. On my Vista system I was stopped because of the installed Firefox 2.0.18 which is declared not to be supported by your plugin package. Guess it would work if minVersion in install.rdf is set to 2.0 Could you try that? I don´t have Firefox 2.0 installed, so can´t test it. Just unzip the xpi, change the rdf, zip + install again. Note to your license question: Your own license note in plugin.cpp is stated to be GPL instead of LGPL. The OSG license is normally LGPL compatible. Yes, I´ll change that. Thanks for the reply, Andreas regards Ralph Andreas Goebel schrieb: Hi all, Open tasks: Port this plugin to linux and mac. Implement keyboard-handling or whatever you like. Please report if all works fine! Robert, I don´t know how I should publish this. I even don´t know if I got that license-thing right or if I should choose another license. I think because the usage of the mozilla code it must be lgpl. You can add it to the osg-examples if you like, but it depends (just like osgbrowser) on the firefox and gecko sources (one only needs headers, though). Ok, have fun with the plugin, test it and improve it! Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Jason Beverage schrieb: I'm having the behavior as Gerrick on my Vista machine w/ FireFox 3. Jason @Gerrick Jason: Did you install the redistributables? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Jason Beverage schrieb: Hi Andreas, Yes, I installed the VC redistributables. Not sure what is going on. Thanks! Jason Hi, this is frustrating. Those problems sometimes it works, sometimes it doesn´t are hardest to fix. I have considered static linking, yes, but I was afraid to open another pandoras box. I had tried static linking some time ago, and then it used to be a pain. Is there an up-to-date howto about static linking the osg, and how to use those macros? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Robert Osfield schrieb: Hi Andreas, On Mon, Dec 8, 2008 at 4:50 PM, Andreas Goebel [EMAIL PROTECTED] wrote: Is there an up-to-date howto about static linking the osg, and how to use those macros? The only guide right now is the osgstaticviewer example. Robert. That looks like a good example. I´ll use this as inspiration and try a static build. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Robert Osfield schrieb: Hi Andreas, On Mon, Dec 8, 2008 at 4:50 PM, Andreas Goebel [EMAIL PROTECTED] wrote: Is there an up-to-date howto about static linking the osg, and how to use those macros? The only guide right now is the osgstaticviewer example. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi Robert, I tried the static build, and it failed. I think I know why it failed: I don´t see the sense in trying a static build with a dynamic linked msvcrt. So I changed the settings in CMake from Multithreaded dynamic (/MD) to multithreaded static (/MT). Now when I build (at last) the osgstaticviewerexample I get tons of errors of multiply defined functions that are both defined in msvcrt.dll and in the static version. This means, that something (a 3rd party for sure) still links to the dynamic msvcrt. What do you think, shouldn´t the static build use a static runtime library? Or am I missing something here? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Jean-Sébastien Guay schrieb: Hi Andreas, Its so strange that the other plugins find the redist, but the curl plugin doesn't. I think the distinction is that the other plugins are only C libraries, whereas curl has C++ code. The redist is for C++. And I've seen the problem of plugins being found but then failing to load, and it was always caused by dependencies not being found at load time. So you just need to figure out where to place them for them to be found. I think you're on the right path. Hope this helps, J-S Thanks for cheering me up! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg firefox plugin alpha
Hi, I have changed a little bit in the xpi and in the plugin itself. It now not only adds the plugin-directory to the osg-file-path, but to the windows-dll-search-path. This worked at least on my machine to enable .ive-support without having the osg-libs in your path. Please: Those people who didn´t see the lower three models, uninstall the old plugin, install the new one and try. Note that that function (named SetDllDirectory ) is only available from WinXP SP1 onwards, so this plugin won´t work with older windows versions. I think that only very few people are using older windows now. Hope this works ... Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Sukender schrieb: Hi Andreas, I strongly suggest you to use (well, "keep") SP1 since dependencies use it, and as it seems to be no reason keeping non-SP1. Your problem is maybe about how "side-by-side" assemblies are used under Windows (XP, Vista...). You may document yourself on that subject. You roughly have to know that before Win2000, Windows tries to load DLLs looking in the PATH. But after 2000, DLLs can also be located in special directories, so that different versions of the same DLL can coexist (See my project doc below). If you have problems with MSVC *runtimes*, have a look to: - http://msdn.microsoft.com/en-us/library/ms235299(VS.80).aspx - http://msdn.microsoft.com/en-us/library/ms235291(VS.80).aspx - And my project doc (I already posted this link but maybe this gonna be useful): http://pvle.svn.sourceforge.net/viewvc/pvle/trunk/Doc/Guides/Deploying%20a%20VisualC%2B%2B%20application.txt?view=markup . It's about how I need to do things for my engine under Windows. I personnaly chose to copy runtimes in a "Microsoft.VC80.CRT" subdir. You can also try to install redistribuables for VC8 SP1. Hope it helps. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sun, 07 Dec 2008 00:31:23 +0100, Andreas Goebel [EMAIL PROTECTED] a écrit: Hi Sukender, interesting doc. I have supplied the redistributables, but in the same directory, not in a subdir. Does this make a difference? And: "x86/Microsoft.VC80.CRT" you specify that directory. Does this mean it has to be a subdir "x86" with another subdir "Microsoft.VC80.CRT", and that containing the dlls and the manifests of the redist, or should the manifests be in the same directory as the program, and the rest in the subdir? Note that in my case the thing is very complicated: - the program works on my machine - on another machine libcurl fails to load. When using debug-level warings one sees, that it is found in the right location, but fails to load. Unfortunately it doesn´t tell why it fails. It even fails when I put everything in my path. If I construct a testcase where libcurl is not needed, everything works. If I construct a testcase where I use osgviewer to load using libcurl, everything works too. It would not work at all if the redist was not found. This is on manifest-hell of a problem. I am not even sure if it is a manifest-problem, it might be something completely different. Regards, Andreas Hi all, now I´ve installed Service Pack 1 for MSVC, rebuilt all, and still on the other system the plugin fails to work. I use MSys to get a console, and catch debug-messages, and it simply states DynamicLibrary: Failed loading ...curl.dll. I have checked all dependencies with Dependency Walker, everything is in place. How can this be? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Hi again, I ´ve downloaded the redist for SP1. Now it works on the other machine, too. Problem: How could I package this that the curl-plugin does find the assemblys? If I don´t manage this, I'll have users to download the redist-package. Its so strange that the other plugins find the redist, but the curl plugin doesn't. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Hi, on my non-dev system the curl-plugin doesn´t load. Any ideas why this could be? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Hi all, now I´ve installed Service Pack 1 for MSVC, rebuilt all, and still on the other system the plugin fails to work. I use MSys to get a console, and catch debug-messages, and it simply states DynamicLibrary: Failed loading ...curl.dll. I have checked all dependencies with Dependency Walker, everything is in place. How can this be? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Hi, I am busy packing the plugin. My question: I´d like to keep in lean and mean. So I´d like to know to which osg-libs it is essential to link to be able to load simple osg-files with textures and no effects. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Robert Osfield schrieb: HI Andreas, Nice to see the plugin work coming along. The setUpViewerAsEmbeddedInWindow calls tricks the viewer into thinking that it has a valid graphics context, but in reality the GraphicsWindowEmbedded that this call creates is just a non op for all makeCurrent/swapBuffer calls, which means the viewer itself can't do these operations. This scheme only works when you have one context per viewer and run the viewer single threaded, and the app that calls viewer.frame() creates it's own graphics context and makes it current, and does the swap buffers call itself. The Embedded functionality of osgViewer does make it extremely easy to graft an viewer into an code that provides the graphics context, but it is limiting - you won't be pbuffer support, or any multi-window/context support, nor threading support, but for a browser this possible isn't to much of an issue as you aren't likely to be drive a full blow simulation from a browser. To get get the full capabilities of osgViewer then using the window inheritance features of osgViewer would be the way forward - here you'd like the browser provide the parent widget that osgViewer will create it's own OpenGL GraphicsContext within. This is typically more awkward to code as you have to go get the native window handle, but if this is possible then you should be able to code up a solution similar to the osgviewerMFC example. Robert. Hi Robert, in my opinion those web-plugins should function as a teaser making people think: That looks cool, lets try the application. Thus the embedded-functionality will be enough for me. I am now packaging the plugin and encounter a problem: The plugin starts (meaning that the core osg-dlls are found), but it does not find the osg-plugins (I have removed osg from my path for testing reasons). Usually when you start an osg-application and put the plugins into the applicaiton-folder (or below into the correct plugin-folder) they are found. Maybe this is different here, as the plugin itself is not an application but a dll. Any idea how I could trick the osg to make it find the plugins? The problem is that I can run the plugin in firefox only, it´s hard to debug there. Regards, Andreas On Thu, Dec 4, 2008 at 8:32 PM, Andreas Goebel [EMAIL PROTECTED] wrote: Hi all, as posted above in the thread reading a node file from http, I have assembled a small firefox-plugin to display osg-files. It is not yet packed, I will have to carefully read the documentation on how to do this (I would like the plugin to be downloaded automatically when a user does not have it). If someone would like to try it: - it´s windows only, firefox 3.04 only (newer versions should work) - you must have osg2.7.6 installed, bin-dir in your path. The plugin is compiled with VC 2005, so maybe only this will work - download the plugin here: http://raumgeometrie.de/testplugin/npbasic.dll (it´s so small, not even worth zipping) - testpages here: http://www.raumgeometrie.de/testplugin/gallery.html I attach the source to the plugin. But be aware of the fact, that the most time-consuming step of building this plugin was to get the basic-example I started with to compile. I will send a zip with project-file later on. Note that the sample-plugins shipped with the firefox-source do use completely different function-names than those described in the plugin-api that can be read on the firefox-dev site. I sticked to the functions named in the sample (and had to research with google for some things). I don´t know if their own samples are outdated, or if the api-documentation is outdated or whatever. The thing that does not (!) work is to put several instances of the plugin on one page. Maybe robert can jump in and explain how the window = viewer-setUpViewerAsEmbeddedInWindow(100,100,800,600); viewer-setSceneData(loadedModel.get()); (which works like next to magic for me) does find it´s OpenGL-context. Probably this is not so easy when there is more than one context. But even if this won´t work, it´s quite a nice plugin so far. Read the source as an inspiration on how very easy this was - hopefully someone can jump in and do this for linux and mac. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Robert Osfield schrieb:
Hi Andreas,
I had a quick review of the plugin.cpp you posted and it's tiny, which
is definitely a good thing ;-)
I see that code you are using is being passed in a native window
handle so there is probably a reasonable chance that we could just use
this with and have the osgViewer create the graphics context using the
window inheritance feature. This might be a way of make the code more
portable across platforms as well as it would reduce the amount of
platform specific code. This is a bridge that could be crossed later
though.
In the review of the code I spotted that the plugin.h was referenced,
but you didn't include the plugin.h. Could you post this. Without
the header I can't say for sure, but my guess is that the OSG related
global variables could be moved into the nsPluginInstance class that
you've created.
Do you have particular web documentation you've been using for inspiration?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Find the attached files. I have already refactored this not to use
global variables. The sources I used are here:
http://www.codeproject.com/KB/openGL/FirefoxOpenGL.aspx
and the osgglut-example.
Regards,
Andreas
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* * BEGIN LICENSE BLOCK *
* Version: MPL 1.1/GPL 2.0/LGPL 2.1
*
* The contents of this file are subject to the Mozilla Public License Version
* 1.1 (the License); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
* http://www.mozilla.org/MPL/
*
* Software distributed under the License is distributed on an AS IS basis,
* WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
* for the specific language governing rights and limitations under the
* License.
*
* The Original Code is mozilla.org code.
*
* The Initial Developer of the Original Code is
* Netscape Communications Corporation.
* Portions created by the Initial Developer are Copyright (C) 1998
* the Initial Developer. All Rights Reserved.
*
* Contributor(s):
*
* Alternatively, the contents of this file may be used under the terms of
* either the GNU General Public License Version 2 or later (the GPL), or
* the GNU Lesser General Public License Version 2.1 or later (the LGPL),
* in which case the provisions of the GPL or the LGPL are applicable instead
* of those above. If you wish to allow use of your version of this file only
* under the terms of either the GPL or the LGPL, and not to allow others to
* use your version of this file under the terms of the MPL, indicate your
* decision by deleting the provisions above and replace them with the notice
* and other provisions required by the GPL or the LGPL. If you do not delete
* the provisions above, a recipient may use your version of this file under
* the terms of any one of the MPL, the GPL or the LGPL.
*
* * END LICENSE BLOCK * */
#ifndef __PLUGIN_H__
#define __PLUGIN_H__
#include pluginbase.h
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
#include windows.h
#include windowsx.h
class nsPluginInstance : public nsPluginInstanceBase
{
public:
nsPluginInstance(NPP aInstance);
~nsPluginInstance();
NPBool init(NPWindow* aWindow);
void shut();
NPBool isInitialized();
// locals
const char * getVersion();
void mousebutton( int button, int state, int x, int y );
void mousemove( int x, int y );
char* filename;
int width;
int height;
HDC hDC;
HGLRC hRC;
osg::ref_ptrosgViewer::Viewer viewer;
private:
NPP mInstance;
NPBool mInitialized;
HWND mhWnd;
osg::observer_ptrosgViewer::GraphicsWindow window;
};
#endif // __PLUGIN_H__
/*OpenSceneGraph Firefox-plugin
*License: GPL 2.0
*Based on Work by Mozilla.org and OpenSceneGraph osgviewerGLUT-sample by Robert Osfield
*(c) Andreas Goebel 2008
*/
#include plugin.h
#include gl/gl.h
#include stdlib.h
/*
//Global Variables
osg::ref_ptrosgViewer::Viewer viewer;
osg::observer_ptrosgViewer::GraphicsWindow window;
char* filename;
*/
//Functions that translate the Windows Mouse-Events to osg-events
void nsPluginInstance::mousebutton( int button, int state, int x, int y )
{
if (window.valid())
{
if (state==0) window-getEventQueue()-mouseButtonPress( x, y, button+1 );
else window-getEventQueue()-mouseButtonRelease( x, y, button+1 );
}
}
void nsPluginInstance::mousemove( int x, int y )
{
if (window.valid())
{
window-getEventQueue()-mouseMotion( x, y );
}
}
//
//
// general initialization and shutdown
//
NPError NS_PluginInitialize()
{
return NPERR_NO_ERROR;
}
void
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
You will probably have to explicitly provide the library path to go searching for the plugins. You could either call use the OSG_LIBRARY_PATH env var or set the search path manually via: osgDB::setLibraryFilePathList(mypath) Or prepend the path to the plugins via: osgDB::getLibraryFilePathList().push_front(mypath); I´d sure like to do this, but I can´t figure out the path. I don´t know beforehand where Firefox will install the plugin, the path might be different on all machines. I tried various functions, but all only return me the path to the firefox-executable, not the plugin-dll. I consider building a setup with inno-setup, where I can extend PATH. Any windows-gurus or firefox-gurus that have an idea how I could get the path to the plugin? Regards, Andreas 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] Very simple Firefox-Plugin to display osg-files
Andreas Goebel schrieb: You will probably have to explicitly provide the library path to go searching for the plugins. You could either call use the OSG_LIBRARY_PATH env var or set the search path manually via: osgDB::setLibraryFilePathList(mypath) Or prepend the path to the plugins via: osgDB::getLibraryFilePathList().push_front(mypath); I´d sure like to do this, but I can´t figure out the path. I don´t know beforehand where Firefox will install the plugin, the path might be different on all machines. I tried various functions, but all only return me the path to the firefox-executable, not the plugin-dll. I consider building a setup with inno-setup, where I can extend PATH. Any windows-gurus or firefox-gurus that have an idea how I could get the path to the plugin? Regards, Andreas Or can I force osg to load the plugins on startup? I remember something about fake .lib-files for the plugins, is that right? How can I build them? Regards, Andreas Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Simon Hammett schrieb: On windows you can call GetModuleFileName which retrieves the fully qualified path to the dll/exe in which the calling function resides. Sadly no, it returns the path to firefox.exe, already tried that. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Simon Hammett schrieb: 2008/12/5 Andreas Goebel [EMAIL PROTECTED]: Simon Hammett schrieb: On windows you can call GetModuleFileName which retrieves the fully qualified path to the dll/exe in which the calling function resides. Sadly no, it returns the path to firefox.exe, already tried that. The only way I can think of that GetModuleFileName would fail is if people start moving code around in memory. Seems unlikely firefox would do that. Try EnumProcessModules then to get the module handle to your dll. Then you can use GetModuleFileName with the correct handle. I´ll have to stop working on that till tonight. Maybe you could give me a code-snippet, I am no expert-windows-api-programmer, I prefer using wxWidgets. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Did you look for the current directory? I'd guess the Plugin Manager
sets it to the plugin dir.
No.
Otherwise if you can't get the DLL instance of your plugin to pass to
GetModuleFileName(), you can try another trick:
HINSTANCE handle =LoadLibrary( name of your plugin dll here );
if (handle)
{
GetModuleFileName(handle, filename, sizeof(filename));
PathRemoveFileSpec(filename);
FreeLibrary(handle);
}
This should work because the list of loaded DLLs is searched first by
LoadLibrary().
This works! Only one should not free the handle, as the lib is
(probably) not loaded again, this gives a crash.
I have then used Luigis way of extracting the path, as I do not have the
header to PathRemoveFileSpec.
I´ll pack this in the late evening, seems to be working now.
Thanks for your help,
Andreas
regards Ralph
___
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] Very simple Firefox-Plugin to display osg-files
Hi all, I have now packed the plugin and the necessary osg-libs into an xpi-file. You can use http://raumgeometrie.de/testplugin/test.html to download the plugin and test it. Use the source-view of the html-page to see how it is embedded. Note the following problem: Even though I have provided the plugin-url in the embed-tag, the plugin does not download when clicking on the icon. The link below (Hier Plugin, means plugin here) does work though. In the mozilla-docs it says that I have to register the mime-type with .htaccess, but either this doesn´t work or I made another mistake. Maybe someone can give insight on this. The plugin-package is lean and mean, meaning that it only works for osg and ive-files with no effects and jpg, gif or png-textures. For it to work with more filetypes I would have to pack all osg-plugins into the package. Please test it and report if it works. It would be great if someone could test on a machine that has no developer-tools installed, as dll-problems will occur here more likely than on a dev-machine that has all kinds o packages installed. Regards have fun, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Jean-Sébastien Guay schrieb: Hello Andreas, Nice work, it seems to work except the below: Note the following problem: Even though I have provided the plugin-url in the embed-tag, the plugin does not download when clicking on the icon. The link below (Hier Plugin, means plugin here) does work though. Yes, that's confusing, but with the link it works. I suspect it's just a small configuration issue, but I don't have any idea what that might be. ... neither do I. I have tried a lot ... I will have to register at mozdev.org, I think, to ask about this. Please test it and report if it works. How do you tell it to load a model? I get just the blue background. That´s a mistake. Look at the page source, it should load a model. If it does not, it means that something is missing. Probably, as I fear, a dll that my system has and yours don´t. I´ll have to look into that. Regards, Andreas Again, good work, and I look forward to lots of cool browser apps in the future using this! J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Jean-Sébastien Guay schrieb: Hi Andreas, That´s a mistake. Look at the page source, it should load a model. If it does not, it means that something is missing. Probably, as I fear, a dll that my system has and yours don´t. I´ll have to look into that. Well, all I get are a few message boxes (I guess those are debugging messages :-) ) and then an empty osgviewer. Do the OSG error messages go to your webserver logs? Perhaps you could redirect osg::notify's streams to print them into the browser? Or a console in the OSG viewer... J-S Hi, my mistake, sorry. I put the new plugin only to my local firefox, not into the xpi-archive. Please re-download in one minute (21:37 in my timezone). Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Hi all, I have now repackaged the xpi. I have turned my old laptop, that does not have dev-libraries, and tried it, and it didn´t work. On my dev-machine it works, even if I remove osg from my path. But: I have lots of libs in my path and in my windows-system. Please download the xpi from raumgeometrie.de/testplugin/test.html (link on bottom) and tell me if it works. If it doesn´t, please give hints what might be wrong. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outof rangeinVertexPaletteManager
Hi Paul Robert, I have now done the following: - changed my code to use DrawElements, which was easy in my case - fixed a bug in flt-exporter with the help of Paul, sent this file to paul Thanks for your help, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Math problem relative to OSG
Hi, sounds complicated. You could do the following: You don´t need to do any translations to your camera, you only need to apply the same rotation as to your node, but not to the absolute position of your camera, but to the relative position of your camera. NodePosition: Old Position of node. Camera Position: OldPosition of camera RelativePosition = CameraPosition - NodePosition NewRelativePosition = Rotate(RelativePosition) NewCameraPosition = NewNodePosition + NewRelativePosition Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Math problem relative to OSG
Vincent Bourdier schrieb: Hi, Hmm, complicted yes, but... 2008/12/4 Andreas Goebel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi, sounds complicated. You could do the following: You don´t need to do any translations to your camera, you only need to apply the same rotation as to your node, but not to the absolute position of your camera, but to the relative position of your camera. NodePosition: Old Position of node. Camera Position: OldPosition of camera RelativePosition = CameraPosition - NodePosition I did : osg::Vec3d vt(mat.getTrans() - getEyePoint()); But mat.getTrans is not the same as your node position, right? This is only the same if the node was at (0,0,0), and then it is only right the first time. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Reading a node file from http
Hi, I am just writing a firefox-plugin for osgViewer, which was surprisingly easy so far. I already have got old bessy in firefox, but it is loaded from a local file. How can I load files from http? I guess that I either have to interact somehow with the firefox plugin-api and stream it somehow to my plugin, or something else that I am not aware of. If someone has done something of the kind, please give me a pointer at where to look for. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Very simple Firefox-Plugin to display osg-files
Hi all,
as posted above in the thread reading a node file from http, I have
assembled a small firefox-plugin to display osg-files.
It is not yet packed, I will have to carefully read the documentation
on how to do this (I would like the plugin to be downloaded
automatically when a user does not have it).
If someone would like to try it:
- it´s windows only, firefox 3.04 only (newer versions should work)
- you must have osg2.7.6 installed, bin-dir in your path. The plugin is
compiled with VC 2005, so maybe only this will work
- download the plugin here:
http://raumgeometrie.de/testplugin/npbasic.dll (it´s so small, not even
worth zipping)
- testpages here: http://www.raumgeometrie.de/testplugin/gallery.html
I attach the source to the plugin. But be aware of the fact, that the
most time-consuming step of building this plugin was to get the
basic-example I started with to compile. I will send a zip with
project-file later on.
Note that the sample-plugins shipped with the firefox-source do use
completely different function-names than those described in the
plugin-api that can be read on the firefox-dev site. I sticked to the
functions named in the sample (and had to research with google for some
things). I don´t know if their own samples are outdated, or if the
api-documentation is outdated or whatever.
The thing that does not (!) work is to put several instances of the
plugin on one page. Maybe robert can jump in and explain how the
window = viewer-setUpViewerAsEmbeddedInWindow(100,100,800,600);
viewer-setSceneData(loadedModel.get());
(which works like next to magic for me)
does find it´s OpenGL-context. Probably this is not so easy when there
is more than one context.
But even if this won´t work, it´s quite a nice plugin so far. Read the
source as an inspiration on how very easy this was - hopefully someone
can jump in and do this for linux and mac.
Regards,
Andreas
/*OpenSceneGraph Firefox-plugin
*License: GPL 2.0
*Based on Work by Mozilla.org and OpenSceneGraph osgviewerGLUT-sample by Robert Osfield
*(c) Andreas Goebel 2008
*/
#include windows.h
#include windowsx.h
#include plugin.h
#include gl/gl.h
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
//Global Variables
osg::ref_ptrosgViewer::Viewer viewer;
osg::observer_ptrosgViewer::GraphicsWindow window;
char* filename;
//Functions that translate the Windows Mouse-Events to osg-events
void mousebutton( int button, int state, int x, int y )
{
if (window.valid())
{
if (state==0) window-getEventQueue()-mouseButtonPress( x, y, button+1 );
else window-getEventQueue()-mouseButtonRelease( x, y, button+1 );
}
}
void mousemove( int x, int y )
{
if (window.valid())
{
window-getEventQueue()-mouseMotion( x, y );
}
}
//
//
// general initialization and shutdown
//
NPError NS_PluginInitialize()
{
return NPERR_NO_ERROR;
}
void NS_PluginShutdown()
{
}
/
//
// construction and destruction of our plugin instance object
//
nsPluginInstanceBase * NS_NewPluginInstance(nsPluginCreateData * aCreateDataStruct)
{
if(!aCreateDataStruct)
return NULL;
nsPluginInstance * plugin = new nsPluginInstance(aCreateDataStruct-instance);
filename = aCreateDataStruct-argv[0]; //This structs holds tha value passed to the plugin with embed
return plugin;
}
void NS_DestroyPluginInstance(nsPluginInstanceBase * aPlugin)
{
if(aPlugin)
delete (nsPluginInstance *)aPlugin;
}
//
// nsPluginInstance class implementation
//
nsPluginInstance::nsPluginInstance(NPP aInstance) : nsPluginInstanceBase(),
mInstance(aInstance),
mInitialized(FALSE)
{
mhWnd = NULL;
}
nsPluginInstance::~nsPluginInstance()
{
}
static LRESULT CALLBACK PluginWinProc(HWND, UINT, WPARAM, LPARAM);
static WNDPROC lpOldProc = NULL;
void EnableOpenGL(HWND hWnd, HDC * hDC, HGLRC * hRC);
void DisableOpenGL(HWND hWnd, HDC hDC, HGLRC hRC);
HDC hDC;
HGLRC hRC;
NPBool nsPluginInstance::init(NPWindow* aWindow)
{
if(aWindow == NULL)
return FALSE;
mhWnd = (HWND)aWindow-window;
if(mhWnd == NULL)
return FALSE;
// subclass window so we can intercept window messages and
// do our drawing to it
lpOldProc = SubclassWindow(mhWnd, (WNDPROC)PluginWinProc);
// associate window with our nsPluginInstance object so we can access
// it in the window procedure
SetWindowLong(mhWnd, GWL_USERDATA, (LONG)this);
//we add EnableOpenGL and SetTimer
EnableOpenGL( mhWnd, hDC, hRC );
SetTimer(mhWnd, 0, 1, (TIMERPROC) NULL); // no timer callback
//osg-related code:
//Node-file is read via http by libcurl:
osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFile(filename);
viewer = new osgViewer::Viewer;
window = viewer-setUpViewerAsEmbeddedInWindow(100,100,800,600);
viewer-setSceneData(loadedModel.get());
viewer-setCameraManipulator(new osgGA
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Hi, I have reviewed my own code and realized that, of course, the global variables were no good idea. I was not aware of the fact, that a plugin (the dll) is loaded only once, and each time the plugin is embedded, a new instance of the plugin-class is created. The global variables that live in the dll exist only once, thus it was not possible to display more than one model on a page. I have refactored this, now one can display several models on one page. There are some more issues, but I will work on that tomorrow. Regards, Andreas Screenshot: Two models on one page. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index out of rangeinVertexPaletteManager
Robert Osfield schrieb: Hi Andreas, I don't know if it fits what you require, but the osg::DrawElements*() primitive set types provide index support that is fully supported by OpenGL so works with the fast paths. The index support works for all per vertex attributes at the same time, so it's quite as flexible as vertex index arrays, so you may have to duplicate some vertex data that you previously didn't have to. Robert. Hi Robert, thank you very much, this might be exactly what I need. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index out of range in VertexPaletteManager
Paul Martz schrieb: This is a missing feature. The FLT exporter doesn't support the use of deprecated VertexIndices. It looks at your DrawArrays PrimitiveSet and assumes there are 96 vertices, but there are only 25, so it flags this as an error. You are welcome to add support for VertexIndices if you want, but spending time adding code to support something that you know will send you down the OpenGL slow path seems rather pointless. You'd be much better off changing your data to use DrawElements. -Paul ... sigh ... I didn´t know that this is deprecated. I just recently introduced the drawArrays, as I thought it was a good idea to share some vertices. Ok, so it´s easier to change code on my side. And what about the ShapeDrawables? Thanks for your answer, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Browser integration
Hello, I would like to embed an osgviewer to standard-browsers (firefox, ie, safari). I already saw Luigi Caloris great work osg4web, but this aims at a much larger scale than what I need. I would just like to embed quite small osg-files to a 3d-gallery. As I saw that browser-integration is on the osg-roadmap, I just wanted to know if there is an easy way to achieve this. If not, I would like to ask if embedding a very simple osg-app into a webbrowser is very difficult. osg is embeded nicely into several toolkits, so my naive approach would be to change one of the toolkit-examples to a browser-plugin-framework. Are there huge pitfalls I am likely to stumble in? If not, I might try this in the next weeks. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Browser integration
Hello Wang Rui, if this is all code needed, it is quite simple. Very nice! Thank you for posting this. Unfortunately I do not understand enough to see if this would be useful for me. Maybe my interest motivates you to translate your wiki (at least this part of it) to english, I am sure other users could benefit from it as well. Regards, Andreas Wang Rui schrieb: Hi, I have written an example before, which results in a very simple OCX file that displays local/http models and images. The website below is in Chinese but maybe you would like to look into some code. :) http://www.osgchina.org/projects/osgChina/wiki/Support/3rd/OSGandIE.php Wang Rui 2008/10/31 Andreas Goebel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hello, I would like to embed an osgviewer to standard-browsers (firefox, ie, safari). I already saw Luigi Caloris great work osg4web, but this aims at a much larger scale than what I need. I would just like to embed quite small osg-files to a 3d-gallery. As I saw that browser-integration is on the osg-roadmap, I just wanted to know if there is an easy way to achieve this. If not, I would like to ask if embedding a very simple osg-app into a webbrowser is very difficult. osg is embeded nicely into several toolkits, so my naive approach would be to change one of the toolkit-examples to a browser-plugin-framework. Are there huge pitfalls I am likely to stumble in? If not, I might try this in the next weeks. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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] Parameter ratio in osgUtil::LineSegmentIntersector::Intersection
Hello,
I need to sort out intersections that are very close to each other. So I
took a look at the LineSegmentIntersector::Intersection definition:
bool operator (const Intersection rhs) const { return
ratio rhs.ratio; }
typedef std::vectorunsigned int IndexList;
typedef std::vectordouble RatioList;
double ratio;
and saw that there is a ratio-parameter for sorting.
What is that ratio-parameter expressing? May I assume that points which
are very close to each other do have a ratio that is very close?
I guess that the other direction is not true: Points with a close ratio
might be apart.
So what I would do if my assumptions are true is first to test if an
intersection has a close ratio to the intersection before in the list.
If this is true, then I will test the distance.
Regards,
Andreas
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Parameter ratio in osgUtil::LineSegmentIntersector::Intersection
Paul Melis schrieb: Andreas Goebel wrote: What is that ratio-parameter expressing? May I assume that points which are very close to each other do have a ratio that is very close? I guess that the other direction is not true: Points with a close ratio might be apart. My impression so far has been that 'ratio' is the parameter more commonly named 't' when talking about a parametric line P, i.e. P(t) = segment_start + t * (segment_end - segment_start) Could be wrong though... Paul Reading more in the code I think so too. That´s good, so t is unique, and I can simply test t against epsilon. Thanks, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shape Intersection
Renan Mendes schrieb: Hi everyone, I need to detect when two shapes intersect and I need to know the point (or set of points) where it happens. I'm using shape drawables and I've been told that OSG doesn't have any support in that Hi Renan, why don´t you do it the mathematical way? What I mean by this is: If you have simple shapes like spheres, planes, triangles, boxes, then you can compute their intersection by using math alone, without the need of OpenGL or the scene graph. Like this: You have two spheres. The intersection is a circle. You can easily compute the midpoint, radius and normal vector of this circle. A book that covers most of those methods is Geometric Tools for Graphics. If you do it the graphic way, a sphere consists of triangles. If you intersect two spheres graphically, you intersect two sets of triangles and get a set of segments as a result. The plane-intersector in the OSG does it like this. This is very useful if you do not know what the objects you intersect with look like. But in your case (only simple shapes), I would compute it mathematically. But (no offence meant, just a hint) if you have problems computing the intersection of a line and a plane (which you said in another thread) then this will be quite difficult for you. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow::ShadowMap not reacting to changes
Jean-Sébastien Guay schrieb: Hello Raymond, Can you try to use a ref pointer instead of the regular pointer for osg::Shader* shader. I believe I encountered exactly this issue when working on the PSSM, please see a patch that I sent +/- a week ago. It has no effect, and anyways, it would not have explained why setAmbientBias did not take effect either... Anything else? Just to reiterate, only setTextureSize() takes effect, not setAmbientBias or addShader. Plus, it works in a straight OSG project (modified from the osgshadow example), but not in our application. So I'm just looking for possible explanations. I know fully that the problem is in our code, I'm just puzzled as to what could cause that. Thanks, J-S Hi, have you run the project with OSG_NOTIFY_LEVEL=debug? There you can see, if your shader-program is faulty. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mathematical foundations
Renan Mendes schrieb: Hi everyone, Since I'm new on the whole computer graphics world, I don't have the mathematical foundations needed to fully comprehend the geometric transformations involved in a scene graph and used by OSG in its methods. I'd like to ask anybody who knows about a good website that deals with this kind of subject. Thanks in advance. Renan M Z Mendes Hi Renan, I´d recommend the book Real Time Rendering, where the math basics are covered and an overview about realtime-graphics is given. In case this is too compressed for you, you would have to use a math-textbook, first. The problem with math-books is, that mathematicians will do far too much on the math side of things to be useful for you. Being a mathematician I don´t mind that, but maybe someone else could suggest a math book that is not too mathematical! Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating shapes under mouse cursor
Renan Mendes schrieb: In 3d coordinates... I know, we'll have to do something about the depth. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi Renan, what I do for this is the following: - compute the line behind the mouse cursor perpendicular to the screen. You will ned the transformation and view matrices for this - intersect this line with a plane parallel to the screen through the origin. You can use the line computed before as a normal vector for this plane The intersection gives a point that is a) behind the mouse b) as close to the origin as possible The choice for the depth might be another, but this one makes sense in some way! Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Development-system for Mac-OS
Hi, I am about to buy a mac to port my osg-based application to mac-os. One simple question: I read about compatibility-problems with the new Mac-OS (10.5, I think). Would it be better to buy a Mac running Mac-OS 10.4, and would programs compiled with this Mac more likely run on older and newer Mac´s? Sorry to ask this slightly offtopic question, but the people here are the most likely to know this. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development-system for Mac-OS
Berg, Michael schrieb: I don't think the problems weren't just 64-bit. About a month ago (), I posted a message with the subject Undefined Symbols in OSG on Mac OS X The OSG binary installer for Mac OS X 10.4 (the 10.4u SDK) *mostly* worked, but my applications would not compile if I made calls to osg::Image::readPixels() or osg::StateSet::setMode(). E. Wing replied that: = Yeah, Apple screwed up and broke binary compatibility between 10.4 and 10.5 when using OpenGL and C++. I have notes and binaries coming on this, but the short story is you can't use 10.4 built frameworks against the 10.5 SDK or you get the linking problems you see. Either switch to the 10.4u SDK on Leopard, or use a set of OSG frameworks built against the 10.5 SDK. = Anyway, once the Mac OS X 10.5 SDK (32-bit only) was released and I upgraded to it (http://www.openscenegraph.org/projects/osg/wiki/Downloads) it solved the linking problems I was having. If you look through the release notes for the 10.5 SDK, it mentions that Apple changes some of the types in the OpenGL headers, so OSG had to be rebuilt for that. Hi, thanks for the info. But does that mean that I would avoid those problems by simply using Mac OS 10.4 ? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development-system for Mac-OS
E. Wing schrieb: In my opinion, you are best off getting Leopard. Apple will not be updating OpenGL drivers for Tiger from this point on. Working OpenGL drivers is by far the most important aspect in my opinion. Thank you all, I summarize: I´d (probably) be best of with: - Mac OS 10.5 - but use 10.4 sdk to target both 10.4 and 10.5 right? I know that the slogan is think different, so that´s what I´ll have to do ... Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mouse Picking (again...)
I was going to attach the souce code to this message, but I've given up, for I know that what I really need is an understanding of the basics of mouse picking. but I mean the true and real basics. What I mean with basics? I need to understand every line of that pickhandler class for starters If not, at least an understanding on how to USE this class... Anyone's been through a similar situation and/or might be able to help me? Thank you Renan M Z Mendes Hi, I have been through exactly that, as I wrote a software for spatial geometry. See here: www.raumgeometrie.de I can assure you that the new pick-classes work perfectly well with shape Drawables, all my code is based on that. There must be a simple mistake on your side. But you might want to have a look at my software before reinventing the wheel. The basic function is: - your mouse is in screen-coordinates - the screen-coords wil have to be transformed back to world-coordinates (which is done automatically by a convenience function of the intersector) - you will have to make something three-dimensional of the two-dimensional screen-coordinates, usually using the near and far clip-planes (automatically done by the intersector) - now you have a segment that lies exactly behind your mouse-pointer - the segment is intersected with the node that is passed to it - (this is done roughly like this: Intersection tests are made for the bounding volumes of each node, if it intersects, one goes further down the tree until real geometry is met. Here intersection is calculated against all triangles) I use a LineSegmentINtersector, which works just perfectly for picking. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Collada dae plugin
Hello, I have built the dae-plugin on Windows with vc express as described in the wiki (i.e. changed cmakelists.txt), though I didn´t build collada myself. When I now run a program (with OSG_NOTIFY_LEVEL=debug), i see that it fails to load the plugin. I guess that I am missing some dlls or something. I used the prebuilt collada-dom binary. Any suggestions on how I can get this to run? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada dae plugin
Gordon Tomlinson schrieb: It might help diagnose the problem if you actually list or copy/paste the missing dlls error messages etc in your request for help, without those details its hard to say what the issue may be When the osg loads a plugin and this plugin needs other dlls there are no reports about those dlls (at least on my system). You just get a plain failed loading plugin In the meantime I found out by trying that iconv.dll was missing, and now I can use the collada-plugin. Is there a webbrowser-plugin for viewing .dae-files? Regards, Andreas __ Gordon Tomlinson Email : [EMAIL PROTECTED] YIM/AIM : gordon3dBrit MSN IM : [EMAIL PROTECTED] Website : www.vis-sim.com www.gordontomlinson.com __ Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival -Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Goebel Sent: Sunday, November 18, 2007 9:15 AM To: OpenSceneGraph Users Subject: [osg-users] Collada dae plugin Hello, I have built the dae-plugin on Windows with vc express as described in the wiki (i.e. changed cmakelists.txt), though I didn´t build collada myself. When I now run a program (with OSG_NOTIFY_LEVEL=debug), i see that it fails to load the plugin. I guess that I am missing some dlls or something. I used the prebuilt collada-dom binary. Any suggestions on how I can get this to run? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about Manifests
Likewise, in the OSG 2.2 win32 binary installer, I didn't want to include MS's redistributable installer. Instead I put a private assembly at %OSG_ROOT%/bin/Microsoft.VC80.CRT. To preserve the plugins in their separate directory, I added that assembly to the PATH (via the OSG_PATH envar) so the plugins could find it. Well, those redists have to get installed from somewhere, because they're not part of the OS. If you dont include them, then you're depending on some other app having installed them for you. While that's a pretty high probability, there's still a non-zero chance of failure. Hi Mike, I do include them, too, with a private assembly. What I meant was that I do not want to include the whole installer. That is a good tip with the OSG_PATH-variable, I will do that! Regards, Andreas cheers -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question about Manifests
Hello, has anything about the usage of manifest-files for osg changed with version 2.2 ? While everything works fine on my production-system, where visual c++ express files are installed, my installer for users doesn´t work anymore. I had included a trick into that installer to avoid having my users to install the visual c++ redistributables (I made them local into the program directory). Thank you, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PickHandler Class on Quick Start Guide
Paul Martz schrieb: My advice: Don't use ShapeDrawable to draw spheres. Use Geometry instead. The osgUtil Intersector classes work with Geometry because Geometry::accept() actually contains code. -Paul Hi, the lineSegment-intersector and the planeIntersector definitely work with shapeDrawables. For picking spheres in a scene I would use a lineSegmentIntersector. As for the polytopeIntersector in the example-code I don´t know, I haven´t tried that. ...except Robert has already publicly stated that the old line segment and plane intersection classes are now deprecated. In light of that, I would not advise developing any new code that uses them. I don´t think so. It´s the osgUtil::IntersectionVisitor that´s deprecated. The LineSegmentIntersector and PlaneIntersector are both quite new and derived, like the polytopeIntersector you use, from osgUtil::Intersector. The best solution is to not use ShapeDrawables -- ever. They are not well supported for anything other than drawing. The osg needs some replacement for standard-shapes like included in glut. In my case, the shapeDrawables do what I want, and thus I will use them! Reagards, Andreas -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PickHandler Class on Quick Start Guide
Paul Martz schrieb: My advice: Don't use ShapeDrawable to draw spheres. Use Geometry instead. The osgUtil Intersector classes work with Geometry because Geometry::accept() actually contains code. -Paul Hi, the lineSegment-intersector and the planeIntersector definitely work with shapeDrawables. For picking spheres in a scene I would use a lineSegmentIntersector. As for the polytopeIntersector in the example-code I don´t know, I haven´t tried that. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] textures and shader
Marcus Fritzen schrieb: Yes, of course, but I am quite a newbie and learning, just remember this ;) You can find the code at http://www.uni-koblenz.de/~mfritzen/osg/ What I want to do additionally, is combining per pixel lighting and shadows and therefore I need the vertex program, which is not doing what it should... Hi Marcus, did you find out some more about this issue? I would like to do something similar as you, and I also do not get the vertexShader to work as it should. Normal textures display correctly, but the shadow simply does not appear. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] textures and shader
Normal textures display correctly, but the shadow simply does not appear.
Regards,
Andreas
Hi,
I have solved this. The textur-coordinates for the shadow-texture are
generated with texGen, so the vertex-shader has to simulate that.
I use the following vertex-shader (which is based on a shader generated
by ShaderGen):
--shader begin
/***
* Fixed.vert Fixed Function Equivalent Vertex Shader *
* Automatically Generated by 3Dlabs GLSL ShaderGen *
* http://developer.3dlabs.com *
***/
varying vec4 Ambient;
vec4 Diffuse;
vec4 Specular;
varying vec4 Ambient2;
void pointLight(in int i, in vec3 normal, in vec3 eye, in vec3 ecPosition3)
{
float nDotVP; // normal . light direction
float nDotHV; // normal . light half vector
float pf; // power factor
float attenuation; // computed attenuation factor
float d;// distance from surface to light source
vec3 VP; // direction from surface to light position
vec3 halfVector; // direction of maximum highlights
// Compute vector from surface to light position
VP = vec3 (gl_LightSource[i].position) - ecPosition3;
// Compute distance between surface and light position
d = length(VP);
// Normalize the vector from surface to light position
VP = normalize(VP);
// Compute attenuation
attenuation = 1.0 / (gl_LightSource[i].constantAttenuation +
gl_LightSource[i].linearAttenuation * d +
gl_LightSource[i].quadraticAttenuation * d * d);
halfVector = normalize(VP + eye);
nDotVP = max(0.0, dot(normal, VP));
nDotHV = max(0.0, dot(normal, halfVector));
if (nDotVP == 0.0)
{
pf = 0.0;
}
else
{
pf = pow(nDotHV, gl_FrontMaterial.shininess);
}
Ambient += gl_LightSource[i].ambient * attenuation;
Diffuse += gl_LightSource[i].diffuse * nDotVP * attenuation;
Specular += gl_LightSource[i].specular * pf * attenuation;
}
vec3 fnormal(void)
{
//Compute the normal
vec3 normal = gl_NormalMatrix * gl_Normal;
normal = normalize(normal);
return normal;
}
void ftexgen(in vec3 normal, in vec4 ecPosition)
{
vec4 vertex = gl_ModelViewMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1].s = dot( ecPosition, gl_EyePlaneS[1] );
gl_TexCoord[1].t = dot( ecPosition, gl_EyePlaneT[1] );
gl_TexCoord[1].p = dot( ecPosition, gl_EyePlaneR[1] );
gl_TexCoord[1].q = dot( ecPosition, gl_EyePlaneQ[1] );
}
void flight(in vec3 normal, in vec4 ecPosition, float alphaFade)
{
vec4 color;
vec3 ecPosition3;
vec3 eye;
ecPosition3 = (vec3 (ecPosition)) / ecPosition.w;
eye = vec3 (0.0, 0.0, 1.0);
// Clear the light intensity accumulators
Ambient = vec4 (0.0);
Diffuse = vec4 (0.0);
Specular = vec4 (0.0);
pointLight(0, normal, eye, ecPosition3);
color = gl_FrontLightModelProduct.sceneColor +
Ambient * gl_FrontMaterial.ambient +
Diffuse * gl_FrontMaterial.diffuse;
color += Specular * gl_FrontMaterial.specular;
color = clamp( color, 0.0, 1.0 );
gl_FrontColor = color;
Ambient2 = gl_FrontLightModelProduct.sceneColor +
Ambient * gl_FrontMaterial.ambient;
gl_FrontColor.a *= alphaFade;
}
void main (void)
{
vec3 transformedNormal;
float alphaFade = 1.0;
// Eye-coordinate position of vertex, needed in various calculations
vec4 ecPosition = gl_ModelViewMatrix * gl_Vertex;
// Do fixed functionality vertex transform
gl_Position = ftransform();
transformedNormal = fnormal();
if (dot(transformedNormal,vec3(0.0, 0.0, 1.0) )0.0)
transformedNormal = -1.0*transformedNormal;
flight(transformedNormal, ecPosition, alphaFade);
ftexgen(transformedNormal, ecPosition);
}
--shader end
The relevant part for you is the ftexgen-function.
In the fragment shader I use the ambient2-color for the shadow, which
then fits nicely to the rest of the scene. In the shader I simulate
two-sided lighting by turning the normal towards the user:
if (dot(transformedNormal,vec3(0.0, 0.0, 1.0) )0.0)
transformedNormal = -1.0*transformedNormal;
This doesn´t give perfect results due to perspective. If someone has a
better idea here, please tell me.
Of course this shader only works if the shadowtexture uses texture-unit 1.
Regards,
Andreas
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
