Re: [osg-users] Question about rendering
Hello Robert,
Thank you.
I have some problem when I try to run iPhone example of the OSG source.
After referring to this
post(http://forum.openscenegraph.org/viewtopic.php?t=14385 ),
I figured out both the VERTEX xxx failed problem and texture not support
problem by adding
Code:
static const char gVertexShader1[] =
varying vec2 v_texCoord; \n
void main() { \n
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; \n
v_texCoord = gl_MultiTexCoord0.xy;
\n
} \n;
static const char gFragmentShader1[] =
varying mediump vec2 v_texCoord;
\n
uniform sampler2D sam;
\n
void main() {
\n
gl_FragColor = texture2D(sam, v_texCoord);
\n
} \n;
osg::Shader* vShader = new osg::Shader( osg::Shader::VERTEX, gVertexShader1
);
osg::Shader* fShader = new osg::Shader( osg::Shader::FRAGMENT,
gFragmentShader1 );
osg::Program* program = new osg::Program;
program-addShader( vShader );
program-addShader( fShader );
_root-getorcreatestateset-setAttribute( program );
Although the problem has been solved, I still do not know why it works after
adding this code.
Thank you very much.
Best regards,
NIE
robertosfield wrote:
Hi Nie,
iOS only support OpenGL ES, so you only can compile against GLES1 or 2, if
you want to do graphics on iOS then you have no choice beyond these. These
two versions of GLES are very different so you'll need to tackle both very
differently so you'll need to decide which route you want to go.
Robert.
On 28 November 2014 at 06:04, Nie Junxiao () wrote:
Hello Robert,
Thank you for replying.
I have checked osgtexture1D example and apply it to my source
code(actually it is an iOS app). Then I found that I have built osglib
using GLES_1_available and GLES_2_available, which makes texture1D not
available in osg( errtexgen not supported ). Is there an alternative
way to use texture1D, or I have to rebuild osglib with GLES_1_available and
GLES_2_available off? I think that I am not using GLES in my project.
Thank you.
NIE
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61899#61899
(http://forum.openscenegraph.org/viewtopic.php?p=61899#61899)
___
osg-users mailing list
()
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
(http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
--
Post generated by Mail2Forum
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61953#61953
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about rendering
Hello Robert,
Thank you.
I have some problem when I try to run iPhone example of the OSG source.
After referring to this
post(http://forum.openscenegraph.org/viewtopic.php?t=14385 ),
I figured out both the VERTEX xxx failed problem and texture not support
problem by adding
Code:
static const char gVertexShader1[] =
varying vec2 v_texCoord; \n
void main() { \n
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; \n
v_texCoord = gl_MultiTexCoord0.xy;
\n
} \n;
static const char gFragmentShader1[] =
varying mediump vec2 v_texCoord;
\n
uniform sampler2D sam;
\n
void main() {
\n
gl_FragColor = texture2D(sam, v_texCoord);
\n
} \n;
osg::Shader* vShader = new osg::Shader( osg::Shader::VERTEX, gVertexShader1
);
osg::Shader* fShader = new osg::Shader( osg::Shader::FRAGMENT,
gFragmentShader1 );
osg::Program* program = new osg::Program;
program-addShader( vShader );
program-addShader( fShader );
_root-getorcreatestateset-setAttribute( program );
Although the problem has been solved, I still do not know why it works after
adding this code.
Thank you very much.
Best regards,
NIE
robertosfield wrote:
Hi Nie,
iOS only support OpenGL ES, so you only can compile against GLES1 or 2, if
you want to do graphics on iOS then you have no choice beyond these. These
two versions of GLES are very different so you'll need to tackle both very
differently so you'll need to decide which route you want to go.
Robert.
On 28 November 2014 at 06:04, Nie Junxiao () wrote:
Hello Robert,
Thank you for replying.
I have checked osgtexture1D example and apply it to my source
code(actually it is an iOS app). Then I found that I have built osglib
using GLES_1_available and GLES_2_available, which makes texture1D not
available in osg( errtexgen not supported ). Is there an alternative
way to use texture1D, or I have to rebuild osglib with GLES_1_available and
GLES_2_available off? I think that I am not using GLES in my project.
Thank you.
NIE
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61899#61899
(http://forum.openscenegraph.org/viewtopic.php?p=61899#61899)
___
osg-users mailing list
()
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
(http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
--
Post generated by Mail2Forum
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61954#61954
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thread safety in OSG
Hi Rico, On 28 November 2014 at 09:11, Rico Widmer ricowid...@gmx.ch wrote: 1) My program uses multiple threads which access the same node object returned by osgDB::readNodeFile(). Is the access to this object thread safe? My program doesn't change the object directly but I don't know if OSG changes the object or a cache or something similar. If so, it might be necessary to lock the access to this object. Whether it's safe depends upon the timing of when all these threads and what other threads might be done. If the scene graph isn't be modified by any threads in the application (yours or ones created by the OSG) then there shouldn't be any issue. I don't know enough about the timing of your threads or what you have setup the rest of the OSG to do to know whether your particular usage is thread safe. 2) Multiple threads will call osgDB::readNodeFile() simultaneously. Is there a need to lock threads away when a thread is using this method? In the OSG code I saw that the caching mechanism is thread safe. I couldn't really figure out though if this is enough to let every thread use that function at-will. There are mechanisms within osgDB::Regisitry and the plugins to allow them to be used in a thead safe way. I would say though you are best to use OSG-3.2.1 rather than 3.0.x as there have been various improvements and thread bug fixes in 3.2.1. There have been further fixes since 3.2.1 as well so the svn/trunk and OSG-3.2 branch will be the most reliable w.r.t really hammering the threading side. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pointer ownership when reading a node file
Hi Rico, On 28 November 2014 at 09:07, Rico Widmer ricowid...@gmx.ch wrote: when I use osgDB::readNodeFile() for reading a file, the function returns a pointer to a node. The destructor of the Node class is protected and it says that it is deleted when not referenced any more. The destructed is deliberately made protected to prevent your from directly deleting it - this is done for almost all Objects in the OSG that should be managed via reference counting. The osg::ref_ptr is the safest way to manage this reference counting. So is it enough to store the returned Node* in a ref_ptrNode? Such a pointer is dereferenced automatically when going out of scope e.g. when the object is destroyed. Bingo, this is exactly what you are meant to do when managing most OSG objects - in particular all the scene graph nodes/state attributes/geometry etc. There are times when you can temporarily use a C pointer rather than a ref_ptr if you know that the object won't be deleted or leaked during that code block. In the case of being deleted on has to consider whether the object might be deleted by another thread whilst you are using a C pointer. There are also readRefNodeFile() functions that are equivalents of readNodeFile() for apps that know that the objects are being cached and used by other threads. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pointer ownership when reading a node file
Thank you very much for your help Robert. Rico -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61957#61957 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thread safety in OSG
Thank you for your response. The scene is only used for calculating LOS. The function providing this can be called by multiple threads though. At the moment I lock the access to the scene: Code: osgSim::LineOfSight los; los.addLOS(start, end); // It is unknown whether OSG changes m_scene during the computation. // To be sure its access is locked. m_lock.enter(); los.computeIntersections(m_scene); m_lock.exit(); Is the locking procedure around computeIntersections necessary? The rest of my code does not change m_scene.[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61958#61958 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving this scene frame rate
Hi,
I found where is the error, but I don't know how to solve it... I'm sending
identity matrix to the
computeMatrixPaletteUniform(geom.getMatrixFromSkeletonToGeometry(),
geom.getInvMatrixFromSkeletonToGeometry()) all the time into void
operator()(osgAnimation::RigGeometry geom). So in the shader the vertex are
not positioned correctly.
This two variables are defined into this function:
Code:
void RigGeometry::computeMatrixFromRootSkeleton()
{
if (!_root.valid())
{
OSG_WARN Warning className() ::computeMatrixFromRootSkeleton if you
have this message it means you miss to call buildTransformer(Skeleton* root),
or your RigGeometry ( getName() ) is not attached to a Skeleton
subgraph std::endl;
return;
}
osg::MatrixList mtxList = getParent(0)-getWorldMatrices(_root.get());
osg::Matrix notRoot = _root-getMatrix();
_matrixFromSkeletonToGeometry = mtxList[0] * osg::Matrix::inverse(notRoot);
_invMatrixFromSkeletonToGeometry =
osg::Matrix::inverse(_matrixFromSkeletonToGeometry);
_needToComputeMatrix = false;
}
I guess there will be some error in the root matrix? That is the first bone of
the skeleton...
Thank you!
Cheers,
Aitor
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61959#61959
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Half Side-by-side
Hi, as suggested, I've solved setting OFF the OSG_SPLIT_STEREO_AUTO_ADJUST_ASPECT_RATIO option and setting SIDE_BY_SIDE stereo HORIZONTAL or TOP_AND_BOTTOM. :-) Thank you! Cheers, Francesco Francesco Argese -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61960#61960 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thread safety in OSG
Hi Rico, Doing LOS calculations should be fine to multi-thread. Robert. On 3 December 2014 at 09:47, Rico Widmer ricowid...@gmx.ch wrote: Thank you for your response. The scene is only used for calculating LOS. The function providing this can be called by multiple threads though. At the moment I lock the access to the scene: Code: osgSim::LineOfSight los; los.addLOS(start, end); // It is unknown whether OSG changes m_scene during the computation. // To be sure its access is locked. m_lock.enter(); los.computeIntersections(m_scene); m_lock.exit(); Is the locking procedure around computeIntersections necessary? The rest of my code does not change m_scene.[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61958#61958 ___ 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] moving a vertex of a Geometry
Hi All, I have a surface where a user can pick points. As suggested I used a Geode with Geometry built with osg::PrimitiveSet::POINTS and verteices. Then I used PointSprite to show an image on each point (but I think this is not really important). Now I need to drag points with the mouse. First of all I have to handle the mouse move event to understand on which point the mouse is over. And now the problem. Given the mouse is over one of the previously picked points, how can I get which is the exact point of the Geometry from a osgUtil::PolytopeIntersector? The Intersection object contains a nodePath that at least refers to the Geometry node, not the single vertex/point. So I guess I have to loop over the actual picked points coordinates (i.e. geometry-getVertexArray()) and calculate the distance from the intersection.localIntersectionPoint. Is that right or is there a better way to implement it? Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61962#61962 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] moving a vertex of a Geometry
Hi Gianni, years ago whan I was working on a 3D editor I faced similar challenge. I solved it with selection buffer, where I had two representation of the model - one for fast rendering, when you obviously don't pick or manipulate, so your model with osg::PrimitiveSet::POINTS will represent this, and other for picking/editing - here a single vertex was a separate node and along with the selection buffer you can put id on each single vertex. Maybe there are some better ideas, but the approach I took worked very well. Just thoughts Nick On Wed, Dec 3, 2014 at 1:41 PM, Gianni Ambrosio g.ambrosio+...@gmail.com wrote: Hi All, I have a surface where a user can pick points. As suggested I used a Geode with Geometry built with osg::PrimitiveSet::POINTS and verteices. Then I used PointSprite to show an image on each point (but I think this is not really important). Now I need to drag points with the mouse. First of all I have to handle the mouse move event to understand on which point the mouse is over. And now the problem. Given the mouse is over one of the previously picked points, how can I get which is the exact point of the Geometry from a osgUtil::PolytopeIntersector? The Intersection object contains a nodePath that at least refers to the Geometry node, not the single vertex/point. So I guess I have to loop over the actual picked points coordinates (i.e. geometry-getVertexArray()) and calculate the distance from the intersection.localIntersectionPoint. Is that right or is there a better way to implement it? Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61962#61962 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] moving a vertex of a Geometry
Hi Gianni Hi All, I have a surface where a user can pick points. As suggested I used a Geode with Geometry built with osg::PrimitiveSet::POINTS and verteices. Then I used PointSprite to show an image on each point (but I think this is not really important). Now I need to drag points with the mouse. First of all I have to handle the mouse move event to understand on which point the mouse is over. And now the problem. Given the mouse is over one of the previously picked points, how can I get which is the exact point of the Geometry from a osgUtil::PolytopeIntersector? The Intersection object contains a nodePath that at least refers to the Geometry node, not the single vertex/point. So I guess I have to loop over the actual picked points coordinates (i.e. geometry-getVertexArray()) and calculate the distance from the intersection.localIntersectionPoint. Is that right or is there a better way to implement it? The LineSegIntersector will retrieve the primitive index and the vertex indices. There's some example in the OSG 3 Cookbook for this. This will save you the trouble iterating. I guess there is something similar for the polytope intersector, which at least will narrow down the number of vertices to check on your end. I've implemented some level-terrain tool where I used some of this stuff. Unfortunately I don't have the source code here, so I could check on this later if you need some more info Cheers Sebastian Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61962#61962 ___ 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] Implementing glEnablei + glDisablei
Hi All, I'm currently working on multiple render target functionality, yesterday I checking in ColorMaski, BlendFunci and BlendEquationi, and today I've moved on to implementing glEnablei/glDisablei functionality. I'm torn of what naming convention to use and the granularity of the design - so I'd like feedback from the community about what feels sensible. Originally I was thinking that as glEnable/glDisable functionality in imlemented via osg::StateSet::setMode(..) I'd add a StateSet::setModei() and expand similar support in osg::State. When I got into looking at how much code I'd need to duplicate+tweak to make this all work I decided that that much code for such a small chunk of functionality was totally disproportionate. When I come across issues like this I use this Complexity of implementation vs Functionality Ratio as an indication of how well designed something is. If it requires lots of Complexity for modest Functionality it screams out that it's the wrong approach. So I've taken a step back and am now thinking about other ways I could tackle this feature. My current favoured approach is to reuse the existing StateSet/StateAttribute mechanism and have one or more subclass from StateAttribute to wrap up the glEnablei and glDisablei functionality. If I am to follow the usual OpenGL-OSG naming convention it would seem sensible to have two classes osg::Enablei and osg::Disablei that wrap up glEnablei and glDisablei respectively. An alternative approach would be to create an osg::Modei class that has an Enabled/Disabled parameter. The Modei name would be a nod to the previous naming convention for handing glEnable/glDisable. The name Modes I originally adopted as the original OpenGL language around glEnable/glDisable used to label them as modes - this was all decided back in the late 90's. This during the fixed function pipeline era of OpenGL where you'd configure the OpenGL state machine by toggling different modes. Since then a decade and half has passed and looking at modern docs for OpenGL the glEnable/glDisable and glEnablei/glDisablei now discuss OpenGL capability rather than modes. I guess the new naming sits better modern shader centric functionality. Given this perhaps if one is to have a single class then perhaps one should name it osg::Capability. The usage mode for the new class/classes would be something like: stateset-setAttribute(new osg::Enablei(GL_BLEND, 0)); stateset-setAttribubte(new osg::Disable(GL_SCISSOR_TEST,1)); OR stateset-setAttribute(new osg::Capabiltyi(GL_BLEND, 0, GL_TRUE)); stateset-setAttribute(new osg::Capabiltyi(GL_SCISSOR_TEST, 0, GL_FALSE); It might still be better though for me to bite the bullet and do the hard work refatoring the internals of osg::State/osg::StateSet to handle a new osg::StateSet::setModei(..) method and associated set/gets. Thoughts/Opinions/Suggestions? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent Window Application [SOLVED]
Hi, Great to see that you got around the transparent mouse clicks as well. I just needed it yesterday and again your method works great. Unfortunatly I have another problem though... I would like to place this application on top of another full-screen windows (game). I didn't think of it earlier, but it does not work (perhaps this should be obvious). Can you think of any workarounds to make this work? Unfortunatly it is no option to run the game in windowed mode, since I'm using it in combination with the oculus rift and tridef to make te game work for it. Hopefully there is another workaround... As always thanks for your help! Cheers, Roy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61965#61965 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent Window Application [SOLVED]
Hi Roy, if you game runs full screen and cannot do anything else even with 'full screen emulation' ( such that you render game full screen but in windowed mode ) the answer might be - an old trick to use hooks to write overlays for games ( search on the web - the trick is used in number of game hacks ) now if you use dx for game and osg for overlay there could be additional problem, which you would need to solve with https://sites.google.com/site/snippetsanddriblits/OpenglDxInterop - such that you add additional overlay as described above, but the texture for this overlay is provided by osg. Regards Sergey On Wed, Dec 3, 2014 at 7:20 PM, Roy Arents osgfo...@tevs.eu wrote: Hi, Great to see that you got around the transparent mouse clicks as well. I just needed it yesterday and again your method works great. Unfortunatly I have another problem though... I would like to place this application on top of another full-screen windows (game). I didn't think of it earlier, but it does not work (perhaps this should be obvious). Can you think of any workarounds to make this work? Unfortunatly it is no option to run the game in windowed mode, since I'm using it in combination with the oculus rift and tridef to make te game work for it. Hopefully there is another workaround... As always thanks for your help! Cheers, Roy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61965#61965 ___ 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] Implementing glEnablei + glDisablei
HI All, Since then a decade and half has passed and looking at modern docs for OpenGL the glEnable/glDisable and glEnablei/glDisablei now discuss OpenGL capability rather than modes. I guess the new naming sits better modern shader centric functionality. Given this perhaps if one is to have a single class then perhaps one should name it osg::Capability. The usage mode for the new class/classes would be something like: stateset-setAttribute(new osg::Enablei(GL_BLEND, 0)); stateset-setAttribute(new osg::Disable(GL_SCISSOR_TEST,1)); I have now checked in a first cut of the above approach. The new Enablei and Disablei classes can be found in a new include/osg/Capability header. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader storage buffer object
Hello all Just by curiosity, I wonder what concrete usage make mandatory the SSBO..? in your scenerio : particle advection doesn't require R/W RAM buffer, ping pong feedback streams are designed for this...(haven't compare perfs but seams obvious) bye -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61969#61969 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader storage buffer object
Hello Julien, Den 03.12.2014 22:27, skrev Julien Valentin: Hello all Just by curiosity, I wonder what concrete usage make mandatory the SSBO..? in your scenerio : particle advection doesn't require R/W RAM buffer, ping pong feedback streams are designed for this...(haven't compare perfs but seams obvious) hmm, FeedbackTransformBuffers can be used for this, somehow . I think that SSBO's and the very latest GL features making sense if thinking about changing the app design/architecture . Avoiding expensive data transfers between host and device as much as possible, and using the power of modern GPU's for high troughput computing. Maybe we should ask why some combination of OSG ComputeShaders SSBO etc. could make sense ? I think one major problem for the pure computing guys is holding overview , debugging, visualizing and tracking their data?? In my eyes , OSG seems to be perfect to handle complex scenes , but it has - right now - not so good support for the very latest GL features (my opinion). I like the idea to combine data computation, data monitoring/debug, and data visualization in one solution. Maybe OSG could be tuned to make it ? good night, Markus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader storage buffer object
Markus Hein wrote: Hello Julien, hmm, FeedbackTransformBuffers can be used for this, somehow . I think that SSBO's and the very latest GL features making sense if thinking about changing the app design/architecture . Well It's my opinion, but a lot of new GL4 features make me worry about correct usage of the GPU ...As we can do everything now (scattered writing/inter thread sync,R/W ram), I think we should ask ourself what worse the cost of use these features. My guess about using SSBO for particle managment instead of streamed buffer is that there's an RAM access overcostbut i'm not an hardwareman -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61971#61971 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] moving a vertex of a Geometry
Hi Sebastian, thank you very much for your hint. I will give a look at the LineSegIntersector. Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61972#61972 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
