Re: [osg-users] order of PreRender camera with respect to the main camera
HI Nick,
If you Camera that is following the main camera requires the same view
matrix then could you not simply set the Camera::ReferenceFrame to
REALATVE_TF so that it inherits the view and projection matrix from above?
Robert.
On 25 October 2014 08:35, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com
wrote:
Hi Robert,
below is my frame code, and this seam to fix it. But, just a question,
shouldnt the main view matrix be updated by the camera manipulator prior to
any other update (I have attached UpdateCallback to the pre render camera
and these seam to be called before the main camera update which results in
frame delay)?
if (_viewer.valid())
{
static bool firstFrame = true;
if (firstFrame)
{
_viewer-frame();
firstFrame = false;
}
else
{
_viewer-advance();
_viewer-eventTraversal();
_viewer-updateTraversal();
if (_reflectionCamera.valid())
{
_reflectionCamera-setViewMatrix(_viewer-getView(0)-getCamera()-getViewMatrix());
}
_viewer-renderingTraversals();
}
}
This way it works, it gurantee the pre render camera has the updated view
matrix
With this update callback it is with delay
class FollowMainCameraNodeCallback : public osg::NodeCallback
{
public:
FollowMainCameraNodeCallback(osg::Camera* camera)
: _camera(camera)
{
}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osg::Camera* thisCamera = dynamic_castosg::Camera*(node);
if (!thisCamera) return;
thisCamera-setViewMatrix(_camera-getViewMatrix());
.
_reflectionCamera-setUpdateCallback(new
FollowMainCameraNodeCallback(_viewer-getView(0)-getCamera()));
Nick
On Fri, Oct 24, 2014 at 5:31 PM, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
thanks Robert
Nick
On Fri, Oct 24, 2014 at 5:19 PM, Robert Osfield robert.osfi...@gmail.com
wrote:
Hi Nick,
The update of the CameraManipulator happens at the end of
VIewer::updateTraversal(). The default Viewer::frame() implementation()
runs the event and then update traversal.
Your own application can override any of the viewer.frame() or
updateTraversal/eventTraversal() methods so if you want to take control and
do things in a different from standard you can do.
Robert.
On 24 October 2014 16:13, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi Community,
I am facing the same problem for long time and always have to hack
it. I have prerender camera that has to follow the main camera. My
pre-render camera is always a frame behind the main camera which is updated
by a CameraManipulator.
The update of the Pre-Render camera is done with UpdateCallback that
simply copy the ViewMatrix of the main camera, but it seam that the main
camera is updated afterwards.
What is the order of these updates? I was expecting the main camera is
updated from the CameraMainpulator and then everything else (including the
Pre-Render cameras), but seam it is not the case?
Any hints on this?
Thanks a bunch as always!
Nick
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Thanks for the helgrind tip. I think I pinpointed the crash in our program, this is working from trunk: As said we have multiple files that reference the same image for a texture, I have found two spots that can cause problems: - In InputStream::readImage(bool readFromExternal) at line 777 the program could get an image from the cache. After this it continues to read the image fields and set parameters. The most problematic is at like 784 where it will set the image filename, which is a string. This is not thread safe. Looking further it will call readObjectFields which will read the name and userdata and crash on that. - When a Texture2D is read it will call Texture2D::setImage and this function will call _image-addClient which can mess up the _numClients counter. The second problem can also appear while reading ive files. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61424#61424 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] order of PreRender camera with respect to the main camera
Hi Robert,
this is really good idea .. Haven't thought of Thanks again
Nick
On Mon, Oct 27, 2014 at 11:52 AM, Robert Osfield robert.osfi...@gmail.com
wrote:
HI Nick,
If you Camera that is following the main camera requires the same view
matrix then could you not simply set the Camera::ReferenceFrame to
REALATVE_TF so that it inherits the view and projection matrix from above?
Robert.
On 25 October 2014 08:35, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi Robert,
below is my frame code, and this seam to fix it. But, just a question,
shouldnt the main view matrix be updated by the camera manipulator prior to
any other update (I have attached UpdateCallback to the pre render camera
and these seam to be called before the main camera update which results in
frame delay)?
if (_viewer.valid())
{
static bool firstFrame = true;
if (firstFrame)
{
_viewer-frame();
firstFrame = false;
}
else
{
_viewer-advance();
_viewer-eventTraversal();
_viewer-updateTraversal();
if (_reflectionCamera.valid())
{
_reflectionCamera-setViewMatrix(_viewer-getView(0)-getCamera()-getViewMatrix());
}
_viewer-renderingTraversals();
}
}
This way it works, it gurantee the pre render camera has the updated view
matrix
With this update callback it is with delay
class FollowMainCameraNodeCallback : public osg::NodeCallback
{
public:
FollowMainCameraNodeCallback(osg::Camera* camera)
: _camera(camera)
{
}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osg::Camera* thisCamera = dynamic_castosg::Camera*(node);
if (!thisCamera) return;
thisCamera-setViewMatrix(_camera-getViewMatrix());
.
_reflectionCamera-setUpdateCallback(new
FollowMainCameraNodeCallback(_viewer-getView(0)-getCamera()));
Nick
On Fri, Oct 24, 2014 at 5:31 PM, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
thanks Robert
Nick
On Fri, Oct 24, 2014 at 5:19 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
Hi Nick,
The update of the CameraManipulator happens at the end of
VIewer::updateTraversal(). The default Viewer::frame() implementation()
runs the event and then update traversal.
Your own application can override any of the viewer.frame() or
updateTraversal/eventTraversal() methods so if you want to take control and
do things in a different from standard you can do.
Robert.
On 24 October 2014 16:13, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
Hi Community,
I am facing the same problem for long time and always have to hack
it. I have prerender camera that has to follow the main camera. My
pre-render camera is always a frame behind the main camera which is
updated
by a CameraManipulator.
The update of the Pre-Render camera is done with UpdateCallback that
simply copy the ViewMatrix of the main camera, but it seam that the main
camera is updated afterwards.
What is the order of these updates? I was expecting the main camera is
updated from the CameraMainpulator and then everything else (including the
Pre-Render cameras), but seam it is not the case?
Any hints on this?
Thanks a bunch as always!
Nick
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Pjotr, On 27 October 2014 10:58, Pjotr Svetachov pjotrsvetac...@gmail.com wrote: As said we have multiple files that reference the same image for a texture, I have found two spots that can cause problems: - In InputStream::readImage(bool readFromExternal) at line 777 the program could get an image from the cache. After this it continues to read the image fields and set parameters. The most problematic is at like 784 where it will set the image filename, which is a string. This is not thread safe. Looking further it will call readObjectFields which will read the name and userdata and crash on that. I've just read through the code, it certainly assumes that it's the only thread writing to the image data, and doesn't account for the possibility that when the osgDB::Registry object cache is active it is possible to start modifying an image that is already been actively used by another thread. I expect this is something that Rui Wang didn't pick up as a possibility when he originally wrote the serializers. In the case when the image is shared it looks to me like the best approach would be to not allow any additional modifications to the image by the InputStream::readImage() method. Even if you added mutex locks around the write operations to the mutex you'd ended with an image that flips state during it's lifetime so that the original owners of the image would then have an Image in a new state that it doesn't have baring on what it was originally. This might be OK in some instances, but could cause real problems for application/code that assumes the Image is invariant once it has been set up. Changing the behaviour to ignore the local modifications when an Image is shared is something that might break applications too, but my instinct is to treat Image as invariant once setup is the more common case so will affect users left often than the current state. Perhaps one possibility would be to have a flag in InputStream to give a hint to what to do. If we do ignore the extra write for Image's pulled from the cache we'd need to still read then discard the options to avoid breaking file compatibility. Another, more drastic workaround would be to duplicate the osg::Image from the cache and let the new Image be modified. This rather defaults the purpose of using a cache though. It's worth adding that this cached object issue will be a wider one that just Image handling, so whatever solution we plump for we'll need to tackle these other cases as well. - When a Texture2D is read it will call Texture2D::setImage and this function will call _image-addClient which can mess up the _numClients counter. The second problem can also appear while reading ive files. I think this problem will be easier to resolve, changing the _numClients to an osg::Atomic should probably be sufficient. I will test this change right now to see if it has any effect on the crashes I'm seeing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Robert, You said that you were working with shaders. A race condition that looks like the Texture2D::setImage example above can also happen with shaders in .osg files: The method Shader_readLocalData can get shaders out of a cache when files are referenced. Then later in Program::addShader the program will call shader-addProgramRef which does not look thread safe to me. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61426#61426 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
HI Pjotr, On 27 October 2014 11:50, Pjotr Svetachov pjotrsvetac...@gmail.com wrote: You said that you were working with shaders. A race condition that looks like the Texture2D::setImage example above can also happen with shaders in .osg files: The method Shader_readLocalData can get shaders out of a cache when files are referenced. Then later in Program::addShader the program will call shader-addProgramRef which does not look thread safe to me. I don't use the Registry object cache for the shader terrain code I'm currently writing so I don't think I'll be hitting this particular issue. I so agree that the Shader::addProgramRef()/removeProgramRef() isn't thread safe. There is a parallel to the Node::addParent/removeParent() method and these are protected by the mutex lock, so I've added the same lock to the Shader::addProgramRef()/removeProgramRef(). I will test this out on my system and check it into svn/trunk is all goes well. This particular fix will be safe to check into the OSG-3.2 branch as it won't affect the ABI. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
robertosfield wrote: In the case when the image is shared it looks to me like the best approach would be to not allow any additional modifications to the image by the InputStream::readImage() method. Even if you added mutex locks around the write operations to the mutex you'd ended with an image that flips state during it's lifetime so that the original owners of the image would then have an Image in a new state that it doesn't have baring on what it was originally. This might be OK in some instances, but could cause real problems for application/code that assumes the Image is invariant once it has been set up. Changing the behaviour to ignore the local modifications when an Image is shared is something that might break applications too, but my instinct is to treat Image as invariant once setup is the more common case so will affect users left often than the current state. Perhaps one possibility would be to have a flag in InputStream to give a hint to what to do. If we do ignore the extra write for Image's pulled from the cache we'd need to still read then discard the options to avoid breaking file compatibility. Another, more drastic workaround would be to duplicate the osg::Image from the cache and let the new Image be modified. This rather defaults the purpose of using a cache though. It's worth adding that this cached object issue will be a wider one that just Image handling, so whatever solution we plump for we'll need to tackle these other cases as well. I'm with you on not changing an image (or other objects) state when it's already in a cache. If people don't want this they should turn the cache off or clear the cache or clone things in the cache or whatever they need. OSG has options for that. Right now I made a small modification on my side to osg that (in case the image comes from a cache) makes a dummy image and uses that one to read too. Then discards that image. For the scenes we work with that works but as you said this issue could be wider that only the images. An option in the InputStream and Serializer class to not set any data to an object, or even better to skip parsing the data (but for the latter you would need an end offset for binary files) would be great. It would allow to easily solve these issues when they come up and could potentially be used to do more advanced things later on. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61430#61430 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Wake effects?
Hi, I'm bringing back this thread up also after 2 years. Did anyone get any success about the wake effect? I'm working around foam+shoreline without any interesting results at moment Thank you! Cheers, Dario -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61431#61431 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking geometry
Hi, Robert I repeat the same question because , I have little problem with internet connection, sorry. You have very clever reply, it force me to think different and I find solution. Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61432#61432 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
