Re: [osg-users] Coordinate system in all readerwriters
On 29/12/09 6:52 PM, Paul Martz wrote: Paul Martz wrote: I've noticed the same thing with OBJ. A little digging reveals that the OBJ plugin has a noRotation Option that disables the x axis rotation. The rotation is only done on file load, not on file write. Rotation about x is on by default. I'd suggest a change to off by default, and the Option changed to doRotation to enable it. The .x plugin has 'leftHanded' and 'rightHanded'. Maybe we could establish a common option for this type of functionality (one that does 'convert to right-handed, Z-axis up'). There already are options with (apparently) related functionality (courtesy of 'osgconv --formats'): Coordinate system: obj:noRotation x:leftHanded x:rightHanded Optimization: obj:generateFacetNormals obj:noTriStripPolygons stl:generateNormals stl:smooth stl:tristrip Image orientation hdr:NO_YFLIP hdr:YFLIP x:flipTexture Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Wojtek, I solved my directional light case. I changed all floats to doubles in * StandardShadowMap::ViewData::aimShadowCastingCamera The light camera position was calculated as float as was thus jumping around. Of course the change from yesterday using double bounding volumes also has to be activated. In the process I also upgraded the polytope class to double (I don't think this is necessary). I can fix the other light type cases (VB/CB/DB) but someone will have to give me a quick walk-through on posting updates to osg so I don't have to do my work twice. Thanks a lot for your support. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21954#21954 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to flip the current frame before it gets drawn?
I'd like to flip (horizontally and/or vertically) the current frame just before it gets drawn on screen, what is the best way to do this? I thought about post-multiplying a projection matrix (that is already available) by a scaling (or) rotation matrix, but of course this approach acts on the scene and not on the frame and has two undesired effects: 1. normals are flipped 2. HUDs are NOT flipped Is it possible to flip the frame that is going to be drawn? If not, how can I avoid the normals from being flipped because of the scaling/mirroring? Thanks in advance. Alessandro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to flip the current frame before it gets drawn?
On 30/12/09 11:12 AM, alessandro terenzi wrote: I'd like to flip (horizontally and/or vertically) the current frame just before it gets drawn on screen, what is the best way to do this? I thought about post-multiplying a projection matrix (that is already available) by a scaling (or) rotation matrix, but of course this approach acts on the scene and not on the frame and has two undesired effects: 1. normals are flipped 2. HUDs are NOT flipped Is it possible to flip the frame that is going to be drawn? If not, how can I avoid the normals from being flipped because of the scaling/mirroring? Render to a texture and draw that flipped? This gets around all the aforementioned problems and doesn't affect the scene/shaders, it's completely transparent. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to flip the current frame before it gets drawn?
Thank you Ulrich. By the way, what is the general approach to RTT? I had a look at some examples some time ago, but it could be useful to have a guide line here...as far as I remember, RTT requires a camera that sees my scene and that will be used to generate a texture, then I'll need another different camera that actually will be used to render that texture, correct? what the texture will be, in my case that camera will be the one that I'm currently using to render my scene, but then I'll need another different camera that actually will be used to render the previous texture, correct? How about HUDs, if I'm not wrong they also use a different camera so performing RTT on the scene will keep HUDs out, am I wrong? Thanks. Alessandro On Wed, Dec 30, 2009 at 11:15 AM, Ulrich Hertlein u.hertl...@sandbox.dewrote: Render to a texture and draw that flipped? This gets around all the aforementioned problems and doesn't affect the scene/shaders, it's completely transparent. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] gl_FrontMaterial deprecated?
Hi guys, did I miss something or is gl_FrontMaterial already deprecated in OpenGL 3? When I try to use gl_FrontMaterial.ambient, .diffuse, .shininess, etc. in the vert/frag shaders I'm getting silly values (e.g. negative for shininess) that don't correspond to what I set in osg::Material. (But I'm not getting errors either.) When I use a uniform to pass those it works fine. I'm aware that this is how it should be done anyhow but I was under the impression that gl_FrontMaterial (and friends) would still work. This is on OS X 10.5.8 (GeForce 8600M, shading language 1.20). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinate system in all readerwriters
Hi Ulrich, Paul, and all, I agree we should unify the coordinate system during loading AND writing. Here are my suggestions : - Have plugins do NO rotation by default (reading and writing) when the format doesn't have coordinate system information (that is to say all but FBX and maybe FLT). - Have plugins read and apply coordinate system information if available by default when reading. - Have optionnal READING options: - readXup, readYup, readZup to suppose model is X, Y or Z-up (overrides format's coordinate system information) - readLeftHanded, readRightHanded (similar setting) - When in conflict (two options defined), use the latest one - Have optionnal WRITING options: - writeXup, writeYup, writeZup, writeLeftHanded, writeRightHanded (which should almost never be supported, in my opinion) - Let plugings optionnally support these options prefixed with their name and _. For instance 3ds_readYup would assume ONLY .3ds files are Y-up. These would take precedence over the general settings. - Also support pluginName_read/writeAutoUp and pluginName_read/writeAutoHanded, which would specifically deactivate a global setting for a given plugin. For instance, fbx_readAutoUp would let the plugin decide the up vector (here using coordinate system information in the .fbx). 3ds_readAutoUp would mean no rotation for .3ds. - Write a portion of code somewhere in osgDB to parse all these options and store it in a nice structure (to avoid each plugin duplicating code). To be called with something like myStructure = osgDB::readStandardCoordinateSystemOptions(PLUGIN_NAME). - As OpenGL doesn't have a etched in stone orientation standard, use the osgGA as an internal standard (that is to say +Z up, right handed) when a change is needed. 1. Please raise your hand if you agree, and tell about changes you'd like to introduce in this summary. 2a. Please mention all plugins you know which break these rules. 2b. Please tell if you agree modifying those plugins. When all is ok, I'll code it. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Ulrich Hertlein u.hertl...@sandbox.de a écrit : On 29/12/09 6:52 PM, Paul Martz wrote: Paul Martz wrote: I've noticed the same thing with OBJ. A little digging reveals that the OBJ plugin has a noRotation Option that disables the x axis rotation. The rotation is only done on file load, not on file write. Rotation about x is on by default. I'd suggest a change to off by default, and the Option changed to doRotation to enable it. The .x plugin has 'leftHanded' and 'rightHanded'. Maybe we could establish a common option for this type of functionality (one that does 'convert to right-handed, Z-axis up'). There already are options with (apparently) related functionality (courtesy of 'osgconv --formats'): Coordinate system: obj:noRotation x:leftHanded x:rightHanded Optimization: obj:generateFacetNormals obj:noTriStripPolygons stl:generateNormals stl:smooth stl:tristrip Image orientation hdr:NO_YFLIP hdr:YFLIP x:flipTexture Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CPack on osg-doc and openthreads-doc under MSVC
Hi all, I got an error building Package openscenegraph-doc (under MSVC v9, in-source build). The error is: CPack: - Install project: OpenSceneGraph CMake Error at cmake_install.cmake:31 (FILE): file INSTALL cannot copy file D:/blah-blah-blah/doc/OpenSceneGraphReferenceDocs/a02321.map to D:/blah-blah-blah/_CPack_Packages/ZIP/OpenSceneGraph-2.9.7/doc/OpenSceneGraphReferenceDocs/a02321.map and the build fails (The file is never the same - sometimes a .png, sometimes a .md5...). I don't know if it's related, but I found generating Package openscenegraph-doc and Package openthreads-doc in the same batch build leads to a strange thing: during the install process, in _CPack_Packages/ZIP/OpenSceneGraph-2.9.7/doc you should find OpenSceneGraphReferenceDocs and OpenThreadsReferenceDocs directories. However, building one deletes the other! Did someone spotted somthing similar? Does it happen with other platforms/compilers? I don't know how to fix it yet... Any idea? Side question: Is there a way to generate 7z or tar.lzma archives under Windows with CPack? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to flip the current frame before it gets drawn?
Hi Alessandro, On 30/12/09 11:32 AM, alessandro terenzi wrote: By the way, what is the general approach to RTT? I had a look at some examples some time ago, but it could be useful to have a guide line here...as far as I remember, RTT requires a camera that sees my scene and that will be used to generate a texture, then I'll need another different camera that actually will be used to render that texture, correct? what the texture will be, in my case that camera will be the one that I'm currently using to render my scene, but then I'll need another different camera that actually will be used to render the previous texture, correct? Yes, that's correct. You need to have two cameras: the scene camera, that is setup like your original camera (view and projection matrices) but renders to a texture instead. Best case you can just take the original camera and change its render target (and detach it from the viewer). The second camera renders (with ortho projection) a simple scene with a quad that displays the generated texture. How about HUDs, if I'm not wrong they also use a different camera so performing RTT on the scene will keep HUDs out, am I wrong? HUDs are usually child nodes of the scene camera so should be rendered without problems. One issue that you might run into are manipulators since they could attempt to modify the second camera instead of the scene camera. HTH, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to flip the current frame before it gets drawn?
Thanks again for your help, I'll try that approach. Kind regards. Alessandro On Wed, Dec 30, 2009 at 11:46 AM, Ulrich Hertlein u.hertl...@sandbox.dewrote: Hi Alessandro, On 30/12/09 11:32 AM, alessandro terenzi wrote: By the way, what is the general approach to RTT? I had a look at some examples some time ago, but it could be useful to have a guide line here...as far as I remember, RTT requires a camera that sees my scene and that will be used to generate a texture, then I'll need another different camera that actually will be used to render that texture, correct? what the texture will be, in my case that camera will be the one that I'm currently using to render my scene, but then I'll need another different camera that actually will be used to render the previous texture, correct? Yes, that's correct. You need to have two cameras: the scene camera, that is setup like your original camera (view and projection matrices) but renders to a texture instead. Best case you can just take the original camera and change its render target (and detach it from the viewer). The second camera renders (with ortho projection) a simple scene with a quad that displays the generated texture. How about HUDs, if I'm not wrong they also use a different camera so performing RTT on the scene will keep HUDs out, am I wrong? HUDs are usually child nodes of the scene camera so should be rendered without problems. One issue that you might run into are manipulators since they could attempt to modify the second camera instead of the scene camera. HTH, /ulrich ___ 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] osgShadow ECEF precision problems
Hi Marius, My congratulations! I am glad you did it. I solved my directional light case. I changed all floats to doubles in * StandardShadowMap::ViewData::aimShadowCastingCamera The code in the above method was based on original ShadowMap code and indeed used floats (I must admit I neglected this method). In the process I also upgraded the polytope class to double (I don't think this is necessary). I can fix the other light type cases (VB/CB/DB) but someone will have to give me a quick walk-through on posting updates to osg so I don't have to do my work twice. osg::Polytope is double based by default as far as I know. Other classes stemming from ViewDependentShadowTechnique inherit and use StandardShadowMap::ViewData::aimShadowCastingCamera method so you have fixed them all in one shot ;-) Can you post your modified StandardShadowMap.cpp ? I am preparing few fixes and I would like to merge my changes with the change you have meade before sending my submissions. Cheers, Wojtek - Original Message - From: Marius Heise mhe...@heise-network.com To: osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 11:04 AM Subject: Re: [osg-users] osgShadow ECEF precision problems Hi Wojtek, The light camera position was calculated as float as was thus jumping around. Of course the change from yesterday using double bounding volumes also has to be activated. Thanks a lot for your support. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21954#21954 ___ 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] Heightfield allocation fails
Hi Isabelle, It seems to be a qmake issue or something similar. I don't know qmake as well as CMake, but are you sure that libs are correctly linked, and that versions of those libs are also correct? You may try adding a gcc option that tells path for lib searching, and/or change libs order on the LIBS += ... line. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Isabelle Gouwy isabelle.go...@gmail.com a écrit : Hi, I'm working under linux, and I'm using qmake to generate the makefile. Maybe it comes from my .pro file because I've tried to comment all the code in my project, except for the heightfield creation and it doesn't work either : I've put my code in main function and commented the rest of my project. If I compile it with the makefile generated by qmake, it doesn't work (my heightfield is 100*0). But if I compile it like that g++ -losg -losgDB main.cpp it works! Here is my .pro file : Code: #Project type TEMPLATE = app #Binary TARGET = map #Sources dir DEPENDPATH += . src src/UI #Includes dirs INCLUDEPATH += src src/AUTOGEN #Where to build DESTDIR += bin #QT additional config CONFIG+= qt opengl stl exceptions warn_on release #QT config QT += core xml gui opengl #DISTFILES DISTFILES += bin/ #Defines DEFINES += #Added libs LIBS += -ldl -lglut -lGLEW -lGLU -lGL -lm -losg -losgDB #Where to build MOCs MOC_DIR = src/AUTOGEN #Where to build .o OBJECTS_DIR = src/.o #Where to build .hpp from .ui UI_DIR = src/AUTOGEN #Where to build .cpp from .qrc RCC_DIR = src/AUTOGEN/RSC/ #Headers HEADERS += Application.hpp \ MainWindow.hpp \ GLWidget.hpp \ Map.hpp \ Camera.hpp \ Particles.hpp \ #UIs FORMS += Ui_MainWindow.ui #Sources SOURCES += main.cpp \ Application.cpp \ MainWindow.cpp \ GLWidget.cpp \ Map.cpp \ Camera.cpp \ Particles.cpp \ I don't understand what's wrong... Thanks a lot Cheers, Isabelle -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21926#21926 ___ 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] [osgPlugins] osgmovie plugin missing?
Hi, Im trying to use it at linux and i follow this steps: 1. Compiled the osg with openscenegraph 2.8.2. I try to load the osgmovie but didnt exists. 2. I've compiled it by hand The same answer that gave to you about the missing plugin has been given. 3. I've installed the quicktime and the ffmpeg and xine-dev everthing possible to install 4. Recompiled the openscenegraph and then the osgart 5. No osgmovie again. I compiled the osgmovie and now: - No error message given but nothing happens. The program is running without doing nothing. I've tried with .mov , with .mpg and with .avi files. Can you help me please? Thanks. Eduardo ... Thank you! Cheers, Eduardo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21963#21963 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VIDEO PLAY mixed with 3D objects
Hi, Im working in linux ubuntu 9.10. I've joined openscenegraph with osgart 2.0 . Im having some problems with the following questions, i hope someone can help me: 1. Compile quicktime plugin I already installed the libquicktime 1.1.13. But when i do the make (followed of the cmake) the openscengraph never compiles the quicktime plugin. What i need to have it compiled? 2. Im using video with the class video lib that is in osgart documentation (tutorial playing a video). The problem is that it only appears a black rectangule and never the video. 3. When i use the following code the objects (instead of load the own textures) keeps black: Code: osg::MatrixTransform* scaleTrans = new osg::MatrixTransform(osg::Matrix::scale(5, 5, 5)); scaleTrans -addChild(osgDB::readNodeFile(../objects/garrafa.3ds)); arTransform-addChild(scaleTrans); It loads the object but with a black texture. I confirmed and the files (.jpg) correspondent to the textures are there. 4. Openscenegraph never compiles the osgmovie I've compiled by hand but i still cannot load any video. Not because the fail of the plugin. It just keep running the program but without doing nothing. Anyone can help me? Thanks. By the way, does openscenegraph works with chromakey? Thanks one more time. ... Thank you! Cheers, Eduardo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21945#21945 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)
Hi all, Is there an endianess problem with DDS format? I'm using a Core2Duo here and I don't know under which kind of machine the DDS has been tested... A little explanation: After a bit of investigation (=cleaning stupid copy-paste), I found that the only true bug I had was Changing R, G or B writer's masks doesn't seem to affect reading in 3rd-party readers. Has anybody encountered this before? Writing DDS: It seems the DDS must be BGR in order to make 3rd-party readers work correctly (by inverting R and B channels). Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools are marked RGB but are BGR... Please help and share your experience! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi Robert and all, I'm lost: - Changing R, G or B writer's masks doesn't seem to affect reading (either the plugin or 3rd-party readers, except when masks are completely nonsense) - Copying the image (DEEP_COPY) and writing the copy instead of the oringinal result in a vertical flip of the image in the file! - Manually inverting R B channels in a copy of the image doesn't do anything... I must have a very stupid mistake somewhere but I can't fugure out where... Any idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, I'm not overly familiar with the dds plugin, but what you describe sounds like a bug in writer in our dds plugin. Robert. On Fri, Dec 18, 2009 at 5:15 PM, Sukender suky0...@free.fr wrote: Hi all, It was discussed a long time ago but I dit not find an answer. Saving to DDS an uncompressed RGB image and then loading from the file works: the loaded image is the same as the original. However, the file is BGR (R and B inverted). I tried three 3rd-party tools (image viewer/converters) and all display the same. Do you think this is a bug in DDS readerwriter? Anyone has a clue about it? Thanks a lot. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] embedded flash problems in browser
Hi, Can you please help me on this? I've made a small example in my linux plataform with osg 2.0 and openscenegrah. Now i want to export it to web. How can i do that? I want that normal users can check my page and can enjoy my experience. How can i make this possbile? Thanks. ... Thank you! Cheers, Eduardo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21967#21967 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Rendering 3DS objects with bump maps
Hello mpai, Did you solve it? How can i render a 3D studio max in openscenegraph? Thanks. ... Thank you! Cheers, Eduardo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21968#21968 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Wojtek, :-) will do. Since I am currently on osg 2.9.5 I will switch to trunk and check if the double modifications only in StandardShadowMap.cpp are enough to solve the problem I had. If this is the case, I will send you the svn patch for osg trunk. My 2.9.5 is too dirty and old that I can send you that patch. Will let you know as soon as I've done it Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21969#21969 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)
Hi, I had some experience with D3D in the past maybe could help clear a picture a little. Basic 32 bit color format using in Directx is named in Direct 3D: D3DFMT_A8R8G8B8. Components are enumerated from most significant byte to least significant byte. Such pixel value is usually set by using single DWORD. for example DWORD color = 0xAA112233 coresponds to following bytes alpha = 0xAA red = 0x11 green = 0x22 blue = 0x33. As I said earlier, this is an order byte significance, not an order of bytes in memory. When you write this dword to memory they will land in following order on Intel (big endian CPUs) [Blue][Red][Green][Alpha]. So in OpenGL notation it would be GL_BGRA. Hope this explains a bit. Hence basic Directx ARGB format should be read as OpenGL BGRA. To switch to more intuitive OpenGL RGBA you apparently have to swap R and B bytes. However, DDS format is capable of storing all variants of 32 bit color layouts. RGBA, BGRA, ABGR, ARGB. As far as I remember only color component bitmasks should be changed accordingly to select proper variant. If your tools do not read them correctly this is most probably an issue with those tools. I am sure OSG DDS ReaderWiriter is not saint here as well. Cheers, Wojtek - Original Message - From: Sukender suky0...@free.fr To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 1:22 PM Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A) Hi all, Is there an endianess problem with DDS format? I'm using a Core2Duo here and I don't know under which kind of machine the DDS has been tested... A little explanation: After a bit of investigation (=cleaning stupid copy-paste), I found that the only true bug I had was Changing R, G or B writer's masks doesn't seem to affect reading in 3rd-party readers. Has anybody encountered this before? Writing DDS: It seems the DDS must be BGR in order to make 3rd-party readers work correctly (by inverting R and B channels). Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools are marked RGB but are BGR... Please help and share your experience! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi Robert and all, I'm lost: - Changing R, G or B writer's masks doesn't seem to affect reading (either the plugin or 3rd-party readers, except when masks are completely nonsense) - Copying the image (DEEP_COPY) and writing the copy instead of the oringinal result in a vertical flip of the image in the file! - Manually inverting R B channels in a copy of the image doesn't do anything... I must have a very stupid mistake somewhere but I can't fugure out where... Any idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, I'm not overly familiar with the dds plugin, but what you describe sounds like a bug in writer in our dds plugin. Robert. On Fri, Dec 18, 2009 at 5:15 PM, Sukender suky0...@free.fr wrote: Hi all, It was discussed a long time ago but I dit not find an answer. Saving to DDS an uncompressed RGB image and then loading from the file works: the loaded image is the same as the original. However, the file is BGR (R and B inverted). I tried three 3rd-party tools (image viewer/converters) and all display the same. Do you think this is a bug in DDS readerwriter? Anyone has a clue about it? Thanks a lot. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Marius, Current trunk version does not draw debug volumes, don't be surprised not seeing them. Its a problem outside of the osgShadow related to changes in COLOR_PER_PRIMITIVE handling. Cheers, Wojtek - Original Message - From: Marius Heise mhe...@heise-network.com To: osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 1:37 PM Subject: Re: [osg-users] osgShadow ECEF precision problems Hi Wojtek, :-) will do. Since I am currently on osg 2.9.5 I will switch to trunk and check if the double modifications only in StandardShadowMap.cpp are enough to solve the problem I had. If this is the case, I will send you the svn patch for osg trunk. My 2.9.5 is too dirty and old that I can send you that patch. Will let you know as soon as I've done it Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21969#21969 ___ 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] DDS uncompressed RGB(A) / BGR(A)
Oops sorry small correction: Intel is little endian. I always confuse these names. I prefer using Least Significant Byte First and Most Significant Byte First to describe the CPU archtecture. Wojtek - Original Message - From: Wojciech Lewandowski lewandow...@ai.com.pl To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 1:57 PM Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A) Hi, I had some experience with D3D in the past maybe could help clear a picture a little. Basic 32 bit color format using in Directx is named in Direct 3D: D3DFMT_A8R8G8B8. Components are enumerated from most significant byte to least significant byte. Such pixel value is usually set by using single DWORD. for example DWORD color = 0xAA112233 coresponds to following bytes alpha = 0xAA red = 0x11 green = 0x22 blue = 0x33. As I said earlier, this is an order byte significance, not an order of bytes in memory. When you write this dword to memory they will land in following order on Intel (big endian CPUs) [Blue][Red][Green][Alpha]. So in OpenGL notation it would be GL_BGRA. Hope this explains a bit. Hence basic Directx ARGB format should be read as OpenGL BGRA. To switch to more intuitive OpenGL RGBA you apparently have to swap R and B bytes. However, DDS format is capable of storing all variants of 32 bit color layouts. RGBA, BGRA, ABGR, ARGB. As far as I remember only color component bitmasks should be changed accordingly to select proper variant. If your tools do not read them correctly this is most probably an issue with those tools. I am sure OSG DDS ReaderWiriter is not saint here as well. Cheers, Wojtek - Original Message - From: Sukender suky0...@free.fr To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 1:22 PM Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A) Hi all, Is there an endianess problem with DDS format? I'm using a Core2Duo here and I don't know under which kind of machine the DDS has been tested... A little explanation: After a bit of investigation (=cleaning stupid copy-paste), I found that the only true bug I had was Changing R, G or B writer's masks doesn't seem to affect reading in 3rd-party readers. Has anybody encountered this before? Writing DDS: It seems the DDS must be BGR in order to make 3rd-party readers work correctly (by inverting R and B channels). Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools are marked RGB but are BGR... Please help and share your experience! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi Robert and all, I'm lost: - Changing R, G or B writer's masks doesn't seem to affect reading (either the plugin or 3rd-party readers, except when masks are completely nonsense) - Copying the image (DEEP_COPY) and writing the copy instead of the oringinal result in a vertical flip of the image in the file! - Manually inverting R B channels in a copy of the image doesn't do anything... I must have a very stupid mistake somewhere but I can't fugure out where... Any idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, I'm not overly familiar with the dds plugin, but what you describe sounds like a bug in writer in our dds plugin. Robert. On Fri, Dec 18, 2009 at 5:15 PM, Sukender suky0...@free.fr wrote: Hi all, It was discussed a long time ago but I dit not find an answer. Saving to DDS an uncompressed RGB image and then loading from the file works: the loaded image is the same as the original. However, the file is BGR (R and B inverted). I tried three 3rd-party tools (image viewer/converters) and all display the same. Do you think this is a bug in DDS readerwriter? Anyone has a clue about it? Thanks a lot. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Coordinate system in all readerwriters
Hi all, Defining a coordinate system for OSG is a good idea. Though to me the most important aspect of reader and writers, is that this expression must be true: read( write( A ) ) = A Rizzen Sukender wrote: Hi Ulrich, Paul, and all, I agree we should unify the coordinate system during loading AND writing. Here are my suggestions : - Have plugins do NO rotation by default (reading and writing) when the format doesn't have coordinate system information (that is to say all but FBX and maybe FLT). - Have plugins read and apply coordinate system information if available by default when reading. - Have optionnal READING options: - readXup, readYup, readZup to suppose model is X, Y or Z-up (overrides format's coordinate system information) - readLeftHanded, readRightHanded (similar setting) - When in conflict (two options defined), use the latest one - Have optionnal WRITING options: - writeXup, writeYup, writeZup, writeLeftHanded, writeRightHanded (which should almost never be supported, in my opinion) - Let plugings optionnally support these options prefixed with their name and _. For instance 3ds_readYup would assume ONLY .3ds files are Y-up. These would take precedence over the general settings. - Also support pluginName_read/writeAutoUp and pluginName_read/writeAutoHanded, which would specifically deactivate a global setting for a given plugin. For instance, fbx_readAutoUp would let the plugin decide the up vector (here using coordinate system information in the .fbx). 3ds_readAutoUp would mean no rotation for .3ds. - Write a portion of code somewhere in osgDB to parse all these options and store it in a nice structure (to avoid each plugin duplicating code). To be called with something like myStructure = osgDB::readStandardCoordinateSystemOptions(PLUGIN_NAME). - As OpenGL doesn't have a etched in stone orientation standard, use the osgGA as an internal standard (that is to say +Z up, right handed) when a change is needed. 1. Please raise your hand if you agree, and tell about changes you'd like to introduce in this summary. 2a. Please mention all plugins you know which break these rules. 2b. Please tell if you agree modifying those plugins. When all is ok, I'll code it. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Ulrich Hertlein u.hertl...@sandbox.de a écrit : On 29/12/09 6:52 PM, Paul Martz wrote: Paul Martz wrote: I've noticed the same thing with OBJ. A little digging reveals that the OBJ plugin has a noRotation Option that disables the x axis rotation. The rotation is only done on file load, not on file write. Rotation about x is on by default. I'd suggest a change to off by default, and the Option changed to doRotation to enable it. The .x plugin has 'leftHanded' and 'rightHanded'. Maybe we could establish a common option for this type of functionality (one that does 'convert to right-handed, Z-axis up'). There already are options with (apparently) related functionality (courtesy of 'osgconv --formats'): Coordinate system: obj:noRotation x:leftHanded x:rightHanded Optimization: obj:generateFacetNormals obj:noTriStripPolygons stl:generateNormals stl:smooth stl:tristrip Image orientation hdr:NO_YFLIP hdr:YFLIP x:flipTexture Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Wojtek, small difference big change :-). Shadow is rock solid now. I only thoroughly tested the directional lighting but it should work for the other cases too. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21974#21974 Attachments: http://forum.openscenegraph.org//files/standardshadowmapcpppatch_180.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] gl_FrontMaterial deprecated?
On 30/12/09 11:33 AM, Ulrich Hertlein wrote: When I try to use gl_FrontMaterial.ambient, .diffuse, .shininess, etc. in the vert/frag shaders I'm getting silly values (e.g. negative for shininess) that don't correspond to what I set in osg::Material. (But I'm not getting errors either.) Please disregard this, the model was using vertex colours so my osg::Material was ignored. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HUD-Problem
Hi, ok tanks for your answer. I think it wasn't the font dll because the geometry also wasn't drawn. But for the future I know to use the latest developer release. I wish you all a good silversterparty. Thank you! Cheers, Carl -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21981#21981 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)
Hi Wojciech, About 3rd party tools, I've tested XNView, The Compressonator (AMD) and DeepExploration, and all seem to ignore the R, G, B masks... Or there is a mistake somewhere in OSG DDS writing that make those masks unreadable... or else I made a mistake somewhere! I'm a bit lost now... What's next? Should we change something according to endianness (if little endian, swap RB when reading and writing)? If you got any idea there... ;) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Wojciech Lewandowski lewandow...@ai.com.pl a écrit : Hi, I had some experience with D3D in the past maybe could help clear a picture a little. Basic 32 bit color format using in Directx is named in Direct 3D: D3DFMT_A8R8G8B8. Components are enumerated from most significant byte to least significant byte. Such pixel value is usually set by using single DWORD. for example DWORD color = 0xAA112233 coresponds to following bytes alpha = 0xAA red = 0x11 green = 0x22 blue = 0x33. As I said earlier, this is an order byte significance, not an order of bytes in memory. When you write this dword to memory they will land in following order on Intel (big endian CPUs) [Blue][Red][Green][Alpha]. So in OpenGL notation it would be GL_BGRA. Hope this explains a bit. Hence basic Directx ARGB format should be read as OpenGL BGRA. To switch to more intuitive OpenGL RGBA you apparently have to swap R and B bytes. However, DDS format is capable of storing all variants of 32 bit color layouts. RGBA, BGRA, ABGR, ARGB. As far as I remember only color component bitmasks should be changed accordingly to select proper variant. If your tools do not read them correctly this is most probably an issue with those tools. I am sure OSG DDS ReaderWiriter is not saint here as well. Cheers, Wojtek - Original Message - From: Sukender suky0...@free.fr To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 1:22 PM Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A) Hi all, Is there an endianess problem with DDS format? I'm using a Core2Duo here and I don't know under which kind of machine the DDS has been tested... A little explanation: After a bit of investigation (=cleaning stupid copy-paste), I found that the only true bug I had was Changing R, G or B writer's masks doesn't seem to affect reading in 3rd-party readers. Has anybody encountered this before? Writing DDS: It seems the DDS must be BGR in order to make 3rd-party readers work correctly (by inverting R and B channels). Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools are marked RGB but are BGR... Please help and share your experience! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi Robert and all, I'm lost: - Changing R, G or B writer's masks doesn't seem to affect reading (either the plugin or 3rd-party readers, except when masks are completely nonsense) - Copying the image (DEEP_COPY) and writing the copy instead of the oringinal result in a vertical flip of the image in the file! - Manually inverting R B channels in a copy of the image doesn't do anything... I must have a very stupid mistake somewhere but I can't fugure out where... Any idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, I'm not overly familiar with the dds plugin, but what you describe sounds like a bug in writer in our dds plugin. Robert. On Fri, Dec 18, 2009 at 5:15 PM, Sukender suky0...@free.fr wrote: Hi all, It was discussed a long time ago but I dit not find an answer. Saving to DDS an uncompressed RGB image and then loading from the file works: the loaded image is the same as the original. However, the file is BGR (R and B inverted). I tried three 3rd-party tools (image viewer/converters) and all display the same. Do you think this is a bug in DDS readerwriter? Anyone has a clue about it? Thanks a lot. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinate system in all readerwriters
Hi Rizzen, Of course! I forgot to add this to the summary. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Rizzen riz...@darkstar.co.za a écrit : Hi all, Defining a coordinate system for OSG is a good idea. Though to me the most important aspect of reader and writers, is that this expression must be true: read( write( A ) ) = A Rizzen Sukender wrote: Hi Ulrich, Paul, and all, I agree we should unify the coordinate system during loading AND writing. Here are my suggestions : - Have plugins do NO rotation by default (reading and writing) when the format doesn't have coordinate system information (that is to say all but FBX and maybe FLT). - Have plugins read and apply coordinate system information if available by default when reading. - Have optionnal READING options: - readXup, readYup, readZup to suppose model is X, Y or Z-up (overrides format's coordinate system information) - readLeftHanded, readRightHanded (similar setting) - When in conflict (two options defined), use the latest one - Have optionnal WRITING options: - writeXup, writeYup, writeZup, writeLeftHanded, writeRightHanded (which should almost never be supported, in my opinion) - Let plugings optionnally support these options prefixed with their name and _. For instance 3ds_readYup would assume ONLY .3ds files are Y-up. These would take precedence over the general settings. - Also support pluginName_read/writeAutoUp and pluginName_read/writeAutoHanded, which would specifically deactivate a global setting for a given plugin. For instance, fbx_readAutoUp would let the plugin decide the up vector (here using coordinate system information in the .fbx). 3ds_readAutoUp would mean no rotation for .3ds. - Write a portion of code somewhere in osgDB to parse all these options and store it in a nice structure (to avoid each plugin duplicating code). To be called with something like myStructure = osgDB::readStandardCoordinateSystemOptions(PLUGIN_NAME). - As OpenGL doesn't have a etched in stone orientation standard, use the osgGA as an internal standard (that is to say +Z up, right handed) when a change is needed. 1. Please raise your hand if you agree, and tell about changes you'd like to introduce in this summary. 2a. Please mention all plugins you know which break these rules. 2b. Please tell if you agree modifying those plugins. When all is ok, I'll code it. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Ulrich Hertlein u.hertl...@sandbox.de a écrit : On 29/12/09 6:52 PM, Paul Martz wrote: Paul Martz wrote: I've noticed the same thing with OBJ. A little digging reveals that the OBJ plugin has a noRotation Option that disables the x axis rotation. The rotation is only done on file load, not on file write. Rotation about x is on by default. I'd suggest a change to off by default, and the Option changed to doRotation to enable it. The .x plugin has 'leftHanded' and 'rightHanded'. Maybe we could establish a common option for this type of functionality (one that does 'convert to right-handed, Z-axis up'). There already are options with (apparently) related functionality (courtesy of 'osgconv --formats'): Coordinate system: obj:noRotation x:leftHanded x:rightHanded Optimization: obj:generateFacetNormals obj:noTriStripPolygons stl:generateNormals stl:smooth stl:tristrip Image orientation hdr:NO_YFLIP hdr:YFLIP x:flipTexture Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinate system in all readerwriters
Hi all, On 30/12/09 11:35 AM, Sukender wrote: - Have plugins do NO rotation by default (reading and writing) when the format doesn't have coordinate system information (that is to say all but FBX and maybe FLT). - Have plugins read and apply coordinate system information if available by default when reading. - Have optionnal READING options: - readXup, readYup, readZup to suppose model is X, Y or Z-up (overrides format's coordinate system information) - readLeftHanded, readRightHanded (similar setting) - When in conflict (two options defined), use the latest one - Have optionnal WRITING options: - writeXup, writeYup, writeZup, writeLeftHanded, writeRightHanded (which should almost never be supported, in my opinion) - Let plugings optionnally support these options prefixed with their name and _. For instance 3ds_readYup would assume ONLY .3ds files are Y-up. These would take precedence over the general settings. - Also support pluginName_read/writeAutoUp and pluginName_read/writeAutoHanded, which would specifically deactivate a global setting for a given plugin. For instance, Do we really want all those options? At the moment we only have: - rotate around X-axis (for Y-up to Z-up conversion) and - convert left- to right-hand CS While I agree that plugins could leave the orientation alone I still think that they should do the conversion to a right-handed coordinate system by default, because the default OpenGL face-winding is right handed. Additionally, how would the applied transformation be transmitted to the writer? If this were to be stored with the loaded node then it could be automatically be undone by the writer. Another possibility might be to just create a transformation node above the unmodified model. The transformation node could do all the necessary scaling/rotation (and FrontFace); this could simply be ignored when writing. The downside of this is that it doesn't integrate nicely and might be a performance penalty. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)
Hi , Sorry, I have not followed all the posts in this thread. I am not sure what is the essence of your problem: Are you saying that 24 bit GL_RGB image written by OSG and later read by OSG looks differently ? Or there is an issue with reading 24 bit color images written by 3rd party tools ? What about 32 bit images ? Are they OK ? About 3rd party tools, I've tested XNView, The Compressonator (AMD) and DeepExploration, and all seem to ignore the R, G, B masks... Or there is a mistake somewhere in OSG DDS writing that make those masks unreadable... or else I made a mistake somewhere! I always recommend peeking into heart of darkness ;-) and trying MS DXTextureTool (installed with DirectX SDK) I just checked, the only 24 bit format that OSG DDS Writer currently writes is GL_RGB. (GL_BGR is not written but could be added quickly is guess). But its capable to read both GL_RGB and GL_BGR. Can you post such 24 bit RGB DDS image that looks differently in OSG and in 3rd party tools ? Wojtek - Original Message - From: Sukender suky0...@free.fr To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 3:09 PM Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A) Hi Wojciech, I'm a bit lost now... What's next? Should we change something according to endianness (if little endian, swap RB when reading and writing)? If you got any idea there... ;) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Wojciech Lewandowski lewandow...@ai.com.pl a écrit : Hi, I had some experience with D3D in the past maybe could help clear a picture a little. Basic 32 bit color format using in Directx is named in Direct 3D: D3DFMT_A8R8G8B8. Components are enumerated from most significant byte to least significant byte. Such pixel value is usually set by using single DWORD. for example DWORD color = 0xAA112233 coresponds to following bytes alpha = 0xAA red = 0x11 green = 0x22 blue = 0x33. As I said earlier, this is an order byte significance, not an order of bytes in memory. When you write this dword to memory they will land in following order on Intel (big endian CPUs) [Blue][Red][Green][Alpha]. So in OpenGL notation it would be GL_BGRA. Hope this explains a bit. Hence basic Directx ARGB format should be read as OpenGL BGRA. To switch to more intuitive OpenGL RGBA you apparently have to swap R and B bytes. However, DDS format is capable of storing all variants of 32 bit color layouts. RGBA, BGRA, ABGR, ARGB. As far as I remember only color component bitmasks should be changed accordingly to select proper variant. If your tools do not read them correctly this is most probably an issue with those tools. I am sure OSG DDS ReaderWiriter is not saint here as well. Cheers, Wojtek - Original Message - From: Sukender suky0...@free.fr To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 1:22 PM Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A) Hi all, Is there an endianess problem with DDS format? I'm using a Core2Duo here and I don't know under which kind of machine the DDS has been tested... A little explanation: After a bit of investigation (=cleaning stupid copy-paste), I found that the only true bug I had was Changing R, G or B writer's masks doesn't seem to affect reading in 3rd-party readers. Has anybody encountered this before? Writing DDS: It seems the DDS must be BGR in order to make 3rd-party readers work correctly (by inverting R and B channels). Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools are marked RGB but are BGR... Please help and share your experience! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sukender suky0...@free.fr a écrit : Hi Robert and all, I'm lost: - Changing R, G or B writer's masks doesn't seem to affect reading (either the plugin or 3rd-party readers, except when masks are completely nonsense) - Copying the image (DEEP_COPY) and writing the copy instead of the oringinal result in a vertical flip of the image in the file! - Manually inverting R B channels in a copy of the image doesn't do anything... I must have a very stupid mistake somewhere but I can't fugure out where... Any idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, I'm not overly familiar with the dds plugin, but what you describe sounds like a bug in writer in our dds plugin. Robert. On Fri, Dec 18, 2009 at 5:15 PM, Sukender suky0...@free.fr wrote: Hi all, It was discussed a long time ago but I dit not find an answer. Saving to DDS an uncompressed RGB image and then loading from the file works: the loaded image is the same as the original. However, the file is BGR (R and B inverted). I
[osg-users] Color fill a primitiveSet
Hi, I have created a triangle with, where a,b and c are the (x,y,z) coordinates of the 3 vertices osg::ref_ptrosg::Geometry geom = new osg::Geometry; osg::ref_ptrosg::Vec3Array v = new osg::Vec3Array; geom-setVertexArray( v.get() ); v-push_back(a); v-push_back(b); v-push_back(c); geom-addPrimitiveSet(new osg::DrawArrays( osg::PrimitiveSet::TRIANGLES, 0, 3 ) ); osg::ref_ptrosg::Geode geode = new osg::Geode; geode-addDrawable( geom.get() ); root-addChild(geode.get()); Could you tell me how i can color fill the inside of the triangle so it will be a green triangle. Thank you! Cheers, Jody -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21986#21986 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Animations in OSG
Hi there what is the best way to animate osg node. At the moment I'm using the QTimer of Qt to transform the object. Is there a better / more efficent way to animate object in OSG? Thanks and best regards Dominic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinate system in all readerwriters
Hi ulrich, As Paul said, OpenGL doesn't have any convention. It's just a common usage that tell us we should use right-handed. However, I agree the number of proposed options could be reduced (I just fear that it may become less explicit... or not?). Your reflexion make me think we should merge read and write options. That way, we may have the two options you mentionned, and writing would the do the opposite operation. We thus keep write(read(A)) == A. Is that okay for you? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Ulrich Hertlein u.hertl...@sandbox.de a écrit : Hi all, On 30/12/09 11:35 AM, Sukender wrote: - Have plugins do NO rotation by default (reading and writing) when the format doesn't have coordinate system information (that is to say all but FBX and maybe FLT). - Have plugins read and apply coordinate system information if available by default when reading. - Have optionnal READING options: - readXup, readYup, readZup to suppose model is X, Y or Z-up (overrides format's coordinate system information) - readLeftHanded, readRightHanded (similar setting) - When in conflict (two options defined), use the latest one - Have optionnal WRITING options: - writeXup, writeYup, writeZup, writeLeftHanded, writeRightHanded (which should almost never be supported, in my opinion) - Let plugings optionnally support these options prefixed with their name and _. For instance 3ds_readYup would assume ONLY .3ds files are Y-up. These would take precedence over the general settings. - Also support pluginName_read/writeAutoUp and pluginName_read/writeAutoHanded, which would specifically deactivate a global setting for a given plugin. For instance, Do we really want all those options? At the moment we only have: - rotate around X-axis (for Y-up to Z-up conversion) and - convert left- to right-hand CS While I agree that plugins could leave the orientation alone I still think that they should do the conversion to a right-handed coordinate system by default, because the default OpenGL face-winding is right handed. Additionally, how would the applied transformation be transmitted to the writer? If this were to be stored with the loaded node then it could be automatically be undone by the writer. Another possibility might be to just create a transformation node above the unmodified model. The transformation node could do all the necessary scaling/rotation (and FrontFace); this could simply be ignored when writing. The downside of this is that it doesn't integrate nicely and might be a performance penalty. Cheers, /ulrich ___ 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] Animations in OSG
Hi Dominic, You can use AnimationPath with AnimationPathCallback or the other is osgAnimation stuff. You can check in examples directory to have a better idea how to use it, and what you can do with it. Cheers, Cedric -- Provide OpenGL services around OpenSceneGraph and more +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net On Wed, 2009-12-30 at 17:12 +0100, Dominic Stalder wrote: Hi there what is the best way to animate osg node. At the moment I'm using the QTimer of Qt to transform the object. Is there a better / more efficent way to animate object in OSG? Thanks and best regards Dominic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Animations in OSG
On 12/30/2009 9:12 AM, Dominic Stalder wrote: what is the best way to animate osg node. At the moment I'm using the QTimer of Qt to transform the object. Is there a better / more efficent way to animate object in OSG? If you want to avoid Qt, you can use an update callback on the Transform node. The update callback can check the current time and alter the transform. Also, look at the osganimate example. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VIDEO PLAY mixed with 3D objects
Hi, Am 29.12.09 19:51, schrieb Eduardo Pinheiro: Im working in linux ubuntu 9.10. I've joined openscenegraph with osgart 2.0 . Im having some problems with the following questions, i hope someone can help me: 1. Compile quicktime plugin I already installed the libquicktime 1.1.13. But when i do the make (followed of the cmake) the openscengraph never compiles the quicktime plugin. What i need to have it compiled? the quicktime-plugin of osg is currently only supported for OS X / Windows. Try the ffmpeg-plugin for linux, should be part of 2.9.x cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] gl_FrontMaterial deprecated?
Ulrich Hertlein wrote: On 30/12/09 11:33 AM, Ulrich Hertlein wrote: When I try to use gl_FrontMaterial.ambient, .diffuse, .shininess, etc. in the vert/frag shaders I'm getting silly values (e.g. negative for shininess) that don't correspond to what I set in osg::Material. (But I'm not getting errors either.) Please disregard this, the model was using vertex colours so my osg::Material was ignored. Cheers, /ulrich Okay, that makes sense. Just for the archives, yes, material colors (and all FFP lighting state) are deprecated in GL3. But they should still work. In GL3.1 and forward, they are removed and will not work. You should get GL_INVALID_OPERATION if you try to set them on the host. I don't think the shader variables are removed in GLSL, just deprecated, so using them in shaders should just generate shader compile warnings with GLSL 1.30 and forward. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinate system in all readerwriters
To simplify things, I'd propose the following: - I don't think we need options to control writing. Your app can do any required transformation with a NodeVisitor before calling osgDB to write. The plugin should just write the scene graph passed to it. - For reading, we just need rotation and scale options. rotate axis degrees and scale x y z. Those alone will handle changes to orientation, handedness, and unit scaling. - If the format stores an up vector, handedness, and unit information, then the import plugins for those few formats need some kind of convertTo option, sort of like FLT's convertToMeters (which scales the model from its native units). As an addendum to the last point, regarding Ulrich's comment, an import plugin can only convert to right-handed if it knows the handedness of the model. Which formats store that information? And to clarify, OpenGL's right-handed rule is only the default for the definition of a front face. Your application and your models may or may not use this convention, and I think it would be wrong for a plugin to do such a conversion automatically, assuming it knows something about the convention you are using. Finally, in principle, I agree: write( read( A ) ) should equal A. But I want to re-emphasize this can only be true in the context of coordinate systems. (100% equality in round-trip model conversions is essentially an impossibility.) Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Color fill a primitiveSet
HI Jody See [OpenSceneGraph]\examples\osggeometry\ __ Gordon Tomlinson gor...@gordontomlinson.com IM: gordon3db...@3dscenegraph.com www.vis-sim.com www.gordontomlinson.com www.PhotographyByGordon.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jody Cole Sent: Wednesday, December 30, 2009 4:02 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Color fill a primitiveSet Hi, I have created a triangle with, where a,b and c are the (x,y,z) coordinates of the 3 vertices osg::ref_ptrosg::Geometry geom = new osg::Geometry; osg::ref_ptrosg::Vec3Array v = new osg::Vec3Array; geom-setVertexArray( v.get() ); v-push_back(a); v-push_back(b); v-push_back(c); geom-addPrimitiveSet(new osg::DrawArrays( osg::PrimitiveSet::TRIANGLES, 0, 3 ) ); osg::ref_ptrosg::Geode geode = new osg::Geode; geode-addDrawable( geom.get() ); root-addChild(geode.get()); Could you tell me how i can color fill the inside of the triangle so it will be a green triangle. Thank you! Cheers, Jody -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21986#21986 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rotation 2 DOF node with 2 Different Matrix.
Hi All, I have a problem about rotating one MatrixTransform node with 2 different Matrix which one of responsible for rotation on X by osg::X_AXIS and one of responsible for rotatin by osg::Y_AXIS. I have done some rotation to MT node but after this operations I am waiting to get Identity matrix for MT which has Identity matrix in initial state. Some psudo codes; - // Initial states osg::MatrixTransform* MT; MT-setMatrix( osg::Matrix::identity() ); osg::Matrix ang1 = osg::Matrix::identity(); osg::Matrix ang2 = osg::Matrix::identity(); // Updates done with this codes ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(10.0f), osg::X_AXIS))); ang2.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(10.0f), osg::Y_AXIS))); MT-setMatrix(ang2 * ang1); - if I rotate my MT by above code; model rotated on Y by localCoordinate axis and rotated on X fixedCoordinate axis. But I wanted to rotate on X local coordınate axis too. If I use one matrix to update rotation; - // Initial states osg::MatrixTransform* MT; MT-setMatrix( osg::Matrix::identity() ); osg::Matrix ang1 = osg::Matrix::identity(); // Updates done with this codes ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(10.0f), osg::X_AXIS))); ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(10.0f), osg::Y_AXIS))); ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(-10.0f), osg::X_AXIS))); ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(-10.0f), osg::Y_AXIS))); MT-setMatrix(ang1); - With above code I can rotate my model X and Y local coordinate axis. But this code has lack too. After apply positive and negative way rotation I am waiting to get IdentityMatrix but after all rotation operation my MT-getMatrix() give me different from IdentityMatrix. I think I should use inverse matrix instead of negative direction rotated matrix to rotate -X or -Y direction. Could it solve my problem or not? By these 2 rotation operations my main goal is that; I want to rotate MT by X and Y local coordinate system. And after all rotations I can get initial state of MT. I mean I apply to many rotation transformation to my unique node and after all dual(for X and -X or for y and -Y with unordered queue) operation I want to get first initial matrix for my MT node. I know this is not hard operations, but I am unstable about choosing which one is right way. I appreciate any comments. Regards. Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rotation 2 DOF node with 2 Different Matrix.
I would store the x and y rotations as separate variables. Use them to compute a single Matrix when you need to update. Test for identity by checking to see if your x and y variables fall within an epsilon range of zero. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 Ümit Uzun wrote: Hi All, I have a problem about rotating one MatrixTransform node with 2 different Matrix which one of responsible for rotation on X by osg::X_AXIS and one of responsible for rotatin by osg::Y_AXIS. I have done some rotation to MT node but after this operations I am waiting to get Identity matrix for MT which has Identity matrix in initial state. Some psudo codes; - // Initial states osg::MatrixTransform* MT; MT-setMatrix( osg::Matrix::identity() ); osg::Matrix ang1 = osg::Matrix::identity(); osg::Matrix ang2 = osg::Matrix::identity(); // Updates done with this codes ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(10.0f), osg::X_AXIS))); ang2.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(10.0f), osg::Y_AXIS))); MT-setMatrix(ang2 * ang1); - if I rotate my MT by above code; model rotated on Y by localCoordinate axis and rotated on X fixedCoordinate axis. But I wanted to rotate on X local coordınate axis too. If I use one matrix to update rotation; - // Initial states osg::MatrixTransform* MT; MT-setMatrix( osg::Matrix::identity() ); osg::Matrix ang1 = osg::Matrix::identity(); // Updates done with this codes ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(10.0f), osg::X_AXIS))); ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(10.0f), osg::Y_AXIS))); ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(-10.0f), osg::X_AXIS))); ang1.preMult(osg::Matrix::rotate(osg::Quat(osg::DegreesToRadians(-10.0f), osg::Y_AXIS))); MT-setMatrix(ang1); - With above code I can rotate my model X and Y local coordinate axis. But this code has lack too. After apply positive and negative way rotation I am waiting to get IdentityMatrix but after all rotation operation my MT-getMatrix() give me different from IdentityMatrix. I think I should use inverse matrix instead of negative direction rotated matrix to rotate -X or -Y direction. Could it solve my problem or not? By these 2 rotation operations my main goal is that; I want to rotate MT by X and Y local coordinate system. And after all rotations I can get initial state of MT. I mean I apply to many rotation transformation to my unique node and after all dual(for X and -X or for y and -Y with unordered queue) operation I want to get first initial matrix for my MT node. I know this is not hard operations, but I am unstable about choosing which one is right way. I appreciate any comments. Regards. Ümit Uzun ___ 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] LightPointNode culling
Thanks, Nick. I tried this out and it does work around the issue, and so far I haven't seen a significant performance hit. This is clearly a bug, though. The lights in the .osg file are set to have a minimum 3 pixel size (I have no idea if this means 3 pixel radius, 3 pixel diameter, or what), but even if I set the small feature culling size to 1 pixel they get culled out. That strongly indicates that the culling algorithm is using the bounding sphere to decide how many pixels the geometry will have, and in this case that's just wrong. I'd like to suggest a fix, but I'm just not familiar enough with the culling code to do that. I hope someone more experienced can take a look at it. Max On Mon, Dec 28, 2009 at 4:33 PM, Trajce Nikolov nikolov.tra...@gmail.com wrote: Hi, I did quick test here. You should disable small feature culling. Have a look at viewer.getCamera()-setCullingMode(osg::CullSettings:: Nick http://www.linkedin.com/in/tnick Sent from Ünalan, İstanbul, Turkey On Mon, Dec 28, 2009 at 11:08 PM, Max Bandazian mbandaz...@gmail.com wrote: Hi, I'm having some trouble with the culling of an osgSim::LightPointNode. They seem to be getting culled out at some arbitrary distance, although I could also be misinterpreting what the class is supposed to do (the header is almost entirely uncommented, so...) The attached .osg file has one triangle and one light point. I'd expect that the lightpoint stays visible until it's either behind the far clipping plane or the eyepoint is more than sqrt(maxVisibleDistance2) away, but in reality it stops getting drawn when the eyepoint is ~1500 away. I'm testing in osgviewer, with version 2.8.2. Is this somehow the correct behavior, or is there a bug in the culling? Thanks, Max Bandazian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] New ffmpeg plugin checked into svn/trunk
Robert Osfield wrote: I was thinking that an OpenAL plugin would be doable, and could either return an audio sink or an AudioStream. ... I'm going to experiment with OpenAL at this end how things go. I see that osgmovie currently uses SDL for audio playback. Is there still interest in using straight OpenAL to play the audio streamed from FFMEPG? Thanks, Michael Day -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21998#21998 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Need OSG BOF organizer
Hi, FWIW bear in mind the OpenGL BOF is traditionally Wednesday eve, so the coveted Wed morning slots go quickly :-) cheers -- mew On Tue, Dec 29, 2009 at 6:45 PM, Paul Martz pma...@skew-matrix.com wrote: Thanks, Wang Rui. Yes, everything can be done by Internet. With SIGGRAPH in Las Angeles this year instead of New Orleans, your flight from China will be just a few hours shorter. :-) I haven't checked the SIGGRAPH web site to see if BOF registration is possible yet. I know the deadline is usually later, April or so. If you have questions about how to register the BOF at the SIGGRAPH web site, email me offline. (You don't need to register yourself at this time, just register the BOF.) Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 Wang Rui wrote: Hi Paul, I'd like to help, based on the premise that all the organizational matters could be done in internet. :) Wang Rui 2009/12/30 Paul Martz pma...@skew-matrix.com: Hi all -- I'm repeating my plea. Both Mike Weiblen and myself would like to step down as BOF organizer for this year's SIGGRAPH. We need someone from the OSG community to step forward and organize this event. Can someone please take this on? If no one steps up for this, there will be no OSG BOF at SIGGRAPH this year. -- Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Black Hawk, Colorado USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinate system in all readerwriters
Hi Paul and all, I agree with you simplification, but I'm not sure it'll keep write(read(A))==A. For instance: - Read a model with a rotation (Y to Z-up for instance). Your +y facing plane will be then +z facing. - Write the model. Model is still rotated and will be +z in the file, thus having write(read(A))!=A. This is why I suggested writers should undo what is done during the reading by applying the opposite transform given by the read options. Of course one could have control over those things by changing options between reading and writing, but it's then the user's choice. It's surely the same when writing first and then reading. Am I wrong? Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Paul Martz pma...@skew-matrix.com a écrit : To simplify things, I'd propose the following: - I don't think we need options to control writing. Your app can do any required transformation with a NodeVisitor before calling osgDB to write. The plugin should just write the scene graph passed to it. - For reading, we just need rotation and scale options. rotate axis degrees and scale x y z. Those alone will handle changes to orientation, handedness, and unit scaling. - If the format stores an up vector, handedness, and unit information, then the import plugins for those few formats need some kind of convertTo option, sort of like FLT's convertToMeters (which scales the model from its native units). As an addendum to the last point, regarding Ulrich's comment, an import plugin can only convert to right-handed if it knows the handedness of the model. Which formats store that information? And to clarify, OpenGL's right-handed rule is only the default for the definition of a front face. Your application and your models may or may not use this convention, and I think it would be wrong for a plugin to do such a conversion automatically, assuming it knows something about the convention you are using. Finally, in principle, I agree: write( read( A ) ) should equal A. But I want to re-emphasize this can only be true in the context of coordinate systems. (100% equality in round-trip model conversions is essentially an impossibility.) Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ 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
