Re: [osg-users] [osgCompute] FBO RTT -> CUDA Kernel -> FBO RTT Setup
Hi, On 07/10/2011 17:32, Conan Doyle wrote: I went to the link for the cuda_auto_contrast example... looks like it is part of flitr(?)... do I have to build all of flitr to build this cuda example? you only have to build it if you want a running example. Alternatively you can just study the code to see how an FBO texture is passed into osgCuda. jp CD J.P. Delport wrote: Hi, On 05/10/2011 22:23, Conan Doyle wrote: Hi, My schedule lightened up a bit... I have an extra 24 hours to work on my osg/cuda problem, so I would like to incorporate CUDA into osg the "correct" way, which I think may be osgCUDA. Here's what I am currently doing Step 1 App renders scene to a FLOAT texture via a FBO/RTT camera Step 2 This texture is used as input to a shader on a second pass/RTT camera. The shader does some calibration stuff then renders it to a full screen quad. Step 3 Final render pass renders quad from step 2. Here's what I NEED to do... Step 1.5 Pass texture from Step 1 to a cuda kernel for processing before the calibration pass (Step 2) Questions: 1. Is this something I can use osgCUDA to do? 2. Would it be similar to the osgTexDemo? 3. Can I use an FBO, or do I have to switch to a PBO RTT? 1. Absolutely 2. Not sure, but I will forward you an example from the osgCuda devs too. I can also point you to one of our examples that does something similar. See the code here: http://code.google.com/p/flitr/source/browse/#svn%2Ftrunk%2Fexamples%2Fcuda_auto_contrast In the above example all you have to change is to place shader passes before or after the cuda pass. E.g. take the glsl_shader example and just change the texture types to osgCuda::TextureRectangle. 3. FBO is OK. CUDA 4.0 is not necessary but would be cool as I have to use it eventually, but to get past this proof of principal step I can use 3.2... or 2.3... CUDA 4.0 works fine and then you can play with Thrust too :) cheers jp CD Thank you! Cheers, Conan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43220#43220 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43257#43257 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Newbie Texture Question
On 10/9/2011 9:28 AM, Robbo wrote: > I am trying to learn OSG for use in Flightgear. I have seen a technique used > regularly > that I am not able to figure out. > Essentially a scene is using an rgb file which is transparent and whilst > quite large > (1024x768), contains many different 'icons' of smaller size and what appears > to be an > 'alpha mask' for the main image area. These icons appear to be extracted and > used within > a dynamic scene, but I am not sure how this is done as it does not appear > obvious in the > code (i was expecting some image coordinates at least). > The particular example within Flightgear (for those who may be familiar) is > wxradar.cxx > and wxecho.rgb) > Could somebody please take the time to explain how this works in principle > and what the > technique is called? Sounds a bit like a Texture Atlas. Yes, I would expect either the UV coordinates to be altered, or perhaps the transform/translate of the texture coordinate matrix. > Robbo -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. "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
[osg-users] Newbie Texture Question
Hi, I am trying to learn OSG for use in Flightgear. I have seen a technique used regularly that I am not able to figure out. Essentially a scene is using an rgb file which is transparent and whilst quite large (1024x768), contains many different 'icons' of smaller size and what appears to be an 'alpha mask' for the main image area. These icons appear to be extracted and used within a dynamic scene, but I am not sure how this is done as it does not appear obvious in the code (i was expecting some image coordinates at least). The particular example within Flightgear (for those who may be familiar) is wxradar.cxx and wxecho.rgb) Could somebody please take the time to explain how This works in principle and what the technique is called? Many thanks, Robbo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Open Flight characteristic not reflected in the current OSG
On 9/29/2011 4:44 PM, David Glenn wrote: Turns out that what you did worked but if you looked at the object that I gave you, it's solid ( its suppose to be transparent) The transparency is set at a node that is labeled WATER that introduces the transparency to the face (Primary) color. Hi David -- I finally got a chance to take a look at this. Comments below. So my partner (John Markano) looked at GeometryRecords.cpp around some ware after line 431 (OSG 3.0.1) or 331 (OSG 2.8.1) he added the line: Code: _PrimaryColor.a() = 1.0 - getTransparency(); Then he thought this would have unwanted side effects I agree. :-) (even though I didn't see any) and adopted a change in the same file but at line 257 (OSG 3.0.1) or 157 (OSG 2.8.1) change the code: Code: colors->push_back(_PrimaryColor); to the line : Code: colors->push_back(osg::Vec4(_PrimaryColor.r(), (_PrimaryColor.g(), (_PrimaryColor.b(), 1.0 - getTransparency())); I zero'd in on the exact same change. I think this is the right thing to do. I'll post this to osg-submissions shortly. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering From First Person
Hi Jeremy, I am a newbie in osg. I am working on a project to build a virtual environment.After trying a lot, I am not able to create first person experience in my environment. Can you help me out in this regard. ... Thank you! Cheers, Rishabh (ryshabtaneja@gmail) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43276#43276 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG report: Collada orthographic support
Hello Rodrigo, I think the important point of contention is not whether this is a bug or a missing feature - this is just a detail. The point to clarify is about OSG's support for ortho cameras. osg::Camera supports orthographic projection as you can see from methods like osg::Camera::setProjectionMatrixAsOrtho() and so on. We use this all the time. The thing that is not supported is to load ortho cameras from COLLADA files, as you have seen. I agree with you that the changes needed to support this should be pretty small. So if you are willing to put in a bit of initial effort into understanding the code, you should be able to implement it pretty easily. The OSG loaders are generally implemented by users like you who need such loaders. As is the case in most open source software, the work done generally covers the needed features only (because of time constraints of the people doing the work, yes, but also for the legitimate reason that if a feature is implemented but ends up not being used, it will likely not be tested thoroughly, and thus when the time comes for people to use it more extensively, it might not even work correctly). We routinely hear the expression "scratching the itch" in open source and agile development in general, meaning that people who do work will want to do the work that is relevant to them, no more and no less. Now, you seem to want to use this feature, so it makes sense that you get in there and implement it. As I said, it should not be a significant amount of work. Gordon's point of an application keeping control over cameras instead of cameras being loaded from data files does not need to concern you too much. I have seen apps that work as Gordon suggests, and others that need to load cameras from data files (the app then generally offers a GUI that lets the user choose which camera to look from). This is exactly what osg::CameraView was designed for (and not osg::Camera, so perhaps that's where the confusion comes from). Looking at osg::CameraView, it seems this class doesn't support ortho projection, but it has a setting for field of view (which is also a projection matrix setting), so I don't think there is anything that would prevent it from supporting them. http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00077.html If you need any help implementing the missing feature then we will gladly answer your questions. Hope this helps, J-S On 09/10/2011 6:13 AM, Rodrigo Benenson wrote: Thanks for your quick comment Gordon. To me Its not a bug , its an unsupported feature :) so you cannot really reports it a as bug I agree that the distinction between features and bugs is a fine line most of the time. Most projects use the tickets/bugs/issues system to keep track of features to be implemented in the next releases, or to document decisions related to not implementing specific features. There are many features of what Collada can support that are not supported in OSG or other apps. ( this is also the same of other model formats) Not every feature of of every formats is needed in OSG in general or really makes sense If OSG supports a particular format I would expect the extend of the support to be as wide as reasonably possible, and otherwise the areas not implemented should be clearly stated the documentation. I for one would Not want to use camera data in my application when loading a DAE model (or any format), my application controls the camera not a model, I just want to load the models, what if I load 30 Dae models and they all have different cameras , which one should I use :(m but that’s me and my apps Under that argument then the COLLADA module should not load any camera. However this clearly not the case. What makes me consider the current status more a bug than a "missing feature" is the mentioned piece of code and comment that mentions http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/dae/daeRSceneObjects.cpp?rev=12791#L617 // TODO The current osg::CameraView does not support an orthographic view to my understanding in current OSG, CameraView does support orthographic view and is that sense, at the very least the comment is incorrect (and should be updated to explain why OSG will not implement this feature); or, more reasonably the missing feature can be easily implemented now. Too me your request is more an Application specific thing and you could extend your application to create that Ortho camera for you, it would be a good way to learn more about OSG It is not specific to my application in the sense that, in my application, some renderings will be done using perspective projection and other ones with orthographic projections. In my application the camera information is meant to be stored in a file, and I considered the Collada files a reasonable (cross 3d tools) choice (to store both the camera information and the models). I canno
[osg-users] [vpb] Large VPB Database build fails without
Hi, I try to build a database with DEM but without textures. After 317 tasks it fails and has still 1595182 tasks pending. After the fail it blacklists the one machine and so finishes the run. The log file of one of these tasks is the following: Code: 0.129: Adding terrainTile 5.253: getTaskName(5,33,0) no nest, 6 12 5.253: DataSet::_run() 6 12 17.588 : started DataSet::createDestination(13) 17.637 : Time for after_reproject 0.049001 17.686 : local_extents = xMin() -180.00 180.00 17.686 : yMin() -60.00 60.00 17.686 : AR=3.00 C1=3 R1=1 17.686 : createNewDestinationGraph 17.926 : Time for _destinationGraph->computeMaximumSourceResolution() = 0.00 17.926 : Time for createDestinationGraph 0.240480 17.926 : Time for after_computeNeighbours 0.10 17.926 : completed DataSet::createDestination(13) 17.926 : Error: no destination graph built, cannot proceed with build. 17.926 : Time to write out DatabaseRevision::FileList - FilesAdded terrain_subtile_L5_X33_Y0/terrain_L5_X33_Y0.osgb.task.0.added, 0 17.926 : Time to write out DatabaseRevision::FileList - FilesRemoved terrain_subtile_L5_X33_Y0/terrain_L5_X33_Y0.osgb.task.0.removed, 0 17.926 : Time to write out DatabaseRevision::FileList - FilesModified terrain_subtile_L5_X33_Y0/terrain_L5_X33_Y0.osgb.task.0.modified, 0 17.926 : Elapsed time = 17.926306 The situation is the same if i resume the build with Code: vpbmaster --tasks build_master.tasks It reloads all tasks from file and than again fails on the identical tasks. I don't know why osgdem complains about the missing destination graph with Code: Error: no destination graph built, cannot proceed with build. Any idea why it fails? my system is: Kubuntu 10.04 64 bit. Kernel 2.6.38-11-generic 12GB RAM OSG and VPB from trunk last week. Thank you for your help, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43278#43278 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG report: Collada orthographic support
Thanks for your quick comment Gordon. > To me Its not a bug , its an unsupported feature :) so you cannot really > reports it a as bug I agree that the distinction between features and bugs is a fine line most of the time. Most projects use the tickets/bugs/issues system to keep track of features to be implemented in the next releases, or to document decisions related to not implementing specific features. > There are many features of what Collada can support that are not supported in > OSG or other apps. ( this is also the same of other model formats) > Not every feature of of every formats is needed in OSG in general or really > makes sense If OSG supports a particular format I would expect the extend of the support to be as wide as reasonably possible, and otherwise the areas not implemented should be clearly stated the documentation. > I for one would Not want to use camera data in my application when loading a > DAE model (or any format), my application controls the camera not a model, I > just want to load the models, what if I load 30 Dae models and they all have > different cameras , which one should I use :(m but that’s me and my apps Under that argument then the COLLADA module should not load any camera. However this clearly not the case. What makes me consider the current status more a bug than a "missing feature" is the mentioned piece of code and comment that mentions > http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/dae/daeRSceneObjects.cpp?rev=12791#L617 // TODO The current osg::CameraView does not support an orthographic view to my understanding in current OSG, CameraView does support orthographic view and is that sense, at the very least the comment is incorrect (and should be updated to explain why OSG will not implement this feature); or, more reasonably the missing feature can be easily implemented now. > Too me your request is more an Application specific thing and you could > extend your application to create that Ortho camera for you, it would be a > good way to learn more about OSG It is not specific to my application in the sense that, in my application, some renderings will be done using perspective projection and other ones with orthographic projections. In my application the camera information is meant to be stored in a file, and I considered the Collada files a reasonable (cross 3d tools) choice (to store both the camera information and the models). I cannot just hard code the camera once and for all. As I asked before, is still someone in the reading list familiar with this part of the code ? Any idea of how trivial or non trivial it is to fix this issue ? I am not familiar with the specifics of the camera matrices handling in OSG, but I would believe the issue to be "not very had" to resolve. Best regards, rodrigob. On Sat, Oct 8, 2011 at 10:24 PM, Gordon Tomlinson wrote: > To me Its not a bug , its an unsupported feature :) so you cannot really > reports it a as bug > > There are many features of what Collada can support that are not supported in > OSG or other apps. ( this is also the same of other model formats) > Not every feature of of every formats is needed in OSG in general or really > makes sense > > I for one would Not want to use camera data in my application when loading a > DAE model (or any format), my application controls the camera not a model, I > just want to load the models, what if I load 30 Dae models and they all have > different cameras , which one should I use :(m but that’s me and my apps > > Too me your request is more an Application specific thing and you could > extend your application to create that Ortho camera for you, it would be a > good way to learn more about OSG > > > > > __ > Gordon Tomlinson > > gor...@gordontomlinson.com > www.photographybyGordon.com > www.vis-sim.com > www.gordontomlinson.com > IM: gordon3db...@3dscenegraph.com > __ > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Rodrigo > Benenson > Sent: Saturday, October 08, 2011 9:26 AM > To: OpenSceneGraph Users > Subject: [osg-users] BUG report: Collada orthographic support > > Thanks Jean-Sébastien for the quick answer. > If the mailing list is the bug report channel, then here I go: > > I am currently working on an application that uses openscenegraph to > render collada animations. > When running my code on the collada files of my interest I get the > following warning: > > Orthographic in 'Camera-camera' not supported > > not support orthographic projection will clearly "mess up" the rendering > output. > Looking into the code I found > http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/dae/daeRSceneObjects.cpp?rev=12
