Re: [osg-users] LineSegmentIntersector numerical imprecisions
Hi Robert and Alistair, I gave it another long thought and found one more idea. Let me show it on example of bounding box of bb_max.[x,y,z] set to 1'000'000 and bb_min.[x,y,z] set to 999'999. I such case, the size of bounding box does not matter and distance of start and end neither (unfortunately) as both are about 1.0. By multiplication of 1e-5, we get pretty small number that would not change bounding box in any way if substracted or added to any component of bounding box. I admit that this is not well designed scene but it shows the precision problem as it is, if I am not mistaken. In my opinion, we should just take the biggest number of all bounding box float values while ignoring the sign. Then, we multiply the biggest value by 1e-5 to get epsilon. This should provide the value big enough value to move all the sides of the bounding box while computations based on bounding box size does not always serve this purpose. We could use Robert's idea to get start and end points. From them, we can get the biggest value for epsilon as well that would provide better epsilon. It should be smaller in most cases, but still big enough to always work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1] and start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be computed from end point 1e7 by multiplying 1e-5 with the result 100. Thus, bounding box will grow to [-101,-101,-101, 101,101,101], making false collision with start point [2,0,0]. Later computation in LineSegmentIntersector will remove the collision, but it costs computational time. After the consideration, my inclination is towards bounding box choosen epsilon (as opposite to start and end point based epsilon), as the user may tend to set high values for end points just to pick through the whole scene or to create fake ray, although not sure if I not overlooked something. Does it seems reasonable? Some more ideas? John On Monday 19 of August 2013 08:50:46 Robert Osfield wrote: Hi John et. al, I too am not too happy with the approach of a fixed epilson, adding the ability for the user to set this value isn't much better. Scaling the epsilon by the size of the bounding box may be an improvement but I'm not yet convinced it's the best approach. The epsilon is there is account for numerical precision issues associated with the mathematical functions being performed. The maths in this case is clamping the present line segment start and end points to the bounding box, here the distance of the sides from the start and the start to the end point along each axis is what will determine the size of the values and the range of the numerical errors that are likely. The largest value is likely to be the length of the line segment so might be the best distance to use as the scale. Thoughts?Robert. On 19 August 2013 06:38, PCJohn pec...@fit.vutbr.cz[1] wrote: Hi Robert, there was recently a commit concerning epsilon in LineSegmentIntersectorthat is now carried as class member. I can imagine motivation behind, but Ibelive there is a better approach to the problem. If the motivation is just to allow the setting bigger epsilon for biggerobjects (too small epsilon, recently statically assigned to 1e-5, will notaffect big bounding boxes because of limited float resolution. I belive, thiswas the motivation behind the change for the person who submitted the patch.) The correct solution in my opinion would be to make epsilon depend on size ofbounding box of the intersected object: // extend bounding box a little bit to avoid floating point imprecisions double epsilon = (bb_max-bb_min).length() * 1e-5;bb_min.x() -= epsilon;bb_min.y() -= epsilon;bb_min.z() -= epsilon;bb_max.x() += epsilon;bb_max.y() += epsilon;bb_max.z() += epsilon; This should work in all cases, for both - small and big objects. Hard-codingepsilon, even when giving the user the ability to change it, is not correctway in my opinion, as there may be very small objects (requiring smallepsilon) together with big objects (requiring big epsilon) in the scene. Wecan give the user the callback to adjust the epsilon for each visited objectin the scene, but I do not belive this is the best approach.___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Model Load Crash
Hi John, On 19 August 2013 19:45, John Farrier john.farr...@gmail.com wrote: now I just need to figure out a way to do this little conversion dance and keep the embedded animation! So, perhaps, I posted too soon. I re-converted the model from the .lws original into .osgb. It was a file of identical size, but a binary comparison showed many differences. It would still not load in my app. Then I converted the .osgb to an .ive. The .ive would not load either. Since the models all load fine with osgViewer, I wonder if I haven't corrupted OSG's internal state somehow. I don't know what I could have done to affect this, but that's my suspicion. Could you post the problem files, including the .lws so that others can see if they can reproduce the problem. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pseydo-cylindrical projection
Hi Alexandre, You shouldn't need to use a render to texture approach to set up drive displays,as each slave camera can just render 60 degrees of the overall FOV (plus a little bit if you are edge blending). All you'd need to do is set the slave cameras view offset matrix so that the left and right displays are rotated by 60 degrees. The osgwindows example does this rotation trick, but for two windows/slave cameras, it should help provide some guidance though. Robert. On 19 August 2013 20:38, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hello List and Forum, We're developing an application that aims to take the best advantages of ultra-wide screen, which in our terms is basically using 3 widescreen monitors. Since our camera is to be of a kind of first person, I'd like to be able to display a field of view of about 180 degrees. I've been able to achieve that by using something like what's in osgdistortion, which is using a CompositeViewer with the main camera and 3 slave cameras. Now the items that should look straight are now bent at the 2 viewport junctions. So the 2 options I found were: 1) RTT everything that is in the scene and draw the texture on a distorted polygon (like in osgdistortion) 2) Draw on a quad and use a shader to distort the quad or what's on it. Questions: 1) In both cases I need to draw to a texture. --- camera-attach(osg::Camera::COLOR_BUFFER, texture, 0, osg::TextureCubeMap::POSITIVE_Z); This approach uses 6 faces of a cube map. Is there a way to use only 3 cameras, i.e. tell the camera to draw only on a part of the texture? 2) Would there be a way to tell the viewer to draw on a texture instead of the cameras? 3) Is the shader approach the best or the textured mesh is better? Thanks all; and sorry if I'm not too clear, it's not much clearer to me :P -- Alexandre Vaillancourt ___ 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] LineSegmentIntersector numerical imprecisions
Hi John, On 20 August 2013 06:09, PCJohn pec...@fit.vutbr.cz wrote: ** We could use Robert's idea to get start and end points. From them, we can get the biggest value for epsilon as well that would provide better epsilon. It should be smaller in most cases, but still big enough to always work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1] and start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be computed from end point 1e7 by multiplying 1e-5 with the result 100. Thus, bounding box will grow to [-101,-101,-101, 101,101,101], making false collision with start point [2,0,0]. Later computation in LineSegmentIntersector will remove the collision, but it costs computational time. After the consideration, my inclination is towards bounding box choosen epsilon (as opposite to start and end point based epsilon), as the user may tend to set high values for end points just to pick through the whole scene or to create fake ray, although not sure if I not overlooked something. The bounding box based epsilon will likely fail when the size of the box is very small compared to the length of the line segment. It's better to be conservative with this type of operation. If we get the computation right then we should be able to reduce the size of the epsilon considerably. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] FBX animations corrupted when using osg 3.2.0 with newer fbx plugin
Hi Björn, simple things first, did you try with SET OSG_OPTIMIZER=OFF Regards, Laurens. On 8/15/2013 10:14 AM, Björn Blissing wrote: To clarify the problem further. Loading and playing single FBX files seems to work fine. My problems begins when I try to copy animations from several FBX files into one model. I am merging animations from several diffrent files (mainly because Autodesk 3D Studio cannot export FBX files with multiple animations). I start by loading the first model, locating the AnimationManager, then opening the rest of the models. For each model I am locating their AnimationManager and getting the animation stored inside it, then coping and registering the animation into the first file's AnimationManager. A similar example can be found in this thread: http://forum.openscenegraph.org/viewtopic.php?t=12022 This strategy worked well with OSG 3.0.1, but for some reason (I haven't figured out why yet) it refuses to work with the new version. The connection between the bones and the animations seems to get a complete mismatch, which results in warped and twisted geometry. The bone responsible for the characters arm gets connected to the geometry of a foot and some of my animated characters literally ends up with their head up their own arse. The hip bones connected to the neck bone, The back bones connected to the foot bone ;) Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55852#55852 ___ 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] LineSegmentIntersector numerical imprecisions
Hi Robert, I have lost in your reasoning. Let me go back to be sure we understand each other. The bounding box based epsilon will likely fail when the size of the box is very small compared to the length of the line segment. I came to conclusion that size of bounding box does not matter. Even the lenght of line segment does not matter. I came to this by considering that box and the line segment (both of size 10, f.ex.) might not be close to [0,0,0], but they may be translated 1e7 far away. In such case, even epsilon of 1 would not change the size of box or line because it is bellow the numerical precision of float that already holds value 10'000'000 and it is not possible to append 1. Even although we want to enlarge it by 10% (from 10 to 11), we can not do it because of high value the float is carrying. Thus, size of line and box does not matter. What matters is the absolute float value, that is 10'000'000 in this case, so epsilon should be 10'000'000 * 1e-5 = 100. If I am wrong in something, please point it out to move our discussion forward. If you have some other approach in mind, please, do the same. I am looking purely for the good solution acceptable for you and OSG. John On Tuesday 20 of August 2013 06:54:21 Robert Osfield wrote: ** We could use Robert's idea to get start and end points. From them, we can get the biggest value for epsilon as well that would provide better epsilon. It should be smaller in most cases, but still big enough to always work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1] and start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be computed from end point 1e7 by multiplying 1e-5 with the result 100. Thus, bounding box will grow to [-101,-101,-101, 101,101,101], making false collision with start point [2,0,0]. Later computation in LineSegmentIntersector will remove the collision, but it costs computational time. After the consideration, my inclination is towards bounding box choosen epsilon (as opposite to start and end point based epsilon), as the user may tend to set high values for end points just to pick through the whole scene or to create fake ray, although not sure if I not overlooked something. The bounding box based epsilon will likely fail when the size of the box is very small compared to the length of the line segment. It's better to be conservative with this type of operation. If we get the computation right then we should be able to reduce the size of the epsilon considerably. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] FLT plugin rescale some textures with dimensions non power of two
Hi Robert, Thanks for your precise answer. I will follow your board. Cheers, Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55889#55889 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector numerical imprecisions
Hi John, I'm a bit confused as what to further explain. For precision purposes it's the math operations done to clamp the line segment to the bounding box that is important. The maths operations bascially use the length of the line segment in each axis and the distance from each face to the start point. An epsilon based on the largest of this values is probably the thing to go for, although one might simply simply it and us the length in each axis of the linesegment otherwise you'd need to introduce if()else blocks that are relatively expensive for the processor to handle. Robert. On 20 August 2013 10:33, PCJohn pec...@fit.vutbr.cz wrote: Hi Robert, I have lost in your reasoning. Let me go back to be sure we understand each other. The bounding box based epsilon will likely fail when the size of the box is very small compared to the length of the line segment. I came to conclusion that size of bounding box does not matter. Even the lenght of line segment does not matter. I came to this by considering that box and the line segment (both of size 10, f.ex.) might not be close to [0,0,0], but they may be translated 1e7 far away. In such case, even epsilon of 1 would not change the size of box or line because it is bellow the numerical precision of float that already holds value 10'000'000 and it is not possible to append 1. Even although we want to enlarge it by 10% (from 10 to 11), we can not do it because of high value the float is carrying. Thus, size of line and box does not matter. What matters is the absolute float value, that is 10'000'000 in this case, so epsilon should be 10'000'000 * 1e-5 = 100. If I am wrong in something, please point it out to move our discussion forward. If you have some other approach in mind, please, do the same. I am looking purely for the good solution acceptable for you and OSG. John On Tuesday 20 of August 2013 06:54:21 Robert Osfield wrote: ** We could use Robert's idea to get start and end points. From them, we can get the biggest value for epsilon as well that would provide better epsilon. It should be smaller in most cases, but still big enough to always work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1] and start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be computed from end point 1e7 by multiplying 1e-5 with the result 100. Thus, bounding box will grow to [-101,-101,-101, 101,101,101], making false collision with start point [2,0,0]. Later computation in LineSegmentIntersector will remove the collision, but it costs computational time. After the consideration, my inclination is towards bounding box choosen epsilon (as opposite to start and end point based epsilon), as the user may tend to set high values for end points just to pick through the whole scene or to create fake ray, although not sure if I not overlooked something. The bounding box based epsilon will likely fail when the size of the box is very small compared to the length of the line segment. It's better to be conservative with this type of operation. If we get the computation right then we should be able to reduce the size of the epsilon considerably. ___ 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] Textured quad displaying problem
Hi, Ohoh I solved the problem, the quad was not directed along the good plane ... Thanks to those who spent time to search a solution. Cheers, Mike -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55890#55890 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Drawable::drawImplementation (push StateSet)
Hi Community,
I have a custom rendering with GL calls and I want to wrap them in push/pop
StateSet (and everything). I see in osg::State all the push/pop (like
pushUniformList) methods are not accessible. Any hint how to do this?
Here is what is something like I need:
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
pushEverything()
doCustomGLRendering();
popEverything()
}
Thanks a bunch!
Nick
--
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] Drawable::drawImplementation (push StateSet)
Hi Nick,
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
osg::ref_ptrosg::StateSet standard_state(new osg::StateSet);
renderInfo.getState()-pushStateSet(standard_state);
perform CustomRendering();
renderInfo.getState()-popStateSet(standard_state);
}
This will replace the state with the default state.
I guess you can get the current state from the renderInfo as well.
cheers
Sebastian
Hi Community,
I have a custom rendering with GL calls and I want to wrap them in
push/pop StateSet (and everything). I see in osg::State all the
push/pop (like pushUniformList) methods are not accessible. Any hint
how to do this?
Here is what is something like I need:
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
pushEverything()
doCustomGLRendering();
popEverything()
}
Thanks a bunch!
Nick
--
trajce nikolov nick
___
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] Drawable::drawImplementation (push StateSet)
Hi Sebastian,
you are right.I can get renderInfo.getState() for the current state, was
wondering about the usage though. Let me try your suggestion and thanks!
Nick
On Tue, Aug 20, 2013 at 2:06 PM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
Hi Nick,
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
osg::ref_ptrosg::StateSet standard_state(new osg::StateSet);
renderInfo.getState()-pushStateSet(standard_state);
perform CustomRendering();
renderInfo.getState()-popStateSet(standard_state);
}
This will replace the state with the default state.
I guess you can get the current state from the renderInfo as well.
cheers
Sebastian
Hi Community,
I have a custom rendering with GL calls and I want to wrap them in
push/pop StateSet (and everything). I see in osg::State all the push/pop
(like pushUniformList) methods are not accessible. Any hint how to do this?
Here is what is something like I need:
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
pushEverything()
doCustomGLRendering();
popEverything()
}
Thanks a bunch!
Nick
--
trajce nikolov nick
___
osg-users mailing
listosg-users@lists.openscenegraph.orghttp://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] Drawable::drawImplementation (push StateSet)
Hi Sebartian,
A default constructed StateSet is empty, so pushing it on the osg::State
won't do anything at all. Also StateSet::pushStateSet() never applies any
State, it just pushes a StateSet on the osg::State stack, the overall
current state will applied once State::apply() is called.
Robert.
On 20 August 2013 12:06, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
Hi Nick,
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
osg::ref_ptrosg::StateSet standard_state(new osg::StateSet);
renderInfo.getState()-pushStateSet(standard_state);
perform CustomRendering();
renderInfo.getState()-popStateSet(standard_state);
}
This will replace the state with the default state.
I guess you can get the current state from the renderInfo as well.
cheers
Sebastian
Hi Community,
I have a custom rendering with GL calls and I want to wrap them in
push/pop StateSet (and everything). I see in osg::State all the push/pop
(like pushUniformList) methods are not accessible. Any hint how to do this?
Here is what is something like I need:
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
pushEverything()
doCustomGLRendering();
popEverything()
}
Thanks a bunch!
Nick
--
trajce nikolov nick
___
osg-users mailing
listosg-users@lists.openscenegraph.orghttp://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] Drawable::drawImplementation (push StateSet)
So Robert, what is the answer?
Nick
On Tue, Aug 20, 2013 at 2:52 PM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Sebartian,
A default constructed StateSet is empty, so pushing it on the osg::State
won't do anything at all. Also StateSet::pushStateSet() never applies any
State, it just pushes a StateSet on the osg::State stack, the overall
current state will applied once State::apply() is called.
Robert.
On 20 August 2013 12:06, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
Hi Nick,
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
osg::ref_ptrosg::StateSet standard_state(new osg::StateSet);
renderInfo.getState()-pushStateSet(standard_state);
perform CustomRendering();
renderInfo.getState()-popStateSet(standard_state);
}
This will replace the state with the default state.
I guess you can get the current state from the renderInfo as well.
cheers
Sebastian
Hi Community,
I have a custom rendering with GL calls and I want to wrap them in
push/pop StateSet (and everything). I see in osg::State all the push/pop
(like pushUniformList) methods are not accessible. Any hint how to do this?
Here is what is something like I need:
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
pushEverything()
doCustomGLRendering();
popEverything()
}
Thanks a bunch!
Nick
--
trajce nikolov nick
___
osg-users mailing
listosg-users@lists.openscenegraph.orghttp://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
--
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] Drawable::drawImplementation (push StateSet)
Hi Robert,
I'm aware of the empty state set.
In my case I of course change the state set.
Will this achieve the desired effect?
Hi Sebartian,
A default constructed StateSet is empty, so pushing it on the
osg::State won't do anything at all. Also StateSet::pushStateSet()
never applies any State, it just pushes a StateSet on the osg::State
stack, the overall current state will applied once State::apply() is
called.
Robert.
On 20 August 2013 12:06, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de
mailto:sebastian.messerschm...@gmx.de wrote:
Hi Nick,
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
osg::ref_ptrosg::StateSet standard_state(new osg::StateSet);
renderInfo.getState()-pushStateSet(standard_state);
perform CustomRendering();
renderInfo.getState()-popStateSet(standard_state);
}
This will replace the state with the default state.
I guess you can get the current state from the renderInfo as well.
cheers
Sebastian
Hi Community,
I have a custom rendering with GL calls and I want to wrap them
in push/pop StateSet (and everything). I see in osg::State all
the push/pop (like pushUniformList) methods are not accessible.
Any hint how to do this?
Here is what is something like I need:
void Drawable::drawImplementation(osg::RenderInfo renderInfo) const
{
pushEverything()
doCustomGLRendering();
popEverything()
}
Thanks a bunch!
Nick
--
trajce nikolov nick
___
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
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
Re: [osg-users] Drawable::drawImplementation (push StateSet)
On 20 August 2013 12:54, Trajce Nikolov NICK trajce.nikolov.n...@gmail.comwrote: So Robert, what is the answer? 42 ;-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawable::drawImplementation (push StateSet)
lol ;-) ... Come on. I am trying to wrap it with osg code instead of OpenGL calls (and forgot many things in between the ages) Nick On Tue, Aug 20, 2013 at 3:00 PM, Robert Osfield robert.osfi...@gmail.comwrote: On 20 August 2013 12:54, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: So Robert, what is the answer? 42 ;-) ___ 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] Drawable::drawImplementation (push StateSet)
On 20 August 2013 13:05, Trajce Nikolov NICK trajce.nikolov.n...@gmail.comwrote: lol ;-) ... Come on. I am trying to wrap it with osg code instead of OpenGL calls (and forgot many things in between the ages) There isn't a straight single line call, or answer to your question about resetting state. osg::State has a list of all the current StateSet + Modes in a series of stacks, a stack for each mode and stack for each stateattribute. Internally osg::State maintains a global_default_attribute for each of these stacks and calls this when the stack is newly emptied when the last stateattribute of that type of popped and the current state applied, the method osg::State::applyGlobalDefaultAttribute(AtrtributeStack) does the actual work so go have a look it it's implementation. The mode stacks also have a similar global_default_value member variable that tracks what to apply when all the modes of given type of popped. What is missing for you is a convenience method that gets all these defaults, or applies these. You could write one and submit it for inclusion in the OSG, or look to create your won StateSet based on these global defaults embedded in osg::State. Alternatively just apply the StateSet to make sure the modes and attributes you care about are set to a value that your OpenGL code requires - this is normally what one does in this instance. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Drawable::drawImplementation (push StateSet)
Thanks Robert, I was thinking to do something like this (but will look in your pointed direction as well). osg::State state = *renderInfo.getState(); osg::ref_ptr osg::StateSet stateSet = new osg::StateSet(); state.captureCurrentState( *stateSet ); state.disableAllVertexArrays(); state.dirtyAllVertexArrays(); GL Drawing state.apply(); The GL code usee glew and some (really few) calls for reseting some states, but my intension was not to include glew in the project and have it all osg clean. Thanks again Nick On Tue, Aug 20, 2013 at 3:27 PM, Robert Osfield robert.osfi...@gmail.comwrote: On 20 August 2013 13:05, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: lol ;-) ... Come on. I am trying to wrap it with osg code instead of OpenGL calls (and forgot many things in between the ages) There isn't a straight single line call, or answer to your question about resetting state. osg::State has a list of all the current StateSet + Modes in a series of stacks, a stack for each mode and stack for each stateattribute. Internally osg::State maintains a global_default_attribute for each of these stacks and calls this when the stack is newly emptied when the last stateattribute of that type of popped and the current state applied, the method osg::State::applyGlobalDefaultAttribute(AtrtributeStack) does the actual work so go have a look it it's implementation. The mode stacks also have a similar global_default_value member variable that tracks what to apply when all the modes of given type of popped. What is missing for you is a convenience method that gets all these defaults, or applies these. You could write one and submit it for inclusion in the OSG, or look to create your won StateSet based on these global defaults embedded in osg::State. Alternatively just apply the StateSet to make sure the modes and attributes you care about are set to a value that your OpenGL code requires - this is normally what one does in this instance. Robert. ___ 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
[osg-users] Make object totally transparent, but not hide :D
Hi, Sorry for noob question, but I need to make an object totally transparent (as invisible) but I have to maintain your presence in the world (the object can't be masked). This means that the object isn't visible but all collisions and others interactions in the world have to work. I can make the transparency using code like this, but the object isn't never really invisible: Code: osg::Material* l_material = (osg::Material*)p_Object-getStateSet()getAttribute(osg::StateAttribute::MATERIAL); l_material-setTransparency(p_face_mode, 1-p_transparency); p_Object-getOrCreateStateSet()-setMode(GL_BLEND, osg::StateAttribute::ON); p_Object-getOrCreateStateSet()-setAttributeAndModes(l_material, osg::StateAttribute::OVERRIDE); Where p_face_mode is FRONT_AND_BACK for example. Thank you! Cheers, Dario Code: -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55902#55902 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Make object totally transparent, but not hide :D
I've been doing that by adding a cull callback to the node I want invisible
like so:
Struct AlwaysCullDrawable : public osg::Drawable::CullCallback
{
/** do customized cull code.*/
virtual bool cull(osg::NodeVisitor*, osg::Drawable* drawable,
osg::State* /*state*/) const
{
return true;
}
};
collisionGeode-setCullCallback(new AlwaysCullDrawable());
Alistair Baxter
Software Engineer
Our next public training event is in Houston, USA on 20th - 22nd August 2013
For further information please visit www.mve.com/calendar
Midland Valley Exploration Ltd.
144 West George Street
Glasgow G2 2HG
United Kingdom
Tel: +44 (0) 141 332 2681
Fax:+44 (0) 141 332 6792
The structural geology experts
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Dario Minieri
Sent: 20 August 2013 14:36
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Make object totally transparent, but not hide :D
Hi,
Sorry for noob question, but I need to make an object totally transparent (as
invisible) but I have to maintain your presence in the world (the object
can't be masked). This means that the object isn't visible but all collisions
and others interactions in the world have to work.
I can make the transparency using code like this, but the object isn't never
really invisible:
Code:
osg::Material* l_material =
(osg::Material*)p_Object-getStateSet()getAttribute(osg::StateAttribute::MATERIAL);
l_material-setTransparency(p_face_mode, 1-p_transparency);
p_Object-getOrCreateStateSet()-setMode(GL_BLEND, osg::StateAttribute::ON);
p_Object-getOrCreateStateSet()-setAttributeAndModes(l_material,
osg::StateAttribute::OVERRIDE);
Where p_face_mode is FRONT_AND_BACK for example.
Thank you!
Cheers,
Dario
Code:
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=55902#55902
___
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] Pseydo-cylindrical projection
Hi Robert, Thanks for your answer. I have implemented something like what's in osgdistortion (--faces), with the 3 slave cameras, FoV of 60 degrees and the rotation of the left and right slave cameras by 60 degrees. It gives much better results than my first implementation of using a single camera with FoV of 180 degrees. However my problem is about world objects that should look 'straight' but are 'bent'. I've modified the osgdistortion --faces example to use only 3 cameras, and used the cessna object to show my issue. See the screenshot attached. There are clear weird bends in the image (I cropped and reduced it in size). Where the red arrows are, we can see the wing, the propeller blade and the cessna nose are, well, bent. This kind of distortion occurs for objects near the top of the screen and near the bottom of the screen, i.e. placing the cessna in the centre of the screen would not result in this distortion. Now, looking at the osgdistortion --dome, some correction seems to be done, but for a whole sphere instead of just a cylinder. And the the camera draws to a texture (TextureCubeMap) that is applied to a geometry instead of drawing directly to the screen (color buffer). What I'd like to achieve is a mix of those two examples: Use only 3 cameras, not the 6 faces of a cube, render to a texture and then distort it (using shaders or a distorted geometry). The goal here is not to have 'straight' lines because it might look weird, but rather 'smoothed' lines, which will probably be curved. So the question that remains: 1) Is it possible to attach cameras to the same texture without using a cube map? Thanks! [image: Images intégrées 1] -- Alexandre Vaillancourt 2013/8/20 Robert Osfield robert.osfi...@gmail.com Hi Alexandre, You shouldn't need to use a render to texture approach to set up drive displays,as each slave camera can just render 60 degrees of the overall FOV (plus a little bit if you are edge blending). All you'd need to do is set the slave cameras view offset matrix so that the left and right displays are rotated by 60 degrees. The osgwindows example does this rotation trick, but for two windows/slave cameras, it should help provide some guidance though. Robert. On 19 August 2013 20:38, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hello List and Forum, We're developing an application that aims to take the best advantages of ultra-wide screen, which in our terms is basically using 3 widescreen monitors. Since our camera is to be of a kind of first person, I'd like to be able to display a field of view of about 180 degrees. I've been able to achieve that by using something like what's in osgdistortion, which is using a CompositeViewer with the main camera and 3 slave cameras. Now the items that should look straight are now bent at the 2 viewport junctions. So the 2 options I found were: 1) RTT everything that is in the scene and draw the texture on a distorted polygon (like in osgdistortion) 2) Draw on a quad and use a shader to distort the quad or what's on it. Questions: 1) In both cases I need to draw to a texture. --- camera-attach(osg::Camera::COLOR_BUFFER, texture, 0, osg::TextureCubeMap::POSITIVE_Z); This approach uses 6 faces of a cube map. Is there a way to use only 3 cameras, i.e. tell the camera to draw only on a part of the texture? 2) Would there be a way to tell the viewer to draw on a texture instead of the cameras? 3) Is the shader approach the best or the textured mesh is better? Thanks all; and sorry if I'm not too clear, it's not much clearer to me :P -- Alexandre Vaillancourt ___ 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 LackOfDistortion.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Make object totally transparent, but not hide :D
HI Dario, I would typically use a NodeMask combined with a TraversalMask on the CullVisitor (controlled via osg::Camera's CullSettings interface) that switches off traversal during the cull traversal. Robert. On 20 August 2013 13:36, Dario Minieri para...@cheapnet.it wrote: Hi, Sorry for noob question, but I need to make an object totally transparent (as invisible) but I have to maintain your presence in the world (the object can't be masked). This means that the object isn't visible but all collisions and others interactions in the world have to work. I can make the transparency using code like this, but the object isn't never really invisible: Code: osg::Material* l_material = (osg::Material*)p_Object-getStateSet()getAttribute(osg::StateAttribute::MATERIAL); l_material-setTransparency(p_face_mode, 1-p_transparency); p_Object-getOrCreateStateSet()-setMode(GL_BLEND, osg::StateAttribute::ON); p_Object-getOrCreateStateSet()-setAttributeAndModes(l_material, osg::StateAttribute::OVERRIDE); Where p_face_mode is FRONT_AND_BACK for example. Thank you! Cheers, Dario Code: -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55902#55902 ___ 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] Pseydo-cylindrical projection
Hi Alexandre, My advice is NOT to do what you are doing, and NOT to follow osgdistotion. I'm not going to try and debug your approach as it's just wrong to start with. If you want to keep following go for it but I won't be spending my time help you bark up the wrong tree. Robert. On 20 August 2013 14:21, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi Robert, Thanks for your answer. I have implemented something like what's in osgdistortion (--faces), with the 3 slave cameras, FoV of 60 degrees and the rotation of the left and right slave cameras by 60 degrees. It gives much better results than my first implementation of using a single camera with FoV of 180 degrees. However my problem is about world objects that should look 'straight' but are 'bent'. I've modified the osgdistortion --faces example to use only 3 cameras, and used the cessna object to show my issue. See the screenshot attached. There are clear weird bends in the image (I cropped and reduced it in size). Where the red arrows are, we can see the wing, the propeller blade and the cessna nose are, well, bent. This kind of distortion occurs for objects near the top of the screen and near the bottom of the screen, i.e. placing the cessna in the centre of the screen would not result in this distortion. Now, looking at the osgdistortion --dome, some correction seems to be done, but for a whole sphere instead of just a cylinder. And the the camera draws to a texture (TextureCubeMap) that is applied to a geometry instead of drawing directly to the screen (color buffer). What I'd like to achieve is a mix of those two examples: Use only 3 cameras, not the 6 faces of a cube, render to a texture and then distort it (using shaders or a distorted geometry). The goal here is not to have 'straight' lines because it might look weird, but rather 'smoothed' lines, which will probably be curved. So the question that remains: 1) Is it possible to attach cameras to the same texture without using a cube map? Thanks! [image: Images intégrées 1] -- Alexandre Vaillancourt 2013/8/20 Robert Osfield robert.osfi...@gmail.com Hi Alexandre, You shouldn't need to use a render to texture approach to set up drive displays,as each slave camera can just render 60 degrees of the overall FOV (plus a little bit if you are edge blending). All you'd need to do is set the slave cameras view offset matrix so that the left and right displays are rotated by 60 degrees. The osgwindows example does this rotation trick, but for two windows/slave cameras, it should help provide some guidance though. Robert. On 19 August 2013 20:38, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hello List and Forum, We're developing an application that aims to take the best advantages of ultra-wide screen, which in our terms is basically using 3 widescreen monitors. Since our camera is to be of a kind of first person, I'd like to be able to display a field of view of about 180 degrees. I've been able to achieve that by using something like what's in osgdistortion, which is using a CompositeViewer with the main camera and 3 slave cameras. Now the items that should look straight are now bent at the 2 viewport junctions. So the 2 options I found were: 1) RTT everything that is in the scene and draw the texture on a distorted polygon (like in osgdistortion) 2) Draw on a quad and use a shader to distort the quad or what's on it. Questions: 1) In both cases I need to draw to a texture. --- camera-attach(osg::Camera::COLOR_BUFFER, texture, 0, osg::TextureCubeMap::POSITIVE_Z); This approach uses 6 faces of a cube map. Is there a way to use only 3 cameras, i.e. tell the camera to draw only on a part of the texture? 2) Would there be a way to tell the viewer to draw on a texture instead of the cameras? 3) Is the shader approach the best or the textured mesh is better? Thanks all; and sorry if I'm not too clear, it's not much clearer to me :P -- Alexandre Vaillancourt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB broken with OSG 3.2
Hello, it seems vpb is broken with OSG 3.2 (it work with OSG 3.1.7) This is the simple command: Code: osgdem -t a.tif -l 3 -o furlo.osgt the image a.tif is [Image: http://img16.imageshack.us/img16/6614/nbon.jpg ] The result in osgviewer is [Image: http://img96.imageshack.us/img96/7932/5dl7.jpg ] Massimo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55907#55907 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB broken with OSG 3.2
Hi Massimo, I can't think of any changes between 3.1.7 and 3.2.0 that are likely to cause a problem. Could you post the a.tif file so I can test against it. Thanks, Robert. On 20 August 2013 16:23, Massimo Tarantini subbi...@yahoo.it wrote: Hello, it seems vpb is broken with OSG 3.2 (it work with OSG 3.1.7) This is the simple command: Code: osgdem -t a.tif -l 3 -o furlo.osgt the image a.tif is [Image: http://img16.imageshack.us/img16/6614/nbon.jpg ] The result in osgviewer is [Image: http://img96.imageshack.us/img96/7932/5dl7.jpg ] Massimo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55907#55907 ___ 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] Pseydo-cylindrical projection
HI Alexandre, On 20 August 2013 17:03, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: May I ask why the way I'm going is not a good approach? It was far more complicated than it needed to be and you weren't getting the result you wanted... (Please note that my OSG knowledge is quite limited when talking about tricky stuff so I use what I get my hands on that'll achieve what I need to do, even if it's not the best solution, so I'm always open for better solutions.) Also, osgwindows uses translations, not a rotations. Changing the translation by a rotation (and updating the camera's projection matrix) I get something like in the image attached. Is that what you had in mind I should use as a basis? osgwindows will be using a projection matrix translation to replicate a power wall usage, for a rotation you simply apply the view offset matrix as a rotation when you set up the slave. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Model Load Crash
Hi, SOLVED So the problem was that I was corrupting something by doing two things in my application: 1.) I was initializing my osg::GraphicContext::Traits on a different thread than I was running and 2.) I was initializing the osg::GraphicContext itself on a different thread than I was running. The program still basically worked I assume because I did end up calling makeCurrent on my context appropriately. Keeping everything on one thread, however, seems like a much better solution in general. Thank you for all the help! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55912#55912 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
