[osg-users] Error while building Virtual Planet Builder
hi, I am using Open Scene Graph version 2.1.11 and I have checked out latest version of Virtual Planet Builder dated 20/09/07. I am getting the following errors while build. /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp: In member function `bool TemplateSerializerC, P::read(osgDB::Input, osg::Object , bool)': /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp:212: error: 'class osgDB::Input' has no member named 'read' /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp: In member function `bool Vec4SerializerC::read(osgDB::Input, osg::Object, bool )': /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp:255: error: 'class osgDB::Input' has no member named 'read' /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp: In member function `bool GeospatialExtentsSerializerC::read(osgDB::Input, osg::O bject, bool)': /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp:343: error: 'class osgDB::Input' has no member named 'read' Can anybody please suggest which version of OSG to be used or how to resolve this problem? Thanks Omkaranathan. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error while building Virtual Planet Builder
Hi Omkaranathan, You'll need to use the SVN version of OSG for the SVN version of VirtualPlanetBuilder (VPB). VPB is undergoing a lot of structural changes right now so is not appropriate to use a base until I've got further through this work. If you want a stable version you'll need to use the 1.9.2 release I made a few weeks back. Robert. On 9/21/07, om [EMAIL PROTECTED] wrote: hi, I am using Open Scene Graph version 2.1.11 and I have checked out latest version of Virtual Planet Builder dated 20/09/07. I am getting the following errors while build. /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp: In member function `bool TemplateSerializerC, P::read(osgDB::Input, osg::Object , bool)': /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp:212: error: 'class osgDB::Input' has no member named 'read' /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp: In member function `bool Vec4SerializerC::read(osgDB::Input, osg::Object, bool )': /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp:255: error: 'class osgDB::Input' has no member named 'read' /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp: In member function `bool GeospatialExtentsSerializerC::read(osgDB::Input, osg::O bject, bool)': /VirtualPlanetBuilder/src/vpb/DatabaseBuilder.cpp:343: error: 'class osgDB::Input' has no member named 'read' Can anybody please suggest which version of OSG to be used or how to resolve this problem? Thanks Omkaranathan. ___ 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] OpenSceneGraph with Qt multiple windowing problem
Hi Robert, thanks for the information about the contexts. Now my task seems to me easier that I thought. I'm subclassing from osgViewer::GraphicsWindow, so I think I'll have to take account for the context IDs and the osg::State, as the osgwxviewer does (though only for one view). Anyways, I have the aid of the osgViewer::GraphicsWindowEmbedded class to copy some of its implementation details. Alberto El Thursday 20 September 2007 17:51:57 Robert Osfield escribió: Hi Alberto, On 9/20/07, Alberto Luaces [EMAIL PROTECTED] wrote: I'm a bit confused about the naming. What do you mean by graphics context? An OpenGL one or an osg::GraphicsContext? osg::GraphicsContext maps directly to an OpenGL context so there should not be any confusion. I ask because currently I have a wxWidgets application with two views of the same scene. Each view is attached to an osgViewer::GraphicsWindow which in turn controls its wxGLcanvas. The two wxGLcanvas were created with a common OpenGL context, so all the GL objects as display lists, textures... are shared. Each osgViewer::GraphicsWindow has one osg::State. A sharing OpenGL contexts doesn't mean actually sharing of the context, its just sharing some data between contexts, so you don't have a common OpenGL context, you have two separate OpenGL contexts that are sharing display lits/texture objects etc. Each GraphicsWindow is a GraphicsContext which maps directly to a single OpenGL graphics context. Each OpenGL graphics context has its own state machine which is mapped by a single osg::State object - which you'll find on the GraphicsContext. Sharing of display lists/texture objects between contexts on the OSG just requires you to set the State::ContextID to same value. If the GraphicsWindow implementation is set up correctly then it'll automatically assign the same ContextID for each of the seperate osg::State objects. In summary I have 2 wxGLCanvas ( sharing GL objects, one only common wxGLContext) 2 osgViewer::GraphicsWindow ( which are in fact 2 osg::GraphicContext) 2 osgViewer::View (I'm using osgViewer::CompositeViewer) 2 osg::State (not sure if only one would do) If, in addition, I wanted to show two more views of a new different scene, should I do the same as before (creating 2 GraphicsWindows, 2 Views, 2 States and connect them to the 2 wxGLCanvas with a new shared OpenGL context) and attaching the Views to the existing CompositeViewer or should I create a new CompositeViewer and attach the 2 new Views there? Ideally a single CompositeViewer should be used per app, and the various Views and associate GraphicsWindow managed according to your needs. The osg::State objects should all be managed as an implementation detail, you shouldn't need to concern yourself with it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 'loosing' textures? = How to create a proper .osg file with multi-texturing?
Hi Robert,
State the leaks out of one subgraph into the next is typically down to
some geometry not having color or normal arrays attached to them when
they need it, or in your case it could be that your are enabling the
second texture unit for all the scene, but only defining tex coords
for that texture unit for a small proportion of the scene.
Agreed, this makes sense, I had come up with this myself too. In the
scene, it looks as loosing textures, which is not really the case.
I assume that osg disables the texture units when no texture and/or
texture coordinates are set for these units, right? At the moment it seems
that there is a dependancy whether or not models are in the same frustum.
BTW, if you want other people to try out your models its best to zip
them all up together as copying and pasting text files is really error
prone.
Ok.
I will dive into this deeper.
thanks again,
Raymond
Robert.
On 9/21/07, Raymond de Vries [EMAIL PROTECTED] wrote:
Hi Robert, good morning,
I fully understand your point of view about the osgViewer, and I support
that. Actually, I've set up a test project to give it a try.
It seems that my problem has to do with my (hand-made) multi-textured
models! So it seems that I am not handling the statesets properly... I
created a multi-textured .osg file by hand, and I suspect that I forgot
to set/change something. It looks ok when I load it in osgviewer and I
don't see any errors reported by osgviewer (env var set to DEBUG_FP).
Other models then this multi-textured plane loose their texture in this
situation:
- 2 windows, each has its own sceneview
- sceneview's frustums are set so that the multi-textured plane is only
visible in 1 sceneview
- it doesn't matter if the other models are in the viewing frustum of
each window
This is how I created the multi-textured plane in .osg file format:
1) export a textured plane from 3dsmax
2) added the textureUnit 1 section by copying from the textureUnit 0
section
3) added the TexCoordArray 1 section by copying from the
TexCoordArray 0 section
3) added TexEnv section
I tried to change the renderbin but it does not change anything.
Can someone please take a look at the attached model? Or point me to a
properly multi-textured model in .osg format?
pfew, it's driving me nuts.
Thanks a lot for your time!
Raymond
Btw I'm now using osg 2.1.11 on WindowsXP, Visual Studio 2005 SP1
Robert Osfield wrote:
On 9/20/07, Raymond de Vries [EMAIL PROTECTED] wrote:
I know, it sounds that I'm doing strange things. But the opposite is
true. Well, I am stripping everything and see where it is. Eventually
it
will be something small stupid, as always ;-)
I'm afraid your set up is novel enough that others will only be clutch
at straws at what the issue. One of the reasons for the new osgViewer
library is to pull a whole range of disparate usage models together
under one family of classes to avoid the issues of users rolling a lot
of functionality on their own as its almost impossible to remotely
support such bespoke configurations.
The OSG does support multiple graphics context just fine, but your
have to be careful about management of threads, contextIDs. In the
case of 2.x it is more robust than ever in multi-threaded
multi-context role, and with osgViewer the vast majority of the
complexity of supporting these configurations is wrapped for you.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
MatrixTransform {
DataVariance STATIC
name Scene Root
nodeMask 0xff
cullingActive TRUE
StateSet {
UniqueID StateSet_0
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHTING ON
}
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
MatrixTransform {
DataVariance STATIC
name Front
nodeMask 0xff
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_1
DataVariance STATIC
nodeMask 0xff
cullingActive TRUE
num_drawables 1
Geometry {
DataVariance DYNAMIC
StateSet {
UniqueID StateSet_2
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE ON
GL_LIGHTING ON
0xba1 ON
Material {
DataVariance STATIC
ColorMode OFF
ambientColor 0.588235 0.588235 0.588235 1
diffuseColor 1 1 1 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
textureUnit 0 {
GL_TEXTURE_2D
Re: [osg-users] OpenSceneGraph with Qt multiple windowing problem
Hi Alberto, On 9/21/07, Alberto Luaces [EMAIL PROTECTED] wrote: thanks for the information about the contexts. Now my task seems to me easier that I thought. I'm subclassing from osgViewer::GraphicsWindow, so I think I'll have to take account for the context IDs and the osg::State, as the osgwxviewer does (though only for one view). Anyways, I have the aid of the osgViewer::GraphicsWindowEmbedded class to copy some of its implementation details. Have a look at the way the constructor/init is done for the GraphicsWindowWin32/X11/Carbon - they all provide a path for detecting use of shared contexts and manage the contextID accordingly. GraphicsWindowEmbedded itself is just a shell. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to activate precaching of textures on current version?
Hi all,
Could anyone please tell me how can i activate the textures precache
in current stable version ?
In the past I had this piece of code to do that task, wich piece of
code would substitute this one ?
for(osgProducer::OsgCameraGroup::SceneHandlerList::iterator
itr=viewer-getSceneHandlerList().begin();itr!=viewer-getSceneHandlerList().end();++itr)
{
osgUtil::SceneView* sceneview = (*itr)-getSceneView();
sceneview-setInitVisitor(new
osgUtil::GLObjectsVisitor(osgUtil::GLObjectsVisitor::COMPILE_DISPLAY_LISTS));
}
Thanks a lot!
Carlos.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to activate precaching of textures on current version?
Hi Carlos,
The osgViewer automatically pre compiles the subgraph when the windows
are created.
Is it that you are looking for a compile pass during the running of the app?
Robert.
On 9/21/07, Carlos Zoido [EMAIL PROTECTED] wrote:
Hi all,
Could anyone please tell me how can i activate the textures precache
in current stable version ?
In the past I had this piece of code to do that task, wich piece of
code would substitute this one ?
for(osgProducer::OsgCameraGroup::SceneHandlerList::iterator
itr=viewer-getSceneHandlerList().begin();itr!=viewer-getSceneHandlerList().end();++itr)
{
osgUtil::SceneView* sceneview = (*itr)-getSceneView();
sceneview-setInitVisitor(new
osgUtil::GLObjectsVisitor(osgUtil::GLObjectsVisitor::COMPILE_DISPLAY_LISTS));
}
Thanks a lot!
Carlos.
___
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] PSSM: Latest Version : Please Test and Debug
Hi Roberts i am working on the texture selection in GLSL, but unfortunately the gl_FragCoord.z is not for all situation between 0 .. 1. I n some cases, if a triangles, has a visible part in the [near,far] range and a hidden part behind the current viewing camera near, the value is from x..1, with x 0. Why is the value not from near .. far allways 0..1, is this an know ATI bug or do i something missunderstand. Or should i add a special matrix? or how can i fix this issue in fragment shader. /adegli 2007/9/19, Adrian Egli [EMAIL PROTECTED]: Thanks robert, i will working on NVidea System (Friday) and i hope that i can fix the problems. The z fighting is a know problem, but i don't yet know wether it come with ati / nvidea. i will fix it friday. regards adrian 2007/9/19, Robert Osfield [EMAIL PROTECTED]: Hi Adrian, To help things along I have gone ahead and merged your ShadowPSSM implementation, but renamed it to ParallelSplitShadowMap to be in keeping with the naming of the other shadow techniques. I have also added the PSSM enabling into osgshadow.cpp, but haven't merged PSSM.cpp as I didn't know what to do with this. When enabling --pssm in osgshadow I get shadows, but also z fighting artificats that suggest the polygon offset needs to be adjusted a bit. Bascially glPolygonOffset is not a standardised quantity under OpenGL so implementations vary, if you optimize for ATI it'll not work well under NVidia and visa versa. We've seen this issue with osgText before and made some tweaks to try and cope with the variance. See src/osg/PolgyonOffset.cpp. It could be that the code in there that tries to account for ATI might not be work well with recent drivers. Robert. On 9/19/07, Adrian Egli [EMAIL PROTECTED] wrote: Sorry Robert, i still fixed an issue this morning, and added also for debugging a define for enable r,g,b for 3 split maps, to color them (DEBUG) regards adrian 2007/9/19, Adrian Egli [EMAIL PROTECTED]: Hi Robert, i did some changes in latest implementation, i now i have a PSSM variant which works quite well. I propose to check this implementation into osgShadow. Of course this is just the first version of our PSSM implementation, but we are still open to change the implementation is implemented it as a shadow technique as you mentioned. A future implementation can be the one Terry started some month ago, but i don't know when he will be able to post a adapted version to our shadow technique abstraction. in the attachment we have to VS2003 project: * First my test case, may we can add this as new example. * Second is the osgShadow example from the SVN with changes i did, marked with //ADEGLI - the source - test.bat, you can see what i tested, the test.ive is a database downloaded from http://www.vision.ee.ethz.ch/~pmueller/wiki/CityEngine/DownloadModelsPompeiihttp://www.vision.ee.ethz.ch/%7Epmueller/wiki/CityEngine/DownloadModelsPompeii others should test. some problem can cause the PolygonOffset, i tested it on two different system with different GPUs, all under windows, i ll test as soon as i have some minutes left also under os/x /regards adegli 2007/9/18, Robert Osfield [EMAIL PROTECTED] : Hi Adrian and Terry, New shadow algorithms need to be implemented as a subclass from osgShadow::ShadowTechnique for them to be considered for merging with SVN. All the hooks required to implement advanced techniques are available to the shadow techniques so it shouldn't cause any significant problems in implementing the PSSM as a ShadowTechniqiue. The use of ShadowTechnique is important as it allows end users to trial out different techniques very easily and find the route which best suits their hardware and scene type. It is even possible that different techniques will be used by one application as they load up different scenes. I did review Terry's PSSM code and did consider porting it across to work as a ShadowTechnique, but alas I've just been snowed under be other work. The same is the case right now, while I'd love to see a good PSSM implementation checked into osgShadow I don't have the time to help out in this effort. Robert. On 9/18/07, Adrian Egli [EMAIL PROTECTED] wrote: Hi Terry, i don't know what robert requires of PSSM. The best and easiest would be to integrate it as a shadow technique, so the user can just change the shadow technique and that's it. Or ? adegli 2007/9/17, Terry Welsh [EMAIL PROTECTED]: Do you know what Robert requires of PSSM to have it included in OSG? Does it just need to be integrated with osgShadow? -- Terry Welsh -
Re: [osg-users] ive format and includeImageFileInIVEFile does itlosereferences to same image?
I now publicly admit that this whole thread had been nonsense. The writer does maintain a map of statesets so duplicating image data is in fact very rare. I still don't understand how a 2.3Mb (uncompressed) dae file plus 0.3Mb of jpeg data ends up as a 20Mbyte ive file! Roger I will not be offended if I am told the above is utter nonsense! Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with HDR, values clamped?
ok, now I understand :) thanks for your answer bnua 2007/9/21, Art Tevs [EMAIL PROTECTED]: Hi, Benoit. Yes there is a kind of clamp. 16 Bit float values can only represent values upto 65504. Thus it is a good practice to add something like: color = min(color, 65504); At the end of your shaders. See nVidia's FP_Specials.pdf for more info. Cheers, Art --- Benoit bossavit [EMAIL PROTECTED] schrieb: Hi all, I'm trying to do a render in HDR with a CameraNode (osg1.2). I have a texture where I set an Image wich contains float values : img-setImage( width, height, 1, GL_INTENSITY16F_ARB, GL_LUMINANCE, GL_FLOAT, data, osg::Image::USE_NEW_DELETE ); texture-setImage(img.get()); texture-setFilter( osg::Texture::MIN_FILTER, osg::Texture::LINEAR ); texture-setFilter( osg::Texture::MAG_FILTER, osg::Texture::LINEAR ); texture-setWrap( osg::Texture::WRAP_S, osg::Texture::CLAMP ); texture-setWrap( osg::Texture::WRAP_T, osg::Texture::CLAMP ); In data I put values between 0.0 and 7.0 I give this texture to my shaders and I project it with glsl function texture2DProj(). I have an artefact with the render (after tone mapping). Values upper than 65510 (not 65536) seems wrong. It's possible there is a max for float value with texture 16 bits ? and these max is the same that integer value? the rest of values or good, I can obtain for exemple a value like 25630.56. Someone can see something? thanks you. bnua ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever ___ 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] ive format and includeImageFileInIVEFile does itlosereferences to same image?
If you don't specify it, you image data will be written uncompressed, and it can explain the size of the ive file. To have your images written in a compressed format add to your option string : compressImageData JPEG_QUALITY 90 (for rgba images you have similar options with the PNG plugin) On 9/21/07, Roger James [EMAIL PROTECTED] wrote: I now publicly admit that this whole thread had been nonsense. The writer does maintain a map of statesets so duplicating image data is in fact very rare. I still don't understand how a 2.3Mb (uncompressed) dae file plus 0.3Mb of jpeg data ends up as a 20Mbyte ive file! Roger I will not be offended if I am told the above is utter nonsense! Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SVN osgViewer plugin build error
Hi, I have just updated and tried to build but I am having this error on the osgViewer plugin : Compiling... ReaderWriterOsgViewer.cpp CompositeViewer.cpp Viewer.cpp View.cpp Generating Code... Linking... Viewer.obj : error LNK2001: unresolved external symbol public: virtual class osg::Object * __thiscall osgViewer::Viewer::cloneType(void)const ([EMAIL PROTECTED]@osgViewer@@[EMAIL PROTECTED]@@XZ) Viewer.obj : error LNK2001: unresolved external symbol public: virtual class osg::Object * __thiscall osgViewer::Viewer::clone(class osg::CopyOp const )const ([EMAIL PROTECTED]@osgViewer@@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@@Z) Viewer.obj : error LNK2001: unresolved external symbol public: virtual bool __thiscall osgViewer::Viewer::isSameKindAs(class osg::Object const *)const ([EMAIL PROTECTED]@osgViewer@@[EMAIL PROTECTED]@@@Z) Viewer.obj : error LNK2001: unresolved external symbol public: virtual char const * __thiscall osgViewer::Viewer::libraryName(void)const ([EMAIL PROTECTED]@osgViewer@@UBEPBDXZ) Viewer.obj : error LNK2001: unresolved external symbol public: virtual char const * __thiscall osgViewer::Viewer::className(void)const ([EMAIL PROTECTED]@osgViewer@@UBEPBDXZ) D:\Code\Magrathea\Dependencies\Main\OpenSceneGraph\lib\Release\..\..\bin\osgPlugins-2.1.11\osgdb_osgviewer.dll : fatal error LNK1120: 5 unresolved externals It lead to another problem, during the INSTALL process of CMAKE I have this error : CMake Error: Error in cmake code at D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/src/osgPlugins/osgViewer/cmake_install.cmake:34: FILE INSTALL cannot find file D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/lib/Release/../../bin/osgPlugins-2.1.11/osgdb_osgviewer.dll to install. Current CMake stack: [4] D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/src/osgPlugins/osgViewer/cmake_install.cmake [3] D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/src/osgPlugins/cmake_install.cmake [2] D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/src/cmake_install.cmake [1] D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/cmake_install.cmake Should it be possible to tell CMake to continue to install even if it didn't find one of the plugins ? -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ive format and includeImageFileInIVEFile doesitlosereferences to same image?
Serge, I was running osgconv with includeImageFileInIVEFile set, so it should have been streming the jpegs into the ive file. If I run osgconv with no options the file is not much bigger (about 23MByte). Roger _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: 21 September 2007 14:29 To: OpenSceneGraph Users Subject: Re: [osg-users] ive format and includeImageFileInIVEFile doesitlosereferences to same image? If you don't specify it, you image data will be written uncompressed, and it can explain the size of the ive file. To have your images written in a compressed format add to your option string : compressImageData JPEG_QUALITY 90 (for rgba images you have similar options with the PNG plugin) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG?: mouse coordinate changes after window move
On 9/21/07, Robert Osfield [EMAIL PROTECTED] wrote: HI Lief, Thanks for the looking into this. I'm open to your suggest for a virtual fullscreen method. Possible this could be wrapped up into the setWindowRectangleImplementation which is automatically detects that the dimensions are fullsize. Any changes we make will need rolling out to Win32 and Carbon as well. I just tried the approach of setting the fullscreen state in setWindowRectangleImplementation, and this works without changing the GraphicsWindow base class. The only issue is: it has the side effect that changing the window size to the screen size through setWindowRectangle makes the window fullscreen, even if the window decorations have not been disabled through setWindowDecoration (this also leaves the windowDecoration context trait out of sync unless I set it to false in setWindowRectangle when going fullscreen). That means, for example, that cycling through the windowed resolutions with , in osgviewer will put the window into fullscreen when you reach the screen resolution (and back to windowed when you reduce the resolution). I could check the decoration trait (in addition to window size) to determine if the window should be fullscreen, but that would mean you'd need to turn decorations on/off before setting the window size (ViewerEventHandler uses this order, but it could be a source of confusion). I suppose I could also add the screen size dimensions check and fullscreen state code in the setWindowDecorationImplementation, so that disabling decorations with a screen size window goes into fullscreen. What are your thoughts on this? By the way, I found that GNOME/metacity does also honor the Motif hints regarding decorations, but the fullscreen state is the only way I've found to get top-level stacking of a window. Leaving the fullscreen state only adds window decorations back if they haven't been disabled with the Motif hint. Would you be able to try out tweaking GraphicsWindow/GraphicsWindowX11 to see if you can get the new window hints working? Robert. On 9/20/07, Leif Delgass [EMAIL PROTECTED] wrote: On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/20/07, Anders Backman [EMAIL PROTECTED] wrote: Problem 2 (windowed): We are using gnome on Ubuntu, and osgviewer --window 100 100 500 500 cow.osg works fine, but after 'f' is pressed two times (first into fullscreen, and then back to windows), we dont get a window. So it seems that it is not possible to go back from fullscreen windowed mode. This is a bug in the window manager ignoring request to add decoration back in. It might be possible to code a workaround for working with such windowing managers but alas I can't divine what the problem might be as everything works just fine on all my linux boxes. Robert. Hi Robert, I have been experimenting with window manager hints regarding a different but related issue. I'm running GNOME under Fedora 5, and the fullscreen mode in osgviewer creates a window that stays under the top and bottom toolbar panels. For me, switching to windowed mode properly adds the window decorations. But what I discovered is that to get true fullscreen windows in GNOME, I need to use the Extended Window Manager Hints (EWMH): http://standards.freedesktop.org/wm-spec/wm-spec-latest.html Sending a ClientMessage event (or using XChangeProperty before mapping the window) to toggle the _NET_WM_STATE_FULLSCREEN Atom for the _NET_WM_STATE property works as expected -- the window is undecorated and appears on top of the toolbars in fullscreen state. I was looking into the OSG implementation and it seems that fullscreen is implemented using a window resize to screen dimensions + the Motif window manager hints to remove decorations. The EWMH spec is intended to replace Motif hints, and it has a slightly different philosophy. You specify the usage/type of window rather than directly controlling the use of decorations. I think what would be needed is a virtual fullscreen() method in GraphicsWindow that can be overriden in GraphicsWindowX11 using this implementation if the window manager supports it, and then the toggleFullscreen() method in ViewerEventHandler could call this function rather than setting the window rectangle and decoration (in the EWMH spec, the window manager is responsible for restoring the original window geometry and decoration when leaving fullscreen state). -- Leif Delgass [EMAIL PROTECTED] -- Leif Delgass [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] using Mesa instead of opengl
Hi, did someone try to run open scene graph with Mesa instead of opengl? Is it working? Or is it possible to use 16 bits color channel with opengl instead of 8 bits color channel? Thanks Jo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] using Mesa instead of opengl
We have used Mesa with OSG, and it seems to have worked for us. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Richard Sent: Friday, September 21, 2007 10:42 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] using Mesa instead of opengl Hi, did someone try to run open scene graph with Mesa instead of opengl? Is it working? Or is it possible to use 16 bits color channel with opengl instead of 8 bits color channel? Thanks Jo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgdb_dae - Collada runtime database
Hi Robert,
When a Collada file is read in and parsed (with osgdb_dae plugin) the contents
is stored in
a runtime database. The data is accessed through a DAE interface which have
load and save
functionality and methods to access the object model.
Since we are working with both Collada for graphics and physics it would be
really convenient
if the same runtime database could be used for both. This would greatly
simplify saving collada
data and save time and memory (no need to parse the collada files twice and
have two runtime
databases at the same time with the same info).
When saving, the graphics state updates would be in one database and the
physics in another and
getting that into one correct collada-file would be somewhat unpleasant.
Currently we have solved this by making it possible for plugins to return a
void-pointer
virtual void* ReaderWrite::getPluginData() { return 0l; }
which plugins can overload if needed such as
virtual void* ReaderWriterDAE::getPluginData() { return reinterpret_castvoid
*(_dae); }
Then we use callbacks in the application on file loads so we get a way to
access the DAE
instance within the collada plugin.
Would it be possible to make some sort of update to OSG to solve this problem,
or
perhaps you have some better suggestion how to do this?
/ Mattias
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN osgViewer plugin build error
HI Serge, Sorry about this error. I've been checking in a set of changes to osgViewer and the osgViewer plugin for the support the reading of viewer configuration files. There has been a series of check-ins, so there is chance that the error you've seen is now fixed. Could you do another svn update and let me know how you get on. If an svn update doesn't work then I'm a bit stumped, as the missing methods should be defined by the META_Object macro that can be now found in include/osgViewer/Viewer. Robert. On 9/21/07, Serge Lages [EMAIL PROTECTED] wrote: Hi, I have just updated and tried to build but I am having this error on the osgViewer plugin : Compiling... ReaderWriterOsgViewer.cpp CompositeViewer.cpp Viewer.cpp View.cpp Generating Code... Linking... Viewer.obj : error LNK2001: unresolved external symbol public: virtual class osg::Object * __thiscall osgViewer::Viewer::cloneType(void)const ([EMAIL PROTECTED]@osgViewer@@[EMAIL PROTECTED]@@XZ) Viewer.obj : error LNK2001: unresolved external symbol public: virtual class osg::Object * __thiscall osgViewer::Viewer::clone(class osg::CopyOp const )const ([EMAIL PROTECTED]@osgViewer@@[EMAIL PROTECTED] @@[EMAIL PROTECTED]@@Z) Viewer.obj : error LNK2001: unresolved external symbol public: virtual bool __thiscall osgViewer::Viewer::isSameKindAs(class osg::Object const *)const ([EMAIL PROTECTED]@osgViewer@@[EMAIL PROTECTED] @@@Z) Viewer.obj : error LNK2001: unresolved external symbol public: virtual char const * __thiscall osgViewer::Viewer::libraryName(void)const ([EMAIL PROTECTED]@osgViewer@@UBEPBDXZ) Viewer.obj : error LNK2001: unresolved external symbol public: virtual char const * __thiscall osgViewer::Viewer::className(void)const (?className@ [EMAIL PROTECTED]@@UBEPBDXZ) D:\Code\Magrathea\Dependencies\Main\OpenSceneGraph\lib\Release\..\..\bin\osgPlugins-2.1.11\osgdb_osgviewer.dll : fatal error LNK1120: 5 unresolved externals It lead to another problem, during the INSTALL process of CMAKE I have this error : CMake Error: Error in cmake code at D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/src/osgPlugins/osgViewer/cmake_install.cmake:34: FILE INSTALL cannot find file D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/lib/Release/../../bin/osgPlugins- 2.1.11/osgdb_osgviewer.dll to install. Current CMake stack: [4] D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/src/osgPlugins/osgViewer/cmake_install.cmake [3] D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/src/osgPlugins/cmake_install.cmake [2] D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/src/cmake_install.cmake [1] D:/Code/Magrathea/Dependencies/Main/OpenSceneGraph/cmake_install.cmake Should it be possible to tell CMake to continue to install even if it didn't find one of the plugins ? -- Serge Lages http://www.magrathea-engine.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] SVN osgViewer plugin build error
Hello Serge, Should it be possible to tell CMake to continue to install even if it didn't find one of the plugins ? I agree, this would be very useful. Sometimes a given (optional) plugin does not compile or link, and then in INSTALL target tries to copy everything in the right place and stops at the missing file. It should be possible to give a warning instead of an error and continue copying the other files. I think I've seen something like that in the CMake docs, but I don't remember. Luigi, is this possible? Thanks, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdb_dae - Collada runtime database
Hi Mattias,
I'm not particularly up to speed on the Collada plugin (I'm not the
author of it) so only can speak at very high level w.r.t OSG
integration. If you want extra information into a plugin one uses the
Options object, potentially you could use this to pass back extra
plugin related data too - for instance by attaching it to the UseData
of the Options object.
Robert.
On 9/21/07, Mattias Linde [EMAIL PROTECTED] wrote:
Hi Robert,
When a Collada file is read in and parsed (with osgdb_dae plugin) the
contents is stored in
a runtime database. The data is accessed through a DAE interface which have
load and save
functionality and methods to access the object model.
Since we are working with both Collada for graphics and physics it would be
really convenient
if the same runtime database could be used for both. This would greatly
simplify saving collada
data and save time and memory (no need to parse the collada files twice and
have two runtime
databases at the same time with the same info).
When saving, the graphics state updates would be in one database and the
physics in another and
getting that into one correct collada-file would be somewhat unpleasant.
Currently we have solved this by making it possible for plugins to return a
void-pointer
virtual void* ReaderWrite::getPluginData() { return 0l; }
which plugins can overload if needed such as
virtual void* ReaderWriterDAE::getPluginData() { return reinterpret_castvoid
*(_dae); }
Then we use callbacks in the application on file loads so we get a way to
access the DAE
instance within the collada plugin.
Would it be possible to make some sort of update to OSG to solve this
problem, or
perhaps you have some better suggestion how to do this?
/ Mattias
___
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] PSSM: Latest Version : Please Test and Debug
Hi Adrian, On 9/21/07, Adrian Egli [EMAIL PROTECTED] wrote: No problem, i played arround and got new variant of shading. the latest version is using antialised shadow mapping, of course it needs some calculation's for doing this, but the result looks much nicer. latest pssm code will be posted as soon as i will have more time left. i will send just the latest implementation, robert you don't have to merge it. i will do it next week. Could you please merge your changes to the changes I made when I integrated your first code drop into the SVN version. I made name changes and fixed some minor compile issues. It'd be great to have these fixes before Monday as I'll be making a the 2.1.12 dev release on Monday and want to make sure it compiles cleanly. We are very close to 2.2 so I don't want to take any risks right now. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG?: mouse coordinate changes after window move
On 9/21/07, Robert Osfield [EMAIL PROTECTED] wrote: setWindowRectangle(x,y,width,height,enableDecoration); Would this help things? I forget to see enableDecroation above would be a bool. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG?: mouse coordinate changes after window move
Hi Lief, On 9/21/07, Leif Delgass [EMAIL PROTECTED] wrote: I just tried the approach of setting the fullscreen state in setWindowRectangleImplementation, and this works without changing the GraphicsWindow base class. The only issue is: it has the side effect that changing the window size to the screen size through setWindowRectangle makes the window fullscreen, even if the window decorations have not been disabled through setWindowDecoration (this also leaves the windowDecoration context trait out of sync unless I set it to false in setWindowRectangle when going fullscreen). I am wondering about having an extra option to for setWindowRectangle which sets the window decoration at the same time. i..e setWindowRectangle(x,y,width,height,enableDecoration); Would this help things? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM: Latest Version : Please Test and Debug
Thanks Paul, fixed in my private working directory. /adegli 2007/9/21, Paul Melis [EMAIL PROTECTED]: Adrian Egli wrote: For those you are interest in see how the latest version looks like... There is a slight compile issue with gcc: ShadowPSSM.cpp: In member function 'virtual void osgShadow::ShadowPSSM::init()': ShadowPSSM.cpp:196: error: 'class osg::Texture2D::FilterMode' is not a class or namespace ShadowPSSM.cpp:196: error: 'LINEAR' was not declared in this scope Line 196 of ShadowPSSM.cpp needs to refer to osg::Texture2D::LINEAR. Paul 2007/9/21, Adrian Egli [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: No problem, i played arround and got new variant of shading. the latest version is using antialised shadow mapping, of course it needs some calculation's for doing this, but the result looks much nicer. latest pssm code will be posted as soon as i will have more time left. i will send just the latest implementation, robert you don't have to merge it. i will do it next week. /adegli 2007/9/21, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi Adrian, I understand the technique enough to comment I'm afraid. Robert. On 9/21/07, Adrian Egli [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Roberts i am working on the texture selection in GLSL, but unfortunately the gl_FragCoord.z is not for all situation between 0 .. 1. I n some cases, if a triangles, has a visible part in the [near,far] range and a hidden part behind the current viewing camera near, the value is from x..1, with x 0. Why is the value not from near .. far allways 0..1, is this an know ATI bug or do i something missunderstand. Or should i add a special matrix? or how can i fix this issue in fragment shader. /adegli 2007/9/19, Adrian Egli [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Thanks robert, i will working on NVidea System (Friday) and i hope that i can fix the problems. The z fighting is a know problem, but i don't yet know wether it come with ati / nvidea. i will fix it friday. regards adrian 2007/9/19, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : Hi Adrian, To help things along I have gone ahead and merged your ShadowPSSM implementation, but renamed it to ParallelSplitShadowMap to be in keeping with the naming of the other shadow techniques. I have also added the PSSM enabling into osgshadow.cpp, but haven't merged PSSM.cpp as I didn't know what to do with this. When enabling --pssm in osgshadow I get shadows, but also z fighting artificats that suggest the polygon offset needs to be adjusted a bit. Bascially glPolygonOffset is not a standardised quantity under OpenGL so implementations vary, if you optimize for ATI it'll not work well under NVidia and visa versa. We've seen this issue with osgText before and made some tweaks to try and cope with the variance. See src/osg/PolgyonOffset.cpp. It could be that the code in there that tries to account for ATI might not be work well with recent drivers. Robert. On 9/19/07, Adrian Egli [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Sorry Robert, i still fixed an issue this morning, and added also for debugging a define for enable r,g,b for 3 split maps, to color them (DEBUG) regards adrian 2007/9/19, Adrian Egli [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi Robert, i did some changes in latest implementation, i now i have a PSSM variant which works quite well. I propose to check this implementation into osgShadow. Of course this is just the first version of our PSSM implementation, but we are still open to change the implementation is implemented it as a shadow technique as you mentioned. A future implementation can be the one Terry started some month ago, but i don't know when he will be able to post a adapted version to our shadow technique abstraction. in the attachment we have to VS2003 project: * First my test case, may we can add this as new example. * Second is the osgShadow example from the SVN with changes i did, marked with //ADEGLI - the source - test.bat, you can see what i tested, the test.ive is a database downloaded from http://www.vision.ee.ethz.ch/~pmueller/wiki/CityEngine/DownloadModelsPompeii
Re: [osg-users] debug plugin library names under linux
I'm running into another problem now. On Windows, I wasn't able to use the osg plugin. The library was osgplugins-2.1.22/osgdb_osgd.dll. I renamed it to osgdb_osg.dll, and it worked. So it seems to have not found the plugin with the 'd' in it. Is there a bug with how we find the plugin libraries, or should the 'd' not be in the plugin name? (The 'd' is already not there on linux, just windows.) It seems someone would have had this problem before me. Are plugins not be tested on windows? andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN osgViewer plugin build error
On 9/21/07, Robert Osfield [EMAIL PROTECTED] wrote: HI Serge, Sorry about this error. I've been checking in a set of changes to osgViewer and the osgViewer plugin for the support the reading of viewer configuration files. There has been a series of check-ins, so there is chance that the error you've seen is now fixed. Could you do another svn update and let me know how you get on. If an svn update doesn't work then I'm a bit stumped, as the missing methods should be defined by the META_Object macro that can be now found in include/osgViewer/Viewer. Robert. Just updated but it fails again to build. but you should resolve it easily : \openscenegraph\src\osgviewer\compositeviewer.cpp(122) : error C4716: 'osgViewer::CompositeViewer::readConfiguration' : must return a value -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debug plugin library names under linux
On 9/21/07, Andy Skinner [EMAIL PROTECTED] wrote: I'm running into another problem now. On Windows, I wasn't able to use the osg plugin. The library was osgplugins-2.1.22/osgdb_osgd.dll. I renamed it to osgdb_osg.dll, and it worked. So it seems to have not found the plugin with the 'd' in it. Is there a bug with how we find the plugin libraries, or should the 'd' not be in the plugin name? (The 'd' is already not there on linux, just windows.) It seems someone would have had this problem before me. Are plugins not be tested on windows? andy Personally I work under Windows and I have no problems with debug plugins. In my debug directory I only have the debug plugins so I am sure OSG loads the correct ones. -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN osgViewer plugin build error
On 9/21/07, Serge Lages [EMAIL PROTECTED] wrote: On 9/21/07, Robert Osfield [EMAIL PROTECTED] wrote: HI Serge, Sorry about this error. I've been checking in a set of changes to osgViewer and the osgViewer plugin for the support the reading of viewer configuration files. There has been a series of check-ins, so there is chance that the error you've seen is now fixed. Could you do another svn update and let me know how you get on. If an svn update doesn't work then I'm a bit stumped, as the missing methods should be defined by the META_Object macro that can be now found in include/osgViewer/Viewer. Robert. Just updated but it fails again to build. but you should resolve it easily : \openscenegraph\src\osgviewer\compositeviewer.cpp(122) : error C4716: 'osgViewer::CompositeViewer::readConfiguration' : must return a value Actually even the first time if I had problems building the osgViewer plugin it was because osgViewer failed to build, but I've just noticed it now. :) -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM: Latest Version : Please Test and Debug
Hi Robert, I will posting it to the OSG submission ( [EMAIL PROTECTED]) as soon as i have rebuild it myself (SVN version of OSG). there is a little issue i have to / like to fix before sunday. I tested it on ATI and NVidea the polygonOffset is quite different for ATI : Factor = -0.02f, Unit = 1.0f for NVidea: Factor = 15.0f, Unit = 10.0f ends in really nice output. How should i implement it, ? GL_VENDOR ? ... adegli 2007/9/21, Robert Osfield [EMAIL PROTECTED]: Hi Adrian, On 9/21/07, Adrian Egli [EMAIL PROTECTED] wrote: No problem, i played arround and got new variant of shading. the latest version is using antialised shadow mapping, of course it needs some calculation's for doing this, but the result looks much nicer. latest pssm code will be posted as soon as i will have more time left. i will send just the latest implementation, robert you don't have to merge it. i will do it next week. Could you please merge your changes to the changes I made when I integrated your first code drop into the SVN version. I made name changes and fixed some minor compile issues. It'd be great to have these fixes before Monday as I'll be making a the 2.1.12 dev release on Monday and want to make sure it compiles cleanly. We are very close to 2.2 so I don't want to take any risks right now. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSGEXP
I'm unable to use the installer for this because it doesn't locate my copy of 3DS Max. Shouldn't it give me an option to manually locate Max if it can't find it? Possible that because I'm using the evaluation version that the installer isn't seeing it where it expects to? -bc ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ScalarBar Text Properties (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Greetings, We use a ScalarBar in our app (OSG 2.0, x86-dual core, Red Hat). When it is created, we get the warning that the file fonts/arial.ttf cannot be found. We have our fonts files in a different location (under a configuration directory, rather than in the fonts directory beneath the executable). Is there a way to construct a ScalarBar without getting this warning? We will be setting a different font anyway (times.ttf, I think) for use with the ScalarBar, so we're not even using arial.ttf. Thanks for your help, Joel Classification: UNCLASSIFIED Caveats: NONE smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN osgViewer plugin build error
On 9/21/07, Serge Lages [EMAIL PROTECTED] wrote: Just updated but it fails again to build. but you should resolve it easily : \openscenegraph\src\osgviewer\compositeviewer.cpp(122) : error C4716: 'osgViewer::CompositeViewer::readConfiguration' : must return a value Now fixed and checked in. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM: Latest Version : Please Test and Debug
On 9/21/07, Adrian Egli [EMAIL PROTECTED] wrote:
Hi Robert,
I will posting it to the OSG submission
([EMAIL PROTECTED] ) as soon as i
have rebuild it myself (SVN version of OSG).
there is a little issue i have to / like to fix before sunday. I tested it
on ATI and NVidea the polygonOffset is quite different
for ATI : Factor = - 0.02f, Unit = 1.0f
for NVidea: Factor = 15.0f, Unit = 10.0f
ends in really nice output.
How should i implement it, ? GL_VENDOR ? ...
There is already some hacks in place in PolygonOffset, see
src/osg/PolygonOffset.cpp:
void PolygonOffset::setFactorAndUnitsMultipliersUsingBestGuessForDriver()
{
s_MultiplerSet = true;
//
osg::notify(osg::NOTICE)PolygonOffset::setFactorAndUnitMultipliersUsingBestGuessForDriver()std::endl;
const GLubyte* renderer = glGetString(GL_RENDERER);
if (renderer)
{
if ((strstr((const char*)renderer,Radeon)!=0) ||
(strstr((const char*)renderer,RADEON)!=0))
{
setFactorMultiplier(1.0f);
setUnitsMultiplier(128.0f);
osg::notify(osg::INFO)PolygonOffset::setFactorAndUnitsMultipliersUsingBestGuessForDriver()
apply ATI workaround.std::endl;
}
}
}
So you above factor/units should be multiplier against these.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] texturing osgSim::SphereSegment
Hi Sylvain, osgSim::SphereSegment is very specialist class that has been designed not to be used with texturing, and its complex shape preclude any easy tex coord mapping for them Is there a reason why you aren't just rolling your own osg::Geometry? This is exactly how I'd set up a sphere segment geometry with texturing. Robert. On 9/21/07, sylvain cormier [EMAIL PROTECTED] wrote: Hi, I would like some help for texturing a movie on a sphere segment. I noticed by pressing s on the surface of a sphere segment I have created , that there are 10 drawables, no vertices and no primitives. Why is this? After having applied a texture, I can see something going on on the sphere segment because pressing s(start) and p(pause) cause the sphere segment to flicker with lines. I can also toggle the texture on and off. On the contrary, texturing a cylinder with: geode-addDrawable(newosg::ShapeDrawable(newosg::Cylinder(osg::Vec3(0.0f,0.0f,0.0f),20,20))); was easy and contained 1 drawable, 166 vertices and 120 primitives. Not really knowing what to do, I tried removing some drawables with geode-removeDrawables(1,9); just to see. I still was able to get a sphere segment which gave me 1 drawable while pressing s. Why is this? are those other 9 drawables not important? I do not know where to go from here, any help would be appreciated. thanks in advance. Sylvain ___ 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
