Re: [osg-users] Experiments on Textures and Images, strange behavior.
Hi Gaëtan, If you are assigning a new Image to an already existing and possibly bound texture, try to set the image dirty. Secondly, you might want to try to set the texture explicitly to: stateset->setTextureAttributeAndModes( 0,map, osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE); Cheers Sebastian Hi, I am trying to understand how texture ande Image are working //some initialized texture with contents osg::ref_ptr map //displays correctly the texture osg::StateSet* stateset = HUD_camera->getOrCreateStateSet(); stateset->setTextureAttributeAndModes( 0,map); //does not display the texture osg::ref_ptr lm = new osg::Texture2D; lm->setImage(map->getImage()); stateset->setTextureAttributeAndModes( 0,lm); Why ? Thank you! Cheers, Gaëtan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54501#54501 ___ 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] Experiments on Textures and Images, strange behavior.
Hi,
Ok I will try to make it clearer.
I have a generated CubeMap, and I want to display each face on a quad with a
HUD Camera. I first tried to generate on face in a Texture2D and it worked
welll since I don't have to copy the image in the original texture in a new
texture (on the opposite if I try to use getIMage(), setImage(), this does not
work anymore) to display it on a quad.
For the CubeMap,Ii want its images (6) to be embedded in Texture2D to simply be
displayed on a quad.
Here is the piece of code :
//map contains the generated Cube map when the function is called
void SDDebugHUD::setTexture(osg::ref_ptr map){
osg::StateSet* stateset = HUD_camera->getOrCreateStateSet();
osg::ref_ptr lm = new osg::Texture2D;
lm->setDataVariance(osg::Object::DYNAMIC);
lm->setImage(map->getImage(3));
stateset->setTextureAttributeAndModes( 0,lm);
}
Thank you!
Cheers,
Gaëtan
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54506#54506
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgDB] Registry::writeNodeImplementation()
Hi Judson, When you say the WriteResult is different could you explain what the result is in each case? Is there file written out OK in ech case. W.r.t binary planting, the most secure way to avoid any plugins being loaded that aren't purka is to build your application as a static binary with all plugins that you'll need explicitly compiled in. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Experiments on Textures and Images, strange behavior.
Hi Gaëtan, There is too much information about the usage of the textures and associated images to know what is going on, but my best guess is that your first texture is being used and has the UnRefImageDataAfterApply set to true (this is the default) so once it's used the image will be discarded, so your second texture->setImage() will be simply setting 0 which of course will not work. Personally I'd suggest not messing around with a second texture, just reuse the first one. If you for some reason really really need to reuse the same image then keep a ref_ptr<> to it so that you can guarantee it's lifetime. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing and re-adding an update callback
Hi All, A wee update on this thread. I have now checked in a fix that fixes both the NodeCallback::addNestedCallback() so it appends the nested callback to the last callback in the chain - previously it would insert the new nested callback rather than append leading to less than obvious ordering, and fixed the removeNestedCallback so that it removed any reference left to the nested callback's nested callback. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Some Question About OSGOcean
Dear Kim, I am a postgraduate student in schools of remote sensing and engineering , WuHan University , China . I am greatly intersted in the open scene graph project , especially in the OSGOcean. It is genuinely attractive and charming. However , I have some questions about the OSGOcean Example. First of all , Is there any documents that specify the details about the project? Such as the relationship between all kinds of classes , or about the parameters in each function memeber of the class? In addition ,how could I get to konw the latest news of the project beside the information offered by the OSG origination websets?Finally , to be frank , I want to be a memeber of the OSGOcean project though I don't have a comprehensive understanding of the details in the project. How can I been a memeber of your project? I am looking forward to your promopt reply. Sincerely Yours , Zhang Mi Schools of remote sensing and engineering , WuHan University , China. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Some Question About OSGOcean
Hi there, Thanks for you interest in osgOcean, I'm glad that you like it. I'm afraid there isn't any formal documentation for the project but I have tried to document as many functions and classes as possible within the code so have a root around in there. Unfortunately due my other commitments the project has laid dormant for a while now. I keep meaning to update it but finding the time is difficult, however I always welcome contributions. If you have any specific questions, ideas or contributions, please don't hesitate to contact me on this email address. Regards, Kim. On 10 June 2013 12:40, WillScott wrote: > Dear Kim, > I am a postgraduate student in schools of remote sensing and > engineering , WuHan University , China . I am greatly intersted in the open > scene graph project , especially in the OSGOcean. It is genuinely > attractive and charming. > However , I have some questions about the OSGOcean Example. First > of all , Is there any documents that specify the details about the project? > Such as the relationship between all kinds of classes , or about the > parameters in each function memeber of the class? In addition ,how > could I get to konw the latest news of the project beside the information > offered by the OSG origination websets?Finally , to be frank , I want > to be a memeber of the OSGOcean project though I don't have a comprehensive > understanding of the details in the project. How can I been a memeber of > your project? >I am looking forward to your promopt reply. > > Sincerely Yours , > > Zhang > Mi > > Schools > of remote sensing and engineering , > > WuHan University , China. > > > > > ___ > 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] Experiments on Textures and Images, strange behavior.
Hi,
I followed your advice and applied directly the cubemap on the quad using 3D
texture coordinates.
Allow me to ask another question are things are very weird !
I render the scene in the CubeMap
Code:
reflectionMap = new osg::TextureCubeMap;
reflectionMap->setTextureSize( 256, 256 );
reflectionMap->setInternalFormat( GL_RGBA);
camerasRoot = new osg::Group;
for(int i=0;i<6;i++){
osg::ref_ptr camera = new osg::Camera;
camera->setViewport( 0, 0, 256, 256 );
camera->setClearMask( GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT );
camera->setRenderOrder( osg::Camera::PRE_RENDER );
camera->setRenderTargetImplementation(
osg::Camera::FRAME_BUFFER_OBJECT );
camera->attach( osg::Camera::COLOR_BUFFER, reflectionMap,0,i );
camera->setReferenceFrame( osg::Camera::ABSOLUTE_RF );
camera->addChild( m_sceneroot );
camera->setPreDrawCallback(pre_cam);
camera->setPostDrawCallback(post_cam);
camera->setProjectionMatrixAsPerspective(90.0,1.0,1.0,100.0);
camerasRoot->addChild(camera);
cameras.push_back(camera);
}
Then this CubeMap is used twice per cycle.
First on a object, via shaders.
Second on two quads,displayed by a HUD camera (in order to see what is in the
map).
On the object, a still image is displayed corresponding to a render from a
previous execution of the application !
On the quads, this image is blended with the correct texture being rendered.
Each time I restart the application, a image of the previous execution is used.
It is sort of confusing.
Thank you!
Cheers,
Gaëtan[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54516#54516
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Experiments on Textures and Images, strange behavior.
Hi Gaëtan, On 10 June 2013 15:26, Gaëtan André wrote: > Then this CubeMap is used twice per cycle. > > First on a object, via shaders. > Second on two quads,displayed by a HUD camera (in order to see what is in the > map). > > On the object, a still image is displayed corresponding to a render from a > previous execution of the application ! > > On the quads, this image is blended with the correct texture being rendered. > > Each time I restart the application, a image of the previous execution is > used. > > It is sort of confusing. This is almost certainly down to an issue of order of setting the texture contents and using them. The OSG has a scheme for controlling the rendering order Camera's, and for render to texture Camera's you use camera->setRenderOrder(osg::Camera::PRE_RENDER); Please have a look at the osgprerender and osgprerendercubemap examples. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Experiments on Textures and Images, strange behavior.
Hi, Thanks again for replying. In my code camera->setRenderOrder(osg::Camera::PRE_RENDER); is present. I looked at the examples, there does not seem to have much difference. Cheers, Gaëtan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54521#54521 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgDB] Registry::writeNodeImplementation()
Hi Robert, On 6/10/2013 4:48 AM, Robert Osfield wrote: Hi Judson, When you say the WriteResult is different could you explain what the result is in each case? Is there file written out OK in ech case. First pass, result status is FILE_NOT_HANDLED message is "Warning: Write to "path" not supported." Second pass, result status is ERROR_IN_WRITING_FILE message is "Warning: Could not find plugin to write nodes to file "path." The file is not written out in either case, because I was specifically interested in testing the non-successful code paths. The reason for the difference is based on whether or not the plugin DLL has been loaded or not. W.r.t binary planting, the most secure way to avoid any plugins being loaded that aren't purka is to build your application as a static binary with all plugins that you'll need explicitly compiled in. It still seems like an attempt to load DLLs would be made for unregistered file extensions (maybe?). Perhaps I did not see an ifdef or condition for the static libary case. However, calling Registry::setLibraryFilePathList() manually might work for my case. 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
Re: [osg-users] [osgDB] Registry::writeNodeImplementation()
Hi Judson.
On 10 June 2013 16:27, Judson Weissert wrote:
> First pass, result status is FILE_NOT_HANDLED message is "Warning: Write to
> "path" not supported."
> Second pass, result status is ERROR_IN_WRITING_FILE message is "Warning:
> Could not find plugin to write nodes to file "path."
> The file is not written out in either case, because I was specifically
> interested in testing the non-successful code paths.
>
> The reason for the difference is based on whether or not the plugin DLL has
> been loaded or not.
Without having some exact code in front of me that reproduces this
difference I can't speculate on the exactly cause or what if anything
is appropriate to do about it. For now I'm going to put this asside as
a low priority issue.
>
> It still seems like an attempt to load DLLs would be made for unregistered
> file extensions (maybe?). Perhaps I did not see an ifdef or condition for
> the static libary case. However, calling Registry::setLibraryFilePathList()
> manually might work for my case.
Explicitly loading plugins with a specific application defined path
and and disabling the loading of new plugins thereafter might be
another route. The could be done via a custom FindFileCallback that
return std::string("") when you decide then nothing else should be
loaded.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Experiments on Textures and Images, strange behavior.
Hi, reflectionMap->setFilter(osg::TextureCubeMap::MIN_FILTER,osg::TextureCubeMap::LINEAR); reflectionMap->setFilter(osg::TextureCubeMap::MAG_FILTER,osg::TextureCubeMap::LINEAR); These two line solved my problem. What is the default filter and why does not it work with it ? Thank you! Cheers, Gaëtan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54526#54526 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Experiments on Textures and Images, strange behavior.
On 10 June 2013 18:10, Gaëtan André wrote: > > reflectionMap->setFilter(osg::TextureCubeMap::MIN_FILTER,osg::TextureCubeMap::LINEAR); > > reflectionMap->setFilter(osg::TextureCubeMap::MAG_FILTER,osg::TextureCubeMap::LINEAR); > > These two line solved my problem. > > What is the default filter and why does not it work with it ? The defaults are for a mipmapped texture, if you were just rendering to the topmost level then unless you enabled the mipmap generation then these levels will be undefined. Note the mipMapGeneration line from the Camera::attach() inline docs: /** Attach a Texture to specified buffer component. * The level parameter controls the mip map level of the texture that is attached. * The face parameter controls the face of texture cube map or z level of 3d texture. * The mipMapGeneration flag controls whether mipmap generation should be done for texture.*/ void attach(BufferComponent buffer, osg::Texture* texture, unsigned int level = 0, unsigned int face=0, bool mipMapGeneration=false, unsigned int multisampleSamples = 0, unsigned int multisampleColorSamples = 0); Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Experiments on Textures and Images, strange behavior.
Hi, Thanks fo the details. Thank you! Cheers, Gaëtan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54530#54530 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgDB] Registry::writeNodeImplementation()
Hi Robert,
Once again, thank you for your time.
I continued to look into the scene export issues I was having, and here
are some of my findings (against OSG 3.1.7 development release).
I attached an alternate implementation of
osgDB::Registry::writeNodeImplementation(). The same changes would apply
to other Registry member functions: writeShaderImplementation(),
writeObjectImplementation(), writeImageImplementation(),
writeHeightFieldImplementation(), and possibly read().
One of the major behavior changes is that once ERROR_IN_WRITING_FILE is
encountered, no more attempts are made to write the file. It also
prevents a possible ERROR_IN_WRITING_FILE status from propagating even
though the real error seemed to be FILE_NOT_HANDED. The changes I made
are based on my assumptions about how the plugins "should work", but I
may have overlooked something. The point of the changes is to make it so
the export behavior is the same, regardless of whether or not a plugin
DLL was loaded in response to an export request.
Also, per our DLL search path discussion, the following DLL paths are
searched when attempting to export a model to "osg.txt" (where txt is an
unregistered extension that is not associated with any plugins):
1. Executable folder: [path to application
binary]\osgPlugins-3.1.7\osgdb_txt.dll ...
2. Location of osgDB DLL: [path to osgDB
DLL]\osgPlugins-3.1.7\osgdb_txt.dll ...
3. System 32 folder: C:\Windows\system32\osgPlugins-3.1.7\osgdb_txt.dll ...
4. System folder: C:\Windows\System\osgPlugins-3.1.7\osgdb_txt.dll ...
5. Windows folder: C:\Windows\osgPlugins-3.1.7\osgdb_txt.dll ...
6. Working directory: .\osgPlugins-3.1.7\osgdb_txt.dll ...
7. Folders specified in PATH env var: [PATH
...]\osgPlugins-3.1.7\osgdb_txt.dll ...
[Repeat list, but omit osgPlugins-* portion of that path]
I ended up loading all of the OSG plugin DLLs I plan to use manually and
calling osgDB::Registry::instance ()->setLibraryFilePathList
(std::string ()); early during application startup to prevent the
traversal of the above search paths. I cannot speak for other platforms,
but for Microsoft Windows environments, the default plugin DLL loading
behavior does not seem suitable for production environments.
Regards,
Judson
ReaderWriter::WriteResult Registry::writeNodeImplementation(const Node&
node,const std::string& fileName,const Options* options)
{
// storage for a ReaderWriter result.
ReaderWriter::WriteResult
result(ReaderWriter::WriteResult::FILE_NOT_HANDLED);
// now look for a plug-in to save the file.
std::string libraryName = createLibraryNameForFile(fileName);
(void) loadLibrary(libraryName);
// attempt to write the file from ReaderWriter(s).
AvailableReaderWriterIterator itr(_rwList, _pluginMutex);
for(;itr.valid();++itr)
{
ReaderWriter::WriteResult rr = itr->writeNode(node,fileName,options);
if (rr.success() || rr.error ())
{
// rr.status(): FILE_SAVED or ERROR_IN_WRITING_FILE
result = rr;
break;
}
// rr.status(): NOT_IMPLEMENTED or FILE_NOT_HANDLED
}
if (result.message().empty())
{
switch(result.status())
{
case(ReaderWriter::WriteResult::FILE_NOT_HANDLED):
result.message() = "Warning: Write to \""+fileName+"\" not
supported.";
break;
case(ReaderWriter::WriteResult::ERROR_IN_WRITING_FILE):
result.message() = "Warning: Error in writing to
\""+fileName+"\".";
break;
}
}
return result;
}___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgDB] Registry::writeNodeImplementation()
Hi Judson, On 10 June 2013 21:12, Judson Weissert wrote: > One of the major behavior changes is that once ERROR_IN_WRITING_FILE is > encountered, no more attempts are made to write the file. This breaks the Chain-Of-Responsibility design pattern used by the plugins, it's up to plugins whether or not that can handle a particular file or not, it's not the position of the Registry to not call plugins in case of another plugins failure, it's up to the plugins themselves. I am not about to merge changes that breaks this long standing mechanism. If you want to override the Registry to change this mechanism then I'm open to making the appropriate methods virtual if they aren't already. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgDB] Registry::writeNodeImplementation()
Hi Robert, I guess what I am trying to convey is that the successful (FILE_SAVED) code paths works correctly, the Chain-Of-Responsibility for that case works fine (first to succeed wins). The problem is when I try to write a file that is not writable (i.e. try to write to a file that is open by another process, or a file that I do not have permission to write to). That is, the case where no ReaderWriter can succeed because the file is simply not writable. The following paragraphs are within the context of the osgDB::Registry::writeNodeImplementation() function. For example, when attempting to export a scene to an *.osgb file, the first loop tries to call writeNode() on a single ReaderWriter. NOT_IMPLEMENTED status gets pushed on the result vector and the vector is cleared. Then, 2 plugins are explicitly loaded when loadLibrary() is called. The 2 plugins that are loaded are associated with the OSGReaderWriter, and ReaderWriterOSG2 classes. The OSGReaderWriter::writeNode() call fails with FILE_NOT_HANDED (which is correct since we requested *.osgb file extension) and the result is pushed onto the result vector. Then, ReaderWriterOSG2::writeNode() fails with ERROR_IN_WRITING file (ok, this makes sense). The problem is that the function returns results.front() which is the error code associated with OSGReaderWriter (in this case FILE_NOT_HANDLED with message "Warning: Write to "filename" not supported"). It should have returned the error associated with ReaderWriterOSG2 (the *.osgb writer) which returned an error status of ERROR_IN_WRITING "Warning: Error in writing to "filename".". Now, the second time through (export the same file again), the following happens. All of the writers fail with various error statuses (same statuses as before). The result vector is cleared, and no plugins are loaded (since they were loaded the first time the export was attempted). The results vector is empty, so the function returns "Warning: Could not find plugin to write nodes to file..." with error status of FILE_NOT_HANDLED. However, that error status and message are not correct because the file extension (*.osgb) is handled and the plugin was found and loaded... it just could not be written. I hope this makes sense. Let me know if I can clarify anything. Regards, Judson On 6/10/2013 4:47 PM, Robert Osfield wrote: Hi Judson, On 10 June 2013 21:12, Judson Weissert wrote: One of the major behavior changes is that once ERROR_IN_WRITING_FILE is encountered, no more attempts are made to write the file. This breaks the Chain-Of-Responsibility design pattern used by the plugins, it's up to plugins whether or not that can handle a particular file or not, it's not the position of the Registry to not call plugins in case of another plugins failure, it's up to the plugins themselves. I am not about to merge changes that breaks this long standing mechanism. If you want to override the Registry to change this mechanism then I'm open to making the appropriate methods virtual if they aren't already. 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
