[Opensg-users] OpenSGToolbox - UserInterfaces in VEs
Hi David, hi all, has someone used the UserInterface library included in OpenSGToolbox in some kind of virtual environment? David, does the library support this in general or are there some constraints we need to know? Best regards, Michael -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
[Opensg-users] TransformationMatrix::multFull
Hi, I got a warning when using multFull with a Vec3f, but the warning went away when converting the Vec3f to Pnt3f first ... OSGMatrix.inl line 1508: ValueType w = _matrix[0][3] * pntIn[0] + _matrix[1][3] * pntIn[1] + _matrix[2][3] * pntIn[2] + _matrix[3][3]; OSGMatrix.inl line 1620: ValueType w = _matrix[0][3] * vecIn[0] + _matrix[1][3] * vecIn[1] + _matrix[2][3] * vecIn[2]; Is there a reason for this? OpenSG 2 r2279 Aloha, Andi -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
Re: [Opensg-users] Direction of DirectionalLights
Hello Theodore, Hall, Theodore wrote: The direction of DirectionalLights is opposite to what I expected, and opposite to the behavior of SpotLights -- at least in OpenSG 1.8. I've been tracing through the logic, and here's what I've figured out: From the OpenGL documentation: http://www.opengl.org/sdk/docs/man/ If the w component of the position is 0, the light is treated as a directional source ... The initial position is (0, 0, 1, 0); thus, the initial light source is directional, parallel to, and in the direction of the -z axis. So the direction is opposite to the GL_POSITION, and conversely, the GL_POSITION is opposite to the direction, and the GL_SPOT_DIRECTION is ignored. OpenGL is probably more consistent than OpenSG here as it simple sets the position of a directional light at one of the infinitely far away points you have when using homogeneous coordinates. But in OpenSG 1.8 DirectionalLight::drawEnter(Action *action) I see: Vec4f dir(_sfDirection.getValue()); dir[3] = 0; glLightfv(light, GL_POSITION , dir.getValues()); glLightf (light, GL_SPOT_CUTOFF, 180.f ); So it's setting the GL_POSITION from the specified direction, instead of its opposite. The direction is pointing toward the light, instead of away from it as with the SpotLight. I suppose it would break a lot of client code, but I would change one line: glLightfv(light, GL_POSITION , (-dir).getValues()); Thoughts? Since offhand it sounds a bit more natural to specify a direction (instead of an infinitely far away) for a DirectionalLight that is what OpenSG calls the relevant field. For consistency it probably should invert the direction, but I'm not sure if this is worth breaking applications in a somewhat subtle way. BTW drawEnter is a callback registered with the DrawAction (not the RenderAction) which is mostly unused at this point as it renders in pure immediate mode (no state sorting, etc.), but in this case renderEnter() eventually does the same thing. Does OpenSG 2.0 follow the same logic? yes. Cheers, Carsten -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
Re: [Opensg-users] TransformationMatrix::multFull
Hello Andreas, Andreas Halm wrote: I got a warning when using multFull with a Vec3f, but the warning went away when converting the Vec3f to Pnt3f first ... OSGMatrix.inl line 1508: ValueType w = _matrix[0][3] * pntIn[0] + _matrix[1][3] * pntIn[1] + _matrix[2][3] * pntIn[2] + _matrix[3][3]; OSGMatrix.inl line 1620: ValueType w = _matrix[0][3] * vecIn[0] + _matrix[1][3] * vecIn[1] + _matrix[2][3] * vecIn[2]; Is there a reason for this? yes, a vector v represents a direction, so in homogeneous coordinates v[3] == 0, for a point p (representing a position) p[3] == 1, which is why the w above is computed differently. This distinction is only relevant for the 3 component case, when Vec4f or Pnt4f are used the last component is explicitly given and both should behave the same way. For the Vec3 case we should probably remove the warning since there is nothing wrong when the above w == 0. For Pnt3 I'm less sure as it indicates that the point is transformed to an infinitely far away point and those can not be represented by Pnt3 (you need a Pnt4 for that). Cheers, Carsten -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
Re: [Opensg-users] TransformationMatrix::multFull
Carsten Neumann wrote: For the Vec3 case we should probably remove the warning done in r2405. Cheers, Carsten -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
Re: [Opensg-users] OpenSGToolbox - UserInterfaces in VEs
Hi Michael, Not yet, as far as I am aware, but it was written with that in mind. Some of classes needed for this are ready. User Interfaces are attached to a UIDrawingSurface. The UIDrawingSurface is used to draw the UserInterface. Currently there are two classes that can draw a UIDrawingSurface within OpenSG. - UIForeground- is an OpenSG Foreground that can be attached to a viewport. This is meant to be used by single window applications, so it is probably not useful for multi-display or distributed systems. - UIRectangle - is an OpenSG Core that renders the UI to a rectangle in the scene. So UIRectangle can be used as a core to a node that is part of the scenegraph. - There are 3 tutorials that show how to use UIRectangle: 20UIRectangle, 21ExampleInterface, and 49LookAndFeel There are limitations. The UIDrawingSurface receives mouse, keyboard, and window events from a WindowEventProducer. The WindowEventProducers have different implementations depending on the window system: win32, x11, or Carbon. Currently there is no WindowEventProducer for handling distributed applications. The current plan to have a WindowEventProducer that is useful in a distributed environment is to write a PassiveWindowEventProducer. This WindowEventProducer would not connect to the underlying window system to capture mouse, keyboard, window events as this doesn't make much sense given there may be 1 window showing the scene. So to use the PassiveWindowEventProducer, application writers would need to define how they want to simulate mouse, keyboard, and window events in the distributed system. Example simulation of input for distributed system. - Mouse - If the VE system uses a 6-dof tracker that the users can manipulate in their hands, then the mouse position can be simulated as the intersection of the ray cast from the tracker with the UIRectangle containing the UI. If the system has buttons on the tracker, then these buttons could be mapped to button1,button2, etc. Something similar could also be done for the mouse scroll wheel. In addition you may want to create a cursor in the scene that follows this intersection. - Keyboard - Given that users would probably not bring a keyboard device with them into the environment, this may be difficult. In this case you may want to create a text input UI, similar to Cell phones without physical keyboards, or game consoles, where the mouse input could be used to press buttons on the UI with Keys associated with them. - Update- The WindowEventProducer would also need to receive update events with the elapsed time since the last update so that time dependent behavior of the UI can operate correctly. e.g. double clicks, tooltip popup time. I plan on doing this at the lab I work at this next month, and will add the PassiveWindowEventProducer to the repo soon. When I have it done, I will make the example code available. In the meantime, please let me know how you feel about this approach, and perhaps features you may like for your own approach. Thanks, David Kabala On Wed, Apr 28, 2010 at 1:39 AM, Michael Raab michael-r...@gmx.de wrote: Hi David, hi all, has someone used the UserInterface library included in OpenSGToolbox in some kind of virtual environment? David, does the library support this in general or are there some constraints we need to know? Best regards, Michael -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
Re: [Opensg-users] [Opensg-commits] r2406 - trunk/Source/System/Dynamics/Base
Hi, On Wed, 2010-04-28 at 17:40 -0500, opensg-comm...@external.lite3d.com wrote: Author: cneumann Date: Wed Apr 28 17:40:32 2010 New Revision: 2406 Trac changeset: http://www.opensg.org//changeset/2406 Modified: trunk/Source/System/Dynamics/Base/OSGFrameHandler.cpp trunk/Source/System/Dynamics/Base/OSGFrameHandler.h trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.h trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.inl Log: fixed: register FrameTasks with the correct aspect copy of the FrameHandler ?? there is only one copy of the FrameHandler. Is this really working, my current guess would be that FrameHandler::the() will return NULL for all but the creating aspect if setup this way. kind regards gerrit -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
Re: [Opensg-users] [Opensg-commits] r2406 - trunk/Source/System/Dynamics/Base
On Thu, 2010-04-29 at 08:12 +0800, Gerrit Voß wrote: Hi, On Wed, 2010-04-28 at 17:40 -0500, opensg-comm...@external.lite3d.com wrote: Author: cneumann Date: Wed Apr 28 17:40:32 2010 New Revision: 2406 Trac changeset: http://www.opensg.org//changeset/2406 Modified: trunk/Source/System/Dynamics/Base/OSGFrameHandler.cpp trunk/Source/System/Dynamics/Base/OSGFrameHandler.h trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.h trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.inl Log: fixed: register FrameTasks with the correct aspect copy of the FrameHandler ?? there is only one copy of the FrameHandler. Is this really working, my current guess would be that FrameHandler::the() will return NULL for all but the creating aspect if setup this way. arrrg, one should not guess before the first coffee in the morning ;). As it is a singleton you will constantly override the FrameHandler if you continuously call get from different aspects. It was not meant to be MT save for more than the standard app thread aspect 0 and drawers parallel with different aspects. What is the app model you have in mind ? kind regards gerrit -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
Re: [Opensg-users] [Opensg-commits] r2406 - trunk/Source/System/Dynamics/Base
Hi, sorry the third, On Thu, 2010-04-29 at 10:44 +0800, Gerrit Voß wrote: On Thu, 2010-04-29 at 08:12 +0800, Gerrit Voß wrote: Hi, On Wed, 2010-04-28 at 17:40 -0500, opensg-comm...@external.lite3d.com wrote: Author: cneumann Date: Wed Apr 28 17:40:32 2010 New Revision: 2406 Trac changeset: http://www.opensg.org//changeset/2406 Modified: trunk/Source/System/Dynamics/Base/OSGFrameHandler.cpp trunk/Source/System/Dynamics/Base/OSGFrameHandler.h trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.h trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.inl Log: fixed: register FrameTasks with the correct aspect copy of the FrameHandler ?? there is only one copy of the FrameHandler. Is this really working, my current guess would be that FrameHandler::the() will return NULL for all but the creating aspect if setup this way. arrrg, one should not guess before the first coffee in the morning ;). As it is a singleton you will constantly override the FrameHandler if you continuously call get from different aspects. It was not meant to be MT save for more than the standard app thread aspect 0 and drawers parallel with different aspects. What is the app model you have in mind ? ok, I think I understand what you tried to fix, the multiple addition of tasks during the tasks sync. Hmm, this does not seem to work correctly this way as it breaks my existing par draw apps ;(. I'll throw it around my head and see what falls out ;) kind regards gerrit -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
Re: [Opensg-users] [Opensg-commits] r2406 - trunk/Source/System/Dynamics/Base
Hi, On Wed, 2010-04-28 at 23:18 -0500, Carsten Neumann wrote: Hello Gerrit, Gerrit Voß wrote: On Thu, 2010-04-29 at 10:44 +0800, Gerrit Voß wrote: On Thu, 2010-04-29 at 08:12 +0800, Gerrit Voß wrote: On Wed, 2010-04-28 at 17:40 -0500, opensg-comm...@external.lite3d.com wrote: Author: cneumann Date: Wed Apr 28 17:40:32 2010 New Revision: 2406 Trac changeset: http://www.opensg.org//changeset/2406 Modified: trunk/Source/System/Dynamics/Base/OSGFrameHandler.cpp trunk/Source/System/Dynamics/Base/OSGFrameHandler.h trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.h trunk/Source/System/Dynamics/Base/OSGFrameTaskMixin.inl Log: fixed: register FrameTasks with the correct aspect copy of the FrameHandler ?? there is only one copy of the FrameHandler. Is this really working, my current guess would be that FrameHandler::the() will return NULL for all but the creating aspect if setup this way. arrrg, one should not guess before the first coffee in the morning ;). As it is a singleton you will constantly override the FrameHandler if you continuously call get from different aspects. It was not meant to be MT save for more than the standard app thread aspect 0 and drawers parallel with different aspects. What is the app model you have in mind ? ok, I think I understand what you tried to fix, the multiple addition of tasks during the tasks sync. yes, I wanted them to be registered with the FrameHandler copy for their aspect. Hmm, this does not seem to work correctly this way as it breaks my existing par draw apps ;(. I'll throw it around my head and see what falls out ;) oops, sorry, I had hoped just doing the registration with the correct copy of the FrameHandler would be safe. Do you already have some more details in which way it breaks? the FrameHandler was designed to be a global instance, e.g. it does not sync (neither cluster nor threads). So in the second aspect the MTRefPtr will report NULL and consequently the program will create a new one and assign it to the global instance ptr, overriding the original one, the original aspect in turn will to the same, so in the worst cast you ping pong FrameHandler creations between the different threads/aspects. At the minimum you loose the task registered initially in the first thread (this is what happens to my app right now). E.g. you can actually test it, there is a CSM example, Examples/CSM/SimpleAnim-Par using a parallel drawer with a simple animation. Currently the animation does not work any more as the app thread tasks have disappeared during the sync. My current 'quick' solution would be to forbid a taks to be registered twice. But I'm still thinking if this would be to restrictive. Preferable I would forbid the registration during the creation of the aspect copy, still looking at this ;) Making all tasks not syncing might be to extreme ;) kind regards gerrit -- ___ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
