Re: [osg-users] Strange Behaviour of Virtual Planet Builder (VS c++ 2007)
Hi all, after testing and playing around with VS2007 i have not yet get a running version. what can i do, no longer supported for VS2007? or what can you propose? adegli 2008/2/1, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED]: :-( 2008/2/1, Jean-Sébastien Guay [EMAIL PROTECTED]: Hello Adrian, after long time no using VP Builder i try do rebuild it on my dev system. i get strange behaviour what can be wrong ? Which version of VPB is this? I have tested the latest SVN head on VC8 and it builds and runs OK. I don't have a VC7 environment to test on, but I don't see why it should make that much of a difference... Sorry to say but I can't help you. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange Behaviour of Virtual Planet Builder (VS c++ 2007)
Hello Adrian, after testing and playing around with VS2007 i have not yet get a running version. what can i do, no longer supported for VS2007? or what can you propose? I guess you mean VS 7 (7.0/7.1) as 2007 does not exist (7.0 = .NET, 7.1 = .NET 2003, 8.0 = .NET 2005, 9.0 = .NET 2008) It's really hard to troubleshoot with so few details... OSG itself builds fine with VS 7, so I would not think that VPB would be much different. But it's hard to say. Can you perhaps check if it's just a missing header in some files, or something like that? What are the specific errors you get? Since I don't have the environment to reproduce this, it's really hard for me to help you. Good luck, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] old wiki
Hello Brede, Sorry for the late reply. I wasn't able to find this information on the new wiki. http://www.openscenegraph.org/osgwiki/pmwiki.php/KnowledgeBase/OpenFlight Here you are: http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/OpenFlight (straight copy-paste of the original page - please edit if it needs updating...) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] to draw landscapes beginning from a matrix
thanks for the satisfactory answer. I have tried to study his solution but it is difficult for the lack of complete documentation. I can try to explain better the problem: I have a matrix of altitudes 410 X 296, I would want to represent her first in 2 dimensions (to color of white the smaller altitude and of black the greatest altitude), then to represent her in 3 dimensions. the purpose is to draw a volcanic ground for the simulation of castings of it washes. can you help me to understand as I must proceed? do you have some example of use of osg::HeightField and osg::Terrain? thanks in advance Aurora Restivo - From: Jean-Christophe Lombardo [EMAIL PROTECTED] http://gmane.org/get-address.php?address=jean%2dchristophe.lombardo%2dAYb5Cdd1jaQ%40public.gmane.org Subject: Re: to draw landscapes beginning from a matrix http://news.gmane.org/find-root.php?message_id=%3c47A1E355.4000707%40cstb.fr%3e Newsgroups: gmane.comp.graphics.openscenegraph.user http://news.gmane.org/gmane.comp.graphics.openscenegraph.user Date: 2008-01-31 15:03:49 GMT (4 days and 3 minutes ago) You might either * build an osg::HeightField (http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01227.html) and draw it with an osgTerrain::TerrainNode node with an osgTerrain::HeightFieldLayer as an elevation layer * or use VirtualPlanetBuilder (http://www.openscenegraph.org/projects/VirtualPlanetBuilder) jcl aurora restivo wrote: Hi! I have necessity to draw landscapes beginning from a matrix that contains the data of the altitude. can you help me? Thanks. Aurora Restivo ___ osg-users mailing list [EMAIL PROTECTED] http://gmane.org/get-address.php?address=osg%2dusers%2dZwoEplunGu0hajLcUbyfC12AsgEQdTeF%40public.gmane.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] Displaying cables
J-S, I've always used setSupportsDisplayList(false) along with setuseDisplayList(false). I don't remember why. I'd have to review the osg geometry code to refresh my memory. Brian [EMAIL PROTECTED] wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Jean-Sébastien Guay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 02/04/2008 10:42AM Subject: [osg-users] Displaying cables Hello, I imagine this is pretty common, I'm just looking for a few hints of how to optimize things. Our apps need to display cables (and most of the time, a large number of them). The cables themselves are controlled by a physical simulation which gives us a set of transforms for the ends of each segment of a cable. For now, we are creating some geometry (quad strips, specifically) to display the cables, and assigning texture coordinates to that geometry, on the fly. This is needed because if, for example, a cable is lengthened (because it's being spooled out of a pulley system for example) the texture shouldn't stretch over it. Similarly, if the physical simulation subdivides the cable into more segments than it was in the last frame, we need to have correct texture coordinates to (hopefully) make the fact that the cable now has more, shorter segments invisible to the user. I know the cable display needs to be optimized because if I just set the cables' nodemasks to 0, the draw times go from 6.6ms to 2.2ms (for the same view). And there are not *that* many cables... There's a lot of other geometry in the scene which is still drawn in the 2.2ms time... So I would appreciate some pointers. I would have assumed quad strips are pretty fast, so perhaps something else is the problem? There's the fact that the geometry is dynamic, which could mean that OSG is trying to recreate display lists each frame, but I tried setUseDisplayList(false) on the geometry and the cables just did not display anymore... Is there something else I need to do in that case? Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
Jean-Sébastien Guay wrote : Hello, For now, we are creating some geometry (quad strips, specifically) to display the cables, and assigning texture coordinates to that geometry, on the fly. (...) I know the cable display needs to be optimized because if I just set the cables' nodemasks to 0, the draw times go from 6.6ms to 2.2ms (for the same view). And there are not *that* many cables... There's a lot of other geometry in the scene which is still drawn in the 2.2ms time... So I would appreciate some pointers. I would have assumed quad strips are pretty fast, so perhaps something else is the problem? There's the fact that the geometry is dynamic, which could mean that OSG is trying to recreate display lists each frame, but I tried setUseDisplayList(false) on the geometry and the cables just did not display anymore... Is there something else I need to do in that case? I have a somewhat similar situation myself. I use capsules to display hoses, which aren't textured but just have a color, and use display lists. Capsules are just cylinders and half spheres, but these are made of a lot of vertices. I ran at something like 1-2 fps(!) when I was redrawing the whole hose everytime the hose changed. When no geometry changed, I shot back to around 25 fps. I got three times faster when I limited myself to changing only the end of the hose, thus keeping the same capsules rather than replacing them with new ones with the same coordinates, color, etc. I then got another factor 3 by making sure I drew as few capsules as I needed. In my case too, the capsules are not that many, I have tens of animated characters moving around, plus a scene to render, but the dynamic shapes ate way more than anything else. I'm not sure if this helps a lot, but I just did this today, and optimizing the geometry was clearly a big win for me. If your app doesn't change all the cables at once, only one part of one cable at a time (a given frame), keeping the geometry should give you a decent boost. If anyone else has other suggestions, I'm interested to hear them too. Sincerely, Laurent Di Cesare. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Number of polygons in viewing frustum
Is there a way to determine the number of polygons being rendered by the GPU in the current viewing frustum? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problems with picking and HUDs
Hi all, Making an application to show the name of different elements, I can do it with everything except with HUDs, do you have any idea why does it happen? Thanks in advance ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Matrixd -- How to remove rotation for acertainaxis?
Tobias Münch wrote on Monday, February 04, 2008 1:01 PM: This works, but only partially. All Object that are near the coordinate axes where fixed in rotation. But everything with a certain height above the axis zero level will be rotated. So the final images gets ugly distorted (Looks like it is sheared). I played a little bit with the values and indces, but couldn't improve it. It isn't clear exactly what you mean, but it sounds like the issue is now just how to get the right rotation in the matrix; you can look up matrix math and rotations on Wikipedia or in a good graphics textbook. Sorry I can't be more help. On Feb 4, 2008 7:23 PM, Thrall, Bryan [EMAIL PROTECTED] wrote: Sorry, hit send too soon, updated below... Thrall, Bryan wrote on Monday, February 04, 2008 12:21 PM: Tobias Münch wrote on Monday, February 04, 2008 11:29 AM: Hello at all, I have osg::Matrixd view matrix and want to remove the rotation around x- and y-axis. Only rotation around z-axis should stay in the matrix. I try a lot of possibilties but couldn't find a solution. When I make the following steps, the rotation around all axis is removed, not only the two specified axis. The same with osg::Matrixd::makeRotate(..); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(0,1,0)); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(1,0,0)); I also tried to set the matrix with complete new values and to take given value for z-rotation, but therefore I miss a function to read the one rotation part (around the z-axis). How can help me? Both of those lines *set* matrix to a non-rotating matrix; what you want is to *modify* the matrix to remove the X and Y rotations. The easiest way is to modify the matrix directly: matrix(0,0) = 1; matrix(0,1) = 0; matrix(0,2) = 0; matrix(1,0) = 0; matrix(1,1) = 1; matrix(1,2) = 0; If I didn't mess up my indices, this zeroes out the X and Y rotations while leaving the Z intact. - Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Matrixd -- How to remove rotation for a certainaxis?
This works, but only partially. All Object that are near the coordinate axes where fixed in rotation. But everything with a certain height above the axis zero level will be rotated. So the final images gets ugly distorted (Looks like it is sheared). I played a little bit with the values and indces, but couldn't improve it. Tobias On Feb 4, 2008 7:23 PM, Thrall, Bryan [EMAIL PROTECTED] wrote: Sorry, hit send too soon, updated below... Thrall, Bryan wrote on Monday, February 04, 2008 12:21 PM: Tobias Münch wrote on Monday, February 04, 2008 11:29 AM: Hello at all, I have osg::Matrixd view matrix and want to remove the rotation around x- and y-axis. Only rotation around z-axis should stay in the matrix. I try a lot of possibilties but couldn't find a solution. When I make the following steps, the rotation around all axis is removed, not only the two specified axis. The same with osg::Matrixd::makeRotate(..); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(0,1,0)); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(1,0,0)); I also tried to set the matrix with complete new values and to take given value for z-rotation, but therefore I miss a function to read the one rotation part (around the z-axis). How can help me? Both of those lines *set* matrix to a non-rotating matrix; what you want is to *modify* the matrix to remove the X and Y rotations. The easiest way is to modify the matrix directly: matrix(0,0) = 1; matrix(0,1) = 0; matrix(0,2) = 0; matrix(1,0) = 0; matrix(1,1) = 1; matrix(1,2) = 0; If I didn't mess up my indices, this zeroes out the X and Y rotations while leaving the Z intact. HTH, -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ 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] Displaying cables
Hi J-S Some thoughts... - any ideas on exactly where you're bottlenecked? - if perception of cable width is critical, how are you ensuring the quads are orthogonal to the viewer? Billboards, adjusting the quad verts, viewer/quad relationship is fixed, etc? - quadstrips are converted to tristrips in the driver; perhaps there's advantage in dispatching tristrips directly. - Ideally, and your target hardware supports it, suggest dispatch linestrip and tessellate each linesegment into a pair of tris in a geometry shader. A vertex shader could take care of texcoord computation given cable/segment lengths. Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, February 04, 2008 9:43 AM To: OpenSceneGraph Users Subject: [osg-users] Displaying cables Hello, I imagine this is pretty common, I'm just looking for a few hints of how to optimize things. Our apps need to display cables (and most of the time, a large number of them). The cables themselves are controlled by a physical simulation which gives us a set of transforms for the ends of each segment of a cable. For now, we are creating some geometry (quad strips, specifically) to display the cables, and assigning texture coordinates to that geometry, on the fly. This is needed because if, for example, a cable is lengthened (because it's being spooled out of a pulley system for example) the texture shouldn't stretch over it. Similarly, if the physical simulation subdivides the cable into more segments than it was in the last frame, we need to have correct texture coordinates to (hopefully) make the fact that the cable now has more, shorter segments invisible to the user. I know the cable display needs to be optimized because if I just set the cables' nodemasks to 0, the draw times go from 6.6ms to 2.2ms (for the same view). And there are not *that* many cables... There's a lot of other geometry in the scene which is still drawn in the 2.2ms time... So I would appreciate some pointers. I would have assumed quad strips are pretty fast, so perhaps something else is the problem? There's the fact that the geometry is dynamic, which could mean that OSG is trying to recreate display lists each frame, but I tried setUseDisplayList(false) on the geometry and the cables just did not display anymore... Is there something else I need to do in that case? Thanks in advance, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Matrixd -- How to remove rotation for a certainaxis?
Tobias Münch wrote on Monday, February 04, 2008 11:29 AM: Hello at all, I have osg::Matrixd view matrix and want to remove the rotation around x- and y-axis. Only rotation around z-axis should stay in the matrix. I try a lot of possibilties but couldn't find a solution. When I make the following steps, the rotation around all axis is removed, not only the two specified axis. The same with osg::Matrixd::makeRotate(..); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(0,1,0)); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(1,0,0)); I also tried to set the matrix with complete new values and to take given value for z-rotation, but therefore I miss a function to read the one rotation part (around the z-axis). How can help me? Both of those lines *set* matrix to a non-rotating matrix; what you want is to *modify* the matrix to remove the X and Y rotations. The easiest way is to modify the matrix directly: matrix(0,0) = 1; matrix(0,0) = 1; matrix(0,0) = 1; matrix(0,0) = 1; -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Displaying cables
Hello, I imagine this is pretty common, I'm just looking for a few hints of how to optimize things. Our apps need to display cables (and most of the time, a large number of them). The cables themselves are controlled by a physical simulation which gives us a set of transforms for the ends of each segment of a cable. For now, we are creating some geometry (quad strips, specifically) to display the cables, and assigning texture coordinates to that geometry, on the fly. This is needed because if, for example, a cable is lengthened (because it's being spooled out of a pulley system for example) the texture shouldn't stretch over it. Similarly, if the physical simulation subdivides the cable into more segments than it was in the last frame, we need to have correct texture coordinates to (hopefully) make the fact that the cable now has more, shorter segments invisible to the user. I know the cable display needs to be optimized because if I just set the cables' nodemasks to 0, the draw times go from 6.6ms to 2.2ms (for the same view). And there are not *that* many cables... There's a lot of other geometry in the scene which is still drawn in the 2.2ms time... So I would appreciate some pointers. I would have assumed quad strips are pretty fast, so perhaps something else is the problem? There's the fact that the geometry is dynamic, which could mean that OSG is trying to recreate display lists each frame, but I tried setUseDisplayList(false) on the geometry and the cables just did not display anymore... Is there something else I need to do in that case? Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem using uniform arrays
Hi Mike I may have narrowed down the problem. It's not so much the arrays that are causing problems, but their usage. For example indexing an array like this: arr[ind] works fine for the vertex shader, but doesn't compile on the fragment shader, saying that the index has to be constant, so that arr[ind] is not allowed, but arr[3] is ok. However, since I'm using long arrays (70 elements), I don't know how to work around this limitation. Any ideas? Notice that this error only happens on 7800, not on 8800. Also, even though I changed the osg notification level to debug, I get no error/warning messages when compiling and linking the shader. Don't know why ... (I used another glsl debugger to get the error messages) Roni - Original Message - From: Mike Weiblen [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, February 04, 2008 8:57 PM Subject: Re: [osg-users] problem using uniform arrays Hi Roni, See below -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Roni Rosenzweig Sent: Monday, February 04, 2008 1:18 AM To: OpenSceneGraph Users Subject: [osg-users] problem using uniform arrays Hello I'm using uniform arrays in my glsl shader. On geforce 8800 it works great, but on 7800 doesn't work (converts to fixed shader). when I try to validate my shader code I get a GL_3DL_array_objects extension is disabled error. Assuming you used 3Dlabs' GLSLvalidate tool which, as you can see, is only helpful up to a point. Are uniform arrays not supported on geforce 7800? No idea. Array support often a driver issue, but could require some hardware capability. Are both GPUs running exactly the same driver? It would be most helpful to see the actual error messages generated during OSG's attempt to compile/link the shader code (eg perhaps you in fact have a bug completely unrelated to arrays) When you increase the OSG_NOTIFY_LEVEL, it will print out the compile/link InfoLogs containing diagnostic info. What are those messages? Cut down your shader code to a bare minimum example that works on 8800 but fails on 7800. That repro case should probably be no more than a couple lines. Hth -- mew ___ 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] Displaying cables
Hi Mike, Thanks for the pointer about the GPU pipeline, I'll check it out. So you're drawing 6x as many quads as necessary; that's seems a good rationale to learn geometry shaders! :-) That and moving texcoord generation off the CPU and into the vertex shader. I'm pretty anxious to try them out myself, but in this case, I don't think it would make that much difference. Sure, in percentage terms 6x more is a lot, but in absolute terms it's still not very much (20 cables with 20 segments of 6 quads each - 2400 quads... and even in terms of vertices it's not that many...), so I guess I'm doing something wrong. It's not the first time someone's displayed cables, and using geometry shaders was not an option until recently, so there's obviously something amiss. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem using uniform arrays
Hi Roni, See below -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Roni Rosenzweig Sent: Monday, February 04, 2008 1:18 AM To: OpenSceneGraph Users Subject: [osg-users] problem using uniform arrays Hello I'm using uniform arrays in my glsl shader. On geforce 8800 it works great, but on 7800 doesn't work (converts to fixed shader). when I try to validate my shader code I get a GL_3DL_array_objects extension is disabled error. Assuming you used 3Dlabs' GLSLvalidate tool which, as you can see, is only helpful up to a point. Are uniform arrays not supported on geforce 7800? No idea. Array support often a driver issue, but could require some hardware capability. Are both GPUs running exactly the same driver? It would be most helpful to see the actual error messages generated during OSG's attempt to compile/link the shader code (eg perhaps you in fact have a bug completely unrelated to arrays) When you increase the OSG_NOTIFY_LEVEL, it will print out the compile/link InfoLogs containing diagnostic info. What are those messages? Cut down your shader code to a bare minimum example that works on 8800 but fails on 7800. That repro case should probably be no more than a couple lines. Hth -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
Hello Mike, Thanks a lot, good questions and suggestions here. - any ideas on exactly where you're bottlenecked? As I said, if I set nodemask to 0 on the cables the draw time goes way down. So I'm pretty sure the bottleneck is there (in other words, it's not how I build the geometry, because that's being done anyways; it's not the physics either). Though more specifically than that I can't say. - if perception of cable width is critical, how are you ensuring the quads are orthogonal to the viewer? Billboards, adjusting the quad verts, viewer/quad relationship is fixed, etc? Sorry, I wasn't very clear. It isn't billboards, and I can see that it sounded like that the way I described it. We're building cylinders with quad strips. So we'll give a subdivision level (number of quads for a segment, for example 6). And then the cable is a set of segments, each of which consists of 6 quads in this case. Since in this case, the cable with the most segments has about 20 of them (120 quads), I don't quite see why it's so slow. Of course, it might be the display list rebuild time, but I can't switch them off for some reason... - quadstrips are converted to tristrips in the driver; perhaps there's advantage in dispatching tristrips directly. I thought of this too, but didn't think it could be significant. If you think it might be something to try, I'll try it out and see. - Ideally, and your target hardware supports it, suggest dispatch linestrip and tessellate each linesegment into a pair of tris in a geometry shader. A vertex shader could take care of texcoord computation given cable/segment lengths. I haven't had much chance of using geometry shaders yet, unfortunately. I'd really have to demonstrate a large incentive to use them (though the hardware we ship to clients will likely support them anyways). It could also be used if the hardware supports it, with other fallbacks if not. We'll see in the next few months. Anyways, thanks a lot, I'm at least making progress and have a few things to try out. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multipass (was: no subject)
Hi, First, please put some subject to your post. Maybe take a look into osgPPU (http://projects.tevs.eu/osgppu) this is a nodekit which is what you looking for. It helps you to make multipass (render to texture and then as input to next texture) in a very simple way, without creating additional camera nodes. Best regards, Art --- [EMAIL PROTECTED] schrieb: Hi all, I have a problem in which I have to do multipass rendering. When I say multipass, it's in fact rendering to a texture which is the input for the next rendering, etc... and that about a hundreds time... I could explain why, but only if necessary, but let's say that no there is no better way than doing a cascaded rendering with that amount of steps, and in fact, that's sphecifically why I'm doing it on GPU... Moving on to OSG related problem, it seems to me that every time you want to render to a texture you have to add a Camera node. I've heard that you could maybe do a little bit better, by having only one Camera node, but several paths leading to it with differents statesets. But in my case, I can't have only one camera, and several statesets, because each time, I have to change the fbo to render to, that can only be done by adding a new camera, with a different texture to render to ... So my question is, is there a better way to do this kind of multipass rendering, than adding a camera for each step ? (better in the sense of less costly ...) I'm asking this because when I look at the stats, drawing takes about 60 ms, and gpu time is 80ms. I expected the value for the gpu, because for each camera, there is a fragment shader associated. But I didn't expect the draw time to be so high, and I really think that is because of the way I'm doing it (too many nodes maybe ... :( ) Thank you all ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Ihre erste Baustelle? Wissenswertes für Bastler und Hobby Handwerker. www.yahoo.de/clever ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Framerate vs stats?
Hello all, I'm seeing something peculiar in one of our apps using OSG 2.2, and I was wondering if someone else had seen something like this or would have an idea what would cause it. The app starts and seems sluggish. Pressing 's' once shows it's running at around 15-20 FPS. But then, if I press 's' a second time, the framerate shoots up to 75 FPS (capped by my refresh rate) and the app is suddenly very smooth. And it stays like that too (I can hide the stats again or whatever, it has no significant effect on the frame rate). So, what could cause this? Why would showing the detailed stats screen have that effect? I've seen cases where showing detailed stats _slowed_ the frame rate, but this is the first time it makes it faster! Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgdem point data etc
Hello, I am a newbie to osg and I have several questions concerning osgdem. Hope somebody has the answers. Is it possible to load xyz Point data with osgdem? Or ist it possible to load Esri Shape Files? Is there a osgdem tutorial available. I have just found the User guide on www.openscenegraph.com Thanks. Andi -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with picking and HUDs
On Mon, 2008-02-04 at 17:15 +0100, Pedro José Muñoz wrote: Hi all, Making an application to show the name of different elements, I can do it with everything except with HUDs, do you have any idea why does it happen? This is going to depend a lot on how you create your HUD. Without more information, no one could possibly help. :) Thanks in advance ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Matrixd -- How to remove rotation for a certain axis?
Hello at all, I have osg::Matrixd view matrix and want to remove the rotation around x- and y-axis. Only rotation around z-axis should stay in the matrix. I try a lot of possibilties but couldn't find a solution. When I make the following steps, the rotation around all axis is removed, not only the two specified axis. The same with osg::Matrixd::makeRotate(..); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(0,1,0)); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(1,0,0)); I also tried to set the matrix with complete new values and to take given value for z-rotation, but therefore I miss a function to read the one rotation part (around the z-axis). How can help me? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
Hello Anders, I did something similar a while back. http://www.vrlab.umu.se/research/colosseum3d/images/cables2.avi Wow, very nice! Also I did not spend that much time on the calculation of texture coordinates, which is as far as I know a fairly hard problem. We're pretty satisfied with just using the world-space distance between the two ends of a segment to determine the texture coordinates. It's not perfect but sufficient... I was more or less drawing a skewed cylinder between the interpolated points. That's what we're doing. Did you use OSG for your implementation? Care to share some details on how your geometry is being built? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
Hi J-S, -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, February 04, 2008 12:55 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Displaying cables Hello Mike, Thanks a lot, good questions and suggestions here. - any ideas on exactly where you're bottlenecked? As I said, if I set nodemask to 0 on the cables the draw time goes way down. So I'm pretty sure the bottleneck is there (in other words, it's not how I build the geometry, because that's being done anyways; it's not the physics either). Though more specifically than that I can't say. I meant GL pipeline bottleneck: increase/decrease the number of cable segments/tessellation to see if you're geometry dispatch/transform-bound; change the aspect ratio of the cable segments (some GPUs are inefficient at rasterizing long skinny triangles; you could get a speed up by adding segments!) - if perception of cable width is critical, how are you ensuring the quads are orthogonal to the viewer? Billboards, adjusting the quad verts, viewer/quad relationship is fixed, etc? Sorry, I wasn't very clear. It isn't billboards, and I can see that it sounded like that the way I described it. We're building cylinders with quad strips. So we'll give a subdivision level (number of quads for a segment, for example 6). And then the cable is a set of segments, each of which consists of 6 quads in this case. Since in this case, the cable with the most segments has about 20 of them (120 quads), I don't quite see why it's so slow. Of course, it might be the display list rebuild time, but I can't switch them off for some reason... So you're drawing 6x as many quads as necessary; that's seems a good rationale to learn geometry shaders! :-) That and moving texcoord generation off the CPU and into the vertex shader. -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem using uniform arrays
That's a nice idea, although I'm not sure if it would work with big arrays
(my array has 70 elements).
Besides, writing 70 such lines is a pain
I might try it tomorrow and update.
Otherwise, I'll just declare that this software only runs on 8800 :-(
Roni
For example indexing an array like this:
arr[ind]
works fine for the vertex shader, but doesn't compile on the fragment
shader, saying that the index has to be constant, so that arr[ind] is
not
allowed, but arr[3] is ok.
However, since I'm using long arrays (70 elements), I don't know how
to
work
around this limitation.
Any ideas
Stupid suggestion, perhaps you can do this? (not sure you can pass an
array to a function, but worth a try...)
vec4 indexArray(vec4[n] array, int i)
{
if (i == 0) return array[0];
if (i == 1) return array[1];
// ...
// error add more indices to the function!
}
Then call
vec4 value = indexArray(arr, ind);
Just to work around the limitation...
Let me know if you try this, I'd be interested to know if it works.
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
I did something similar a while back. http://www.vrlab.umu.se/research/colosseum3d/images/cables2.avi This is 100 segments simulated in 300Hz and controlled by a phantom haptic device. This is then refined using splines into more segments used for rendering. This version did not account for rotation of the controlpoints, which sometimes caused some rotation artefacts (where the normals were not defined). Also I did not spend that much time on the calculation of texture coordinates, which is as far as I know a fairly hard problem. The dynamic interpolation (depending on the gradient of the tangent) causes the total length of the cable to vary (whereas the texture coordinate is based in the linear distance of total length derived from the controlpoints). Using a vertexshader would speedup the skinning by an order of a magnitude. But in this example the rendering-time was not that bad. I was more or less drawing a skewed cylinder between the interpolated points. /Anders On Feb 4, 2008 7:40 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi J-S Some thoughts... - any ideas on exactly where you're bottlenecked? - if perception of cable width is critical, how are you ensuring the quads are orthogonal to the viewer? Billboards, adjusting the quad verts, viewer/quad relationship is fixed, etc? - quadstrips are converted to tristrips in the driver; perhaps there's advantage in dispatching tristrips directly. - Ideally, and your target hardware supports it, suggest dispatch linestrip and tessellate each linesegment into a pair of tris in a geometry shader. A vertex shader could take care of texcoord computation given cable/segment lengths. Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, February 04, 2008 9:43 AM To: OpenSceneGraph Users Subject: [osg-users] Displaying cables Hello, I imagine this is pretty common, I'm just looking for a few hints of how to optimize things. Our apps need to display cables (and most of the time, a large number of them). The cables themselves are controlled by a physical simulation which gives us a set of transforms for the ends of each segment of a cable. For now, we are creating some geometry (quad strips, specifically) to display the cables, and assigning texture coordinates to that geometry, on the fly. This is needed because if, for example, a cable is lengthened (because it's being spooled out of a pulley system for example) the texture shouldn't stretch over it. Similarly, if the physical simulation subdivides the cable into more segments than it was in the last frame, we need to have correct texture coordinates to (hopefully) make the fact that the cable now has more, shorter segments invisible to the user. I know the cable display needs to be optimized because if I just set the cables' nodemasks to 0, the draw times go from 6.6ms to 2.2ms (for the same view). And there are not *that* many cables... There's a lot of other geometry in the scene which is still drawn in the 2.2ms time... So I would appreciate some pointers. I would have assumed quad strips are pretty fast, so perhaps something else is the problem? There's the fact that the geometry is dynamic, which could mean that OSG is trying to recreate display lists each frame, but I tried setUseDisplayList(false) on the geometry and the cables just did not display anymore... Is there something else I need to do in that case? Thanks in advance, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Matrixd -- How to remove rotation for a certainaxis?
Sorry, hit send too soon, updated below... Thrall, Bryan wrote on Monday, February 04, 2008 12:21 PM: Tobias Münch wrote on Monday, February 04, 2008 11:29 AM: Hello at all, I have osg::Matrixd view matrix and want to remove the rotation around x- and y-axis. Only rotation around z-axis should stay in the matrix. I try a lot of possibilties but couldn't find a solution. When I make the following steps, the rotation around all axis is removed, not only the two specified axis. The same with osg::Matrixd::makeRotate(..); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(0,1,0)); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(1,0,0)); I also tried to set the matrix with complete new values and to take given value for z-rotation, but therefore I miss a function to read the one rotation part (around the z-axis). How can help me? Both of those lines *set* matrix to a non-rotating matrix; what you want is to *modify* the matrix to remove the X and Y rotations. The easiest way is to modify the matrix directly: matrix(0,0) = 1; matrix(0,1) = 0; matrix(0,2) = 0; matrix(1,0) = 0; matrix(1,1) = 1; matrix(1,2) = 0; If I didn't mess up my indices, this zeroes out the X and Y rotations while leaving the Z intact. HTH, -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Matrixd -- How to remove rotation for a certainaxis?
Won't this also remove the scale? -John On Mon, 4 Feb 2008, Thrall, Bryan wrote: Sorry, hit send too soon, updated below... Thrall, Bryan wrote on Monday, February 04, 2008 12:21 PM: Tobias M?nch wrote on Monday, February 04, 2008 11:29 AM: Hello at all, I have osg::Matrixd view matrix and want to remove the rotation around x- and y-axis. Only rotation around z-axis should stay in the matrix. I try a lot of possibilties but couldn't find a solution. When I make the following steps, the rotation around all axis is removed, not only the two specified axis. The same with osg::Matrixd::makeRotate(..); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(0,1,0)); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(1,0,0)); I also tried to set the matrix with complete new values and to take given value for z-rotation, but therefore I miss a function to read the one rotation part (around the z-axis). How can help me? Both of those lines *set* matrix to a non-rotating matrix; what you want is to *modify* the matrix to remove the X and Y rotations. The easiest way is to modify the matrix directly: matrix(0,0) = 1; matrix(0,1) = 0; matrix(0,2) = 0; matrix(1,0) = 0; matrix(1,1) = 1; matrix(1,2) = 0; If I didn't mess up my indices, this zeroes out the X and Y rotations while leaving the Z intact. HTH, -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem using uniform arrays
Hello Roni,
For example indexing an array like this:
arr[ind]
works fine for the vertex shader, but doesn't compile on the fragment
shader, saying that the index has to be constant, so that arr[ind] is
not
allowed, but arr[3] is ok.
However, since I'm using long arrays (70 elements), I don't know how
to
work
around this limitation.
Any ideas
Stupid suggestion, perhaps you can do this? (not sure you can pass an
array to a function, but worth a try...)
vec4 indexArray(vec4[n] array, int i)
{
if (i == 0) return array[0];
if (i == 1) return array[1];
// ...
// error add more indices to the function!
}
Then call
vec4 value = indexArray(arr, ind);
Just to work around the limitation...
Let me know if you try this, I'd be interested to know if it works.
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Two-sided surfaces not having correct display
I have a few geometries where I would like the material to display on both sides and having the correct normals. I have tried to just turn on the two sided light model, but things get really ugly then. Here is the material used... osg::Material * matPin = new osg::Material(); matPin-setAmbient( osg::Material::FRONT_AND_BACK, OHole ); matPin-setDiffuse( osg::Material::FRONT_AND_BACK, OHole ); matPin-setSpecular(osg::Material::FRONT_AND_BACK, OHole ); matPin-setShininess( osg::Material::FRONT_AND_BACK, 64.0f); osgHCore-m_OtherHoleSS = new osg::StateSet(); osgHCore-m_OtherHoleSS-setAttributeAndModes(matPin, osg::StateAttribute::ON ); / osg::LightModel* lightmodel = new osg::LightModel; lightmodel-setTwoSided( true ); osgHCore-m_OtherHoleSS-setAttributeAndModes(lightmodel, osg::StateAttribute::ON ); / I've attached 2 images. cyl-wo-lightmodel.jpg has the lightmodel commented out as shown above. cyl-w-lightmodel.jpg is with it uncommented. (-with- -without-). Notice the weird lighting of the square pads. This material is only attached to the hole cylinder geode. Ideas? Thanks, Greg attachment: cyl-wo-lightmodel.jpgattachment: cyl-w-lightmodel.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying cables
I'm interested but I cannot open the AVI. Is there a special CODEC that needs to be downloaded? thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, February 04, 2008 12:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Displaying cables Hello Anders, I did something similar a while back. http://www.vrlab.umu.se/research/colosseum3d/images/cables2.avi Wow, very nice! Also I did not spend that much time on the calculation of texture coordinates, which is as far as I know a fairly hard problem. We're pretty satisfied with just using the world-space distance between the two ends of a segment to determine the texture coordinates. It's not perfect but sufficient... I was more or less drawing a skewed cylinder between the interpolated points. That's what we're doing. Did you use OSG for your implementation? Care to share some details on how your geometry is being built? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Matrixd -- How to remove rotation for a certainaxis?
John Kelso wrote on Monday, February 04, 2008 2:31 PM: Won't this also remove the scale? Yes, but only for the X and Y axes :) On Mon, 4 Feb 2008, Thrall, Bryan wrote: Sorry, hit send too soon, updated below... Thrall, Bryan wrote on Monday, February 04, 2008 12:21 PM: Tobias M?nch wrote on Monday, February 04, 2008 11:29 AM: Hello at all, I have osg::Matrixd view matrix and want to remove the rotation around x- and y-axis. Only rotation around z-axis should stay in the matrix. I try a lot of possibilties but couldn't find a solution. When I make the following steps, the rotation around all axis is removed, not only the two specified axis. The same with osg::Matrixd::makeRotate(..); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(0,1,0)); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(1,0,0)); I also tried to set the matrix with complete new values and to take given value for z-rotation, but therefore I miss a function to read the one rotation part (around the z-axis). How can help me? Both of those lines *set* matrix to a non-rotating matrix; what you want is to *modify* the matrix to remove the X and Y rotations. The easiest way is to modify the matrix directly: matrix(0,0) = 1; matrix(0,1) = 0; matrix(0,2) = 0; matrix(1,0) = 0; matrix(1,1) = 1; matrix(1,2) = 0; If I didn't mess up my indices, this zeroes out the X and Y rotations while leaving the Z intact. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Matrixd -- How to remove rotation for a certainaxis?
I found a very easy and intuitiv way to remove inclination (y-axis) and rolling (x-axis) from a view matrix: osg::Vec3deye,center,up; matrix.getLookAt(eye,center,up,1); center.set(center.x(),center.y(),eye.z()); //removes inclination up.set(0,0,1); //removes rolling matrix.makeLookAt(eye,center,up); At first I request eye, center and up vector from the matrix. Then I set the heigt from center-vector to the height of eye-vector, which removes the inclination (y-axis rotation). Then I set a new up-vector to (0,0,1) which removes the rolling (x-axis rotation) from the matrix. Finally I create a new view matrix with the manipulated vectors. It works 100% fine. Thanks for all hints, Tobias On Feb 4, 2008 10:37 PM, Thrall, Bryan [EMAIL PROTECTED] wrote: John Kelso wrote on Monday, February 04, 2008 2:31 PM: Won't this also remove the scale? Yes, but only for the X and Y axes :) On Mon, 4 Feb 2008, Thrall, Bryan wrote: Sorry, hit send too soon, updated below... Thrall, Bryan wrote on Monday, February 04, 2008 12:21 PM: Tobias M?nch wrote on Monday, February 04, 2008 11:29 AM: Hello at all, I have osg::Matrixd view matrix and want to remove the rotation around x- and y-axis. Only rotation around z-axis should stay in the matrix. I try a lot of possibilties but couldn't find a solution. When I make the following steps, the rotation around all axis is removed, not only the two specified axis. The same with osg::Matrixd::makeRotate(..); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(0,1,0)); matrix = osg::Matrixd::rotate(osg::DegreesToRadians(0.0), osg::Vec3(1,0,0)); I also tried to set the matrix with complete new values and to take given value for z-rotation, but therefore I miss a function to read the one rotation part (around the z-axis). How can help me? Both of those lines *set* matrix to a non-rotating matrix; what you want is to *modify* the matrix to remove the X and Y rotations. The easiest way is to modify the matrix directly: matrix(0,0) = 1; matrix(0,1) = 0; matrix(0,2) = 0; matrix(1,0) = 0; matrix(1,1) = 1; matrix(1,2) = 0; If I didn't mess up my indices, this zeroes out the X and Y rotations while leaving the Z intact. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ 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] Removal from email list
Hello, I'm directly using this software anymore and would like to be removed from the list. Thank you, Scott (Cell) 650-430-0645 (Email) [EMAIL PROTECTED] Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removal from email list
you have to remove your self at http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ 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 Scott Yacko Sent: Monday, February 04, 2008 9:08 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Removal from email list Hello, I'm directly using this software anymore and would like to be removed from the list. Thank you, Scott (Cell) 650-430-0645 (Email) [EMAIL PROTECTED] Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ 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] Displaying cables
I belive its XVid. Either use VLC Media player or download XVid codec, depending on platform: http://www.xvidmovies.com/codec/ /Anders On Feb 5, 2008 12:41 AM, Netschke, Greg [EMAIL PROTECTED] wrote: I'm interested but I cannot open the AVI. Is there a special CODEC that needs to be downloaded? thanks -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, February 04, 2008 12:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Displaying cables Hello Anders, I did something similar a while back. http://www.vrlab.umu.se/research/colosseum3d/images/cables2.avi Wow, very nice! Also I did not spend that much time on the calculation of texture coordinates, which is as far as I know a fairly hard problem. We're pretty satisfied with just using the world-space distance between the two ends of a segment to determine the texture coordinates. It's not perfect but sufficient... I was more or less drawing a skewed cylinder between the interpolated points. That's what we're doing. Did you use OSG for your implementation? Care to share some details on how your geometry is being built? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
