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] [osgCompute] Experiences with osgCompute
Hi Bart, We renamed modules and computation nodes. We also get rid of the META_object macros for user defined computations. Check out the current SVN version and see it done. Check out the example as well: http://www.cg.informatik.uni-siegen.de/data/Downloads/svt/osgCUDAEverywhere.zip However, we did not include geometry offsets. We currently have a discussion about this topic internaly. Best regards, Jens -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43285#43285 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Above Water Fog artifacts.
Hi Bawenang, At a quick glance, I can see the problem mix problem. Thanks for reporting it. With regard to the sky dome, you'll have to add the fogging code into the skydome shader, it can be found in the resources. The skydome was only really there for the example program and they've all be chosen to blend nicely with the fogging colour, obviously this doesn't suit all applications. However, one problem with fogging the sky dome is that all of the sky with be fogged, essentially creating a flat colour since the sky dome (in the example app) will always be a fixed distance, moving with the camera. K. On 7 October 2011 09:08, Bawenang Rukmoko ben...@cs.its.ac.id wrote: Hi, I've found some artifacts on the above water for scene shader. 1. When I tried implementing billboard tree with some transparent pixels, the transparent parts look not quite transparent. Like shown in the first picture. I believe it's because of these lines in the osgOcean_ocean_scene.frag: Code: float fogFactor = computeFogFactor( osgOcean_AboveWaterFogDensity, gl_FogFragCoord ); final_color = mix( osgOcean_AboveWaterFogColor, final_color, fogFactor ); And when I added a line in that shader like this: Code: float fogFactor = computeFogFactor( osgOcean_AboveWaterFogDensity, gl_FogFragCoord ); final_color = mix( osgOcean_AboveWaterFogColor, final_color, fogFactor ); final_color.a = textureColor.a; It worked like in the second picture. 2. I believe the fog is only implemented to the objects but not the sky dome (as can be seen in the third picture). How do I make it also work with the sky dome? Thanks. Thank you! Cheers, Bawenang quot;There's no place like 127.0.0.1quot; -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43245#43245 ___ 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] Off-axis projection on multiple screens
Hi Chris, I've just scanned your email quickly as I have tone of emails to get through this morning. Here's a couple of high level suggestion to get your on your way: 1) You conceptually have a single View, with multiple Cameras - the osgViewer library is designed to fit this concept so you should use a single osgViewer::View(or Viewer is is subclassed from View) and then multiple slave Camera to provide the different components of the view. 2) For rendering cubes you don't use asymmetric frustums, but rotated ones, so you modify the view matrix offset and don't need to touch the perspective matrix. 3) The osgView::View::setUpViewFor3DSphericalDisplay(..) implementation found in src/osgViewer/View.cpp provides an example of setting up the slave Camara's of a View to render the scene into the 6 faces of cubemap and then has final slave Camera that renders the results to the screen with distortion correction. This is rather more sophisticated than you need as you won't need 6 cameras, render to texture or the distortion correction step, but if you can understand how it works then your setup will be straight forward. Please note the use of view matrix offsets to get the cube map positions. Robert. On Fri, Oct 7, 2011 at 9:13 AM, Christopher Geelen c.d.gee...@student.tue.nl wrote: Hello, This will be my first post, so feel free to correct me when I'm forgetting to explain some facts/not include neccesary files, when this seems obvious. Let me first explain the situation. Last years december TheVirus (Bart Jan) posted some questions here, about setting up a view across multiple screens, when these screens are perpendicular to each other. To quote the situation: TheVirus wrote: I want to build an app which should have one camera (or two identical, meaning that they are at the same position, facing the same direction, if that is more convenient) and multiple screens. The screens will be aligned in a 90 degree angle towards each other. So they are perpendicular: top view: Code: | - 1 | 2 | | | v | O Where O is the eye or camera. It's like looking at a box with holes in all sides and you want to see the inside. And the screens on which I want to project are the sides of the box. [..] In the PcubeE paper they say: To generate perspective-corrected images on each screen of pCubee, we use a standard off-axis projection scheme as described by Deering [9]. This is done in OSG by creating three View objects that correspond to the three visible screens on pCubee. The camera for each View is located at the user’s eye-position (which I will set manually at like right in the middle of the two screens, so at 45 degrees), oriented perpendicular to its corresponding virtual screen, and given a view frustum that passes through the corners of its virtual screen. [/i] Now, months later, I am assigned to finish the task Bart Jan started. We have created a cube, and our goal is to set up views so that we can 'look' inside the box. The purpose is to make it all embedded. Since then, I already made quite some progress (to say it myself) with learning OSG and to apply it to a BeagleBoard (which is where the application will run, eventually). The code is made to run at three different processors, but within the code they will communicate to each other through a serial connection. The code is attached to this post, but please note that this code is adjusted from the Beagleboard to make it work on the PC (Visual Studio), so it may seem a bit loose. Still this was neccessary to disable sensors etc, and to make it possible to run at just one screen/processor. To explain the functionality: In Box.cpp and CreateWindows.cpp you must define at which screen you are looking. BART = on top, MARTIJN = front/back and GERTJAN = from the side. With the keys 'a'/'d' you can simulate the sensor functionality, this represents rotating the cube around one axis. In this code I am rotating the camera by setting the view matrix with the eye, center, up vectors. This is working. Note that I am setting the radius hardcoded (r = 10). Since the camera will start on-axis, that is facing the screen and looking directly inside the box, you will see all three objects. But when this camera is rotated, the projection matrix has to be adjusted, so that you can see a perspective view, only at one side of the 'box'. Eventually this view should dissapear, when the camera is at such a position, that it cannot see that side of the box. And this is where the trouble begins. I am having trouble understanding how to correctly set up this projection matrix. If I understand correctly, I have to adjust the left/right settings of the frustum, so this will coincide with the left and right boundaries of the box. But
Re: [osg-users] [OpenGL ES] Bug in loading textures
Hi Hartwig,
Once you are happy with your solution could please post the full
source code files that you've changed to osg-submissions.
Thanks,
Robert.
On Sat, Oct 8, 2011 at 11:50 AM, Hartwig Wiesmann
hartwig.wiesm...@wanadoo.nl wrote:
Hi,
this is my patch for Texture::computeInternalFormatWithImage(...) replacing
lines 1435 - 1442:
Code:
// GLES doesn't cope with some internal OpenGL formats so map them to the
appropriate equivalents.
#if defined(OSG_GLES1_AVAILABLE) || defined(OSG_GLES2_AVAILABLE)
switch (internalFormat)
{
case 1:
_internalFormat = GL_LUMINANCE;
break;
case 2:
_internalFormat = GL_LUMINANCE_ALPHA;
break;
case 3:
case GL_RGB8_OES:
_internalFormat = GL_RGB;
break;
case 4:
case GL_RGBA8_OES:
_internalFormat = GL_RGBA;
break;
default:
_internalFormat = internalFormat;
}
OSG_NOTICEInternal format corrected for OpenGL ES from 0x
std::hexinternalFormat to 0x
std::hex_internalFormatstd::endl;
#else
_internalFormat = internalFormat;
#endif
Cheers,
Hartwig
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43268#43268
___
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] [vpb] Large VPB Database build fails without
Hi Torben, You'll need to track down which tasks have failed and then look at the associated log output for that task to see what might have gone wrong. Robert. On Sun, Oct 9, 2011 at 12:12 PM, Torben Dannhauer tor...@dannhauer.info wrote: 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 ___ 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
Hi Rodrigo, I've been offline for 5 days due to our telecoms provider screwing up our connection, so haven't been able to chip in. I'll through in a couple of thoughts. First thing, a missing feature ain't a bug. A bug is something that has been written to provide a particular feature that doesn't do that feature correctly. A bug you typically fix by fixing existing code, not by writing new code. Second, as general policy bugs are a much higher priority to fix than new features, bugs generally effect a many more people, and new features generally help less users and often brings their own bugs that need to be fixed over time. Given this difference it's a good strategy to prioritize bugs fixes as it keeps the code base at a high quality, and improves productivity. If one is going to prioritize bugs over features then one needs to be clear about what is a bug and what is a new feature. Trying to label request for a new feature a bug is BAD thing to do, and would encourage you to ask if it might be a bug or a missing feature rather than blurt out a bug, crying wolf over a just a feature you'd like to been added. Third, the OSG is developed by a community, with features developed in response by the needs of that community. If you need a feature that others need to too then it's possible to collaborate. If you need a feature that no one has needed before and you are the only one who needs it then it's really your own responsibility to develop it. Other members of the community are likely to be supportive of this. There isn't some sugar daddy that funds the OSG and provides resources to develop code at the whim of the community. There are quite a few of us who do put a work into the project in our free time or without payment - I spend around a half of my time do pure open source work without an income, but most of this time will be spent fixing bugs, reviewing and merging fixes, getting release out etc. Fourth, no bug tracking or feature tracking!! I've used both in the past within companies and found that they were counterproductive. I've always found the most effective way to fix bugs is to broadcast the problem and engage the community and respond to them promptly - it's people who characterize and then fix bugs, not computer systems, so shortening the loop between the parties that find problems and those who fix them as much as possible is the idea bug resolution system. Prioritizing bug fixes is important part of this strategy. I still find most bug tracking and feature system separate users rather pull them closer together so are a backwards step w.r.t resolving the problems. Feature requests systems would also false give the impression/expectation that requesting a feature will be something that will be responded to. Since it's the community that puts in the time to make things happen, this would require others to freely give up their time just to service your needs, while we are pretty helpful and friendly we all all have own work that needs attention, and a life outside to nourish our souls and bodies. The informal system of users posting to mailing list/forum about what features we'd like to see is really a great way to find others who have similar needs, and can provide insight in how to tackle problems. It's people community directly with people, the social and common needs aspect to the community that really drives it. So some aspects of the OpenSceneGraph project that might seem like missing common computer systems aren't oversights but quite deliberate choices to use two way human communication as the system of choice. There are some systems that are of really benefit though - version control systems are invaluable. Subversion has served us quite well, but it does have it problems, so mid/longer term I would like to see use migrate across to git. The github responsitory is an experiment done by members of the community and isn't an official repository, this is still our openscenegraph.org subversion set up. Hope this helps, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Large VPB Database build fails without obvious reason
Hi Robert, I already did this and posted the output. Here is die log file again: [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 [code] Meanwhile I was able to disentangle the error a little bit: I discovered that if I only add DEM data (-d), then the number files tasks is much higher (more than twice) than with additional texture data (-d and -t). This make me assume that there is a bug, so it is not surprising that he fails in task 317 of 1.5 million trask with a strange error (see above). Additionally I discovered that me CUDA and/or NVTT integration seems to be erroneous. If I add --compressor-nvtt to the vpbmaster call, then it hangs in the tasks, osgdem seems to stall and is killed after 120sec by the kernel. If I remove that protection, it hangs infinite. without the --compressor string (and with textures) it works perfectly. Best regards, Torben ... Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43291#43291 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using osgViewer::Viewer with independant slave cameras
Hi! I've search the archives, but could not find any posts on this topic. I want to setup a osgViewer::Viewer with 4 cameras, which can be controlled independently from the master camera, if the user click-drags in the corresponding viewport. Creating the viewer and 4 slaves is not a problem, but to manipulate each cam separately. I have an implementation of my project with the composite viewer, which works, but due to some technical implications, I want to switch to a single viewer. I tried to set setAllowEventFocus(true) to the master and slave cams, but that did not work. Can anybody give me a hint on how to setup the viewer correctly or point me to an example where this is done? Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::Viewer with independant slave cameras
Hi Casten, If you have 4 independent views then you should use the CompositeViewer class. osgViewer::Viewer is for a single View. See the osgcomposite viewer example. Robert. On Mon, Oct 10, 2011 at 2:37 PM, Carsten Scharfe cscha...@dspace.de wrote: Hi! I’ve search the archives, but could not find any posts on this topic. I want to setup a osgViewer::Viewer with 4 cameras, which can be controlled independently from the master camera, if the user click-drags in the corresponding viewport. Creating the viewer and 4 slaves is not a problem, but to manipulate each cam separately. I have an implementation of my project with the composite viewer, which works, but due to some technical implications, I want to switch to a single viewer. I tried to set setAllowEventFocus(true) to the master and slave cams, but that did not work. Can anybody give me a hint on how to setup the viewer correctly or point me to an example where this is done? Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ ___ 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] [osgCompute] FBO RTT - CUDA Kernel - FBO RTT Setup
I finally got everything built and running... one more question... What type of video format does the cuda_auto_contrast example takes as input. I had an avi (not sure of any specfics) on my machine and the example read it and display it (as far as I could tell) but it was scrolling in a funky way other wierness... CD J.P. Delport wrote: 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 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=43298#43298 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::Viewer with independant slave cameras
Hi Robert, Yes, that's what I did first. But unfortunately my 4 views have to be embededded in windows (derived from CDocuemntView on Windows). Creating a view for each window also creates a new graphics context, since each view has its own window handle. Therefore much memory is consumed, which blows my app, if I load a bigger scene (~250k polys, on a Quadro 580FX). Any idea on how I could convince each view of a composite viewer to share the graphics context? Regards, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, October 10, 2011 4:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Using osgViewer::Viewer with independant slave cameras Hi Casten, If you have 4 independent views then you should use the CompositeViewer class. osgViewer::Viewer is for a single View. See the osgcomposite viewer example. Robert. On Mon, Oct 10, 2011 at 2:37 PM, Carsten Scharfe cscha...@dspace.de wrote: Hi! I've search the archives, but could not find any posts on this topic. I want to setup a osgViewer::Viewer with 4 cameras, which can be controlled independently from the master camera, if the user click-drags in the corresponding viewport. Creating the viewer and 4 slaves is not a problem, but to manipulate each cam separately. I have an implementation of my project with the composite viewer, which works, but due to some technical implications, I want to switch to a single viewer. I tried to set setAllowEventFocus(true) to the master and slave cams, but that did not work. Can anybody give me a hint on how to setup the viewer correctly or point me to an example where this is done? Cheers, Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ ___ 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] Using osgViewer::Viewer with independant slave cameras
Hi Carsten, On Mon, Oct 10, 2011 at 3:32 PM, Carsten Scharfe cscha...@dspace.de wrote: Any idea on how I could convince each view of a composite viewer to share the graphics context? CompositeViewer works just fine with a sharing a context between all views. The osgcompositeviewer does *EXACTLY* this. Please read the example. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] FBO RTT - CUDA Kernel - FBO RTT Setup
Hi Conan, be sure to update to the latest revision of flitr and osgCuda. There has been some fixes (very recent) for the proper handling of cudaMallocPitch allocated arrays. The example should be able to read any movie file that FFmpeg can consume. It would even consume single .jpg/.png image files too. The example will convert any input to grayscale. If you still get weird tearing, try making a 1024x1024 image and see what that does. HTH jp On 10/10/2011 16:19, Conan Doyle wrote: I finally got everything built and running... one more question... What type of video format does the cuda_auto_contrast example takes as input. I had an avi (not sure of any specfics) on my machine and the example read it and display it (as far as I could tell) but it was scrolling in a funky way other wierness... CD J.P. Delport wrote: 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 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=43298#43298 ___ 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
[osg-users] Simulation Loop in osgWidget
Hi,
I am using osgWidget to run osg inside a window frame.
It works fine when I use
viewer.home();
No problem.
However, if I use:
while(!viewer.done())
{
viewer.frame();
}
to get access to the simulation loop, the widget window is lost and osg is
again using the full screen.
How can I use osgWidget and program inside the simulation loop?
Thank you
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43302#43302
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing vertex color without calling setColorArray
Thanks, that makes sense. I'll give those a shot. I'm also having another issue that's proving to be more annoying now. It seems to be the same as the problems in this thread: http://forum.openscenegraph.org/viewtopic.php?t=401 Thanks for the help. I'm going to make a new post as this is a separate issue. ~ Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43303#43303 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Colors bleeding between ShapeDrawables and Geometries
Hi Guys, I've come across this issue a few times now, and its gotten to the point where I really need a resolution. The details seem similar to what's documented here: http://forum.openscenegraph.org/viewtopic.php?t=401 Essentially, I'm setting two geometries to different colors, but they always show up as the same color (whether its the first or second). This first started happening when I was using a Box ShapeDrawable and a custom geometry (DrawArrays), so I switched the Box to a custom geometry (still a box), and made sure normals were set, but the same thing is still happening. My main scene is using lighting, however this behavior is happening in a separate scenegraph I'm using for rendering to a texture. I tried adding the normals just in case the lighting was affecting the subgraph, but it didn't make any difference. The box / geometries I'm using don't have any materials set on them, so i would think this is the case for the 'default' material? Both geometries have vertex/color/normal arrays, as I only need a solid color for each. Have I missed something here, or is there any other way to get around this issue. I've run into this in other projects too, so I'm really interested in figuring out how to avoid this, especially when using ShapeDrawables. Thanks in advance, ~ Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43304#43304 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Simulation Loop in osgWidget
On Mon, 2011-10-10 at 17:25 +0200, dan marshal wrote:
Hi,
I am using osgWidget to run osg inside a window frame.
Can you clarify what you mean by this? osgWidget is an OSG nodekit, I'm
not entirely sure what to derive from this statement (which makes the
rest of the e-mail impossible to understand).
Thanks!
It works fine when I use
viewer.home();
No problem.
However, if I use:
while(!viewer.done())
{
viewer.frame();
}
to get access to the simulation loop, the widget window is lost and osg is
again using the full screen.
How can I use osgWidget and program inside the simulation loop?
Thank you
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43302#43302
___
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] Colors bleeding between ShapeDrawables and Geometries
This type of problem is usually caused by missing data: colors, normals (if lighting), or texture coordinates (if rendering with texture enabled). You might also see behavior that *looks* like the missing data problem if you change the normal, color, or tex coordinate data dynamically and forget to dirty the display list. Your scene graph sounds pretty simple; what happens if you write it out to a .osg file and display it in the osgviewer app? Do you see the problem there, too? -Paul On 10/10/2011 2:04 PM, Dan West wrote: Hi Guys, I've come across this issue a few times now, and its gotten to the point where I really need a resolution. The details seem similar to what's documented here: http://forum.openscenegraph.org/viewtopic.php?t=401 Essentially, I'm setting two geometries to different colors, but they always show up as the same color (whether its the first or second). This first started happening when I was using a Box ShapeDrawable and a custom geometry (DrawArrays), so I switched the Box to a custom geometry (still a box), and made sure normals were set, but the same thing is still happening. My main scene is using lighting, however this behavior is happening in a separate scenegraph I'm using for rendering to a texture. I tried adding the normals just in case the lighting was affecting the subgraph, but it didn't make any difference. The box / geometries I'm using don't have any materials set on them, so i would think this is the case for the 'default' material? Both geometries have vertex/color/normal arrays, as I only need a solid color for each. Have I missed something here, or is there any other way to get around this issue. I've run into this in other projects too, so I'm really interested in figuring out how to avoid this, especially when using ShapeDrawables. Thanks in advance, ~ Dan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
I've exported my subgraph to the .osg format, but it wouldn't load in osgviewer
(possibly since it's a camera?).
I've looked at the exported file in a text editor, but it looks to me like
everything has vertices, colors, and normals as they should. Could someone with
more experience take a look? Am I missing anything here or have I set something
up wrong?
Code:
Camera {
UniqueID Camera_0
nodeMask 0x
cullingActive FALSE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Viewport {
UniqueID Viewport_1
x 0
y 0
width 2046
height 2048
}
textureUnit 0 {
}
textureUnit 1 {
}
textureUnit 2 {
}
textureUnit 3 {
GL_TEXTURE_GEN_S OVERRIDE|OFF
GL_TEXTURE_GEN_T OVERRIDE|OFF
GL_TEXTURE_GEN_R OVERRIDE|OFF
GL_TEXTURE_GEN_Q OVERRIDE|OFF
TexGen {
mode OBJECT_LINEAR
plane_s 1 0 0 0
plane_t 0 1 0 0
plane_r 0 0 1 0
plane_q 0 0 0 1
}
}
}
referenceFrame ABSOLUTE
clearColor 0 0.4 0 1
clearMask 0x100
Use Viewport_1
transformOrder PRE_MULTIPLY
ProjectionMatrix {
0.000977517 0 0 0
0 0.000976563 0 0
0 0 -0.002002 0
-0 -0 -1.002 1
}
ViewMatrix {
1 0 -0 0
-0 1 -0 0
0 0 1 0
0 0 -500 1
}
renderOrder PRE_RENDER
renderTargetImplementation FRAME_BUFFER_OBJECT
renderTargetFallback PIXEL_BUFFER_RTT
drawBuffer 0
readBuffer 0
bufferComponent COLOR_BUFFER {
internalFormat 0
Texture2D {
UniqueID Texture2D_2
DataVariance DYNAMIC
wrap_s CLAMP
wrap_t CLAMP
wrap_r CLAMP
min_filter LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_USER_DEFINED_FORMAT
internalFormat GL_RGBA
resizeNonPowerOfTwo TRUE
}
level 0
face 0
mipMapGeneration FALSE
}
num_children 2
MatrixTransform {
UniqueID MatrixTransform_3
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
2046 0 0 0
0 2048 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_4
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_5
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 0.2 0.2 0.2 1
diffuseColor 0.8 0.8 0.8 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays QUADS 0 4
}
VertexArray UniqueID Vec3Array_6 Vec3Array 4
{
0.5 0.5 0
-0.5 0.5 0
-0.5 -0.5 0
0.5 -0.5 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_7 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_8 Vec4Array 1
{
0.8 0.8 0.8 0.8
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_9
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_10
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 0.2 0.2 0.2 1
diffuseColor 0.8 0.8 0.8 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_11 Vec3Array 18
{
0 0 0
1 0 0
0.92388 0.382683 0
0.707107 0.707107 0
0.382683 0.92388 0
6.12323e-017 1 0
-0.382683 0.92388 0
-0.707107 0.707107 0
-0.92388 0.382683 0
-1 1.22465e-016 0
-0.92388 -0.382683 0
-0.707107 -0.707107 0
-0.382683 -0.92388 0
-1.83697e-016 -1 0
0.382683 -0.92388 0
0.707107 -0.707107 0
0.92388 -0.382683 0
1 0 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_12 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_13 Vec4Array 1
{
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
On 10/10/2011 4:55 PM, Dan West wrote:
I've exported my subgraph to the .osg format, but it wouldn't load in osgviewer
(possibly since it's a camera?).
I've looked at the exported file in a text editor, but it looks to me like
everything has vertices, colors, and normals as they should. Could someone with
more experience take a look? Am I missing anything here or have I set something
up wrong?
In your original post, you said you weren't using Material colors. But in the
.osg file below, you *are* using Material colors, and they're set the same for
both objects. Lighting is on by default in OSG, so that's why your objects are
rendered in the same color.
-Paul
Code:
Camera {
UniqueID Camera_0
nodeMask 0x
cullingActive FALSE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Viewport {
UniqueID Viewport_1
x 0
y 0
width 2046
height 2048
}
textureUnit 0 {
}
textureUnit 1 {
}
textureUnit 2 {
}
textureUnit 3 {
GL_TEXTURE_GEN_S OVERRIDE|OFF
GL_TEXTURE_GEN_T OVERRIDE|OFF
GL_TEXTURE_GEN_R OVERRIDE|OFF
GL_TEXTURE_GEN_Q OVERRIDE|OFF
TexGen {
mode OBJECT_LINEAR
plane_s 1 0 0 0
plane_t 0 1 0 0
plane_r 0 0 1 0
plane_q 0 0 0 1
}
}
}
referenceFrame ABSOLUTE
clearColor 0 0.4 0 1
clearMask 0x100
Use Viewport_1
transformOrder PRE_MULTIPLY
ProjectionMatrix {
0.000977517 0 0 0
0 0.000976563 0 0
0 0 -0.002002 0
-0 -0 -1.002 1
}
ViewMatrix {
1 0 -0 0
-0 1 -0 0
0 0 1 0
0 0 -500 1
}
renderOrder PRE_RENDER
renderTargetImplementation FRAME_BUFFER_OBJECT
renderTargetFallback PIXEL_BUFFER_RTT
drawBuffer 0
readBuffer 0
bufferComponent COLOR_BUFFER {
internalFormat 0
Texture2D {
UniqueID Texture2D_2
DataVariance DYNAMIC
wrap_s CLAMP
wrap_t CLAMP
wrap_r CLAMP
min_filter LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_USER_DEFINED_FORMAT
internalFormat GL_RGBA
resizeNonPowerOfTwo TRUE
}
level 0
face 0
mipMapGeneration FALSE
}
num_children 2
MatrixTransform {
UniqueID MatrixTransform_3
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
2046 0 0 0
0 2048 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_4
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_5
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 0.2 0.2 0.2 1
diffuseColor 0.8 0.8 0.8 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays QUADS 0 4
}
VertexArray UniqueID Vec3Array_6 Vec3Array 4
{
0.5 0.5 0
-0.5 0.5 0
-0.5 -0.5 0
0.5 -0.5 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_7 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_8 Vec4Array 1
{
0.8 0.8 0.8 0.8
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_9
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_10
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 0.2 0.2 0.2 1
diffuseColor 0.8 0.8 0.8 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_11 Vec3Array 18
{
0 0 0
1 0 0
0.92388 0.382683 0
0.707107 0.707107 0
0.382683 0.92388 0
6.12323e-017 1 0
-0.382683 0.92388 0
-0.707107 0.707107 0
Re: [osg-users] Simulation Loop in osgWidget
Very sorry!
If I create a window using:
osgViewer::Viewer viewer;
osgWidget::WindowManager* wm = new osgWidget::WindowManager(
viewer,
WINDOW_WIDTH,
WINDOW_HEIGHT,
MASK_2D
);
..
.viewer.home();
I get a viewer object inside a window.
===
However if I change
viewer.home();
to
while(!viewer.done())
{
viewer.frame();
}
I lose the osgWidget:WindowManager window and the viewer object now takes over
the entire screen.
I would like to keep my window but be able to add additional code inside the
viewer simulation loop.
How can I use the osgWidget::Window and be able to add calls to the simulation
loop?
Thank you again,
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43310#43310
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
