[osg-users] Camera callbacks
Hi, I very like the capability of osg::Node to register any number of update, event and cull callbacks. This allows for a nice modular approach with each module registering callbacks for anything they wish without disturbing others. I came to a problem that Camera can register just one Initial-,Pre-,Post-, and Final-DrawCallback. Surely, I can register my own callback container that would call all my registered callback. But that is not compatible with OSG- registered Callbacks, for instance OcclusionQueryNode would overwrite my callback container. Could we possibly make the similar approach for the camera as for osg::Node? I can volunteer to make the first iteration for osg- submissions, if the community and Robert thinks that it is a good idea. My idea for implementation would be to append ref_ptrDrawCallback _nestedCallback into the Camera::DrawCallback structure, append Camera::add*Callback() and Camera::remove*Callback() and make Camera::callCallbacks(DrawCallback *cb) with a parameter giving pointer to the first DrawCallback of Initial-,Pre-,Post-, and Final- DrawCallback list. An alternative would be to let the user call nested callbacks from DrawCallback::operator(), but as we would always want (probably) to call all the callbacks and never stop in the middle of the work, I personally like the first approach more and it is more compatibility-friendly, as users will not need to modify their existing callbacks to get the new multi-callback capability. But I am ok with any approach. Do you think it is a good idea? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera callbacks
Hi Robert,
Providing similar support for Camera::DrawCallbacks would be possible,
there isn't the same imperative for controlling traversal, but it'd
keep the public Camera API simple - it's complicated enough as it is
so am reluctant to add further API to it.
Sorry, I am not native English. By the last sentence do you mean that the
multiple Camera::DrawCallback support must be as simple as possible or that
you would prefer to not put it into the API?
I am not pushing the things, but it seems that shadow classes are already not
compatible with OcclusionQueryNode as they both register pre and post draw
callbacks. And a programmer might want to make his own callbacks for profiling
reasons, start various OpenGL queries, resize his own custom RenderBuffers used
for HDR rendering whenever screen window resizes, etc.
My idea was:
struct OSG_EXPORT DrawCallback : virtual public Object
{
DrawCallback() {}
DrawCallback(const DrawCallback,const CopyOp) {}
META_Object(osg, DrawCallback);
virtual void operator () (osg::RenderInfo renderInfo) const;
virtual void operator () (const osg::Camera /*camera*/) const {}
ref_ptrDrawCallback _nestedCallback;
};
inline void addPreDrawCallback(DrawCallback* dc)
{
if (dc != NULL) {
dc-_nestedCallback = _preDrawCallback;
_preDrawCallback = dc;
}
}
inline void removePreDrawCallback(DrawCallback* dc)
{
if (dc != NULL) {
if (dc == _preDrawCallback)
_preDrawCallback = _preDrawCallback-_nestedCallback;
else
{
DrawCallback *c = _preDrawCallback;
while (c) {
if (c-_nestedCallback==dc) {
c-_nestedCallback = c-_nestedCallback-
_nestedCallback;
dc-_nestedCallback = NULL;
return;
}
}
}
}
}
Not sure if it is enough thread-safe. If you think that Initial-,Pre-,Post-,
and Final-DrawCallback functionality has too many methods,
we can make like see bellow, while possibly deprecating some of the current
methods.
enum DrawCallbackEnum { INITIALIZE_DRAW_CALLBACK = 0,
PRE_DRAW_CALLBACK = 1,
POST_DRAW_CALLBACK = 2,
FINALIZE_DRAW_CALLBACK = 3 };
inline void addPreDrawCallback(DrawCallbackEnum which, DrawCallback* dc)
{
if( which 4 ) {
ref_ptrDrawCallback c = _drawCallbacks[which];
}
inline void removePreDrawCallback(DrawCallbackEnum which, DrawCallback*
dc)
{ }
ref_ptrDrawCallback _drawCallbacks[4]; // this replaces four variables
John
On Wednesday 09 of April 2014 16:16:31 Robert Osfield wrote:
Hi John,
Original Node callbacks didn't support multiple callbacks, but I
worked out that I could add the functionality relatively
non-intrusively by nesting callbacks. The key advantage with nesting
is that it enables a callback retain data on the stack within the
local scope of the callback - which makes things easy to implement and
gives you thread safety for free, and enables the callback to take
complete controlling traversal.
Providing similar support for Camera::DrawCallbacks would be possible,
there isn't the same imperative for controlling traversal, but it'd
keep the public Camera API simple - it's complicated enough as it is
so am reluctant to add further API to it. The alternative would be to
add a list of callbacks, but as you said this would break
compatibility.
Robert.
On 9 April 2014 14:10, PCJohn pec...@fit.vutbr.cz wrote:
Hi,
I very like the capability of osg::Node to register any number of update,
event and cull callbacks. This allows for a nice modular approach with
each
module registering callbacks for anything they wish without disturbing
others.
I came to a problem that Camera can register just one Initial-,Pre-,Post-,
and Final-DrawCallback. Surely, I can register my own callback
container that would call all my registered callback. But that is not
compatible with OSG- registered Callbacks, for instance
OcclusionQueryNode would overwrite my callback container. Could we
possibly make the similar approach for the camera as for osg::Node? I can
volunteer to make the first iteration for osg- submissions, if the
community and Robert thinks that it is a good idea.
My idea for implementation would be to append
ref_ptrDrawCallback _nestedCallback into the Camera::DrawCallback
structure, append Camera::add*Callback() and Camera::remove*Callback()
and make Camera::callCallbacks(DrawCallback *cb) with a parameter giving
pointer to the first DrawCallback
[osg-users] osgt - kate syntax highlight
Hi all, I wanted to hand-edit osgt files. It is nightmare to do it without code- folding and text highlighting. Thus, I created highlight definition file for kate editor (attached). Especially, code folding is very very helpful to edit and analyse any osgt file. For those interested: To install it, place osgt.xml to appropriate folder. On my Kubuntu 13.04, the correct place is: /usr/share/kde4/apps/katepart/syntax/osgt.xml Restart of kate might be necessary afterwards. To check the successful installation, look in Menu - Tools - Highlighting - Markup and you should see OpenSceneGraph option. Now, any osgt file opened should contain code folding and highlighting support. One interesting thing - I tried to edit few hundred megabyte file with hundreds of thousands of nodes and I got frozen kate for one minute on the first code folding click. But after one minute it got back again. The rest of editing was very fast. The file provides just very basic things, but already very helpful. Feel free to improve it and to provide us with updated version. John osgt.xml Description: XML document ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How change the vertical sync?
Hi Julio,
this is the code I am using (you may need to reformat it, because email splits
many lines into two). Call it once you have active context.
You may still need some includes like
#include osg/GLExtensions
#if defined(__WIN32__) || defined(_WIN32)
# [...]
#else
# include GL/glx.h
#endif
and so on.
John
//
// vsync could be controlled by following OpenGL extensions:
//
// Swap control approaches:
// GLX_SGI_swap_control (1995) / WGL_EXT_swap_control (1999) /
GLX_EXT_swap_control (2009)
// GLX_EXT_swap_control_tear (2011) / WGL_EXT_swap_control_tear (2011)
//
// Synchronization approaches:
// GLX_SGI_video_sync (1995) / GLX_OML_sync_control (2001) /
WGL_OML_sync_control (2001)
//
// Swapping a group of drawables and windows:
// GLX_SGIX_swap_group (1996) / GLX_SGIX_swap_barrier (1996) /
GLX_NV_swap_group (2003) / WGL_NV_swap_group (2003)
//
const char* extensions = NULL;
#if defined(__WIN32__) || defined(_WIN32)
typedef const char* WINAPI WGLGETEXTENSIONSSTRINGARB( HDC );
WGLGETEXTENSIONSSTRINGARB* wglGetExtensionsStringARB;
osg::setGLExtensionFuncPtr( wglGetExtensionsStringARB,
wglGetExtensionsStringARB );
typedef const char* WINAPI WGLGETEXTENSIONSSTRINGEXT();
WGLGETEXTENSIONSSTRINGEXT* wglGetExtensionsStringEXT;
osg::setGLExtensionFuncPtr( wglGetExtensionsStringEXT,
wglGetExtensionsStringEXT );
if( wglGetExtensionsStringARB )
{
HDC dc = wglGetCurrentDC();
extensions = wglGetExtensionsStringARB( dc );
}
else if( wglGetExtensionsStringEXT )
{
extensions = wglGetExtensionsStringEXT();
}
#else
// get current display
// (glXGetCurrentDisplay() is supported since GLX 1.2)
Display *d = glXGetCurrentDisplay();
// (glXGetCurrentContext() is supported maybe since beginning? (1.0?),
// at least it is supported in GLX 1.2)
GLXContext c = glXGetCurrentContext();
// get current screen
// (glXQueryContext() is available since GLX 1.3)
int screen;
if( c == NULL || glXQueryContext( d, c, GLX_SCREEN, screen ) != Success )
{
OSG_WARN GLX: failed to get screen number. endl;
screen = DefaultScreen( d );
}
// get glx extension string
// (glXQueryExtensionsString is available since GLX 1.1)
extensions = glXQueryExtensionsString( d, screen );
#endif
if( extensions )
{
#if defined(__WIN32__) || defined(_WIN32)
if( osg::isExtensionInExtensionString( WGL_EXT_swap_control,
extensions ) )
{
typedef BOOL WINAPI WGLSWAPINTERVALEXTPROC(int interval);
WGLSWAPINTERVALEXTPROC* wglSwapIntervalEXT =
(WGLSWAPINTERVALEXTPROC*)osg::getGLExtensionFuncPtr( wglSwapIntervalEXT,
extensions );
bool adaptiveSwapSupported = osg::isExtensionInExtensionString(
WGL_EXT_swap_control_tear, extensions );
#else
bool sgiSwapControl = osg::isExtensionInExtensionString(
GLX_SGI_swap_control, extensions );
bool extSwapControl = osg::isExtensionInExtensionString(
GLX_EXT_swap_control, extensions );
if( sgiSwapControl || extSwapControl )
{
typedef int (*PFNGLXSWAPINTERVALSGIPROC) (int interval);
typedef void (*PFNGLXSWAPINTERVALEXTPROC) (Display *dpy, GLXDrawable
drawable, int interval);
PFNGLXSWAPINTERVALSGIPROC glXSwapIntervalSGI = sgiSwapControl ?
(PFNGLXSWAPINTERVALSGIPROC)osg::getGLExtensionFuncPtr(
glXSwapIntervalSGI, extensions ) : NULL;
PFNGLXSWAPINTERVALEXTPROC glXSwapIntervalEXT = extSwapControl ?
(PFNGLXSWAPINTERVALEXTPROC)osg::getGLExtensionFuncPtr(
glXSwapIntervalEXT, extensions ) : NULL;
bool adaptiveSwapSupported = osg::isExtensionInExtensionString(
GLX_EXT_swap_control_tear, extensions );
#endif
int value = _vsync ? ( adaptiveSwapSupported ? -1 : 1 ) : 0;
OSG_NOTICE OSGWiget: Setting vertical synchronization (
value != 0 ? ON : OFF )
(swap interval set to value ). endl;
#if defined(__WIN32__) || defined(_WIN32)
if( wglSwapIntervalEXT )
wglSwapIntervalEXT( value );
#else
// try glXSwapIntervalEXT in the first place as it supports
// adaptive swap ([WGL|GLX]_EXT_swap_control_tear) and zero value for
disabling v-sync
if( glXSwapIntervalEXT )
glXSwapIntervalEXT( d, glXGetCurrentDrawable(), value );
else
if( glXSwapIntervalSGI )
{
// glXSwapIntervalSGI does not support value 0 according to
documentation,
// only values =1, but it seems to work for disabling v-sync
anyway
if( glXSwapIntervalSGI( value ) )
OSG_WARN glXSwapIntervalSGI() failed. endl;
}
#endif
}
}
On Tuesday 15 of October 2013 20:55:03 Eric Sokolowsky wrote:
If you have an Nvidia card, you can set the environment variable
__GL_SYNC_TO_VBLANK=1 or =0 to enable or disable vertical syncing, but this
must be done before the graphics context is
Re: [osg-users] graphics context capabilities in cull phase
Hi Robert and Mathias, back after the weekend. I do also wonder about formalizing the extension set up. In essence we are initializing bool relating to feature supported yes/no, and the function pointers. Currently it's all rather adhoc how this is all done. The whole area could do with a major refactor to make things more coherent. For refactoring, three ideas are coming to my mind (please, append yours): 1. I would like to have GL_FEATURE(...) macro that would register me a bool that would be set to a yes/no depending on some evaluation (extension support, GL version, GLSL version, number of texture samplers, etc.). I should be able to get its value on per-contextID basis. and GL_FUNCTION() macro that would register me a function that would be automatically initialized (per-context) during realize. But I am worrying about performance hit as looking-up the function by contextID might take some time. Thus, I would prefer another approach. 2. I would like to have a class, say GraphicsContextMediator, and I would append members by macros named, say, GL_FEATURE(...) (for an auto-detected bool) and GL_FUNCTION(...) (for an auto-binded OpenGL function). They would automatically initialize their content on the GraphicsContextMediator construction. The construction would be triggered by a proxy during GraphicsContext::realize(). GraphicsContextMediator could be a private class, if we want. It can be inside any .cpp file, providing GL informations wherever programmer puts it, including StatsHandler. This way, StatsHandler might stop out-source OpenGL function pointers from Drawable::Extensions, but they might be moved to its own code, possibly improving the code quality. 3. Still one more option - to use existing osg::isExtensionOrVersionSupported() and similar functions and make them work properly even outside active graphics context. However, this functionality would probably not serve for advanced things like getting number of texture samplers or max uniforms, etc. Just extensions and OpenGL version and nothing more. Still more ideas by anyone? For a registry of objects to initialize my inclination would be to have a registry of all OpenGL objects types, which is essentially osg::Drawable and osg::StateAttribute's, perhaps one could just have a registry of osg::Object and then cast these to Drawable or StateAttribute then call a function to do the initialize. I would also be inclined to have a initializeExtensions(State) method that Drawable and StateAttribute have that is called. This approach would mean you wouldn't need to worry about the specifics of the various extension classes. However, this might not be ideal subdivision for this feature. I agree, just I do not understand - what do you mean by registry of OpenGL object types? Object type is not an instance, thus it does not have a pointer that could be registered in a list. Could you clarify for me how it would work? Thanks, John On Friday 20 of September 2013 14:16:36 Robert Osfield wrote: Hi John and Mathias, I haven't discounted or approve of any one option yet, but have done a little more thinking. Mathias's suggestion of a flag whether the realize should invoke all the initialization steps or leave it to lazy initialization would be sensible if we wish to avoid the cost of initializing all extensions sounds reasonable compromise. Although this might leave application developers need to support both lazy and realize initializations in their applications yet in case. For a registry of objects to initialize my inclination would be to have a registry of all OpenGL objects types, which is essentially osg::Drawable and osg::StateAttribute's, perhaps one could just have a registry of osg::Object and then cast these to Drawable or StateAttribute then call a function to do the initialize. I would also be inclined to have a initializeExtensions(State) method that Drawable and StateAttribute have that is called. This approach would mean you wouldn't need to worry about the specifics of the various extension classes. However, this might not be ideal subdivision for this feature. I do also wonder about formalizing the extension set up. In essence we are initializing bool relating to feature supported yes/no, and the function pointers. Currently it's all rather adhoc how this is all done. The whole area could do with a major refactor to make things more coherent. More widely I do also wonder whether we should split up the scene graph data from the OpenGL implementation, so that the scene graph data object would have a list of implementations, these implementations might contain handles to extensions or OpenGL object id's a handle to the extension. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] graphics context capabilities in cull phase
Hi Robert, you are right. ViewerBase::setRealizeCallback is one solution. Unfortunately, there are two problems with it. The easier one - multiple realize callbacks: Several components of my application would like to register realize callback (rendering component, OpenCL component, and maybe one or two more). I very like NodeCallback approach for Node class that you can register any number of update, event or cull callbacks. Would you be ok with extending the realize callback with the similar functionality as NodeCallback provides, e.g. multiple called routines? The second - knowing your viewer: Viewer and CompositeViewer can not be queried for the instance (something like singleton approach). Thus, each module or application component that need to register realizeCallback have to somehow acquire the pointer to the Viewer. Such query functionality for Viewer/CompositeViewer instance is already missing in osgQt. osgQt needs to know Viewer and it is implemented using osgQt::setViewer() funtion. In my opinion (criticizing because I designed it) it is a hack and not a nice solution. The same would be for ShadowVolumes if they would ever be included in osgShadow. They need realizeCallback for OpenCL initialization and initialization of one or two *::Extensions needed for shadow rendering. I can create osgShadow::setViewer(ViewerBase*) function to pass Viewer in, but I have an impression that it is a hack. Anyway, I can live with it at the moment. But would you be against making ViewerBase* ViewerBase::instance() method that would return the Viewer/CompositeViewer that was constructed as f.ex. the first one? Initializing all extension on realize is no bad thing though, one would need to have a registry of extension objects and have a proxy object for each one to register itself with the extension registry. In the simplest case, the registry might be just a list of pointers to initialization routines. The initialization routines would just call *::Extensions::setupGLExtensions(). The initialization routines would register themselves to the registry (possibly std::list) by proxy objects. Just repeating what you wrote to make sure I understand you correctly. Correct me otherwise. The registry might be std::list or did you planned to put it into the container class? This would be very non-intrusive approach that would just initialize the existing *::Extensions classes (e.g. Drawable::Extensions,...) One could then get the extension supported by calling the registry. This was not my initial intention as *::Extensions classes can be get by *::getExtensions(contextID) method (e.g. Drawable::getExtensions(contextID)). But we might design something if it would be useful. However, this type of scheme would add extra complexity, and increase the footprint of the OSG in memory and the speed of initialize as you'd need to register all extensions even the ones that you application doesn't need. My plan was with proxies and std::list of pointers to initialization routines. We have about 18 *::Extensions classes, so it is eighteen pushes to std::list. If using inline constructors, the code will be very fast and time taken non- measurable. Calling of *::getExtensions(contextID, true) during realize for all 18 registered *::Extensions should not make any measurable impact. Creating of graphics context or making it current might take much more time. And we may make this *::Extensions initialization optional by some flag. Thanks, John On Thursday 19 of September 2013 15:20:15 Robert Osfield wrote: Hi John, I don't believe it's necessary to initialize all extensions together as if you do have code paths/scene graph subgraph selection that is dependent on extension/version presence it'll be for specific extensions/versions, as you could initialize the ones of interest for you application within a Viewer Realizer operation, see osgvolume for an example of this. So without any changes to the OSG can achieve what you want with a little bit of coding. Initializing all extension on realize is no bad thing though, one would need to have a registry of extension objects and have a proxy object for each one to register itself with the extension registry. One could then get the extension supported by calling the registry. However, this type of scheme would add extra complexity, and increase the footprint of the OSG in memory and the speed of initialize as you'd need to register all extensions even the ones that you application doesn't need. Robert. On 19 September 2013 14:43, PCJohn pec...@fit.vutbr.cz wrote: Hi Robert, I noticed one missing feature in OSG and I would be glad to discuss the solution with you before making further steps. The problem: - In cull phase, it would be useful to be able to find out which OpenGL extensions are supported and GLSL version available in the graphics context. Why anybody might need it? The programmer
[osg-users] graphics context capabilities in cull phase
Hi Robert, I noticed one missing feature in OSG and I would be glad to discuss the solution with you before making further steps. The problem: - In cull phase, it would be useful to be able to find out which OpenGL extensions are supported and GLSL version available in the graphics context. Why anybody might need it? The programmer might want to cull different scene graphs for contexts with different capabilities. For example, if target platform supports two sided stencil, it might cull one scene graph (faster and simpler graph), while providing another scene graph if only single side stenciling is available. The same for geometry shaders - they might be supported through GL_ARB_geometry_shader4 extension - requiring their own shader code, through OpenGL 3.2 with different shader code, or programmer might provide still different graph for OpenGL 4.0 geometry shader, profiting from multiple invocations capability introduced in GLSL 4.0. However, to make this work, we need to get graphics context capabilities in cull phase. Proposed solutions (for you to judge and possibly suggest the best approach): - To avoid extensive changes to OSG, I think, we can use the existing approach of Extensions nested class, like Drawable::Extensions, Stencil::Extensions, etc. The advantage of the approach is that the user may detect whatever he may want or think of inside Extensions::setupGLExtensions() while the users are already familiar with this concept. The problem with the Extensions class is that it is not initialized until the first getExtensions() call inside draw phase. Usually it means that we can not get valid Extensions instance in the first frame cull phase. And it is still not guaranteed to be initialized for the second frame. - My idea, and I ask your counsel, was to auto-initialize all *::Extensions instances for any new graphics context that is realized in the application. If this might me overkill for some reason, we might provide some per-graphics- context flag for the user and he might choose which context should use this functionality and which should not. - To implement such functionality, we might use proxy approach and register all *::Extensions classes in some global list. Then, we might, for instance, go through the list and call setupGLExtensions() for all registered *::Extensions classes. Such procedure would be done whenever a context is realized. - Another approach might be to give the user the possiblity to register GraphicsContext::realizeCallback (something like swapCallback but for realize). This way, the user may initialize required *::Extensions classes himself. The disadvantage of this approach is that the user would be required to write some code (the initialization code and callback registration). The proxy approach mentioned above would do the job for him automatically. Before discussing implementation details, do you think that the proposal is reasonable or would you prefer different approach for the problem? Essentially, it is about ability to know graphics context capabilities during cull phase to be able to cull the scene graph that is the best suitable for the graphics context. Thanks for the answer and keeping OSG growing. John ___ 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, if I understand you correctly, you proposed the idea to not expand bounding box, but to lengthen the line segment. I feel it as more complicated as I am not convinced that it will not tend to more numerical problems. On small slopes close to the edge, you may easily hit different side of bounding box and on nearly parallel lines get hit with the side even if there is none, resulting with wrong line clipping. Lenghtening the segment might not fix these numerical problems. For me, bounding box size increase is simple and robust solution. Some expert might consider all the details of LineSegmentIntersector implementation, local coordiante system and all the precision that box and line is using and prove that there will be no problems. If somebody is interested to put a time to this, I would welcome it. For myself as I lack the time and lengthening of line segment would probably not bring any noticeable performance difference, thus bounding box size increase is for me quick and robust solution. This is my conclusion. I am not saying it is the best, etc., but it should work. More ideas? (Sorry for late answer, I was under heavy work load for two days and one night.) John On Tuesday 20 of August 2013 11:12:53 Robert Osfield wrote: 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
Re: [osg-users] LineSegmentIntersector numerical imprecisions
Hi Robert, after this new idea, I am starting to ask myself, what are the cases for which we need epsilon? - when the line segment accidentally misses bbox while triangle intersection routines would indicate intersection (can this happen?) - when clipping puts the start or end point inside the bbox, thus triangles on the bbox surface might be omitted from the intersection If only the second point is the case, your proposed solution could handle this quite well. Once again, we have probably different opinion about computing epsilon. If I understand it right, you want to make epsilon something line lineSegmentLenght*1e-5, am I right, or once again I do not understand your idea? (By epsilon I mean the space distance that you shift the start or end.) I am writing it because lineSegmentLength is unrelated to the float precision of newly computed start and end. Thus, computation based on lineSegmentLength would fail in many cases. If we have newly computed start close to the [0,0,0], we have high precision and epsilon should be very small, otherwise we waste float precision. And if newly computed start is [1e10, 1e10, 1e10], then epsilon must be quite big to move such point, otherwise missing intersections may occur. Unfortunately, computer floating arithmetic is strange and 1e10 + 1e2 = 1e10 . Correct me if I am not right. John On Thursday 22 of August 2013 10:17:57 Robert Osfield wrote: Hi John, I wasn't thinking of expanding the line segment, rather expanding the bounding box just with a epsilon scaled by the line segment length. However, you confusion about what I was thinking has given me an idea - perhaps the best thing to do is do the intersection against the original bounding box then pull the intersection point on the line segment back towards the original end points just a little. In essence this is exactly what expanding the bounding box always did, but rather than put the epsilon into the bounding box, we just put it into the ratio that is used to compute the near start and and end points, as a ratio is used when computing the distance there won't be any need to scale the epsilon too. So the code: // clip s to xMin. s = s+(e-s)*(bb_min.x()-s.x())/(e.x()-s.x()); Would change to something like: s = s+(e-s)*((bb_min.x()-s.x())/(e.x()-s.x())-epsilon); One would need to add a check to make sure the ratio computed isn't less than the epsilon though, you wouldn't want the start and end points migrating outwards. Robert. ___ 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 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] 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
[osg-users] LineSegmentIntersector numerical imprecisions
Hi Robert, there was recently a commit concerning epsilon in LineSegmentIntersector that is now carried as class member. I can imagine motivation behind, but I belive there is a better approach to the problem. If the motivation is just to allow the setting bigger epsilon for bigger objects (too small epsilon, recently statically assigned to 1e-5, will not affect big bounding boxes because of limited float resolution. I belive, this was 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 of bounding 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-coding epsilon, even when giving the user the ability to change it, is not correct way in my opinion, as there may be very small objects (requiring small epsilon) together with big objects (requiring big epsilon) in the scene. We can give the user the callback to adjust the epsilon for each visited object in the scene, but I do not belive this is the best approach. I would very prefer to scale epsilon by the size of the object as this is how the floats change their precision. Bigger the object, bigger the value in float, smaller float precision, bigger the epsilon is needed. The precision of float is between 1e-7 to 1e-6, so multiplying the size of bounding box by 1e-5 should provide big enough increase of the bounding box to avoid numerical imprecisions. Having to specify epsilon by programmer is making the things more difficult for him, as he should understand float problems and has to think about the precision value, while he usually just wants intersector to work correctly, not taking care about hardware precision limitations. Scaling the epsilon would do the work for him without giving him another parameter that may turn things wrong if not set properly. Your opinion on this point? I can create patch based on your suggestions. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow Volumes integration
Hi Robert and J-S,
thanks for suggestions. The namespace trick seems interesting.
I will try to lead our code in this direction.
John
On Friday 01 of February 2013 09:05:47 Robert Osfield wrote:
Hi Johan and JS,
My inclination would be towards using a nested namespace as suggest by
J-S, this will avoid wider namespace pollution with generic names, but
still allow the implementation to use the short hand and end up with
more readable code. Another twist on this is to use the class as a
namespace, so have the support classes nested within the
ShadowTechnique implementation.
Robert.
On 1 February 2013 00:38, Jean-Sébastien Guay jean_...@videotron.ca wrote:
Hi John,
One suggestion, you could use nested namespaces, and then abbreviate
locally so it's easier to read. For example:
namespace osgShadow
{
namespace ShadowVolume
{
class Occluder { ... }
}
}
// then in some .cpp file where you need to use it:
namespace osgsv = osgShadow::ShadowVolume;
void someFunction()
{
osg::ref_ptrosgsv::Occluder occluder = new osgsv::Occluder;
}
That way we don't need a new separate top-level namespace, it shows it's
clearly a shadow technique so it's in osgShadow, yet it's separate from
the
other osgShadow code so you prevent name clashes. And using the
abbreviated
name locally helps with code that would become really verbose and hard to
read, while not being ambiguous like using namespace ... in the case
some
classes have the same name eventually.
Just a suggestion, I don't know if Robert will like this style, he may
prefer one of your other suggestions but this is another alternative to
add
to the mix.
J-S
On 31/01/2013 5:21 AM, PCJohn wrote:
Hi,
me and my coleague have developed number of Shadow Volume shadow
algorithms
and we would like to contribute them one day to OSG.
To mention the reason for Shadow Volumes: They are often used in CAD,
etc.
as
they work in screen space, thus they do not suffer with
aliasing/resolution
problems of Shadow Map-based algorithms. Surely, you pay the quality by
the
speed. But sometimes, you simply can not tolerate shadow artifacts and
performance of shadow volumes on today graphics cards is basically
excellent
(in my eyes).
My questions (probably on Robert) to best fit with OSG design:
- My implementation covers number of methods (7-10 planned, 2 in
developement,
4 finished) starting from simple cpu implementations and finishing by
geometry
shader and OpenCL implementations (silhouette based approaches). Thus I
have
family of classes like Occluder, OccluderGroup, ShadowDataBuilder,
CpuSilhouetteDataBuilder, OpenCLSilhouetteOccluder (12 at the moment,
and
more on the way). I was considering to append them to osgShadow library,
but I
am worrying about some name clashes as, for instance, Occluder or
ShadowDataBuilder are too general names and developers of Shadow Maps
might
(1) want to use them or (2) they might cause some confusion as there is
already, for instance, OccluderGeometry class.
Would you prefer to:
(a) do not worry about clashes and simply use Occluder name as it is
still
not
in use in osgShadow (the same with all other classes).
(b) to create namespace osgShadowVolume and make ecosystem of classes of
shadow maps and shadow volumes distinct - they really does not have much
in
common and probably only share just two abstract base classes:
osgShadow::ShadowedScene and osgShadow::ShadowTechnique. Having two
separate
namespaces may make even doc more understandable because when looking for
a
particular class, I will look into the appropriate namespace and not to
the
mix of both shadow approaches.
(c) prepend Occluder by a prefix SV, e.g. SVOccluder, SVOccluderGroup
(d) prepend Occluder by ShadowVolume prefix, e.g. ShadowVolumeOccluder,
ShadowVolumeVertexExtrusionDataBuilder,
ShadowVolumeGeometryShader2DManifoldSilhouetteOccluder. I am just not
sure
if
some names would not lost readability - 4 words in class name seems
acceptable
to me but adding two more seems too much. And surely, I would need to
think
how to make the longest names a little bit shorter - the last class still
does
not exist, but its full name would not be acceptable.
(e) postpone the decision
I am refactoring my code now so any suggestions welcomed.
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
__
Jean-Sebastien Guay jean_...@videotron.ca
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users
[osg-users] Shadow Volumes integration
Hi, me and my coleague have developed number of Shadow Volume shadow algorithms and we would like to contribute them one day to OSG. To mention the reason for Shadow Volumes: They are often used in CAD, etc. as they work in screen space, thus they do not suffer with aliasing/resolution problems of Shadow Map-based algorithms. Surely, you pay the quality by the speed. But sometimes, you simply can not tolerate shadow artifacts and performance of shadow volumes on today graphics cards is basically excellent (in my eyes). My questions (probably on Robert) to best fit with OSG design: - My implementation covers number of methods (7-10 planned, 2 in developement, 4 finished) starting from simple cpu implementations and finishing by geometry shader and OpenCL implementations (silhouette based approaches). Thus I have family of classes like Occluder, OccluderGroup, ShadowDataBuilder, CpuSilhouetteDataBuilder, OpenCLSilhouetteOccluder (12 at the moment, and more on the way). I was considering to append them to osgShadow library, but I am worrying about some name clashes as, for instance, Occluder or ShadowDataBuilder are too general names and developers of Shadow Maps might (1) want to use them or (2) they might cause some confusion as there is already, for instance, OccluderGeometry class. Would you prefer to: (a) do not worry about clashes and simply use Occluder name as it is still not in use in osgShadow (the same with all other classes). (b) to create namespace osgShadowVolume and make ecosystem of classes of shadow maps and shadow volumes distinct - they really does not have much in common and probably only share just two abstract base classes: osgShadow::ShadowedScene and osgShadow::ShadowTechnique. Having two separate namespaces may make even doc more understandable because when looking for a particular class, I will look into the appropriate namespace and not to the mix of both shadow approaches. (c) prepend Occluder by a prefix SV, e.g. SVOccluder, SVOccluderGroup (d) prepend Occluder by ShadowVolume prefix, e.g. ShadowVolumeOccluder, ShadowVolumeVertexExtrusionDataBuilder, ShadowVolumeGeometryShader2DManifoldSilhouetteOccluder. I am just not sure if some names would not lost readability - 4 words in class name seems acceptable to me but adding two more seems too much. And surely, I would need to think how to make the longest names a little bit shorter - the last class still does not exist, but its full name would not be acceptable. (e) postpone the decision I am refactoring my code now so any suggestions welcomed. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Uniform above Program
Hi, it seems that it is not possible to put an uniform to the stateset of the scene root (for example, light position) and to put Program at the bottom (say, at a stateset of a drawable). It seems to me that the Program and all its Uniforms must be put the same StateSet. This way, it works for me. However, it is not a flexible approach. Must the Program and all its Uniforms be put to the same StateSet or should I investigate this bug candidate? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Uniform above Program
Hi Sergey, this never worked for me for about a half of year. Update: now it works! It seems that maybe, I was unlucky on svn update and, kept the update for a while, seeing this issue. Based on your assurance, I made some tests and updated my shader routines. All shows that the issue is gone. Thanks. John On Friday 17 of August 2012 12:52:01 Sergey Polischuk wrote: Hi, John it seems that it is not possible to put an uniform to the stateset of the scene root (for example, light position) and to put Program at the bottom (say, at a stateset of a drawable). It's just not true, and works for me all the time. Can you post minimal example that dont work? Cheers, Sergey. 17.08.2012, 12:20, PCJohn pec...@fit.vutbr.cz: Hi, it seems that it is not possible to put an uniform to the stateset of the scene root (for example, light position) and to put Program at the bottom (say, at a stateset of a drawable). It seems to me that the Program and all its Uniforms must be put the same StateSet. This way, it works for me. However, it is not a flexible approach. Must the Program and all its Uniforms be put to the same StateSet or should I investigate this bug candidate? John ___ 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] ProxyNodes
Hi, I want to load my scene from multiple files. There should be one main.osgt file that should include or reference other files. I was expecting that osg::ProxyNode should serve for this purpose. Or is there another friendly approach? ProxyNode difficultly: - it does not support immediate loading of referenced files, e.g. ProxyNode is loaded on the next cull traversal only. Not immediately. As a result, I can not make pure geometry processing (without scene visualization) as all geometries of ProxyNodes just remains on disk. Or, is there an convenient approach to force ProxyNodes to be loaded? The best approach for me would be to indicate in osgDB::readNode() call that I want to read specified file including all ProxyNodes within it. Thanks, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] shared context and compile context
I have fallen to the problems of compile context and sharing lists (wglShareLists, glXCreateContext(x,x,true,x)). They share display lists, VBO/IBO, shaders, textures, FBO, PBO. But how is it with rendering capabilities, e.g. is OSG compile context and shared OpenGL context guaranteed to have the same OpenGL version and the same extensions available? I am looking for general case that include systems with several various graphics cards or even remote rendering setups with OSG. For example, I may create OpenGL 4.0 style shader in compile context because it indicates that OpenGL 4.0 is available, but can I relay on a presumption that rendering context will support OpenGL 4.0 as well? Or even worse scenario - the user may specify arbitrary context for sharing in traits. Will it break above mentioned things? Thanks, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shared context and compile context
Hi Robert, I see, sharing context is not so portable... Anyway, I see them used at least for compile contexts. Does it mean that compile contexts and background compiling is not recommended to be used in general? Or at least on Linux and Windows? I had impression they are used for PagedLOD... My original problem came from question whether all osg::GraphicsContext with the same contextID supports exactly the same OpenGL/GLU/WGL/GLX extensions. Thanks for clarification. This info is very valuable. John Robert Osfield wrote: Hi John, I would have though WGL/GLX/OpenGL driver would produce an error if you tried to share contexts that didn't provide the same capabilities. What problems are you seeing? As a general note, compile contexts haven't proven to be particularly portable and wouldn't recommend general deployment. If you know that they definitely work well for you app and the platforms that your are targeting then great, but otherwise I'd suggest not trying to use them. Robert. On Wed, Oct 6, 2010 at 1:04 PM, PCJohn pec...@fit.vutbr.cz wrote: I have fallen to the problems of compile context and sharing lists (wglShareLists, glXCreateContext(x,x,true,x)). They share display lists, VBO/IBO, shaders, textures, FBO, PBO. But how is it with rendering capabilities, e.g. is OSG compile context and shared OpenGL context guaranteed to have the same OpenGL version and the same extensions available? I am looking for general case that include systems with several various graphics cards or even remote rendering setups with OSG. For example, I may create OpenGL 4.0 style shader in compile context because it indicates that OpenGL 4.0 is available, but can I relay on a presumption that rendering context will support OpenGL 4.0 as well? Or even worse scenario - the user may specify arbitrary context for sharing in traits. Will it break above mentioned things? Thanks, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shared context and compile context
Thanks. Very answered my question. John Robert Osfield wrote: Hi John, On Wed, Oct 6, 2010 at 1:45 PM, PCJohn pec...@fit.vutbr.cz wrote: I see, sharing context is not so portable... I implemented them under Linux with NVidia drivers and they worked as expected, but with other drivers and other OS's reports back from the community haven't been so positive, so it looks like it's a feature that driver developers don't put much effort in to make sure it's solid. Anyway, I see them used at least for compile contexts. Does it mean that compile contexts and background compiling is not recommended to be used in general? Or at least on Linux and Windows? I had impression they are used for PagedLOD... The DatabasePager will utilize a CompileContext if you've set them up explictly, but if you haven't it won't use them instead compiling the GL objects from a time slot given to it by the various graphics threads with the associated graphics contexts/windows. My original problem came from question whether all osg::GraphicsContext with the same contextID supports exactly the same OpenGL/GLU/WGL/GLX extensions. If they don't support all the same features then the contextID should not be the same, but this assumes that the contexts and sharing of contextID have all be set up correctly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] time going backward
Hi, I see events coming with decreasing time (GUIEventAdapter::getTime()). However, I expected always increasing sequence. Is this feature or bug? Further investigation shows that current OSG trunk sends different timestamps for FRAME events than for other events. Seems like it is using different clocks shifted by about 2 seconds. Is it feature or should I investigate? Definitely, it puzzles CameraManipulators, etc... John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] precompiled binaries
Hi, I want to contribute precompiled binaries of Inventor/Coin plugin to https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1 and https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs90sp1 . Is there a standard procedure to proceed? I am willing to maintain and updates the binaries by the new releases of Inventor/Coin if I get write access (Do not worry about svn - I am not beginner). Otherwise, I can just deliver the binaries. At least one person asked me about the binaries, so I think, osgtoy would be a natural place to put it. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] threading and captureCurrentState
Hi guys, thanks for all your answers. Unfortunately, I am leaving for a week holidays in one hour. Anyway, the problem is following: - I am generating shadow volumes on the fly in cull visitor - It works perfectly, except the cases when mirrors are used - let's recall that mirror turns right-handed coordinate system to left-handed, thus the programmer needs to change FrontFace setting to keep face culling working properly. - Ignoring FrontFace settings, I may construct anti-shadow volume that produces wrong results when mixed with non-anti volumes, etc. - Moreover, blending and alpha test settings should be detected and semi-transparent object should not cast shadows. I can detect them bellow in the scene graph during triangle collecting traversal, but what about attributes above my shadow node? Ignoring them may result in wrong results. I guess, the best solution is to query current traversal state for blending and front face settings. At least that is what I have done in another scene graph library. Other option is to traverse scene graph up from my shadowed node to see if there are any attributes important for myself. But if there is no nice solution, lets leave the problem. I just wanted to create complete issue-free solution, as this solution may be contributed back to OSG one day when stable enough. John Wojciech Lewandowski wrote: Hi John, If you need this to setup uniforms for shadow fragment shaders then maybe standard GL gl_FrontFacing variable could do the trick ? Its available at least in GLSL 1.50 and above. I have not checked when it was introduced maybe its available in earlier GLSL profiles. Wojtek *From:* PCJohn mailto:pec...@fit.vutbr.cz *Sent:* Thursday, August 05, 2010 12:41 AM *To:* OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org *Subject:* Re: [osg-users] threading and captureCurrentState Yes. There is. Oh. I see. Sorry for confusion, you call it attribute stack and that is a correct name for it. Anyway, there is State::_attributeMap that is composed of AttributeStack structs and they have a member attributeVec that is serving as a stack of attributes. The top of the stack is current attribute or the last pushed attribute. That is the one I need to get. Until now, I see a threading issue like two threads manipulating the attribute stack. I'll say it again: you can't access those attribute stacks from the cull traversal. They don't contain anything sensible. I that case a different question: How to get current osg::FrontFace attribute? I mean the one that would be active for any drawable traversed at the present moment during cull traversal that is just in progress and I am handling it in my custom Shadow class that is already working perfectly except some attribute values that user may pass from the scene graph above and that need to be properly handled to cast shadows correctly. The answer: you do not need it would be wrong at the moment. Thx, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] threading and captureCurrentState
Hi,
captureCurrentState name is misleading - it is not capturing state from
OpenGL.
It should be, maybe, getCurrentState. It is just taking last pushed
attributes on the state stack. These attributes are returned in the
StateSet given as parameter. Thus, the function should work any time
during cull traversal, I guess.
I do not understand, but it work with SingleThreaded and
CullDrawThreadPerContext while it crashes with DrawThreadPerContext and
CullThreadPerCameraDrawThreadPerContext. It seems to me like two
threads are accessing state stack...
John
Wojciech Lewandowski wrote:
Hi,
I don't think its allowed to call captureCurrentState in Cull stage. I
am not certain about this, but would expect that captureCurrentState
would read OpenGL state and update osg::State accordingly. If this is
the case then it does require valid OpenGL context, which is only
guaranteed to be valid in Render stage. SingleThreaded mode is bit
different and manages SceneViews differently which has the side effect
that OpenGL context often remains valid beetwen Render stages .
Wojtek
--
From: PCJohn pec...@fit.vutbr.cz
Sent: Tuesday, August 03, 2010 4:38 PM
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Subject: [osg-users] threading and captureCurrentState
Hi,
I see a threading issue when capturing current attributes in cull phase.
My code placed in my derived ShadowTechnique::cull():
void MyShadowVolume::cull( osgUtil::CullVisitor cv )
{
ref_ptr StateSet currentState = new StateSet;
cv.getState()-captureCurrentState( *currentState );
cv.pushStateSet( _ss1 );
_shadowedScene-Group::traverse( cv );
cv.popStateSet();
cv.pushStateSet( _ss2 );
_shadowedScene-Group::traverse( cv );
cv.popStateSet();
}
StateSets are not changing. It crashes inside captureCurrentState
while I have to wait few seconds. However, the time changes
(race-condition?). It looks like threading issue and if I set
viewer.setThreadingModel( SingleThreaded ), the problem seems to
disappear.
Is the code above correct? Am I using captureCurrentState correctly?
I need it to determine FrontFace attribute settings.
Thanks,
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] threading and captureCurrentState
Hi Tim, Tim Moore wrote: On Wed, Aug 4, 2010 at 9:33 AM, PCJohn pec...@fit.vutbr.cz mailto:pec...@fit.vutbr.cz wrote: Hi, captureCurrentState name is misleading - it is not capturing state from OpenGL. It should be, maybe, getCurrentState. It is just taking last pushed attributes on the state stack. These attributes are returned in the StateSet given as parameter. Thus, the function should work any time during cull traversal, I guess. No. CullVisitor::pushStateSet does not affect the graphics state immediately. It is used to build the state graph that is used during the draw traversal to change the state. You really can't use osg::State for much outside of the graphics traversal. We do not understand each other. I am not using it outside cull traversal, neither I want to do anything with OpenGL state. I do not understand, but it work with SingleThreaded and CullDrawThreadPerContext while it crashes with DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext. It seems to me like two threads are accessing state stack... There isn't a state stack. See http://www.bricoworks.com/articles/stateset/stateset.html and http://www.bricoworks.com/articles/stategraph/stategraph.html. Yes. There is. Oh. I see. Sorry for confusion, you call it attribute stack and that is a correct name for it. Anyway, there is State::_attributeMap that is composed of AttributeStack structs and they have a member attributeVec that is serving as a stack of attributes. The top of the stack is current attribute or the last pushed attribute. That is the one I need to get. Until now, I see a threading issue like two threads manipulating the attribute stack. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] threading and captureCurrentState
Yes. There is. Oh. I see. Sorry for confusion, you call it attribute stack and that is a correct name for it. Anyway, there is State::_attributeMap that is composed of AttributeStack structs and they have a member attributeVec that is serving as a stack of attributes. The top of the stack is current attribute or the last pushed attribute. That is the one I need to get. Until now, I see a threading issue like two threads manipulating the attribute stack. I'll say it again: you can't access those attribute stacks from the cull traversal. They don't contain anything sensible. I that case a different question: How to get current osg::FrontFace attribute? I mean the one that would be active for any drawable traversed at the present moment during cull traversal that is just in progress and I am handling it in my custom Shadow class that is already working perfectly except some attribute values that user may pass from the scene graph above and that need to be properly handled to cast shadows correctly. The answer: you do not need it would be wrong at the moment. Thx, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] threading and captureCurrentState
Hi,
I see a threading issue when capturing current attributes in cull phase.
My code placed in my derived ShadowTechnique::cull():
void MyShadowVolume::cull( osgUtil::CullVisitor cv )
{
ref_ptr StateSet currentState = new StateSet;
cv.getState()-captureCurrentState( *currentState );
cv.pushStateSet( _ss1 );
_shadowedScene-Group::traverse( cv );
cv.popStateSet();
cv.pushStateSet( _ss2 );
_shadowedScene-Group::traverse( cv );
cv.popStateSet();
}
StateSets are not changing. It crashes inside captureCurrentState while
I have to wait few seconds. However, the time changes (race-condition?).
It looks like threading issue and if I set viewer.setThreadingModel(
SingleThreaded ), the problem seems to disappear.
Is the code above correct? Am I using captureCurrentState correctly? I
need it to determine FrontFace attribute settings.
Thanks,
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setAmbientIntensity without setTwoSided
Hi, I want to set ambientIntensity. There is a class for it - osg::LightModel. However, I do not want to do anything with TwoSided, LocalViewer or ControlColor settings. They must be inherited from the state above in the scene graph. How to achieve that? Thx, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FirstPersonManipulator
Hi Julien, just to avoid misunderstanding: Manipulator, you are speaking about, is not the one submitted to trunk short time ago, but the one downloaded from internet, probably. John Julien Soula wrote: Hi, Is this manipulator still on tests ? I just tried it and had the same You are lost in space error as Pierre Bourdin, with a terrain, which was my first goal... Pretty much better on a building roof situated on this same terrain, where it seems to work fine. If there was some improvement, could you please keep me informed ? Thx a lot and good job, Cheers, Julien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29329#29329 ___ 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-submissions] Shader composition
Hi Robert, I would appreciate others having a look at Roland's implementation as well. I took a look at Rolands code some time ago as I built my own simple shader composition for myself as well. The problems, I found myself with shader composition is that I often need to customize the shaders. Many people may want to keep functionality similar to OpenGL pipeline, thus they would prefer to use Gouraud shading. Me, I want to use Phong shading. One person may prefer Blinn-Phong (half-vector) specular reflection, while I prefer Phong reflection (reflection vector). Some people would want to include Shadow maps that needs their small piece of code in fragment shader. Others as me, look for shadow volumes in the future while they considers using geometry shaders. In my opinion, the most difficult part of the design would be to allow a programmer to make all these things and to add even more of them in the future, based on the craziest (but meaningful) ideas of the programmers. One more experience from me: Shader compilation is time expensive work by my experience. Say, it is a real difference to compile twenty shaders or compile one and reuse it twenty times from cache. It would be nice to have a cache and if the shader of particular parameters were already generated, it would be reused. (Not sure, if Rolands submission includes cache feature.) Looking forward to have a shader composition in OSG! John BTW: Sending copy to OSG-discussion as well, for others input. Robert Osfield wrote: In terms of the final approach I merge, I would like to retain the flexibility of the OSG current StateAttribute + GL mode approach, this is already a form of state composition that has all the inheritance/compositional behavior that I'd like to see, but we currently rely upon the GL drivers to do the mapping fixed function pipeline to shaders for us. Roland's approach does provide something similar to this, am I'm still learning about the implementation details so can't yet comment in full of how close it gets. I would appreciate others having a look at Roland's implementation as well. Robert. On Tue, Jun 22, 2010 at 12:56 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Hi, Robert I hope you will also look at Virtual Program in shader composition example. I am not trying to sell the implementation but I really would like to see shader composition simple and easy to use and I think that VirtualProgram approach could be seen as such fairly simple interface. I was hoping that current osg::Program could be extended to allow incomplete shaders like VirtualProgram allows. In that case VirtualProgram could be removed. OSG could solve shader completness in similar way as uniforms are handled: neccessary uniforms are selected and applied when program is applied. I think shaders could be selected and compiled in the same moment ie when program is applied and using similar logic and handling as uniforms. We would need to have the functional name for the shader to select shaders used by program. That name would work bit like uniform name. It was semantics parameter in VirtualProgram but some other shader names could be used as well for this purpose. And the other subject I think may affect your work are Open GL 4.0 subroutines. Lets make the shader composition in OSG future compatible with this concept. That are only my 2 cents. I don't want to start any fierce discussion. I will accept a solution you would select as most appropriate. Cheers, Wojtek -- From: Robert Osfield robert.osfi...@gmail.com Sent: Monday, June 21, 2010 7:02 PM To: osg-submissi...@lists.openscenegraph.org Subject: Re: [osg-submissions] Shader composition Hi Roland, Johannes et. al, I've mostly cleared my desk for other tasks so am now ready to dive back into the topic of shader composition. My plan this week is to dig out my own design notes, and do a review of Roland's submissions and experiment with the runtime usage/results of the submission to get better idea of the problem domain and the submission itself. Any updates on the submission or any thoughts on shader composition would be most welcome. Once I'm more back up to speed on Roland's submission and my collected more of my own thoughts together I'll strik a discussion on osg-users about shader composition, but feel free to chip in on this thread if you have comments about Roland's submission. Cheers, Robert. ___ osg-submissions mailing list osg-submissi...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org ___ osg-submissions mailing list osg-submissi...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org ___ osg-submissions mailing list
Re: [osg-users] current context
Thanks. I was worrying about such answer, but that is logical design. I will probably proceed with drawCallbacks and make scene graph updates in update event. Thanks, John Tim Moore wrote: On Sat, Jun 19, 2010 at 7:29 AM, PCJohn pec...@fit.vutbr.cz mailto:pec...@fit.vutbr.cz wrote: Hi, Is it guaranteed that there is proper current context during update traversal? If no, is the same guaranteed for cull traversal? No, and no. In some threading modes there might be a current context during those phases, but there is no guarantee. Asking because of a bug in StatsHandler related to support of GPU time. Going to attempt fix afterwards. John There is only a context current during drawing i.e., during calls to drawImplementation, camera callbacks, etc. You can also use a GraphicsOperation functor to do something that needs a current context. Tim ___ 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] osgGA::CameraViewSwitchManipulator
[..] As with in so many areas of OSG, the main documentation is the source code. My big wish would be to change this and to require submissions to contain documentation as well. Mandatory doc requirement would be probably too much, but at least official desire for documentation should be here. From my side, I provided all my recent submissions with doc. But this is just a wish to have the doc. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] different behavior on the trackball manipulator
Send me the code if you want. I will take a look. If the size of data would be larger, use my email address only. Thx, John Trajce (Nick) Nikolov wrote: it is using some sample with osgviewer., I can post you the code if you are interested. -Nick On Sat, Jun 12, 2010 at 2:53 PM, PCJohn pec...@fit.vutbr.cz mailto:pec...@fit.vutbr.cz wrote: Strange. Unfortunately, all my models gets centered on the screen, so I can not reproduce the problem on my side. Can you investigate further what is happening and whether the problem is not in your code? Is the problem happening with osgviewer as well? John Trajce (Nick) Nikolov wrote: Hi John, I just ran an old code. In the older version, the model was centered on the screen. with the new manipulators it is not. I use the default behavior -Nick On Sat, Jun 12, 2010 at 2:28 PM, PCJohn pec...@fit.vutbr.cz mailto:pec...@fit.vutbr.cz wrote: Hi Nick, there are two major changes to CameraManipulator::computeHomePosition(): - the computation uses bounding box by default (the model center is located more precisely) - the computation considers the camera fov to make sure that the model nicely fits to the screen (small fov may make the model larger than screen while big fov too small). If there is a bug, you see some problems with the approach, or you would like some adjustments, we can discuss them further. John Trajce (Nick) Nikolov wrote: Hi community, I updated osg from the trunk today (after a month) and I am seeing different behavior on the trackball manipulator - the scene starts far away from my model. I was following the thread of the reengineering of this piece of the code which happened lately. Anyone experiencing the same/similar ? -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 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] old QOSGWidget and new trunk Manipulators : mouse event problem
Hi Eric, if the behavior is the same for all manipulators, it means that it has nothing to do with new manipulators architecture. For example, SphericalManipulator is still using the old approach. If you see the problem even with this manipulator, the bug seems likely to be on some other place, like QOSGWidget... John Eric Pouliquen wrote: Hi all, I'm using an old version of a CompositeViewerQOSG and QOSGWidget, modified for my needs, and as I switched to OSG trunk version to have good fbx animation behavior, my NodeTrackerManipulators seems to not receive mouse events at all... I see that a lot of changes have been made on manipulators on trunk version, so there is somehting with this new code doing like handle function is never called :( What I don't understand is that the example osgviewerQT --CompositeViewer runs well in the trunk version also... I tried to uncomment the #ifndef WIN32 in QOSGWidget (I'm on Windows) to enable mousePressEvent function, but nothing changed. Does anyone have any any about that ? The behaviour is the same for any manipulator... Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=28744#28744 ___ 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] different behavior on the trackball manipulator
Hi Nick, there are two major changes to CameraManipulator::computeHomePosition(): - the computation uses bounding box by default (the model center is located more precisely) - the computation considers the camera fov to make sure that the model nicely fits to the screen (small fov may make the model larger than screen while big fov too small). If there is a bug, you see some problems with the approach, or you would like some adjustments, we can discuss them further. John Trajce (Nick) Nikolov wrote: Hi community, I updated osg from the trunk today (after a month) and I am seeing different behavior on the trackball manipulator - the scene starts far away from my model. I was following the thread of the reengineering of this piece of the code which happened lately. Anyone experiencing the same/similar ? -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] different behavior on the trackball manipulator
Hi JP, the zoom update submission was sent to Robert and it waits for commit. It reverts the zoom to use original behaviour by default. Concerning 4 manipulator, which one do you mean? I am expecting it is TerrainManipulator. It avoids you to go over +/- 90 degrees in vertical direction. It can be turned off by setVerticalAxisFixed(). Just for the case that you would think that the behaviour should be different, we can discuss ideas. John J.P. Delport wrote: Hi Nick, On 07/06/10 19:24, Trajce (Nick) Nikolov wrote: Hi community, I updated osg from the trunk today (after a month) and I am seeing different behavior on the trackball manipulator - the scene starts far away from my model. I was following the thread of the reengineering of this piece of the code which happened lately. Anyone experiencing the same/similar ? I'm also seeing changes. The 4 manipulator now does a funny flip for the southern hemisphere. And I think, will confirm, that the zoom works differently. jp -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] different behavior on the trackball manipulator
Strange. Unfortunately, all my models gets centered on the screen, so I can not reproduce the problem on my side. Can you investigate further what is happening and whether the problem is not in your code? Is the problem happening with osgviewer as well? John Trajce (Nick) Nikolov wrote: Hi John, I just ran an old code. In the older version, the model was centered on the screen. with the new manipulators it is not. I use the default behavior -Nick On Sat, Jun 12, 2010 at 2:28 PM, PCJohn pec...@fit.vutbr.cz mailto:pec...@fit.vutbr.cz wrote: Hi Nick, there are two major changes to CameraManipulator::computeHomePosition(): - the computation uses bounding box by default (the model center is located more precisely) - the computation considers the camera fov to make sure that the model nicely fits to the screen (small fov may make the model larger than screen while big fov too small). If there is a bug, you see some problems with the approach, or you would like some adjustments, we can discuss them further. John Trajce (Nick) Nikolov wrote: Hi community, I updated osg from the trunk today (after a month) and I am seeing different behavior on the trackball manipulator - the scene starts far away from my model. I was following the thread of the reengineering of this piece of the code which happened lately. Anyone experiencing the same/similar ? -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
[osg-users] osgQt broken in OSG trunk
Just reporting a compile problem in OSG trunk in osgQt. See compiler output bellow. The problem was noticed on Qt 4.4.0. While it is not present on some more recent Qt versions. Probably broken compatibility with older Qt. John Scanning dependencies of target osgQt [ 98%] Building CXX object src/osgQt/CMakeFiles/osgQt.dir/QFontImplementation.o [ 98%] Building CXX object src/osgQt/CMakeFiles/osgQt.dir/QGraphicsViewAdapter.o In file included from /usr/include/qt4/QtWebKit/QWebSettings:1, from /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:21, from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /usr/include/qt4/QtWebKit/qwebsettings.h:23:27: error: qwebkitglobal.h: No such file or directory In file included from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:95:7: warning: no newline at end of file In file included from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:15: /data/Cadwork/OSG-trunk/include/osgQt/QWidgetImage:53:7: warning: no newline at end of file In file included from /usr/include/qt4/QtWebKit/QWebSettings:1, from /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:21, from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /usr/include/qt4/QtWebKit/qwebsettings.h:41: error: function definition does not declare parameters In file included from /usr/include/qt4/QtWebKit/QtWebKit:6, from /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:22, from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /usr/include/qt4/QtWebKit/qwebpage.h:172: warning: ISO C++ forbids declaration of ‘QWebSettings’ with no type /usr/include/qt4/QtWebKit/qwebpage.h:172: error: expected ‘;’ before ‘*’ token In file included from /usr/include/qt4/QtWebKit/QtWebKit:9, from /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:22, from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /usr/include/qt4/QtWebKit/qwebview.h:71: warning: ISO C++ forbids declaration of ‘QWebSettings’ with no type /usr/include/qt4/QtWebKit/qwebview.h:71: error: expected ‘;’ before ‘*’ token make[2]: *** [src/osgQt/CMakeFiles/osgQt.dir/QGraphicsViewAdapter.o] Error 1 make[1]: *** [src/osgQt/CMakeFiles/osgQt.dir/all] Error 2 make: *** [all] Error 2 j...@dudell:/data/Cadwork/OSG-trunk/build-Linux$ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt broken in OSG trunk
Hi Robert, now fixed. Works excellently. Thanks. There are just few warnings (see bellow). Anyway, works now. Thanks, John [ 97%] Building CXX object src/osgQt/CMakeFiles/osgQt.dir/QFontImplementation.o Linking CXX shared module ../../../lib/osgPlugins-2.9.8/osgdb_bvhd.so [ 97%] Building CXX object src/osgQt/CMakeFiles/osgQt.dir/QGraphicsViewAdapter.o In file included from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:94:7: warning: no newline at end of file In file included from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:15: /data/Cadwork/OSG-trunk/include/osgQt/QWidgetImage:53:7: warning: no newline at end of file [ 97%] Building CXX object src/osgQt/CMakeFiles/osgQt.dir/QWidgetImage.o In file included from /data/Cadwork/OSG-trunk/include/osgQt/QWidgetImage:18, from /data/Cadwork/OSG-trunk/src/osgQt/QWidgetImage.cpp:14: /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:94:7: warning: no newline at end of file In file included from /data/Cadwork/OSG-trunk/src/osgQt/QWidgetImage.cpp:14: /data/Cadwork/OSG-trunk/include/osgQt/QWidgetImage:53:7: warning: no newline at end of file [ 97%] Building CXX object src/osgQt/CMakeFiles/osgQt.dir/__/__/include/osgQt/moc_QGraphicsViewAdapter.o In file included from /data/Cadwork/OSG-trunk/build-Linux/src/osgQt/__/__/include/osgQt/moc_QGraphicsViewAdapter.cxx:10: /data/Cadwork/OSG-trunk/build-Linux/src/osgQt/__/__/include/osgQt/../../../../../../../include/osgQt/QGraphicsViewAdapter:94:7: warning: no newline at end of file Linking CXX shared library ../../lib/libosgQtd.so [ 98%] Built target osgQt Robert Osfield wrote: Hi John, I believe that osgQt has probably failed to build now rather before as previously osgQt required QWebKit to be installed, but this requirement has now been relaxed by moving the QWebKit integration to entirely within the include/osgQT/QWebViewImage. Alas, in my refactor I clearly didn't catch cleanig up the QWebKit headers, I've now removed the headers from QGraphicsViewAdapter and checked this into svn/trunk. Could you please try out svn/trunk to see how it now builds, hopefully it'll now build with 4.4.0. Robert. On Tue, Jun 1, 2010 at 11:02 AM, PCJohn pec...@fit.vutbr.cz wrote: Just reporting a compile problem in OSG trunk in osgQt. See compiler output bellow. The problem was noticed on Qt 4.4.0. While it is not present on some more recent Qt versions. Probably broken compatibility with older Qt. John Scanning dependencies of target osgQt [ 98%] Building CXX object src/osgQt/CMakeFiles/osgQt.dir/QFontImplementation.o [ 98%] Building CXX object src/osgQt/CMakeFiles/osgQt.dir/QGraphicsViewAdapter.o In file included from /usr/include/qt4/QtWebKit/QWebSettings:1, from /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:21, from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /usr/include/qt4/QtWebKit/qwebsettings.h:23:27: error: qwebkitglobal.h: No such file or directory In file included from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:95:7: warning: no newline at end of file In file included from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:15: /data/Cadwork/OSG-trunk/include/osgQt/QWidgetImage:53:7: warning: no newline at end of file In file included from /usr/include/qt4/QtWebKit/QWebSettings:1, from /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:21, from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /usr/include/qt4/QtWebKit/qwebsettings.h:41: error: function definition does not declare parameters In file included from /usr/include/qt4/QtWebKit/QtWebKit:6, from /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:22, from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /usr/include/qt4/QtWebKit/qwebpage.h:172: warning: ISO C++ forbids declaration of ‘QWebSettings’ with no type /usr/include/qt4/QtWebKit/qwebpage.h:172: error: expected ‘;’ before ‘*’ token In file included from /usr/include/qt4/QtWebKit/QtWebKit:9, from /data/Cadwork/OSG-trunk/include/osgQt/QGraphicsViewAdapter:22, from /data/Cadwork/OSG-trunk/src/osgQt/QGraphicsViewAdapter.cpp:14: /usr/include/qt4/QtWebKit/qwebview.h:71: warning: ISO C++ forbids declaration of ‘QWebSettings’ with no type /usr/include/qt4/QtWebKit/qwebview.h:71: error: expected ‘;’ before ‘*’ token make[2]: *** [src/osgQt/CMakeFiles/osgQt.dir/QGraphicsViewAdapter.o] Error 1 make[1]: *** [src/osgQt/CMakeFiles/osgQt.dir/all] Error 2 make: *** [all] Error 2 j...@dudell:/data/Cadwork/OSG-trunk/build-Linux$ ___ osg-users mailing list osg
Re: [osg-users] Manipulator warning: eventTimeDelta =
Hello, it used to be INFO, so it might not be so visible before. It is caused by an event that comes with lower timestamp than the previous one, e.g. event from the past. For me, it looks like a bug in event time routines. John Torben Dannhauer wrote: Hi, after upgrading my osg to newest SVN with the new manipulators, my software throws a lot of warnings during flight manipulator usage. The warning text ist: Code: Manipulator warning: eventTimeDelta = - -XXX is a quite small number down to XXe-005 Any clue what this warning causes? Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=28339#28339 ___ 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] RFC: QWidgetImage changes
Hi J-S, thanks for the work. I am going to test it soon. John Jean-Sébastien Guay wrote: Hi all, As I said in a different thread, I've been working in the last few days to get QWidgetImage to a point where it can fill a need we have: to be able to use Qt to make HUDs and to display widgets over / inside an OSG scene. --- Current results --- I've attached what I have at this point. The modified QWidgetImage + QGraphicsViewAdapter classes can be rendered fullscreen (i.e. the Qt QGraphicsView's size follows the size of the OSG window) or on a quad in the scene as before. It will let events go through to OSG if no widget is under the mouse when they happen (useful when used as a HUD with transparent parts - a click-focus scheme could be added later too). It also supercedes Martin Scheffler's submission because it adds a getter/setter for the QGraphicsViewAdapter's background color (and the user can set their widget to be transparent using widget-setAttribute(Qt::WA_TranslucentBackground) themselves). The included osgQtBrowser example has been modified to serve as a test bed for these changes. It has lots more command line arguments than before, some of which can be removed eventually (once things are tested). Note that it may be interesting to change its name or split it into two examples. Though if things go well, the specific QWebViewImage class can be removed completely and we can consolidate to using QWidgetImage everywhere, and then a single example to demonstrate it would make more sense, albeit not named osgQtBrowser... You can try this path by using the --useWidgetImage --useBrowser command line arguments - this results in an equivalent setup to QWebViewImage, but using QWidgetImage, and doesn't work completely yet for some unknown reason, see below. Remaining issues There are a few issues left to fix, and for these I request the community's assistance. They are not blockers for me, and with my limited Qt experience I don't feel like I'm getting any closer to fixing them, so if someone else could pitch in and see what they can find, it would be appreciated. It would be really nice to get them fixed, that way we'd really have a first-class integration of Qt widgets in an OSG scene. The issues are noted in the osgQtBrowser.cpp source file, but here they are too: --- QWidgetImage still has some issues, some examples are: 1. Editing in the QTextEdit doesn't work. Also when started with --useBrowser, editing in the search field on YouTube doesn't work. But that same search field when using QWebViewImage works... And editing in the text field in the pop-up getInteger dialog works too. All these cases use QGraphicsViewAdapter under the hood, so why do some work and others don't? a) osgQtBrowser --useWidgetImage [--fullscreen] (optional) b) Try to click in the QTextEdit and type, or to select text and drag-and-drop it somewhere else in the QTextEdit. These don't work. c) osgQtBrowser --useWidgetImage --sanityCheck d) Try the operations in b), they all work. e) osgQtBrowser --useWidgetImage --useBrowser [--fullscreen] f) Try to click in the search field and type, it doesn't work. g) osgQtBrowser h) Try the operation in f), it works. 2. Operations on floating windows (--numFloatingWindows 1 or more). Moving by dragging the titlebar, clicking the close button, resizing them, none of these work. I wonder if it's because the OS manages those functions (they're functions of the window decorations) so we need to do something special for that? But in --sanityCheck mode they work. a) osgQtBrowser --useWidgetImage --numFloatingWindows 1 [--fullscreen] b) Try to drag the floating window, click the close button, or drag its sides to resize it. None of these work. c) osgQtBrowser --useWidgetImage --numFloatingWindows 1 --sanityCheck d) Try the operations in b), all they work. e) osgQtBrowser --useWidgetImage [--fullscreen] f) Click the button so that the getInteger() dialog is displayed, then try to move that dialog or close it with the close button, these don't work. g) osgQtBrowser --useWidgetImage --sanityCheck h) Try the operation in f), it works. 3. (Minor) The QGraphicsView's scrollbars don't appear when using QWidgetImage or QWebViewImage. QGraphicsView is a QAbstractScrollArea and it should display scrollbars as soon as the scene is too large to fit the view. a) osgQtBrowser --useWidgetImage --fullscreen b) Resize the OSG window so it's smaller than the QTextEdit. Scrollbars should appear but don't. c) osgQtBrowser --useWidgetImage --sanityCheck d) Try the operation in b), scrollbars appear. Even if you have floating windows
[osg-users] getCameraContainingPosition in osg::View
Hi, why are methods: computeIntersections and getCameraContainingPosition implemented in osgViewer::View class? I wish it would be in osg::View. Any chance? If yes, I may contribute one more feature for osgGA camera manipulators. I am in the process of osgGA camera manipulators improvements: I want to point mouse pointer by mouse click turn camera to it. The work is done and I may contribute parts of the work back to OSG. However, I reached linking problems since osgViewer uses osgGA and osgGA can not use osgViewer (circular reference). My idea would be whether intersections can be done without osgViewer::View, inside osg::View, knowing just master camera and slave cameras. Before I start to dig into it, I want to ask: is there a way to implement it in osg::View or should I give up? I my opinion, osg::View intersections may have meaning for headless applications as well - no window, just geometry processing. Thanks, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About OSG and Distributed Issue?
Go forward. Raknet is networking library - using UDP (performance benefits). UDP disadvantage is that it is sometimes firewalled. If you reach data consistency problems, look for simple solutions... John xyc508 wrote: Thanks John, I am try OSG+Raknet+OpenAL+MFC to develop Distributed Interactive Simulation, is it feasible? Donlin 在2010-04-16 03:35:23，PCJohn pec...@fit.vutbr.cz 写道： Hi Dolin, the complexity of distributed/collaborative virtual scenes are so high that you can make a PhD research on it. You can google for Blue-c, DIS (Distributed Interactive Simulation), Active Transactions, etc. for more details. Basically, the problem is coming from the replication - you need to replicate the scene among the computers because you can not afford to make a remote access to read scene data. As second point, you often need to update data very quickly, and often validate them - but how to validate the data if you do not have all the up-to-date data accessible locally - you are still in distributed system with non-zero update propagation times... Solution of computer game DOOM 1 - it was simple enough, by the way. John xyc508 wrote: Hi,Robert, I mean that on web,diffrent person login on the same scene,they can see others,also can chat each other. I am not sure which tools or engine is right with OSG? is Raknet or others? are there any examples or current project for this issue? Thanks. Donlin 在2010-04-15 18:12:41，Robert Osfield robert.osfi...@gmail.com 写道： Hi Donlin, 2010/4/14 xyc508 xyc...@163.com: how to develop OSG for Distributed usage? Could one give which Distributed tool or software is right or best? There are plenty of different approaches, which is best for you? Well I don't really know what you have in mind by Distributed usage, if you give a few more details about what you are trying to achieve then perhaps others will be able to point you in the right direction. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About OSG and Distributed Issue?
Hi Dolin, the complexity of distributed/collaborative virtual scenes are so high that you can make a PhD research on it. You can google for Blue-c, DIS (Distributed Interactive Simulation), Active Transactions, etc. for more details. Basically, the problem is coming from the replication - you need to replicate the scene among the computers because you can not afford to make a remote access to read scene data. As second point, you often need to update data very quickly, and often validate them - but how to validate the data if you do not have all the up-to-date data accessible locally - you are still in distributed system with non-zero update propagation times... Solution of computer game DOOM 1 - it was simple enough, by the way. John xyc508 wrote: Hi,Robert, I mean that on web,diffrent person login on the same scene,they can see others,also can chat each other. I am not sure which tools or engine is right with OSG? is Raknet or others? are there any examples or current project for this issue? Thanks. Donlin 在2010-04-15 18:12:41，Robert Osfield robert.osfi...@gmail.com 写道： Hi Donlin, 2010/4/14 xyc508 xyc...@163.com: how to develop OSG for Distributed usage? Could one give which Distributed tool or software is right or best? There are plenty of different approaches, which is best for you? Well I don't really know what you have in mind by Distributed usage, if you give a few more details about what you are trying to achieve then perhaps others will be able to point you in the right direction. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light multi-parenting
Thanks Robert, to close the thread, I am putting more info based what you have written and my experiments: - LightSource with Light attached - can be far down in the scene graph while it shines on whole scene. It uses PositionalStateContainer of RenderState to store light position. Advantages: - huge benefit is that the light shines on whole scene. That is how we expect the things happens in reality. This implies LightSource limitations: - only 8 lights per scene - OpenGL IDs can not be shared - multiple references / multi-parenting (with different transformations) can not work (by design) - Light (just StateSet attribute) - shines just on objects down in the scene graph It does not use PositionalStateContainer of RenderState. Advantages: - OpenGL IDs can be shared, provided that up to 8 lights with unique ID shines at any moment - multiple references / multi-parenting (with different transformations) works correctly and lights are instanced correctly on multiple positions Limitations: - To make the light shine on the whole scene or specified part of the scene is little bit troublesome in some cases. Especially, if the light position is expected to be animated by some transformation down in the scene graph. - there are still some issues in OSG implementation on multiple light references, but it can be (hopefully) easily fixed, if needed To express my opinion after the understanding of lights: Lights are very well designed. (Considering to contribute OSG light documentation, if it happens I will have a time.) To handle more advanced scene setups and for the purpose of shadows, I am considering some extensions. However, it depends how important the extensions turn out to be. John Robert Osfield wrote: Hi John, Have a look into discussion on osg-users about positional state. LightSource is what positions Light in the scene. You can't have one GL light in more than one place at a time, and the light has to be positioned by a specific modelview matrix, not one artificially inherited, so LightSource's role is to place the light. Robert. On Mon, Mar 22, 2010 at 11:52 AM, PCJohn pec...@fit.vutbr.cz wrote: Gurus, What is the reason for keeping LightSource in OSG? I successfully removed all osg::LightSources from my scene graph and used just osg::Light - it is well placed and follows the transformation of the parent node (f.ex. locomotive) as it moves. Except absolute reference frame, is there any reason for LightSource existence in OSG? I think yes, but missing arguments. Thx for explanation, John Thrall, Bryan wrote: You place the LightSource in the scene graph where you want the light to be positioned. I don't think it is necessary for directional lights (they are infinitely far away, so don't have a position), but say you want a spotlight attached to a train locomotive. You could update osg::Light's position every time the locomotive moves, or you could attach a LightSource to the locomotive's scene graph and have the light placed correctly automatically. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light multi-parenting
As for limitation osg::Light/LightSource/OpenGL lighting all work with the same limitations - that is there is only ever guaranteed to be 8 fixed function pipeline light supported. If you want to use more than 8 then you'll need to use shaders, or localize the lights to difference subgraphs have different lights assigned for them. The fact you need to position lights as well means that one has to apply the appropriate modelview matrix for each of these lights before application, which complicated the implementation. The only way to tackle this right now with the OSG is to break the scene up into separate subgraphs that each target their own RenderStage. This is possible, but awkward at present. Thanks. Things are very clear now. If I develop a solution worthy to be shared with others, I will be back. Thanks once again, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light multi-parenting
Gurus, What is the reason for keeping LightSource in OSG? I successfully removed all osg::LightSources from my scene graph and used just osg::Light - it is well placed and follows the transformation of the parent node (f.ex. locomotive) as it moves. Except absolute reference frame, is there any reason for LightSource existence in OSG? I think yes, but missing arguments. Thx for explanation, John Thrall, Bryan wrote: You place the LightSource in the scene graph where you want the light to be positioned. I don't think it is necessary for directional lights (they are infinitely far away, so don't have a position), but say you want a spotlight attached to a train locomotive. You could update osg::Light's position every time the locomotive moves, or you could attach a LightSource to the locomotive's scene graph and have the light placed correctly automatically. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] light multi-parenting
Hi, I reached some difficulties with handling of lights when I was considering some improvements to osgShadow, like multiple light sources: 1. single light source object can be placed two times to the scene. Because of multi-parenting, the light may have two different transformations. Although one object and one unique pointer, it identifies two light sources, thus it is not unique light identification. When current implementation of ShadowMap::setLight(light) sets the light for shadows, which one of the two should cast the shadows? Definitely, not both of them, at least not with the current light implementation. Options: - The most robust approach is to use paths, identifying the node path down in the scene graph to the light. This would allow proper identity of multiple-parented objects and position of the light would be given by the transformations on the path. - Another approach may use just the first or the last light occurence in the scene graph. - cull-time approach may use first or last occurence of the light in the RenderStage::PositionalAttributeList. - any other options? The first most robust approach is used by Open Inventor and it works pretty good, although it may be considered overkill by some people. My current preference is to use the first position of the light in the scene graph (retrieved from RenderStage::PositionalAttributeList, because it is used in cull-time), and to silently keep all the remaining light occurrences in the scene graph on the same position. When an user will need lights on different positions, he will just create copies of the same light. 2. LightSource question: I was always wondering why there are two light classes - osg::Light and osg::LightSource - and not just one. Is the only purpose for having both osg::Light and osg::LightSource the ability of LightSource to specify ReferenceFrame? Apparently, osg::Light as Attribute can not have reference frame. Any other reasons, or am I missing something? Thanks, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light multi-parenting
Hi J-S, 1. single light source object can be placed two times to the scene. Because of multi-parenting, the light may have two different transformations. Although one object and one unique pointer, it identifies two light sources, thus it is not unique light identification. How do you give a single light source two different OpenGL light IDs? Or do you manage that all in shaders, thus without the restrictions of light IDs? No, because it is one light source, it has one OpenGL ID. As I understand it, if we're on the fixed pipeline then multi-parenting lights wouldn't make sense because the light would still have only one ID, and the traversal would just use the last (first?) transformation when sending that light's state each frame. How would you handle this? Let's expect a large train station model with many trains, each composed of many wagons. The wagons are for passangers and because it is night, there are light sources in the wagons. The wagon model is definitely loaded from file only once and reused, say hundred times throughout the large train station for each wagon (let's expect just one type of wagons). And because the light is stored in the wagon model, each wagon will use the same light for lighting the interior of the wagon (not exterior). The camera can be on any place and I always see through the windows of wagons their lit interiors. The same light is instanced using multiparenting in all the wagons in the train station, still using the same OpenGL ID. This works perfectly in OSG until I start to think about shadows... :-) Maybe, it is a border case, but I wish OSG can handle any scene If I am designing something, I want to do it in a way to handle most possible situations to avoid people having issues. Hope, there is a solution for it. Thanks for your recent comment. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light multi-parenting
Hi Bryan, osg::Light is a StateAttribute and osg::LightSource is a Group, so Light represents the OpenGL state (like the light ID) for a light in the scene, and LightSource represents the location of that light (note that LightSource has a Light). And why there is LightSource? What is meaning of it? I think, I can live just with osg::Light. And really, I used only osg::Light in my application. Is there any reason for me or anyone else to use osg::LightSource? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release likely, need community assistance
Hi Paul -- Confirming: Inventor plugin works very well. However, I found
out that FindInventor.cmake is very poor and very old - it is not
capable to find new version of required libraries for the plugin,
particularly Coin3. Attaching new version that may be already included
in OSG 2.9.6.
John
Paul Martz wrote:
PCJohn wrote:
Is it possible to include plugins? I am particularly interested in
updated Inventor plugin.
John
Hi John -- I've merged the latest Inventor plugin onto the 2.8 branch.
Can you test, please? I don't have the dependencies, so don't build
this plugin.
-Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#
# Find Open Inventor
#
# This module defines:
# INVENTOR_FOUND, if false, do not try to link against Inventor.
# INVENTOR_INCLUDE_DIR, where to find headers.
# INVENTOR_LIBRARY, the library to link against.
# INVENTOR_LIBRARY_DEBUG, the debug library to link against.
# INVENTOR_SOWIN_LIBRARY, the SoWin library - window binding library for
Inventor
# INVENTOR_SOWIN_LIBRARY, the SoWin debug library
# INVENTOR_SOXT_LIBRARY, the SoXt library - window binding library for Inventor
# INVENTOR_SOXT_LIBRARY, the SoXt debug library
#
#
# Inventor
#
# notes:
# - Coin is honored over SGI Inventor
# - Coin is detected by coin-config script, COINDIR environment variable,
#and finally standard system locations are searched
# - SGI Inventor is searched at standard system locations only
#
# coin-config tells much of Coin instalation (if present)
execute_process (COMMAND coin-config --prefix
OUTPUT_VARIABLE COIN_PREFIX
OUTPUT_STRIP_TRAILING_WHITESPACE)
# try to find Inventor includes (priority paths)
FIND_PATH(INVENTOR_INCLUDE_DIR Inventor/So.h
${COIN_PREFIX}/include
$ENV{COINDIR}/include
NO_DEFAULT_PATH
)
# try to find Inventor includes (regular paths)
FIND_PATH(INVENTOR_INCLUDE_DIR Inventor/So.h
/usr/local/include
/usr/include
/sw/include
/opt/local/include
/opt/csw/include
/opt/include
)
# default Inventor lib search paths
SET(INVENTOR_LIB_SEARCH_PATH
/usr/local/lib
/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
)
# try to find Coin release lib (priority paths)
FIND_LIBRARY(INVENTOR_LIBRARY_RELEASE
NAMES coin5 coin4 coin3 coin2 coin1 Coin
PATHS ${COIN_PREFIX}/lib
$ENV{COINDIR}/lib
NO_DEFAULT_PATH
)
# try to find Coin release lib (regular paths)
FIND_LIBRARY(INVENTOR_LIBRARY_RELEASE
NAMES coin5 coin4 coin3 coin2 coin1 Coin
PATHS ${INVENTOR_LIB_SEARCH_PATH}
)
# try to find SGI Inventor lib
FIND_LIBRARY(INVENTOR_LIBRARY_RELEASE
NAMES Inventor
PATHS ${INVENTOR_LIB_SEARCH_PATH}
)
# try to find Coin debug lib (priority paths)
FIND_LIBRARY(INVENTOR_LIBRARY_DEBUG
NAMES coin5d coin4d coin3d coin2d coin1d
PATHS ${COIN_PREFIX}/lib
$ENV{COINDIR}/lib
NO_DEFAULT_PATH
)
# try to find Coin debug lib (regular paths)
FIND_LIBRARY(INVENTOR_LIBRARY_DEBUG
NAMES coin5d coin4d coin3d coin2d coin1d
PATHS ${INVENTOR_LIB_SEARCH_PATH}
)
# set release to debug if only debug found
IF(NOT INVENTOR_LIBRARY_RELEASE AND INVENTOR_LIBRARY_DEBUG)
SET(INVENTOR_LIBRARY_RELEASE ${INVENTOR_LIBRARY_DEBUG})
ENDIF(NOT INVENTOR_LIBRARY_RELEASE AND INVENTOR_LIBRARY_DEBUG)
# set debug to release (if only release found)
IF(NOT INVENTOR_LIBRARY_DEBUG AND INVENTOR_LIBRARY_RELEASE)
SET(INVENTOR_LIBRARY_DEBUG ${INVENTOR_LIBRARY_RELEASE})
ENDIF(NOT INVENTOR_LIBRARY_DEBUG AND INVENTOR_LIBRARY_RELEASE)
# INVENTOR_LIBRARY
IF (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(INVENTOR_LIBRARY
optimized ${INVENTOR_LIBRARY_RELEASE}
debug ${INVENTOR_LIBRARY_DEBUG})
ELSE(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(INVENTOR_LIBRARY
${INVENTOR_LIBRARY_RELEASE})
ENDIF(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
# set INVENTOR_FOUND appropriately
SET(INVENTOR_FOUND NO)
IF(INVENTOR_INCLUDE_DIR AND INVENTOR_LIBRARY)
SET(INVENTOR_FOUND YES)
ENDIF(INVENTOR_INCLUDE_DIR AND INVENTOR_LIBRARY)
#
# SoWin
#
# notes: SoWin is searched by COINDIR environment variable
#(as expected to be located at Windows platform)
# try to find SoWin lib (priority paths)
FIND_LIBRARY(INVENTOR_SOWIN_LIBRARY
NAMES sowin1
PATHS $ENV{COINDIR}/lib
NO_DEFAULT_PATH
)
# try to find SoWin lib (regular paths)
FIND_LIBRARY(INVENTOR_SOWIN_LIBRARY
NAMES sowin1
PATHS ${INVENTOR_LIB_SEARCH_PATH}
)
# try to find SoWin debug lib (priority paths)
FIND_LIBRARY(INVENTOR_SOWIN_LIBRARY_DEBUG
NAMES sowin1d
PATHS $ENV{COINDIR}/lib
NO_DEFAULT_PATH
)
# try to find SoWin debug lib (regular paths)
FIND_LIBRARY(INVENTOR_SOWIN_LIBRARY_DEBUG
NAMES sowin1d
PATHS ${INVENTOR_LIB_SEARCH_PATH}
)
# SoWin debug library defaults to non-debug lib
IF(NOT INVENTOR_SOWIN_LIBRARY_DEBUG
Re: [osg-users] [osgPlugins] iv plugin with coin4 from svn
j...@dudell:/data$ osgviewerd cube.iv
osgDB::ReaderWriterIV::readNode() Reading file cube.iv
osgDB::ReaderWriterIV::readNode() File cube.iv loaded successfully.
j...@dudell:/data$
I see no problem with the model - it is loads and renders without any
problem on my OSG 2.8.2 and Coin 3
John
Michele Fiorentino wrote:
Hi,
this is the simple model i could find.. and gives assert!
the same eror from vrml and more complex files...
cube.iv
Code:
#Inventor V2.1 ascii
DEF _CUBE_SEP Separator {
Cube {
width 0.1
height 0.1
depth 0.1
}
}
Code:
C:\dev\external_libs\OSG-dataosgviewerglutd cube.iv
osgDB::ReaderWriterIV::readNode() Reading file cube.iv
Assertion failed: unit PRIVATE(this)-unitdata.getLength(), file ..\..\src\ele
ments\SoMultiTextureCoordinateElement.cpp, line 435
Thank you!
Cheers,
Michele
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=25611#25611
___
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] 2.8.3 release likely, need community assistance
Is it possible to include plugins? I am particularly interested in updated Inventor plugin. John Paul Martz wrote: Hi folks -- I am 99% certain that I'll be doing a 2.8.3 release in the next few weeks. The release will not be API compatible with 2.8.2. I wanted to let you all know my plans, and also solicit input and assistance if there are any changes you'd like to get into this release. With some community input, I'm sure this release could be valuable to others besides myself. I'm not inclined to incorporate any major changes such as the Notify changes, new text/binary file format, or the weak_ptr-related changes. Large changes increase the complexity of the merge and the odds of me introducing errors as I apply the changes. I'm really just interested in bug fixes and feature changes that affect only a limited portion of OSG as a whole. The work will be done on the existing 2.8 branch. There was a little-publicized 2.8.2b tag, which is just 2.8.2 plus a fix for MSFBO on Mac OS X. So the first change I'll make to the 2.8 branch is to fold in the MSFBO fix from 2.8.2b. Other changes I have in mind: * The biggest change is to backport current svn trunk osgAnimation and the FBX plugin. This will require changes to other parts of OSG, and so far I've identified these: - Changes to osgDB required by FBX. - Un-deprecation of the osgAnimation dotosg wrapper. - r10671 Core changes required for osgAnimation. - r10672 Core changes required for osgAnimation. - r11009 (only the portion applicable to the BVH plugin, so that it is compatible with osgAnimation). (This is a pretty complex change, and it's about as complex as I would want to get. In a test merge, I ran into quite a few merge conflicts that had to be resolved manually, with risk of introducing error. Hopefully everything else will be much simpler to merge over to the 2.8 branch.) * Fix for osgUtil::Optimizer FlattenStaticTransformsVisitor (r11131). * Fix for OcclusionQueryNode (r10933 and r11127). * Mac OS X 10.6 support. Not yet sure which svn revisions. * New Xcode updates for osgAnimation. * A run of genwrappers to support any and all API changes. * Possibly backport some examples such as osganimationviewer, haven't looked at them yet. What I'd like from the community: * Any suggestions for other changes? Ideally, they should be modular, tight changes that merge onto the 2.8 branch with a minimum of conflicts. Please post requests using the specific svn revision number. (Also, please don't suggest anything unless you are willing and able to test the change once it's in on the 2.8 branch.) * Anyone out there with Mac OS X experience? Specific things I'd like assistance with would be: - Input on which svn revisions are required to enable support for Mac OS X 10.6. The goal is to be able to build OSG 2.8.3 against the 10.6 SDK. - Somebody with a Mac that already has 10.6, for testing. I have 10.5 but can upgrade if no one else steps forward. - An Xcode expert to create appropriate Xcode files for the 2.8.3 release (needs to work with the osgAnimation backport). If everything goes well, I see no reason why we can't release by end of March, so I'd like to set this schedule: * All change requests by end of day Friday 12 March. * All code changes in by 17 March. * All Xcode and genwrapper changes in by 22 March. * Release candidate 1, 22 March. * Testing period, 23-30 March. * Release, 31 March. Please give this some thought, and thanks in advance for pitching in. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions about physic engines.
Hi Ricardo, sorry to not go into the details - so just few hints from my friend that is going his project on ODE+OSG. He done the integration like this: - he loads the scene by OSG - he converts the scene geometry to ODE geometry and sends it to ODE by ODE functions - he setups the ODE world - he starts the ODE simulation - each frame, he reads all required transformations from ODE and updates OSG transformations (ODE simulation is applied to OSG scene) Concerning your questions: - sorry, I have no knowledge about osgPhysics - friction, mass, etc. - it is always a little bit tricky to put additional information to the file (3ds, collada) if the format is not designed to carry this information. However, number of formats supports additional text info connected to a scene graph node. Maybe, this will be the way. My friend is setting this information inside his code after loading each particular scene object. It is easy solution for the starting... - simulation steps: yes, you need to do the simulation steps and then render. It sometimes happens that you are doing number of simulation steps per one rendering step. That is not a problem. But sorry, I did not know implementation details. You will need to take a look to doc and tutorials. Sorry, no more knowledge on my side, but hopefully, it helps a little bit, John Ricardo Ruiz wrote: Hi mates. I have several questions regarding about physics engines in OSG. BTW, I'm a OSG beginner. If I want to use ODE, must I add osgPhysics plugin to my OSG? How can I load a scene with physics values? Let's say I'm creating a scene in 3Ds MAX, and I export it to COLLADA (or any other format). Does OSG or osgPhysics read these values (mass, friction...)? And the most important, how can I tell 3Ds MAX that objets have different physic properties? And the last one. Usually physics engines requere a fixed (or almost) time step, ODE is one of them. How should I manage that inside OSG, I mean, after integrating ODE with ODE? Thank you very much for your time and help. Cheers, Ricardo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23771#23771 ___ 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] multiple osgShadow::ShadowMap
Hi, Is it possible to have multiple shadow maps? I mean, f.ex., two light sources and two osgShadow::ShadowMap casting two shadows in a single pass? Studying osgShadow::ShadowMap shows that it is not directly supported. Anyway, I created two ShadowMaps, made one parent of the other and a scene as a child. I made ShadowMaps use different uniforms, created my own shader processing both shadow textures (and base texture). However, it still does not work. One shadow texture works well, but if I use two, only one is displayed correctly. Any ideas? Thx, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Benchmarking Software (Linux)
If you are looking for things like 3D mark 2006, I do not know. But for a very simple benchmark measuring basic OpenGL characteristics like vertices per second throughput and pixels per second (fillrate), you may take a look on lsperf.sourceforge.net . (No binaries yet, sources in svn: |svn co https://lsperf.svn.sourceforge.net/svnroot/lsperf lsperf) Feel free to provide feedback to my email. John | Jeremy Moles wrote: Is anyone aware of any nice OpenGL benchmarking software for Linux? Do I need to write something like this? (LIKE I HAVE THE TIME!) :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN version of OpenSceneGraph
How are others under WIndows getting on? Except linking problem of osgversion, just few warnings. On MSVC 2003 .NET: In osg: Texture2DArray.cpp \OSG\src\osg\Texture2DArray.cpp(106) : warning C4018: '=' : signed/unsigned mismatch D:\OSG\include\osg\Math(197) : warning C4244: 'return' : conversion from 'const double' to 'float', possible loss of data In osgDB: \OSG\src\osgDB\Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope \OSG\src\osgDB\Registry.cpp(571) : definition of 'itr' used \OSG\src\osgDB\Registry.cpp(564) : definition of 'itr' ignored \OSG\src\osgDB\Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope \OSG\src\osgDB\Registry.cpp(571) : definition of 'itr' used \OSG\src\osgDB\Registry.cpp(564) : definition of 'itr' ignored \OSG\src\osgDB\Registry.cpp(572) : warning C4288: nonstandard extension used : 'itr' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope \OSG\src\osgDB\Registry.cpp(571) : definition of 'itr' used \OSG\src\osgDB\Registry.cpp(564) : definition of 'itr' ignored John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD preprocessing
Paul Martz napsal(a): [...] The naïve approach -- just let OSG load it -- appears to cause a guaranteed frame rate hit. I imagine you could break the texture up into smaller chunks and let OSG page each in incrementally as it comes into range. Yes, breaking the texture into the smaller ones looks like necessary. I made already some measurements of glTexImage2D. 32 0,040,52 64 0,060,61 128 0,170,82 256 0,421,6 512 1,8 4,8 102411,317,9 204842 69 4096170 6500 The first column is texture size, second time in milliseconds for GF 6600 and the last column is time for ATI 1950. You may notice driver bug for 4096 ATI textures. Anyway, loading a large scene for preprocessing seems not trivial - hacks to OSG plugin will be probably necessary. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake problem
INCLUDE_DIRECTORIES( ${INVENTOR_INCLUDE_DIR} ) seems to fix include
problem, anyway INVENTOR_LIBRARY_DEBUG, although defined, is not used
for debug linking - as a result, debug build is broken while release
seems ok.
I think, something is broken in the general OSG scripts related to
*_DEBUG variables.
John
PCJohn napsal(a):
Hi,
this is probably question on Luigi:
Inventor plugin CMakeLists.txt stopped working - it is neither including
necessary includes correctly detected by FindInventor.cmake, nor linking
libraries correctly detected in the same way. Therefore, the plugin not
compiles.
Do you see any problem in the file?
(inlining it for your convenience)
INCLUDE(OsgMacroUtils)
SET(TARGET_SRC
[...]
)
SET(TARGET_HDRS
[...]
)
ADD_DEFINITIONS(-DCOIN_DLL)
SET(TARGET_EXTERNAL_LIBRARIES ${INVENTOR_LIBRARY} )
SETUP_PLUGIN(iv)
Many thanks,
John
___
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] PagedLOD preprocessing
Hi, advanced problem: Is there a chance to preprocess scene by OSG to use PagedLOD? The scene contains 3GB of textures (or any higher number). My idea was to make PagedLOD scene that would load high-resolution textures only for the most close scene parts to the camera. The problem is clear: OSG would probably freeze the computer during preprocessing when loading all the textures. In Inventor, it seemd simple: just to override the texture type and make the implementation not to load texture data. Any chance for solution in OSG? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD preprocessing
The scene contains 3GB of textures (or any higher number). My idea was to make PagedLOD scene that would load high-resolution textures only for the most close scene parts to the camera. 3GB is not overly large, and the reason for PageLOD existance is helping handle this and much large scenes. Cool! I am looking forward to test it on much larger data sets. The problem is clear: OSG would probably freeze the computer during preprocessing when loading all the textures. In Inventor, it seemd simple: just to override the texture type and make the implementation not to load texture data. Any chance for solution in OSG? There every chance of a solution in the OSG, first up you load the data, for instance do it incrementally, and then to generate the LOD levels as required. This is a tasks for you to work out though - the OSG is a scene graph rather than a modelling tool. Surely, I already started on algorithms by myself. But what are the possibilities of loading the scene data to not burn all free memory? I am guessing there are two approaches: - You mentioned incremental loading - but I do not see any possibility to break in to the load-at-once algorithms of osgDB::Registry, ReaderWriterOSG, and their friends - override of loading algorithms of PluginOSG for Texture class, although I am not sure if it is possible to do so John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
