Re: [osg-users] ortho2D camera and frustum camera layering(render order)
Hi Michael, If you want to have a series of layers of 2D and 3D content then you simply set up you Camera's with an appropriate RenderOrder number, the ordering goes : PRE_RENDER, from negative to positive RenderOrder number POST_RENDER, from negative to positive RenderOrder number In your case you 2D background you'd probably just draw with a PRE_RENDER, the 3D as defaults, and the 2D foreground as POST_RENDER. The only other item you'd need to tweak is that the clear of the colour buffer on the 3D and 2D foreground Camera's should be disabled. Robert. On Tue, Jul 28, 2009 at 7:43 PM, Michael Irby IImi...@wms.com wrote: Hi, Yes, I started with this example but it does not completely accomplish what I need. I need more than a hud and there can be N amount of 2D and 3D cameras in the graph. So for an example something like a 2D camera in front with 2D content, then a 3D camera with 3D content and then another 2D camera behind that with 2D content. There can be many layers of 2D and 3D geometry. And the POST_RENDER I believe only serves for having a hud above 3D content. What I am writing must support 2D and 3D graphics living together in the scene graph and have a way to control the layering of the the different cameras. The NESTED_RENDER for cameras seems like it would serve my purpose, but I think that is only for slave cameras? It would be great to be able to have a nested render on cameras in the graph and be able to give an order then render for each camera should happen. Thank you! Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15564#15564 ___ 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] What are txf and tpf files ?
Hi Mach, Terrapage databases usually have overly aggressive LOD range settings so it culls out tiles complete at long distances. As others have said the default camera position in osgviewer is beyond the distance range of many Terrapage databases so you have to zoom before it starts paging in. There is nothing wrong here, it's simply the way the database is set up, and the fact that osgviewer is a general purpose 3D viewer so the default camera positions reflect what is appropriate for the broadest range of 3D scenes. W.r.t memory consumption unless you are in range of the LOD distances you won't see any paging in at all, and the memory won't start increasing either. This is the OSG doing exactly what it's supposed to, it's the whole point of database paging - you only load what is required, and if the database says that a tile ain't in range it simply won't load it. Get in range of the LOD and things will automatically start paging in. For a simulator you'll be controlling the camera position to be within the confines of the model any way so you'll see the terrain pop up. Robert. On Wed, Jul 29, 2009 at 7:33 AM, Mach Bhaisar...@dsi.co.ae wrote: I tried changing both LOD and Eye point but it didn't work. As an after thought i opened task manager to monitor the memory consumption of osgviewer and then loaded the txp file. There was no increase in memory consumption which was a bit disappointing. Then i opened another simpler txp and the memory consumption just shot up. So i can conclude fairly that the osgviewer is not reading the txp file at all. As of now i am looking at other viewers / options mentioned here. And i would love to get more nudges in the right diection. Thank you all. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15575#15575 ___ 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] osg::View::computeIntersections and Shaders
Hi Harold, There is no connection between the intersection traversal and shaders, the IntersectionVisitor ignores state completely. What is probably the problem is how the Effect node is interacting with the intersection traversal. Go put some break points in your code to see what is happening during the intersection traversal. Robert. On Wed, Jul 29, 2009 at 10:59 AM, Harold Comereharold.com...@gmail.com wrote: Hi all, I will time to explain my problem clearly this time :) I use osg::View::computeIntersections to get the picked node. When a node is picket, i apply a shader effect. The select effect is done by a class SelectEffect wich inherate of osgFX::Effect. To apply the select effect i insert a SelectEffect between the picked node and its parent. Then to remove the effect, i delete the SelectEffect and restor initial parent. The problem is when i call osg::View::computeIntersections, it do not intersect nodes with an select effect applied. If i display the intersected drawable list returned by computeIntersections, before and after have applied the select effect on the node containing the picked drawable, the drawable simply disapear from list. Is there any link between shaders and osg::View::computeIntersections ? I cant get it from source code. Thanks for your attention, Regards, Harold ___ 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] Optimizer changes LOD rangemode
Hi Favien, This sounds like a bug. Any chance you could have a look at fixing it? :-) Robert. On Wed, Jul 29, 2009 at 11:06 AM, Fabien Dachicourtd...@spaceyes.fr wrote: Hi All, Using osg 2.8, it seems that the optimizer option COMBINE_ADJACENT_LODS doesn't take care of LOD rangemode. LOD children with rangemode PIXEL_SIZE_ON_SCREEN are merged in a LOD with rangemode DISTANCE_FROM_EYE_POINT. Regards, -- Fabien ___ 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] [OT] Looking for a lib that adapts terrain to 3D object
Hi Sukender, I'm diving in this thread rather late... One of my intentions for osgTerrain is to support adding polygonal constraints to the tessellation of the height fields. This will allow us to import building outlines etc. and have them automatically matched with the terrain. This is a feature I won't be able to tackle soon though, too many other tasks on my plate... but I'll get there eventually if others don't beat me to it ;-) Robert. On Tue, Jul 28, 2009 at 3:59 PM, suky0...@free.fr wrote: Hi all, I saw (once upon a time...) a library/toolkit/nodekit/whatever that's able to nicely adapt/modify a terrain mesh so that a given 3D object (say a building) is on the floor instead of floating over it. You know, when you got a heightfiled that does not match the building altitude... I guess it was on this mailing list... Does anyone knows what I'm talking about, and where to find it? I just can't! 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Draw time vs. GPU time Stats question
Hi Alex, Draw time is composed of the Draw dispatch (yellow bar) and the Draw GPU (orange bar). The Draw dispatch is the OSG's CPU overhead in sending all the OpenGL tokens and data into the OpenGL fifo. The Draw GPU is the time it takes to render the frame down on the GPU, it's value is determined by an OpenGL extension, but this extension doesn't provide an absolute timing so the position on the on screen stats is just an estimate that the OSG makes. Robert. On Wed, Jul 29, 2009 at 10:30 PM, Pecoraro, Alexander Nalexander.n.pecor...@lmco.com wrote: Is it fair to say that the Draw time in the OSG stats measures the time needed to sort and call the display lists of the Geometry nodes obtained by the Cull stage and make the other frame rendering related OpenGL calls? And GPU time is the time that the GPU spends rendering the geometry (vertices, textures, etc)? Thanks. Alex ___ 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] Perspective / Orthogonal projection matrix with CameraManipulator
Hi Andrew, I would not recommend trying to make an orthographic view behave like a perspective view, it simple doesn't work (this is not an OSG issue, but the basic principles involved.) I've written about this before so I won't waste my key presses have a look through the archives. The upshot is I would suggest keeping orthographic views for fixed maps/side/front views, or very constrained user interaction models. If you try to make a orthographic behave like a perspective you'll just waste lots of time. Robert. On Thu, Jul 30, 2009 at 6:22 PM, Andrew Thompsonandyb1...@yahoo.co.uk wrote: Hi there, I am using a custom CameraManipulator class (inheriting osgGA::MatrixManipulator) which is added to my scene after the OpenSceneGraph is initialised The CameraManipulator has two member variables I've added, a Vec3d target and position. These are used to create a projection matrix by calling Matrix::makeLookAt. As the events are handled by the manipulator, I am updating the position/target and recomputing the matrix, then on Frame I am returning the constructed matrix. This provides a great perspective view, however I cannot work out how to construct an orthogonal projection using a target/position. In addition, I'd like to be able to change the Field Of View when I create the matrix. I realise there is a Matrix::makeOrtho and Matrix::makePerspective, however I'm not sure how to use these with my CameraLocation/Target variables. Could anyone offer me some advice? Thank you! Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15659#15659 ___ 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] Blending Low Resolution Texture to Big Screen
Hi Kiruba, Your problem is unreasonable expectations. Mip mapping is purely for minification and won't help you when you magnify. What you should expect is heavily un-sampled textures to look lousy, this is normal. The fix is to sample your textures correctly so they aren't heavily undersampled. Robert. On Fri, Jul 31, 2009 at 8:08 AM, kiruba nanthamkkirubanant...@yahoo.com wrote: Hi Robert, Yes i understand i am trying to do somthing that beyond OSG support. i have already done these teture mappings but i have never tried these mipmapping techniques. even now i am able mipmap it but my big problem here as you said undersampling. i checked with CImg Library (3rd party) applications but i am unable to integrate it in my application. please can you explain if you have any idea? regards, kiruba. --- On Mon, 7/27/09, Robert Osfield robert.osfi...@gmail.com wrote: From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] Blending Low Resolution Texture to Big Screen To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: Monday, July 27, 2009, 3:46 PM Hi Kurba, I'm Ulrich, this is classic undersampling, the best way to solve it is to choose you texture resolution far more appropriately, you certainly can't expect good results with such an aggressive undersampling, OpenGL certainly won't help you, and the OSG does have any magical pixie dust to help you either. If you really really must try and use such an undersampled image then go have a look at 3rd party tools for image processing to see if they can provide edge detection and filtering based on this, or some other specific method to handling such extreme undersampling. Robert. On Mon, Jul 27, 2009 at 11:08 AM, kiruba nanthamkkirubanant...@yahoo.com wrote: Hi Hertlein, Thank you for your reply, Yes, i accept as you said i am blowing each pixel in the texture to 8x its size. but what all i want is after making this image bigger (i.e. 8x) just adding some blur to overall picture so that the edges dostn't look odd. the problem here is i don't know how to add blur in OSG. if you can give some tutorial links i can look in to it. Regards, Kiruba. --- On Mon, 7/27/09, Ulrich Hertlein u.hertl...@sandbox.de wrote: From: Ulrich Hertlein u.hertl...@sandbox.de Subject: Re: [osg-users] Blending Low Resolution Texture to Big Screen To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: Monday, July 27, 2009, 3:01 PM On 27/07/09 10:48 AM, kiruba nantham wrote: Hi friends, I am new to OSG. i am trying to map my small texture (128*128 pixel) to Big display (800*800 pixel). i am able to load successfully but i face one problem with it. the problem is my picture doesn't like smooth, my image looks very bad (picture is attached with this mail). can any one suggest any way to make my picture look proper? Increase the resolution. There is simply not enough information in a 128x128 image to make it look nice at the output resolution. Remember that your blowing up each pixel in the texture to 8x its size. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and WPF Questions
Hello everyone, sorry for not writing so long, but I've been quite busy. I've tried some things to integrate OSG in .NET, but none of the solutions were satisfactory. As stated by Brian above, the WPF popup windows were flickering and I didn't manage to get the rendering to texture to work. Then I tried WinForms and there also at least the shadow of those windows were flickering. :( Now my boss said I should leave .NET aside and said I should try using the Fox-Toolkit. So everyone thank you for your help in .NET, but seems like I won't work on this topic any further. Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15810#15810 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glMultiTexCoord4f , OSG with OGL code
Hi Pau, On 5/08/09 1:58 AM, Pau Moreno wrote: I've realized that the problem is that I'm losing the graphics context. I'm having the same problem with the inicialization of a shader, and it crashes here before the glMultiTexCoord4f(), so I think if I solve the problem with the shader this maybe solves my first issue. My problem is that I have to work with a geometry shader, so I have to do all the initializations in OGL. I finally found a solution to initialize glew doing viewer.setRealizeOperation( ... ); but when I do viewer.realize, seems that I loose the Graphics Context again. I want to initialize my shader (glCreateProgramObjectARB) in a diferent place than where I do glewInit... how I can do that? Why are you manually creating GLSL programs? If you could just use osg::Program you wouldn't have any context issues in the first place. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg 2.2 How to disable picking for objects attached to camera with smaller viewport when they are no visible in the scene
Hi James, The easiest way to do selective picking is the use a traversal mask on the intersection traversal that maps to node masks on the nodes in your scene. For instance is you set a node mask of 0x1 on the parts of the scene you won't to pick, and 0x2 on the parts your don't want to, then use a traversal mask of 0x1 then only the parts you won't will be picked. Robert. On Fri, Jul 31, 2009 at 9:38 AM, James Simyawny1...@hotmail.com wrote: Hi, i have a hud camera with a viewport of (x, y, w=200, h=200) and projection fixed at (x, x+w, y, y+h). The objects attached to Camera is an image of size 640*480 which is the screen resolution for the viewer. i have a pickhandler that handles the picking for the hud and the 3D objects behind the hud. The pickhandler picks the hud when i click on the camera, it also picks the hud when i click outside the camera as shown by the red dot in the attachment. Is there anyway i can disable picking outside the camera? Thank you! Cheers, James -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15670#15670 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2-rc4 problem with osgViewerFox
Hello ^^ If I try to compile the sample-program in debug-mode I also get an error, but a violation access-error (when he tries calling readNodeFile). I've also experienced the linker-warning when trying to compile in Release-mode. So has anyone solved the problem yet? Or does anyone have a different approach/idea how it could work? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15815#15815 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] complete copy of my scenegraph
Hi Bob, Cloning your whole scene graph sounds like a very heavy handed thing to do. What might be better is to use use a custom node that manages both StateSet's and then decides upon which to use depending upon the cull traversal mask from within a custom traversal method. You could also set this up using a Group containing two subgraphs that have a Group with the appropriate StateSet and NodeMask, but sharing the same subgraph. Robert. On Tue, Jul 28, 2009 at 7:50 PM, Bob Youmansbyoum...@knology.net wrote: Hi All, as I’m trying to set up my scenegraph for rendering in two ways, I’m thinking I want 2 complete copies: one to set callbacks and statesets on for the shader-version and another to have that user can “throw” without any of this stuff. Then I can user the viewer::setSceneData to swap them. Can I do this simply by using CopyOp::DEEP_COPY_ALL? Thanks, Bob ___ 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] Deadlock when loading osg.dll, singletons are evil
Hi Tanguy,
I don't have a windows box to test against so can't do anything first
hand. It does very much sound like Windows threading issue that will
require a specific Windows mechanism in your application set up to
avoid hitting these problems. I don't what what the solution might
be, but perhaps it would require serialization of all system calls
like getenv.
The solution will not be ditching singletons. They are extremely
useful to design and implementation of the OSG. You simply can't
replace them without major surgery of API and implementation, and even
if you did you'd loose significant flexibility and function -
something which is currently loosely coupled (yes a great OO asset)
would end up be far more tightly coupled than it is now.
Please remember that the OSG is used heavily by thousands of
developers on thousands of applications across dozens of platforms,
with many applications which are heavily threaded - and it's been
under decades development without this issue cause problems. The
problems you are seeing are serious, but they aren't the norm, it's
because of your particular application usage model and platform. I'm
certainly open to finding an OSG solution, but it'll have to be
unobtrusive and require minimal code and API changes, otherwise it
simply won't be merged as the cost and risks to existing users will be
too great.
As a general note, please abstain from using immotive language to try
and make your point. I have found over the years that the quality of
reasoning if often inversely proportional to how immotive the language
is used by a poster, so once I see such language I know it's a early
warning of what may well be an unreasonable request. If you have a
good point, you don't need trumped up rhetoric, the facts speak for
themselves.
Robert.
On Mon, Aug 3, 2009 at 7:34 PM, Tanguy
Fautretang...@aristechnologies.com wrote:
Hi all,
With the help of Aymeric, we've been able to create a small program
reproducing the problem. On my machine (Core i7, Vista x64, VC8 and VC9,
Debug and Release) it deadlocks 99% of the time. Other machines have
shown to deadlock less often (Aymeric's machine deadlocks roughly 20% of
time, Dave's only about 10 %).
The example program is very simple. While you'll find the full program
with its cmake files attached, I've copy/pasted the heart of the program
directly into this post. The full explanation of why it is deadlocking
has already been posted by Aymeric
(http://forum.openscenegraph.org/viewtopic.php?p=15636).
Cheers,
Tanguy
// Library.cpp (to be compiled in Library.dll)
static const char * env =
std::getenv(LIBRARY_UBER_OPTION_ENV_VARIABLE);
// Main.cpp (to be compiled in Main.exe)
void libraryThreadMain(void *)
{
LoadLibraryA(Library.dll);
}
void threadMain(void * argv)
{
const char * prog_name = ((char **)argv)[0];
struct stat sd;
stat(prog_name, sd);
}
int main(int argc, char * argv)
{
HANDLE thread_a = (HANDLE) _beginthread(libraryThreadMain, 0,
0);
HANDLE thread_b = (HANDLE) _beginthread(threadMain, 0, argv);
WaitForSingleObject(thread_a, INFINITE);
WaitForSingleObject(thread_b, INFINITE);
CloseHandle(thread_a);
CloseHandle(thread_b);
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 released
Hi Sukender, Thanks for uploading these. Are they all ready to upload? Could you provide the md5sum's and sizes of these files so I can verify they have been uploaded OK? Cheers, Robert. On Tue, Aug 4, 2009 at 10:11 AM, Sukendersuky0...@free.fr wrote: Hi Robert, As expected, I did a mistake when building two VC9 packages (documentation was missing in packages named all because I forgot to generate the doc before). Sorry. Please use openscenegraph-all-2.8.2-win32-x86-vc90-Debug(2).zip and openscenegraph-all-2.8.2-win32-x86-vc90-Release(2).zip (instead of the without (2) ones). Same thing for openscenegraph-all-2.8.2-win32-x86-vc80sp1-Release(2).zip as told in my previous mail. Upload should be complete in less that 30 min. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Mail d'origine - De: Sukender suky0...@free.fr À: OpenSceneGraph Users osg-users@lists.openscenegraph.org Envoyé: Tue, 4 Aug 2009 07:41:21 +0200 (CEST) Objet: Re: [osg-users] OpenSceneGraph-2.8.2 released Hi Robert, hi Jose-Luis, hi all, I'm uploading VC8sp1 binaries for 2.8.2, as for VC9sp1. However, You'll have to delete openscenegraph-all-2.8.2-win32-x86-vc80sp1-Release.zip (which was truncated beacause of a transfer termination) and use/rename openscenegraph-all-2.8.2-win32-x86-vc80sp1-Release(2).zip instead. BTW, Jose-Luis and Robert, may packages maintainers have a full read/write access to a specific FTP folder, such as one with their name? That would avoid such things, as I could have replaced the truncated file. (And I have to check something on VC9 binaries I uploaded ; I just hope all went right or I'll have to upload renamed files again!) And a final question: should the site have a link (or text reference) to download a doc package on the wiki/Support page? Something like this: Reference Guides - online reference for OpenSceneGraph API's. Offline documentation may be downloaded from one of the precompiled binaries set on the download page. Cheers, -- Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 03 Aug 2009 16:51:57 +0200, suky0...@free.fr a écrit: Hi Robert, hi all, Uploading VC9sp1 binaries for 2.8.2 (release debug - ETA: 3 minutes)... I'll try to do the same with VC8sp1 tonight or tomorrow. Please tell if anything went wrong. Cheers, PS: I'll certainly become active again on the mailing list from now :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Mail d'origine - De: Robert Osfield robert.osfi...@gmail.com À: OpenSceneGraph Users osg-users@lists.openscenegraph.org Envoyé: Tue, 28 Jul 2009 08:33:04 +0200 (CEST) Objet: [osg-users] OpenSceneGraph-2.8.2 released Hi All, I'm delighted to announced the 2.8.2 release, the second patch release of the OpenSceneGraph-2.8 series. We don't have any binaries yet, so I'd appreciate if some gracious souls could pitch in and build the binaries and then upload them to ftp so we can work on getting them uploaded to the downloads page. Many thanks for all your assistance in testing and bug fixing, Robert. -- Source code packages can be found on the Downloads page (http://www.openscenegraph.org/projects/osg/wiki/Downloads): source package : OpenSceneGraph-2.8.2.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.2 OpenSceneGraph Updates between 2.8.2 and 2.8.1 releases include: ¶ * Build fixes for: o RedHat Enterprise Linux o Building of dicom plugin with ITK under Linux. * Crash fixes to: o crash during window destruction under Windows when using closing a MFC based GraphicsWindow o deadlock under Windows due threading issues with atomic operations in Win32 Barrier implementation o OpenFlight plugin not handling spaces at the end of option strings * Bug fixes to : o computation of sector range in osgSim::LightPoint o extension checking of FBO packed stencil support o position of tabs at corners of manipulators o threading bug in .osg plugin that occurred during multi-threaded initialization o alignment of Text what setting alignment after assign text string o loading of compressed texture arrays o texture generate mipmap for non power of two textures o regression in X11 key symbol remapping, improved support for Russian keyboards o regression of StencilMask setting in RenderStage o small memory leak in X11 usage o Transform::computeBound() double BoundingSphere support o Resize handling when master and slave Cameras share the same GraphicsContext o Handling of locale in plugins and env var parsing so it always follows the '.' decimal place convention regardless of
Re: [osg-users] Feature request for 2.9: please include swig bindings in main release
Hi Guys, For 2.9.x we a not far away from a feature freeze so adding lots of extra code is not appropriate. Longer term I'd love to see us properly solve the issues of language wrappers and introspection for the OSG in a way that is easy to maintain for all involved. What form this might take I don't know. My original hope was that osgIntrospection would be the basis of solving these problems, but alas this hasn't picked up the usage out in the community. I believe it would be inappropriate to have two different schemes for wrapping though, so if we introduce a new scheme it'll need solve be fit to replace osgIntrospection's place in the core OSG, rather than just add another scheme that runs in a parallel. W.r.t MixinVector, have a look at the svn logs from include/osg/Array to see the author and details of why the changes we required. The quick answer is that in C++ you need a virtual destructor to do inheritance, but std::vector doesn't have one, so the results on inheriting from it are undefined and can lead to memory leaks. Robert. On Tue, Aug 4, 2009 at 3:46 PM, Gerwin de Haangerwindeh...@gmail.com wrote: Hi Luigi, Frank and others, FYI I am currently using osgswig with a patched osg 2.9.5. This patch consists of reverting the MixinVector stuff from osg 2.6+ with the standard std:vector alternative in osg 2.4 so osgswig can wrap the VecArrays again. I have tried this only on linux, and I'm not sure if I break anything in osg itself by messin' up MixinVector. Luigi, I am interested in your modifications, could you send them to me so I can integrate them? First thing would be to make a list of things that are wrapped or are ignored. I started working in that direction by using a wrapped version of osgIntrospection to inspect what's available in the osg libraries and plugins. Adding unit tests for basic instantiation would be a bonus. As far as automation of the process goes, I'm keen to see what the techniques from the new wrapITK could bring us. (http://code.google.com/p/wrapitk/) My colleagues tell me ITK is bigger a beast than osg, an heavy on STL templates and nested classes, but that their Python/Java wrappings are impressive. As far as (potential) users go, please mail me your name, company/institution and a use case so I can update the list (http://code.google.com/p/osgswig/wiki/UsingOsgswig). Hopefully we can convince others (e.g. bosses, colleagues) that working on and working with osgswig is useful. regards, Gerwin On Tue, Aug 4, 2009 at 4:15 PM, Frank Midgley midgl...@janelia.hhmi.org wrote: On Aug 4, 2009, at 7:55 AM, Luigi Calori wrote: I'm unwilling to update as each time I update osg... there are some problems with swig wrapping. One of the worst issues has been the MixinVector that has broken all the vecArrays wrapping thus preventing python construction of geometry. I do not know weather Robert is aware of the hassle this mod has caused to osgswig users. I'm still running against OSG 2.6 but was finally able to construct custom geometry via Python with code similar to the following: def vectorArrayFromList(vectorList): from ctypes import * vectorArray = osg.Vec3Array(len(vectorList)) arrayPointer = pointer(c_float.from_address(int(vectorArray.getDataPointer( vectorSize = vectorArray.getDataSize() offset = 0 for vector in vectorList: for dim in range(3): arrayPointer[offset + dim] = vector[dim] offset += vectorSize return vectorArray The vectorList argument should be a list of tuples to stick into the array, e.g. [(1.0, 2.0, 3.0), (4.0, 5.0, 6.0)]. The trick is to take advantage of the Vec3Array constructor that takes just a length argument. You get a vector full of (0.0, 0.0, 0.0) values which you can then replace with real data via ctypes. I adapted this from Randolph Fritz's post to osg-users (http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg23368.html). You can do the same thing for primitive sets: def primitiveSetFromList(primitiveType, vertexIndexList): from ctypes import * primitiveSet = osg.DrawElementsUInt(primitiveType, len(vertexIndexList)) arrayPointer = pointer(c_uint.from_address(int(primitiveSet.getDataPointer( offset = 0 for vertex in vertexIndexList: arrayPointer[offset] = vertex offset += 1 return primitiveSet I haven't done massive testing but it's working fine so far on both Mac OS X and Win XP… -Frank Frank Midgley HHMI JFRC - Scientific Computing midgl...@janelia.hhmi.org (571) 209-4629 ___ 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] Registry object cache observations / questions
Hi Tim, On Tue, Aug 4, 2009 at 9:31 PM, Tim Mooretimo...@redhat.com wrote: It's not critical as far as we're concerned. OK, I'll patch the OSG-2.8 branch but not worry too much about a 2.8.3. If we later need a 2.8.3 for other reasons then it could rolled into this. I've made most of the changes to svn/trunk to move the flush of the cache into osgViewer::Viewer/CompositeViewer rather than osgDB::DatabasePager. This actually cleans things up w.r.t a CompositeViewer, as with multiple scene's the object cache will have been clear multiple times per frame, and also fixes the general case of where no DatabasePager is assigned but the object cache is used. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBOs without color or depth attachments / DrawBuffer / ReadBuffer
Hi Wojtek, Comments interspersed below. On Tue, Aug 4, 2009 at 11:47 PM, Wojciech Lewandowskilewandow...@ai.com.pl wrote: (1) We agreed that we may now remove the code forcing attachment of color/depth buffers to FBO when user had not attached such buffer. To relax FBO requirements its neeccessary to refactor DrawBuffer/ReadBuffer management. Specifically, we need to allow for explicit setting of GL_NONE for DrawBuffer ReadBuffer. Current implementation does use GL_NONE flag but interprets it more like INHERIT BUFFER SETTING FROM PARENT value. In practice glDrawBuffer( GL_NONE ) and glReadBuffer( GL_NONE ) is not called by OSG. (2) We also agreed that it would be nice if we could add setDrawBuffer/setReadBuffer methods to State and change buffers in 'lazy update' manner. I promised I would try to come up with solution and post a submission implementing above proposals. I considered couple options and decided that best approach to implementing (1) would be adding DRAW_BUFFER / READ_BUFFER to CullSettings::VariablesMask flags. As we are going to allow for GL_NONE buffers in their verbatim meaning, we need to specifcally define methods to allow cameras inherit or override buffer settings from their parents. I think it will be appropriate to handle this in similar way Camera::_clearColor is handled. CullSettings::CLEAR_COLOR mask defines whether ClearColor is inherited or overriden. CullSettings::DRAW_BUFFER and CullSettings::READ_BUFFER could be introduced and interpreted in the same way with Camera::_drawBuffer, Camera::_readBuffer variables. Do you approve such a plan of extending CullSettings masks for use with DrawBuffer and ReadBuffer ? I think this would be appropriate - i.e. to extend CullSettings to default to inheriting the _readBuffer and _drawBuffer values, and on setting change this inheritance mask to allow the variable to be used. Other members of CullSettings work this way so look at these for a template. I also have a decision problem with feature (2): I wanted to add following osg::State methods and variables State::_drawBuffer void State::setDrawBuffer( GLuint ) GLuint State::getDrawBuffer( void ) State::_readBuffer void State::setReadBuffer( GLuint ) GLuint State::getReadBuffer( void ) Difficulty here is related to proper setting of default values of State::_readBuffer and State::_drawBuffer. OpenGL spec says that defaults depend on context. They are set to GL_BACK for double buffered contexts and set to GL_FRONT for single buffered contexts. When State is created its not yet known with which context it would be used. I came up with 2 possible solutions: (A) Changing State::_drawBuffer/_readBuffer defaults after associating State with GraphicsContext. This is usually done in GraphicsWindow(or its subclass)::init virtual method. This method would have to call state-setDrawBuffer/setReadBuffer to initialize defaults properly. Drawbacks: - many classes deriving from GraphicsWindow - many changes need to be done. - not sure what defaults should be applied for SharedContexts and external contexts for windows created by the users. - I am hesitant to modify all GraphicsWindow subclasses::init because I am mainly Windows progrmammer. I'am afraid I may break something in Linux or MacOS. (B) Read buffer defaults ( glGet(GL_DRAW_BUFFER) ) set in GL Context when State sees context for the first time. Good place for this would be State::initializeExtensionProcs method. Drawbacks: - initializeExtensionProcs is mainly used for setting OpenGL context / State capability variables like number of texture stages etc. Setting DrawBuffer/ReadBuffer defaults would be (dangerous?) precedence of StateAttributes/StateModes like initialization. Which option do You prefer here ? I don't prefer either I wonder if a has been applied flags could be used in osg::State to accompany the _drawBuffer and _readBuffer member variables, and if the variables haven't yet been applied to OpenGL the previous value is ignored and the gl calls are made regardless of whether previous value held in osg::State. This way the default effectively doesn't existing and the calling code will always set it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dashboard error
Hi Sukender, Are you still seeing these problems? Robert. On Tue, Aug 4, 2009 at 8:36 AM, suky0...@free.fr wrote: Hi Jose-Luis et al Either the dashboard does not respond, or I get the folowing error: no handler found Warning: error_log(backup/cdash.log) [function.error-log]: failed to open stream: Permission denied in /home/www/cdash_OSG/cdash/common.php on line 192 Hope it helps :) 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
Re: [osg-users] Perspective / Orthogonal projection matrix with CameraManipulator
Hi Robert, Thanks for your reply. Yes I realise the problems inherent in making an orthogonal view behave like a perspective view. What I'm trying to do however is create a plan view on a CAD like application for oil rigs. So imagine in perspective view you can move around the rig, in plan view you want to see it top down, everything's in wireframe, sort of like a blueprint. I need the ability to zoom in the plan view, but not rotate or move forwards/backwards, literally just pan/zoom. I noticed osg::Camera offers more direct access to the view/projection than the camera manipulator (which only affects the View), so I've dumped camera manipulator and created two cameras - perspective / plan. Then I am directly updating the camera in the perspective/plan mode from my own event handling code. (In addition I need multiple other cameras that I can position around the scene in perspective mode and switch to on various key presses). One problem - I am trying to swap the cameras in/out of the osg::Viewer so I was using osg::Viewer::setCamera and getCamera to get/set the default camera, however it is not behaving as expected. Is this the right way to set the default camera? I just one one to render at a time, not to composite the view. If I sort the orthogonal code (Plan view) I'll post it here for reference purposes. Thank you, Andrew On Wed, Aug 5, 2009 at 8:23 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Andrew, I would not recommend trying to make an orthographic view behave like a perspective view, it simple doesn't work (this is not an OSG issue, but the basic principles involved.) I've written about this before so I won't waste my key presses have a look through the archives. The upshot is I would suggest keeping orthographic views for fixed maps/side/front views, or very constrained user interaction models. If you try to make a orthographic behave like a perspective you'll just waste lots of time. Robert. On Thu, Jul 30, 2009 at 6:22 PM, Andrew Thompsonandyb1...@yahoo.co.uk wrote: Hi there, I am using a custom CameraManipulator class (inheriting osgGA::MatrixManipulator) which is added to my scene after the OpenSceneGraph is initialised The CameraManipulator has two member variables I've added, a Vec3d target and position. These are used to create a projection matrix by calling Matrix::makeLookAt. As the events are handled by the manipulator, I am updating the position/target and recomputing the matrix, then on Frame I am returning the constructed matrix. This provides a great perspective view, however I cannot work out how to construct an orthogonal projection using a target/position. In addition, I'd like to be able to change the Field Of View when I create the matrix. I realise there is a Matrix::makeOrtho and Matrix::makePerspective, however I'm not sure how to use these with my CameraLocation/Target variables. Could anyone offer me some advice? Thank you! Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15659#15659 ___ 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] Perspective / Orthogonal projection matrix with CameraManipulator
Hi Andrew, On Wed, Aug 5, 2009 at 9:35 AM, Andrew Burnett-Thompsonaburnettthomp...@googlemail.com wrote: I noticed osg::Camera offers more direct access to the view/projection than the camera manipulator (which only affects the View), so I've dumped camera manipulator and created two cameras - perspective / plan. Yes this would be doable, although having two separate views in CompositeViewer might be more logical an easier to manage. Then I am directly updating the camera in the perspective/plan mode from my own event handling code. (In addition I need multiple other cameras that I can position around the scene in perspective mode and switch to on various key presses). One problem - I am trying to swap the cameras in/out of the osg::Viewer so I was using osg::Viewer::setCamera and getCamera to get/set the default camera, however it is not behaving as expected. What problem are you seeing? Using the viewer.getCamera()-set..MatrixAs..(..) methods work fine, but if you need to make sure that you aren't also attaching a CameraManipulator as this will overwrite your values on each frame. Is this the right way to set the default camera? Just use the Camera that is already assigned to the Viewer. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg on iPhone / iPod touch with OpenGL ES 1.1
Hi All, Just for your information : http://www.computamaps.com/assets/press/iphone.htm regards adrian 2009/7/17 Robert Osfield robert.osfi...@gmail.com Hi Marco, No OpenGL ES 1.x code has been checked in yet, but there have been successful trail ports to OpenGL ES 1.x. Next week I'll just so happen to be with a client interested in this side of work, although not related to the iFamilyOfProducts, so hopefully we'll be able to come up with clearer strategy for getting OpenGL ES 1.x support integrated into the core OSG. The likely approach will be to initially start with a branch in our svn repository for the port to OpenGL ES, and then have me refactor svn/trunk to step by step pull in the changes till we have svn/trunk compatible with OpenGL ES 1.x and then later with openGL ES 2.x. The time frame is difficult to pinpoint right now as it depends on various different groups coordinating work as well just how quickly the technical challenges are surmounted. I would hope that we could see a OpenSceneGraph-2.12 release (the next stable release after the imminent OSG-2.10 release) with OpenGL ES 1.x support this autumn. Cheers, Robert. On Thu, Jul 16, 2009 at 5:28 PM, Marco Lohsemlo...@motama.com wrote: Since this is my first post: First of all, thank you for osg! We would be interested in a OpenGL ES 1.1 version for running our osg based applications on iPhone / iPod touch using Open GL ES 1.1 I found some references saying that there will be support for this platform. Now, I would like to know what the current status is, what still needs to be done, etc. I would also be interested in knowing the current status and plans for Open GL ES 2.0 (for the latest iPhone versions). We are willing to help with beta-testing, and - depending on the current status - also to do some coding. I would appreciate your comments Thank you! Marco -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15037#15037 ___ 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBOs without color or depth attachments /DrawBuffer / ReadBuffer
Robert,
Thanks for the quick answers.
[..]
Do you approve such a plan of extending CullSettings masks for use with
DrawBuffer and ReadBuffer ?
I think this would be appropriate - i.e. to extend CullSettings to
default to inheriting the _readBuffer and _drawBuffer values, and on
setting change this inheritance mask to allow the variable to be used.
Other members of CullSettings work this way so look at these for a
template.
Thats what I plan to do. I picked up Camera::_clearColor handling example
for the same purpose.
[..]
Which option do You prefer here ?
I don't prefer either
I wonder if a has been applied flags could be used in osg::State to
accompany the _drawBuffer and _readBuffer member variables, and if the
variables haven't yet been applied to OpenGL the previous value is
ignored and the gl calls are made regardless of whether previous value
held in osg::State. This way the default effectively doesn't existing
and the calling code will always set it.
I agree, it seems the best option. Using existing framework like
haveAppliedAttribute would mean that we want to make DrawBuffer/ReadBuffer
an attribute. I am not sure if this is what you are after ? To some degree
it makes sense, I can imagine that someone may want to add such state in
StateSet to turn off DrawBuffer to draw to depthBuffer only.
But on the other hand I have the feeling that image/texture read may be
vulnerable to unexpected readBuffer changes. So maybe it wil be better to
not make DrawBuffer/ReadBuffer attributes but treat them independently like
I propesed earlier + add extra flags bool: _drawBufferValid,
_readBufferValid and corresponding logic and methods to make sure that
first setDrawBuffer/setReadBuffer is always apllied.
This is an example how osg::State::setDrawBuffer method would look in this
scenario:
void osg::State::setDrawBuffer( GLenum bufferMode )
{
if( !_drawBufferValid || _drawBuffer != bufferMode )
{
glDrawBuffer( bufferMode )
_drawBuffer = bufferMode;
_drawBufferValid = true;
}
}
If you accept that, I am rolling up my sleeves and start work ;-)
Wojtek
___
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] OSG and shaders
Hi, @btrall: Where do you find this ShaderGen? I found it neither in the classlist nor the osg examples. @carnibirdy: Rewritting the lights effects and texture mapping in the shader is quite easy. You can find implementation examples here (http://www.typhoonlabs.com/), in the OpenGL Shading Language Course part or here (http://www-evasion.imag.fr/Membres/Sebastien.Barbier/Enseignement/tp_glsl.zip) for several shaders, including a phong lighting. For the texture mapping see this post (http://forum.openscenegraph.org/viewtopic.php?t=3293). Have fun! Cheers, Maxime -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15829#15829 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to draw a Curved Surface on the top of terrain?
Hi Jason, Last time I checked (half a year ago), osggis did no create a curved polygon when creating a filled polygon for e.g. Russia. Since no sampling points are created inside the polygon the tessellated triangles goes straight from one edge to the other thought the ground. It would be great news if this has been fixed i later versions of osggis! Please let me know. // John Jason Beverage wrote: Hi Lipan, You could look into using projected textures with the osgSim::OverlayNode or if you are rendering vector data such as that from an ESRI shapefile I'd recommend looking at osggis at http://www.osggis.org. Jason On Mon, Aug 3, 2009 at 7:15 AM, Pan Li osg...@163.com mailto:osg...@163.com wrote: Hi, 1、how to draw a Curved Surface on the top of terrain? like the fig1. 2、how to compute the surface area of the Curved Surface? any examples?? thanks a lot!! Cheers, lipan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15723#15723 ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, 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 -- Best regards, John WeatherOne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using GLObjectsVisitor with DrawThreadPerContext
Hi, In our application we create new objects in runtime. Most of the time newly created objects are not in frustum in the beginning hence they do not result in a stutter But, when the object comes into the frustum texture download and display list creation results in stutters. It is acceptable for us to have stutter when the object is created so whenever we create an object we use GLObjectVisitor to compile GL objects. We do this in a FinalDrawCallback. The problem we are facing is that this results in crashes. The crash is very rare. Sometimes more than an hour passes with hundreds of objects created and destroyed. There are some computers; however, where the problem is far more frequent. The difference of these computers is that they have Quaddro cards and more powerful CPU's. Our application uses DrawThreadPerContext and all test computers have at least two CPU's. When we run in SingleThreaded mode we do not see any problems. So the question is whether it is safe to use GLObjectsVisitor in a FinalDrawCallback? If not, how should it be used? General info: OS: Suse 10.3 CPU: Several different CPU's (at least two CPU) Graphics : Several different NVidia cards OSG: 2.9.5 (SVN version 10258) Tugkan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using GLObjectsVisitor with DrawThreadPerContext
Hi Tugkan, I don't know offhand why it's crashing, but in svn/trunk there is now a helper class for incrementally compiling OpenGL objects prior to merging with the scene graph to help prevent frame drops. The class is osgUtil::IncrementalCompileOperation, and this can be assigned to the Viewer/CompositeViewer using: /** Set the incremental compile operation. * Used to manage the OpenGL object compilation and merging of subgraphs in a way that avoids overloading * the rendering of frame with too many new objects in one frame. */ void setIncrementalCompileOperation(osgUtil::IncrementalCompileOperation* ico); Robert. On Wed, Aug 5, 2009 at 10:48 AM, Tugkan Calapoglutug...@vires.com wrote: Hi, In our application we create new objects in runtime. Most of the time newly created objects are not in frustum in the beginning hence they do not result in a stutter But, when the object comes into the frustum texture download and display list creation results in stutters. It is acceptable for us to have stutter when the object is created so whenever we create an object we use GLObjectVisitor to compile GL objects. We do this in a FinalDrawCallback. The problem we are facing is that this results in crashes. The crash is very rare. Sometimes more than an hour passes with hundreds of objects created and destroyed. There are some computers; however, where the problem is far more frequent. The difference of these computers is that they have Quaddro cards and more powerful CPU's. Our application uses DrawThreadPerContext and all test computers have at least two CPU's. When we run in SingleThreaded mode we do not see any problems. So the question is whether it is safe to use GLObjectsVisitor in a FinalDrawCallback? If not, how should it be used? General info: OS: Suse 10.3 CPU: Several different CPU's (at least two CPU) Graphics : Several different NVidia cards OSG: 2.9.5 (SVN version 10258) Tugkan ___ 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] Feature request for 2.9: please include swig bindings in main release
A couple of points:
Firstly it is possible to inject C++ code in to Python quite easily using
scipy.weave. And using a cast in the C++ and the .this member in the Python
swig wrappers makes marshaling data between the two quite easy.
So you can write code like this:
Code:
v = mesh.vertices
f = mesh.faces.flatten()
tri_geometry = osg.Geometry()
verts = osg.Vec3Array()
faces = osg.DrawElementsUInt(osg.PrimitiveSet.TRIANGLES,0)
# Fix for problems with vectors, but also _much_ faster
pVerts = int(verts.this)
pFaces = int(faces.this)
mesh2osgCode =
osg::Vec3Array *verts = (osg::Vec3Array *)pVerts;
osg::DrawElementsUInt *faces = (osg::DrawElementsUInt *)pFaces;
//Set up vertex array
verts-reserve(v_array-dimensions[0]);
int v_s0 = v_array-strides[0] / sizeof(double);
int v_s1 = v_array-strides[1] / sizeof(double);
double *begin = v;
double *end = v + (v_array-dimensions[0] * v_s0);
for (double *p = begin; p end ;p += v_s0) {
double a = *p;
double b = *(p + v_s1);
double c = *(p + v_s1 + v_s1);
verts-push_back( osg::Vec3(a,b,c) );
}
//Set up faces
faces-reserve(f_array-dimensions[0]);
int f_s0 = f_array-strides[0] / sizeof(long int);
long int *f_begin = f;
long int *f_end = f + (f_array-dimensions[0] * f_s0);
for (long int *p = f_begin; p f_end ;p += f_s0) {
faces-push_back( *p );
}
scipy.weave.inline(mesh2osgCode,[v,f,pVerts,
pFaces],headers=[osg/Geometry],libraries=[osg],include_dirs=[/home/joe/include],
library_dirs=[/home/joe/lib])
tri_geometry.setVertexArray(verts)
tri_geometry.addPrimitiveSet(faces)
This example is a little complex as it is reading data from the numpy array
data structure, but it has the benefit of (a) working and (b) being much faster
than trying to move all that data around in pure Python.
Secondly, I've been reading up on SWIG but not had time to play around with
things yet. I was thinking that SWIG runs in two passes - the first one parses
the code to work out what to wrap, the second pass compiles code to make the
wrappers. What we want to do is to tell SWIG that MixinVectors are std::vectors
during that first phase, but let it compile against the correct code in the
second phase. Will this work? Might it be as simple as adding:
Code:
#ifdef SWIG
#define MixinVector std::vector
#endif
I'll have a play around later, but there are maybe some other ways to do this
based on the fact that we don't need SWIG to build against std::vector, we just
need it to parse MixinVector as if it was a std::vector. Well, I think that's
what is needed, I'm only just starting to look at this so I might be completely
wrong.
Of course a helper function to convert between osg::Arrays and numpy.arrays
would be much more useful to me in practice...
Cheers,
Joe
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=15833#15833
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT problem - missing faces
Hi Robert, thank you for your answer. I'll try to give some more details on the current setup: - multiple physical displays/projectors which overlap to produce a single (flat-)screen - alignment and blending of the displays is done with the 3rd-party stuff - the displays support checkerboard-stereo In mono-mode my integration of OSG and the 3rd party stuff works perfectly and all display do what they are supposed to do. The post-processing is done in the camera's postDrawCallback without any magic :) The problem starts when I enable OSGs checkerboard-stereo because the image-distortion in the postDrawCallback will result in an unusable checkerboard-frame. So basically I'm trying to get checkerboard-stereo to work. Due to the described problem, I need access to the left and right frames to distort them individually. Normally they are blend together via stenciling in osg::RenderStage::draw(). As far as I know, there is no direct access to these frames. I could either implement some kind of callback into OSG or implement a variant of checkerboard-stereo myself. Currently I'm trying to render both frames individually to an FBO and putting them together afterwards. In this case I would have control of both frames and I would be able to manipulate them with the help of the 3rd-party code. osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't able to do the trick since I've found no way to access the FBO OSG utilizes. Therefore I've tried my own implementation (currently on a single display) with the following setup and the given result in the post before (take a look at the attached picture). The current implementation is very similiar to the osgprerender example (stereo is not enabled) except that I'm creating my own FBO in a preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and is used as the rendertarget for the first (left) (RTT-)camera. RenderTargetImplementation for this camera has not been explicitly set. The texture is attached to a rectangular geometry, which is itself a child of the osgViewers camera. Unfortunately the result of the RTT looks like the attached image. The image was saved in the postDrawCallback. I'm pretty sure I've messed something up or missed something. RTT with OSGs FBO works fine and I've looked at the code but I didn't find anything. Does someone have an idea? Or maybe another way to implement checkerboard-stereo? It looks like some faces get culled away. If its useful I'll post some code. @Robert: I'm not using osgUtils low level stereo right now but I guess some of the code would later be useful to get the correct left and right camera-position-setup. Nice greetings and thanks for any help or hint! Mathias Buhr P.S.: I was already able to do the distortion with that implementation (with blitting the FBO-image back to the window-system provided FB to get the 3rd party stuff working). Am 04.08.09 19:14, schrieb Robert Osfield: Hi Mathias, You don't really provide enough info about your overall viewer setup to give a direct answer. It sounds like you are using the OSG's low level stereo support in osgUtil and combining this with a 3rd party code that does distortion correction or similar. Doing low level stereo and distortion correction is really going to work visually even if you got it to work code wise, as the low level stereo support in osgUtil assumes a flat display. Have a bash at explaining what your system is trying to do at a high level and then others will have a better chance of suggesting how to go about it. Robert. On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhrmathias...@gmx.de wrote: Hi, before going into the details of the problem, I'd like to explain what I'm trying to do and what I have done until now. I have a 3rd-party function/method which is out of my scope. It seems to read and write the window-system provided framebuffer and manipulates/distorts the image. The first implementation was through calling this function in a postdraw-callback. Everything works fine this way. Unfortunately this is not possible if the CHECKBOARD flag is set because the postdraw-callback is called after the complete frame (including the stenceling for the checkerboard) is rendered. The function would distort the checkerboard. Hence, I have to apply this function for each eye separately. This seems possible with some changes to OSG itself but it also would break the possibilty to upgrade later. So I decided to take another approach: I've tried rendering to an FBO (RTT, similar to osgprerender) but I can't apply the function anymore in the postdraw-callback (gives GL errors). Since there is no access to the OSG-managed FBO (for bliting from FBO to FB) I have implemented my own and rendered to that instead. I'll give you a brief overview for that: MainCamera - addChild(QUAD_STRIP)//an osg:Geode with an osg::Texture2D - addChild(LeftCamera) -
Re: [osg-users] Deadlock when loading osg.dll, singletons are evil
Hi Robert, It is indeed a Windows specific issue. If you get the chance to test the example on a Windows machine, it would really be appreciated. Aymeric and I have spent 3 days tracking, understanding and reproducing the problem. As a consequence, a fair amount of detailed technical explanation and MSDN references have been posted on this discussion to illustrate it. It is indeed a problem that requires a specific set of conditions to be triggered. It mainly requires a Windows application to be already running several threads when loading another dll (in the example, the dll is explicitly loaded to easily to reproduce the problem). It is a form of subtle and intricate race condition. We've had that potential race condition in our code for many months, but it was not until recently that the we saw that deadlock occurs in a consistent manner. Hence, I'm not surprised that nobody reported this issue before. I apologize if I've appeared too emotional. The fact that the discussion has been mixing two points (the deadlock technical details and the singleton design critic) is probably not helping. Although I will not hide what I think about singletons. Just in the last two weeks, not counting the deadlock with osg.dll, we've spent quite a long time tracking two thread-safety issues in OpenSSL and LibCurl that are actually related to the singleton design (for the story, the OpenSSL developers have acknowledged it as an API limitation and the LibCurl developers have already committed a fix). Hence, it may not be surprising that I appear emotional about singletons. My experience leads me to disagree on the statement that singletons help in having a loosely coupled design. I think that singletons are actually a hidden and tightly coupling design. To come back to the deadlock issue, I don't think there is any way to fix it without breaking the current OSG API compatibility. While I would favour removing the singletons (and would heavily suggest other designs for OSG 3.0), I perfectly understand and agree with you that such an approach is unacceptable in the short term. The least disruptive solution I can think of (while being quite robust) would be to introduce an initOsg() and a destroyOsg() function. It's a fairly common approach and is in fact the one mandated by MSDN regarding the limitations of DllMain (and the deadlocks that may follow if violated). initOsg() would initialize and construct all the global variables of Osg when called, while destroyOsg() would take care of the destruction of such objects. The benefits are twofold: - The user would have a better control on the lifetime of the OSG and its global variables (among other things, solving the deadlock issue exposed in this discussion). - The user would have the ability to reset the library in a predictable manner, which is currently impossible. A few points should be observed: 1. init/destroyOsg needs to be referenced counted (allowing multiple and re-entrant initializations) 2. init/destroyOsg needs to be thread-safe 3. init/destroyOsg needs to be aware that osg is divided into several components (e.g. osg, osgDB, osgViewer, etc). It would probably be needed that the user can in fact select which components of osg he wants to init/destroy (in which case points 1 and 2 need to be done per component). Regards, Tanguy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 05 August 2009 08:56 To: OpenSceneGraph Users Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are evil Hi Tanguy, I don't have a windows box to test against so can't do anything first hand. It does very much sound like Windows threading issue that will require a specific Windows mechanism in your application set up to avoid hitting these problems. I don't what what the solution might be, but perhaps it would require serialization of all system calls like getenv. The solution will not be ditching singletons. They are extremely useful to design and implementation of the OSG. You simply can't replace them without major surgery of API and implementation, and even if you did you'd loose significant flexibility and function - something which is currently loosely coupled (yes a great OO asset) would end up be far more tightly coupled than it is now. Please remember that the OSG is used heavily by thousands of developers on thousands of applications across dozens of platforms, with many applications which are heavily threaded - and it's been under decades development without this issue cause problems. The problems you are seeing are serious, but they aren't the norm, it's because of your particular application usage model and platform. I'm certainly open to finding an OSG solution, but it'll have to be unobtrusive and require minimal code and API changes, otherwise it simply won't be merged as the cost and
Re: [osg-users] RTT problem - missing faces
HI Mathias, Given your setup it's pretty clear that you'd need to not use the OSG in built stereo support (that is implemented internally using osgUtil::SceneView), and instead setup up two slave camera sets that do the render to texture/post render for each eye and in the final step do the checkboard stereo at the same time. Robert. On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhrmathias...@gmx.de wrote: Hi Robert, thank you for your answer. I'll try to give some more details on the current setup: - multiple physical displays/projectors which overlap to produce a single (flat-)screen - alignment and blending of the displays is done with the 3rd-party stuff - the displays support checkerboard-stereo In mono-mode my integration of OSG and the 3rd party stuff works perfectly and all display do what they are supposed to do. The post-processing is done in the camera's postDrawCallback without any magic :) The problem starts when I enable OSGs checkerboard-stereo because the image-distortion in the postDrawCallback will result in an unusable checkerboard-frame. So basically I'm trying to get checkerboard-stereo to work. Due to the described problem, I need access to the left and right frames to distort them individually. Normally they are blend together via stenciling in osg::RenderStage::draw(). As far as I know, there is no direct access to these frames. I could either implement some kind of callback into OSG or implement a variant of checkerboard-stereo myself. Currently I'm trying to render both frames individually to an FBO and putting them together afterwards. In this case I would have control of both frames and I would be able to manipulate them with the help of the 3rd-party code. osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't able to do the trick since I've found no way to access the FBO OSG utilizes. Therefore I've tried my own implementation (currently on a single display) with the following setup and the given result in the post before (take a look at the attached picture). The current implementation is very similiar to the osgprerender example (stereo is not enabled) except that I'm creating my own FBO in a preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and is used as the rendertarget for the first (left) (RTT-)camera. RenderTargetImplementation for this camera has not been explicitly set. The texture is attached to a rectangular geometry, which is itself a child of the osgViewers camera. Unfortunately the result of the RTT looks like the attached image. The image was saved in the postDrawCallback. I'm pretty sure I've messed something up or missed something. RTT with OSGs FBO works fine and I've looked at the code but I didn't find anything. Does someone have an idea? Or maybe another way to implement checkerboard-stereo? It looks like some faces get culled away. If its useful I'll post some code. @Robert: I'm not using osgUtils low level stereo right now but I guess some of the code would later be useful to get the correct left and right camera-position-setup. Nice greetings and thanks for any help or hint! Mathias Buhr P.S.: I was already able to do the distortion with that implementation (with blitting the FBO-image back to the window-system provided FB to get the 3rd party stuff working). Am 04.08.09 19:14, schrieb Robert Osfield: Hi Mathias, You don't really provide enough info about your overall viewer setup to give a direct answer. It sounds like you are using the OSG's low level stereo support in osgUtil and combining this with a 3rd party code that does distortion correction or similar. Doing low level stereo and distortion correction is really going to work visually even if you got it to work code wise, as the low level stereo support in osgUtil assumes a flat display. Have a bash at explaining what your system is trying to do at a high level and then others will have a better chance of suggesting how to go about it. Robert. On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhrmathias...@gmx.de wrote: Hi, before going into the details of the problem, I'd like to explain what I'm trying to do and what I have done until now. I have a 3rd-party function/method which is out of my scope. It seems to read and write the window-system provided framebuffer and manipulates/distorts the image. The first implementation was through calling this function in a postdraw-callback. Everything works fine this way. Unfortunately this is not possible if the CHECKBOARD flag is set because the postdraw-callback is called after the complete frame (including the stenceling for the checkerboard) is rendered. The function would distort the checkerboard. Hence, I have to apply this function for each eye separately. This seems possible with some changes to OSG itself but it also would break the possibilty to upgrade later. So I decided to take another approach: I've tried
Re: [osg-users] Deadlock when loading osg.dll, singletons are evil
Hi Tanguy, On Wed, Aug 5, 2009 at 12:55 PM, Tanguy Fautretang...@aristechnologies.com wrote: To come back to the deadlock issue, I don't think there is any way to fix it without breaking the current OSG API compatibility. While I would favour removing the singletons (and would heavily suggest other designs for OSG 3.0), I perfectly understand and agree with you that such an approach is unacceptable in the short term. Um... I have yet to see a compelling reason for not using singletons like Registry or a decent proposal for a replacement. For OSG-3.0 my plan is to focus on refactoring just the core scene graph and how rendering is implemented, for the rest of the API changes we should keep as minimal as possible to try and reduce to headache of porting from OSG-2.x to OSG-3.x. We can't avoid refactoring the core scene graph state management to be able to do shader composition, but the rest of changes we minimize. The least disruptive solution I can think of (while being quite robust) would be to introduce an initOsg() and a destroyOsg() function. It's a fairly common approach and is in fact the one mandated by MSDN regarding the limitations of DllMain (and the deadlocks that may follow if violated). My gut reaction is YUK. Design wise, implementation wise and support wise I know it's a hack. initOsg() would initialize and construct all the global variables of Osg when called, while destroyOsg() would take care of the destruction of such objects. OK. So this uber initOsg() method would need to initialize all global variables and hence know about all global variance and hence be tightly coupled with all global variables. Now if you have a very simply set of libs to work with, and everything is fixed in it's relationship this might work, but... if you have a loosely coupled design that allows you to extend it at runtime what then?? For instance NodeKits... who inits these? Do we have explict init's for each NodeKit the user might use. What about NodeKits that are pulled in at runtime to enable the loading of a particular databases? The benefits are twofold: - The user would have a better control on the lifetime of the OSG and its global variables (among other things, solving the deadlock issue exposed in this discussion). - The user would have the ability to reset the library in a predictable manner, which is currently impossible. A few points should be observed: 1. init/destroyOsg needs to be referenced counted (allowing multiple and re-entrant initializations) 2. init/destroyOsg needs to be thread-safe 3. init/destroyOsg needs to be aware that osg is divided into several components (e.g. osg, osgDB, osgViewer, etc). It would probably be needed that the user can in fact select which components of osg he wants to init/destroy (in which case points 1 and 2 need to be done per component). OK state all possible benefits and ignore the monstrous downsides such as tight coupling and blowing out of the water the extensibility that the OSG is known for. I sure want to see a good solution to the problems you are seeing but I won't idly stand by while the OSG is made less easy to use and less extensible. You go explain to all the thousands of OSG users that having to re-factor they code for no gain, whilst compromising in extensibility that just supporting your particular usage pattern. What we have at hand is very specific issue that occurs when a very specific set of things are done in a client application, it's not a general problem that requires a major re-factor. Careful initiation at your end may well be the solution. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and shaders
On 5/08/09 11:41 AM, Maxime BOUCHER wrote: @btrall: Where do you find this ShaderGen? I found it neither in the classlist nor the osg examples. It could be that it's not part of 2.8 but in trunk it's in: src/osgUtil/ShaderGen.cpp include/osgUtil/ShaderGen examples/osgshadergen/osgshadergen.cpp Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT problem - missing faces
Yes, thats exactly the plan but I need the images back in the FB to get the 3rd party stuff working. This means I have to call glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to distortion-code or the function won't work. This assumes the image in GL_BACK and GL_BACK has to be stored to the FBO afterwards. How to do this? Greetings MAthias Am 05.08.09 14:08, schrieb Robert Osfield: HI Mathias, Given your setup it's pretty clear that you'd need to not use the OSG in built stereo support (that is implemented internally using osgUtil::SceneView), and instead setup up two slave camera sets that do the render to texture/post render for each eye and in the final step do the checkboard stereo at the same time Robert. On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhrmathias...@gmx.de wrote: Hi Robert, thank you for your answer. I'll try to give some more details on the current setup: - multiple physical displays/projectors which overlap to produce a single (flat-)screen - alignment and blending of the displays is done with the 3rd-party stuff - the displays support checkerboard-stereo In mono-mode my integration of OSG and the 3rd party stuff works perfectly and all display do what they are supposed to do. The post-processing is done in the camera's postDrawCallback without any magic :) The problem starts when I enable OSGs checkerboard-stereo because the image-distortion in the postDrawCallback will result in an unusable checkerboard-frame. So basically I'm trying to get checkerboard-stereo to work. Due to the described problem, I need access to the left and right frames to distort them individually. Normally they are blend together via stenciling in osg::RenderStage::draw(). As far as I know, there is no direct access to these frames. I could either implement some kind of callback into OSG or implement a variant of checkerboard-stereo myself. Currently I'm trying to render both frames individually to an FBO and putting them together afterwards. In this case I would have control of both frames and I would be able to manipulate them with the help of the 3rd-party code. osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't able to do the trick since I've found no way to access the FBO OSG utilizes. Therefore I've tried my own implementation (currently on a single display) with the following setup and the given result in the post before (take a look at the attached picture). The current implementation is very similiar to the osgprerender example (stereo is not enabled) except that I'm creating my own FBO in a preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and is used as the rendertarget for the first (left) (RTT-)camera. RenderTargetImplementation for this camera has not been explicitly set. The texture is attached to a rectangular geometry, which is itself a child of the osgViewers camera. Unfortunately the result of the RTT looks like the attached image. The image was saved in the postDrawCallback. I'm pretty sure I've messed something up or missed something. RTT with OSGs FBO works fine and I've looked at the code but I didn't find anything. Does someone have an idea? Or maybe another way to implement checkerboard-stereo? It looks like some faces get culled away. If its useful I'll post some code. @Robert: I'm not using osgUtils low level stereo right now but I guess some of the code would later be useful to get the correct left and right camera-position-setup. Nice greetings and thanks for any help or hint! Mathias Buhr P.S.: I was already able to do the distortion with that implementation (with blitting the FBO-image back to the window-system provided FB to get the 3rd party stuff working). Am 04.08.09 19:14, schrieb Robert Osfield: Hi Mathias, You don't really provide enough info about your overall viewer setup to give a direct answer. It sounds like you are using the OSG's low level stereo support in osgUtil and combining this with a 3rd party code that does distortion correction or similar. Doing low level stereo and distortion correction is really going to work visually even if you got it to work code wise, as the low level stereo support in osgUtil assumes a flat display. Have a bash at explaining what your system is trying to do at a high level and then others will have a better chance of suggesting how to go about it. Robert. On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhrmathias...@gmx.dewrote: Hi, before going into the details of the problem, I'd like to explain what I'm trying to do and what I have done until now. I have a 3rd-party function/method which is out of my scope. It seems to read and write the window-system provided framebuffer and manipulates/distorts the image. The first implementation was through calling this function in a postdraw-callback. Everything works fine this way. Unfortunately this is not possible if the CHECKBOARD flag is set because the postdraw-callback is called after the complete frame
Re: [osg-users] how to draw a Curved Surface on the top of terrain?
No - osggis does not drape polygon geometries. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Wed, Aug 5, 2009 at 5:45 AM, John Vidar Larring larr...@weatherone.tvwrote: Hi Jason, Last time I checked (half a year ago), osggis did no create a curved polygon when creating a filled polygon for e.g. Russia. Since no sampling points are created inside the polygon the tessellated triangles goes straight from one edge to the other thought the ground. It would be great news if this has been fixed i later versions of osggis! Please let me know. // John Jason Beverage wrote: Hi Lipan, You could look into using projected textures with the osgSim::OverlayNode or if you are rendering vector data such as that from an ESRI shapefile I'd recommend looking at osggis at http://www.osggis.org. Jason On Mon, Aug 3, 2009 at 7:15 AM, Pan Li osg...@163.com mailto: osg...@163.com wrote: Hi, 1、how to draw a Curved Surface on the top of terrain? like the fig1. 2、how to compute the surface area of the Curved Surface? any examples?? thanks a lot!! Cheers, lipan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15723#15723 ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, 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 -- Best regards, John WeatherOne ___ 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] RTT problem - missing faces
Hi Mathias, I can't really give you any recommendation as you are already doing custom code w.r.t FBO which means there is too many unknowns for me to guess at. Robert. On Wed, Aug 5, 2009 at 1:31 PM, Mathias Buhrmathias...@gmx.de wrote: Yes, thats exactly the plan but I need the images back in the FB to get the 3rd party stuff working. This means I have to call glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to distortion-code or the function won't work. This assumes the image in GL_BACK and GL_BACK has to be stored to the FBO afterwards. How to do this? Greetings MAthias Am 05.08.09 14:08, schrieb Robert Osfield: HI Mathias, Given your setup it's pretty clear that you'd need to not use the OSG in built stereo support (that is implemented internally using osgUtil::SceneView), and instead setup up two slave camera sets that do the render to texture/post render for each eye and in the final step do the checkboard stereo at the same time Robert. On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhrmathias...@gmx.de wrote: Hi Robert, thank you for your answer. I'll try to give some more details on the current setup: - multiple physical displays/projectors which overlap to produce a single (flat-)screen - alignment and blending of the displays is done with the 3rd-party stuff - the displays support checkerboard-stereo In mono-mode my integration of OSG and the 3rd party stuff works perfectly and all display do what they are supposed to do. The post-processing is done in the camera's postDrawCallback without any magic :) The problem starts when I enable OSGs checkerboard-stereo because the image-distortion in the postDrawCallback will result in an unusable checkerboard-frame. So basically I'm trying to get checkerboard-stereo to work. Due to the described problem, I need access to the left and right frames to distort them individually. Normally they are blend together via stenciling in osg::RenderStage::draw(). As far as I know, there is no direct access to these frames. I could either implement some kind of callback into OSG or implement a variant of checkerboard-stereo myself. Currently I'm trying to render both frames individually to an FBO and putting them together afterwards. In this case I would have control of both frames and I would be able to manipulate them with the help of the 3rd-party code. osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't able to do the trick since I've found no way to access the FBO OSG utilizes. Therefore I've tried my own implementation (currently on a single display) with the following setup and the given result in the post before (take a look at the attached picture). The current implementation is very similiar to the osgprerender example (stereo is not enabled) except that I'm creating my own FBO in a preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and is used as the rendertarget for the first (left) (RTT-)camera. RenderTargetImplementation for this camera has not been explicitly set. The texture is attached to a rectangular geometry, which is itself a child of the osgViewers camera. Unfortunately the result of the RTT looks like the attached image. The image was saved in the postDrawCallback. I'm pretty sure I've messed something up or missed something. RTT with OSGs FBO works fine and I've looked at the code but I didn't find anything. Does someone have an idea? Or maybe another way to implement checkerboard-stereo? It looks like some faces get culled away. If its useful I'll post some code. @Robert: I'm not using osgUtils low level stereo right now but I guess some of the code would later be useful to get the correct left and right camera-position-setup. Nice greetings and thanks for any help or hint! Mathias Buhr P.S.: I was already able to do the distortion with that implementation (with blitting the FBO-image back to the window-system provided FB to get the 3rd party stuff working). Am 04.08.09 19:14, schrieb Robert Osfield: Hi Mathias, You don't really provide enough info about your overall viewer setup to give a direct answer. It sounds like you are using the OSG's low level stereo support in osgUtil and combining this with a 3rd party code that does distortion correction or similar. Doing low level stereo and distortion correction is really going to work visually even if you got it to work code wise, as the low level stereo support in osgUtil assumes a flat display. Have a bash at explaining what your system is trying to do at a high level and then others will have a better chance of suggesting how to go about it. Robert. On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhrmathias...@gmx.de wrote: Hi, before going into the details of the problem, I'd like to explain what I'm trying to do and what I have done until now. I have a 3rd-party function/method which is out of my scope. It seems to
Re: [osg-users] Dashboard error
No!!! It works now... Maybe I did something wrong? Sorry for disturbing... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Mail d'origine - De: Robert Osfield robert.osfi...@gmail.com À: OpenSceneGraph Users osg-users@lists.openscenegraph.org Envoyé: Wed, 5 Aug 2009 10:17:11 +0200 (CEST) Objet: Re: [osg-users] Dashboard error Hi Sukender, Are you still seeing these problems? Robert. On Tue, Aug 4, 2009 at 8:36 AM, suky0...@free.fr wrote: Hi Jose-Luis et al Either the dashboard does not respond, or I get the folowing error: no handler found Warning: error_log(backup/cdash.log) [function.error-log]: failed to open stream: Permission denied in /home/www/cdash_OSG/cdash/common.php on line 192 Hope it helps :) 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] RTT problem - missing faces
Thanks again Robert! I really appreciate it. I've build a small example which should help to demonstrate the problem. I removed the post processing since it is not reallly helpful nor the problem. I hope this helps Greetings Mathias Am 05.08.09 14:49, schrieb Robert Osfield: Hi Mathias, I can't really give you any recommendation as you are already doing custom code w.r.t FBO which means there is too many unknowns for me to guess at. Robert. On Wed, Aug 5, 2009 at 1:31 PM, Mathias Buhrmathias...@gmx.de wrote: Yes, thats exactly the plan but I need the images back in the FB to get the 3rd party stuff working. This means I have to call glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to distortion-code or the function won't work. This assumes the image in GL_BACK and GL_BACK has to be stored to the FBO afterwards. How to do this? Greetings MAthias Am 05.08.09 14:08, schrieb Robert Osfield: HI Mathias, Given your setup it's pretty clear that you'd need to not use the OSG in built stereo support (that is implemented internally using osgUtil::SceneView), and instead setup up two slave camera sets that do the render to texture/post render for each eye and in the final step do the checkboard stereo at the same time Robert. On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhrmathias...@gmx.dewrote: Hi Robert, thank you for your answer. I'll try to give some more details on the current setup: - multiple physical displays/projectors which overlap to produce a single (flat-)screen - alignment and blending of the displays is done with the 3rd-party stuff - the displays support checkerboard-stereo In mono-mode my integration of OSG and the 3rd party stuff works perfectly and all display do what they are supposed to do. The post-processing is done in the camera's postDrawCallback without any magic :) The problem starts when I enable OSGs checkerboard-stereo because the image-distortion in the postDrawCallback will result in an unusable checkerboard-frame. So basically I'm trying to get checkerboard-stereo to work. Due to the described problem, I need access to the left and right frames to distort them individually. Normally they are blend together via stenciling in osg::RenderStage::draw(). As far as I know, there is no direct access to these frames. I could either implement some kind of callback into OSG or implement a variant of checkerboard-stereo myself. Currently I'm trying to render both frames individually to an FBO and putting them together afterwards. In this case I would have control of both frames and I would be able to manipulate them with the help of the 3rd-party code. osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't able to do the trick since I've found no way to access the FBO OSG utilizes. Therefore I've tried my own implementation (currently on a single display) with the following setup and the given result in the post before (take a look at the attached picture). The current implementation is very similiar to the osgprerender example (stereo is not enabled) except that I'm creating my own FBO in a preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and is used as the rendertarget for the first (left) (RTT-)camera. RenderTargetImplementation for this camera has not been explicitly set. The texture is attached to a rectangular geometry, which is itself a child of the osgViewers camera. Unfortunately the result of the RTT looks like the attached image. The image was saved in the postDrawCallback. I'm pretty sure I've messed something up or missed something. RTT with OSGs FBO works fine and I've looked at the code but I didn't find anything. Does someone have an idea? Or maybe another way to implement checkerboard-stereo? It looks like some faces get culled away. If its useful I'll post some code. @Robert: I'm not using osgUtils low level stereo right now but I guess some of the code would later be useful to get the correct left and right camera-position-setup. Nice greetings and thanks for any help or hint! Mathias Buhr P.S.: I was already able to do the distortion with that implementation (with blitting the FBO-image back to the window-system provided FB to get the 3rd party stuff working). Am 04.08.09 19:14, schrieb Robert Osfield: Hi Mathias, You don't really provide enough info about your overall viewer setup to give a direct answer. It sounds like you are using the OSG's low level stereo support in osgUtil and combining this with a 3rd party code that does distortion correction or similar. Doing low level stereo and distortion correction is really going to work visually even if you got it to work code wise, as the low level stereo support in osgUtil assumes a flat display. Have a bash at explaining what your system is trying to do at a high level and then others will have a better chance of suggesting how to go about it. Robert. On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhrmathias...@gmx.de wrote: Hi,
Re: [osg-users] OSG and shaders
Thank you for the links. I have already read them and found nothing useful at this stage. As every link I've read... The shaders codes are given without the mains, the mains without the shaders, the openscenegraph.org tutorials are with osgGL2 (which I can't work with), and there is no other tutorial on openscenegraph WITH shaders. I opened something like 300 links these past three days. I had to combine 5 of them to get to understand what is a shader, to load it and to write: gl_Position = ftransform(); gl_FragColor = gl_Color; for .vert and .frag One more day to know how to send the texture. And now I'm stuck with the mapping. Has anyone a long rope? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15845#15845 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT problem - missing faces
Hi Mathias, I'm afraid I have way too much work on my plate to go investigating user applications. Robert. On Wed, Aug 5, 2009 at 2:44 PM, Mathias Buhrmathias...@gmx.de wrote: Thanks again Robert! I really appreciate it. I've build a small example which should help to demonstrate the problem. I removed the post processing since it is not reallly helpful nor the problem. I hope this helps Greetings Mathias Am 05.08.09 14:49, schrieb Robert Osfield: Hi Mathias, I can't really give you any recommendation as you are already doing custom code w.r.t FBO which means there is too many unknowns for me to guess at. Robert. On Wed, Aug 5, 2009 at 1:31 PM, Mathias Buhrmathias...@gmx.de wrote: Yes, thats exactly the plan but I need the images back in the FB to get the 3rd party stuff working. This means I have to call glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to distortion-code or the function won't work. This assumes the image in GL_BACK and GL_BACK has to be stored to the FBO afterwards. How to do this? Greetings MAthias Am 05.08.09 14:08, schrieb Robert Osfield: HI Mathias, Given your setup it's pretty clear that you'd need to not use the OSG in built stereo support (that is implemented internally using osgUtil::SceneView), and instead setup up two slave camera sets that do the render to texture/post render for each eye and in the final step do the checkboard stereo at the same time Robert. On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhrmathias...@gmx.de wrote: Hi Robert, thank you for your answer. I'll try to give some more details on the current setup: - multiple physical displays/projectors which overlap to produce a single (flat-)screen - alignment and blending of the displays is done with the 3rd-party stuff - the displays support checkerboard-stereo In mono-mode my integration of OSG and the 3rd party stuff works perfectly and all display do what they are supposed to do. The post-processing is done in the camera's postDrawCallback without any magic :) The problem starts when I enable OSGs checkerboard-stereo because the image-distortion in the postDrawCallback will result in an unusable checkerboard-frame. So basically I'm trying to get checkerboard-stereo to work. Due to the described problem, I need access to the left and right frames to distort them individually. Normally they are blend together via stenciling in osg::RenderStage::draw(). As far as I know, there is no direct access to these frames. I could either implement some kind of callback into OSG or implement a variant of checkerboard-stereo myself. Currently I'm trying to render both frames individually to an FBO and putting them together afterwards. In this case I would have control of both frames and I would be able to manipulate them with the help of the 3rd-party code. osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't able to do the trick since I've found no way to access the FBO OSG utilizes. Therefore I've tried my own implementation (currently on a single display) with the following setup and the given result in the post before (take a look at the attached picture). The current implementation is very similiar to the osgprerender example (stereo is not enabled) except that I'm creating my own FBO in a preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and is used as the rendertarget for the first (left) (RTT-)camera. RenderTargetImplementation for this camera has not been explicitly set. The texture is attached to a rectangular geometry, which is itself a child of the osgViewers camera. Unfortunately the result of the RTT looks like the attached image. The image was saved in the postDrawCallback. I'm pretty sure I've messed something up or missed something. RTT with OSGs FBO works fine and I've looked at the code but I didn't find anything. Does someone have an idea? Or maybe another way to implement checkerboard-stereo? It looks like some faces get culled away. If its useful I'll post some code. @Robert: I'm not using osgUtils low level stereo right now but I guess some of the code would later be useful to get the correct left and right camera-position-setup. Nice greetings and thanks for any help or hint! Mathias Buhr P.S.: I was already able to do the distortion with that implementation (with blitting the FBO-image back to the window-system provided FB to get the 3rd party stuff working). Am 04.08.09 19:14, schrieb Robert Osfield: Hi Mathias, You don't really provide enough info about your overall viewer setup to give a direct answer. It sounds like you are using the OSG's low level stereo support in osgUtil and combining this with a 3rd party code that does distortion correction or similar. Doing low level stereo and distortion correction is really going to work visually even if you got it to work code wise, as the low level stereo
Re: [osg-users] osg 2.2 How to disable picking for objects attached to camera with smaller viewport when they are not visible in the scene
Hi Robert, I thought about what you mentioned but i dont think that method will work for me. I am trying to do a scroll panel which has a variable size. I am using the approach where i have a sub camera which projects only some parts of the contents attached to the camera. I realised that the contents are pickable even if there are not visible. I was thinking if theres a method which can detect nodes that are not visible and disable picking. However, it seems like i have to manually detect? In that way, it seems alittle inefficient? Thank you for your help! Cheers, James -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15848#15848 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 3DS loader revisited?
Hi all, I'm working on something that needs 3DS import (Well, a modified 3DS import, that reads data in keyframes). However I noticed the underlying lib3DS seems a bit old (and it seems the few problems I got are related). Is that really true? Should we work on upgrading the loader, or is there a risk to break compatibility? Any thoughts will be appreciated... 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] OSG and shaders
Well, I'm doing an internship too. At the beginning I didn't know osg at all, neither shaders. There are still an extraordinary amount of things I ignore about OSG (my advice: when you try to do or understand something, take a look at how it's done in OpenGL). Shaders aren't as hard to use as OSG, I discovered about one month ago and I can now write some modests but nice effects. The essential is to read code and tutorials. Don't try to go fast, it's the best way to misunderstand what you manipulate and to write bad code, failing your internship. You have 6 months, you can waste it OR spend 2 months to understand osg and shaders and then writting good code, masterizing your internship. Thus, first read a few osg tutorials (to understand how textures are mapped for example, it seems you don't), I think the 4 or 5 firsts should be enough. After, try to understand what is a shader (I guess you don't really). Then try to understand the shader tutorials from typhoonlabs, or this (http://www.siteduzero.com/tutoriel-3-8879-communiquer-avec-l-application-attributs-et-uniforms.html?bcsi-ac-20A76BC15DBD50F6=194870AE0303lbVE9ryZWUuZzrBgMzY7DS6IPWi9BwMAAMDCRwEQDgAAINVbBwA=), it's in french. I advice to look at osgshader example ONLY to understand (or copy the code) how to load and activate a shader, it's 5 lines. Don't take me for moralistic, I did these errors. Good luck and take your time, it's the best way to success. Cheers, Maxime -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15849#15849 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and shaders
Thank you very much, I was so desperate :\ -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15851#15851 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3DS loader revisited?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Sukender, Sukender wrote: Hi all, I'm working on something that needs 3DS import (Well, a modified 3DS import, that reads data in keyframes). However I noticed the underlying lib3DS seems a bit old (and it seems the few problems I got are related). Is that really true? Should we work on upgrading the loader, or is there a risk to break compatibility? Any thoughts will be appreciated... Thanks! I recall having the same issue at one point and Robert said to go ahead with updating it. I just never got to it due to other things. So I would say it should be a safe bet to update it, but ideally we should factor out the bundled library and put it in the dependencies instead. It makes for cleaner design and allows to use the system-provided one on Linux, for example. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKeaWhn11XseNj94gRAr85AKDmY+cIbDrkFnzmz7IOh9s5YHALGgCgzZ5N qoNaH85r//lOit7tyF0y7hI= =I8QH -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3DS loader revisited?
Hi Sukender, In the past (quite a few years ago now) I did sync with lib3ds, but it didn't change for a long while so haven't kept up with it. The OSG's version has now diverged substationally from lib3ds with it's use of istream's rather than FILE so an easy merge will no longer be possible. What could probably do is backport the features from the current lib3ds you want. Robert. On Wed, Aug 5, 2009 at 3:30 PM, Sukendersuky0...@free.fr wrote: Hi all, I'm working on something that needs 3DS import (Well, a modified 3DS import, that reads data in keyframes). However I noticed the underlying lib3DS seems a bit old (and it seems the few problems I got are related). Is that really true? Should we work on upgrading the loader, or is there a risk to break compatibility? Any thoughts will be appreciated... 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText texture not reloading correctly the secondtime?
Hi guys,
We're having the same problem here. Textures are corrupted or are
showing the wrong image when the viewer is destroyed and re-created.
I've been tracking it for a week now. Here is the simplified core logic
of the application that shows the problem.
For (;;)
{
{
osgViewer::Viewer viewer();
viewer.setSceneData(scene_data);
viewer.run();
scene_data-releaseGLObjects();
osgDB::Registry::instance()-releaseGLObjects();
}
/* do other stuff */
}
- The problem appears randomly, it's not deterministic.
- The problem appears on all kind of different hardware.
- Destroying all the osg::Texture objects in scene_data after run() (and
re-creating them before run()) seems to solve the problem (note osgText
still appears corrupted.
- Only the textures that were shown during the last frame are corrupted;
all other textures are fine.
I've noticed something really strange once. The debugger stopped with an
assert on an invalid iterator usage. It happened in the graphics thread,
doing the culling. What puzzled me is that the graphic thread was still
running while the main thread is already in the viewer destructor
(thereby causing the culling to iterate over a scene that is no longer
valid). In fact the graphic thread was actively running and doing
culling/drawing after viewer.run() had exited.
Robert, could you confirm that the rendering thread is not supposed to
be actively culling/drawing when being outside of Viewer::run() (or more
precisely, Viewer::frame())?
From what I understand from Texture.cpp and Texture2D.cpp, if the
graphic thread were to be still running after calling
releaseGLObjects(), the osg::Texture objects would re-create an
osg::Texture::TextureObject (containing the actual OpenGL texture
object) and be left in a state where they think they have a valid
TextureObject. This would explain quite a lot.
Cheers,
Tanguy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Juan
Casanueva
Sent: 04 May 2009 17:21
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] osgText texture not reloading correctly the
secondtime?
Hi JS,
I think I have exactly the same problem you are having.
I have an application that opens/closes a osg viewer. When I close the
osg viewer, everything gets deleted, even the viewer. However, when I
open the viewer the second time, some of the textures do not appear.
This seems to be happening at random, since the textures that disappear
are not the same ones every time. Sometimes its the terrain textures,
sometimes the clouds, sometimes the 3d models (.ac)... I must say that
the problem does not happen every time on my application. It happens
from time to time, although if I open/close the viewer 3 or 4 times I
eventually end up seeing the problem.
I have no idea what is causing this problem, so I can't really help:(
Just to let you know that it is not happening only on your application
:)
regards
Juan
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11304#11304
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText texture not reloading correctly the secondtime?
Hi Tanguy,
On Wed, Aug 5, 2009 at 4:53 PM, Tanguy
Fautretang...@aristechnologies.com wrote:
Robert, could you confirm that the rendering thread is not supposed to
be actively culling/drawing when being outside of Viewer::run() (or more
precisely, Viewer::frame())?
If you are using DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext then the draw thread will run
over the end of frame() or even run().
Call viewer.stopThreading(); to ensure the threads are stopped.
--
W.r.t osgText not clearing it's GL objects properly, in theory
releaseGLobjects() should work, and should purge the graphics context
just fine. Looking at the implementation of Tex
void Text::releaseGLObjects(osg::State* state) const
{
TextBase::releaseGLObjects(state);
getActiveFont()-releaseGLObjects(state);
}
And
void Font::releaseGLObjects(osg::State* state) const
{
if (_stateset.valid()) _stateset-releaseGLObjects(state);
for(GlyphTextureList::const_iterator itr=_glyphTextureList.begin();
itr!=_glyphTextureList.end();
++itr)
{
(*itr)-releaseGLObjects(state);
}
// const_castFont*(this)-_glyphTextureList.clear();
// const_castFont*(this)-_sizeGlyphMap.clear();
}
Which broadly looks to be the right thing.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText texture not reloading correctly thesecondtime?
Hi Robert,
Thanks for the explanation. It clears quite a lot of confusion.
I've added the stopThreading(), and this build is going to go through a
test cycle tonight, so I will know fairly soon if the problem still
appears.
Cheers,
Tanguy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 05 August 2009 17:20
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgText texture not reloading correctly
thesecondtime?
Hi Tanguy,
On Wed, Aug 5, 2009 at 4:53 PM, Tanguy
Fautretang...@aristechnologies.com wrote:
Robert, could you confirm that the rendering thread is not supposed to
be actively culling/drawing when being outside of Viewer::run() (or
more
precisely, Viewer::frame())?
If you are using DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext then the draw thread will run
over the end of frame() or even run().
Call viewer.stopThreading(); to ensure the threads are stopped.
--
W.r.t osgText not clearing it's GL objects properly, in theory
releaseGLobjects() should work, and should purge the graphics context
just fine. Looking at the implementation of Tex
void Text::releaseGLObjects(osg::State* state) const
{
TextBase::releaseGLObjects(state);
getActiveFont()-releaseGLObjects(state);
}
And
void Font::releaseGLObjects(osg::State* state) const
{
if (_stateset.valid()) _stateset-releaseGLObjects(state);
for(GlyphTextureList::const_iterator itr=_glyphTextureList.begin();
itr!=_glyphTextureList.end();
++itr)
{
(*itr)-releaseGLObjects(state);
}
// const_castFont*(this)-_glyphTextureList.clear();
// const_castFont*(this)-_sizeGlyphMap.clear();
}
Which broadly looks to be the right thing.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glMultiTexCoord4f , OSG with OGL code
Hi, Since I know, OSG doesn't have support for geometry shaders, does it? I'll check it again. Thank you! Cheers, Pau -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15857#15857 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glMultiTexCoord4f , OSG with OGL code
Pau Moreno wrote on Wednesday, August 05, 2009 12:22 PM: Since I know, OSG doesn't have support for geometry shaders, does it? I'll check it again. It has had support since January, 2008, according to the SVN log; see osg::Shader. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Offscreen Rendering - clamping problem
Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do additional processing. Currently the image/texture copy occurs before the postdrawcallback resulting in the image/texture not having the postdraw effects. Is there a reason why the copy isn't after the postdrawcallback? Thanks, Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Sorry about the multiple posts/wrong subjects. Another copy/paste artifact. Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do additional processing. Currently the image/texture copy occurs before the postdrawcallback resulting in the image/texture not having the postdraw effects. Is there a reason why the copy isn't after the postdrawcallback? Thanks, Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Offscreen Rendering - clamping problem
I think I found the reason. It looks like X windows doesn't support floating point pbuffers. Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Brian R Hill/DEF/c...@csc Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/04/2009 06:02PM Subject: [osg-users] Offscreen Rendering - clamping problem Folks, Sorry for another post on this subject. I just can't figure out how to disable the clamping of the output. I'm want to render offscreen without a window with 32 bit floats. Attached is the sample code I'm working with, it's based on the osgscreencapture.cpp example. It uses a shader to write an input uniform float val to the pbuffer. The val varies from -1.0 ... 2.0. Any help would be appreciated. Thanks, Brian (See attached file: offscreenrender.cpp)___ 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] RenderStage::draw order of copyTexture and PostDrawCallback
Hi Brian, Brian R Hill wrote: Sorry about the multiple posts/wrong subjects. Another copy/paste artifact. Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do additional processing. Currently the image/texture copy occurs before the postdrawcallback resulting in the image/texture not having the postdraw effects. Is there a reason why the copy isn't after the postdrawcallback? Copy to where? In the postdrawcallback you have the result of the rendering to FBO copied back to the CPU (osg::Image) if an image was attached to your FBO camera. You can modify the data in the callback and then call dirty on the image and the texture would be updated on GPU. If you then use this texture you should see changes. The osgprerender example does exactly this. I'm not sure if you are expecting anything else? If so, please provide more details on what you want to do. cheers jp Thanks, Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • ___ 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Offscreen Rendering - clamping problem
Hi, why are you not reading the floating point values directly from the FBO without worrying about the final frame buffer precision? Have a look at the callback in osgmultiplerendertargets for the GL_FLOAT case. You can get a CPU copy of your floating point FBO and manipulate the data as you want. cheers jp Brian R Hill wrote: I think I found the reason. It looks like X windows doesn't support floating point pbuffers. Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Brian R Hill/DEF/c...@csc Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/04/2009 06:02PM Subject: [osg-users] Offscreen Rendering - clamping problem Folks, Sorry for another post on this subject. I just can't figure out how to disable the clamping of the output. I'm want to render offscreen without a window with 32 bit floats. Attached is the sample code I'm working with, it's based on the osgscreencapture.cpp example. It uses a shader to write an input uniform float val to the pbuffer. The val varies from -1.0 ... 2.0. Any help would be appreciated. Thanks, Brian (See attached file: offscreenrender.cpp)___ 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 -- 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Computing depth buffer in osgVolume
Hi, I would like to add the computation of the z-depth value in the ray traced volume shaders. I'm pretty new to raytracing on gpu, so forgive me if this is a naive question! I've tried to add this code in the fragment shader, just after the line gl_FragColor = color: gl_FragColor = color; vec4 inter = gl_ModelViewProjectionMatrix * vec4(texcoord,1); gl_FragDepth = inter.z / inter.w; return; In theory my idea is to compute the position of the intersection with the volume, and use the model view projection transformation matrix to get z buffer value computed. It looks good... but it's not right! Does any one have an idea about what I'm doing wrong? Thanks for any help, Regards, Yvon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi Brian, Brian R Hill wrote: Sorry about the multiple posts/wrong subjects. Another copy/paste artifact. Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do additional processing. Currently the image/texture copy occurs before the postdrawcallback resulting in the image/texture not having the postdraw effects. Is there a reason why the copy isn't after the postdrawcallback? Copy to where? In the postdrawcallback you have the result of the rendering to FBO copied back to the CPU (osg::Image) if an image was attached to your FBO camera. You can modify the data in the callback and then call dirty on the image and the texture would be updated on GPU. If you then use this texture you should see changes. The osgprerender example does exactly this. I'm not sure if you are expecting anything else? If so, please provide more details on what you want to do. cheers jp Thanks, Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • ___ 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. MailScanner thanks Transtec Computers for their support. ___ 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] Billboard problem
Hello, i tried to place some treebillboards in my Terrain, but i have problems with the texturing. I have two textures: [Image: http://www.husseini.de/markus/C.jpg ] [Image: http://www.husseini.de/markus/T.jpg ] If I render the billboard the black color should be invisible but it doesn't work. I get this code from the Osg Help Tutorials. m_refTexPencil = new osg::Texture2D; m_refTexPencil-setImage( osgDB::readImageFile( _Pencil ) ); m_refTexCracks = new osg::Texture2D; m_refTexCracks-setImage( osgDB::readImageFile( _Cracks ) ); m_refGeo= new osg::Geometry; m_refVerts = new osg::Vec3Array; m_refVerts-push_back( osg::Vec3( 0, 0, 0 )+vecPos ); m_refVerts-push_back( osg::Vec3( 100, 0, 0 )+vecPos ); m_refVerts-push_back( osg::Vec3( 100, 0, 100 )+vecPos ); m_refVerts-push_back( osg::Vec3( 0, 0, 100 )+vecPos ); m_refGeo-setVertexArray( m_refVerts ); m_refPrimitiveSet = new osg::DrawElementsUInt( osg::PrimitiveSet::QUADS, 0 ); m_refPrimitiveSet-push_back( 3 ); m_refPrimitiveSet-push_back( 2 ); m_refPrimitiveSet-push_back( 1 ); m_refPrimitiveSet-push_back( 0 ); m_refGeo-addPrimitiveSet( m_refPrimitiveSet ); m_refTexCoords = new osg::Vec2Array( 4 ); (*m_refTexCoords)[0].set( 0.0f, 0.0f ); (*m_refTexCoords)[1].set( 1.0f, 0.0f ); (*m_refTexCoords)[2].set( 1.0f, 1.0f ); (*m_refTexCoords)[3].set( 0.0f, 1.0f ); m_refGeo-setTexCoordArray( 0, m_refTexCoords ); m_refGeo-setTexCoordArray( 1, m_refTexCoords ); m_refBillboard = new osg::Billboard; m_refBillboard-setMode( osg::Billboard::AXIAL_ROT );//POINT_ROT_EYE ); m_refStateSet = m_refBillboard-getOrCreateStateSet(); m_refStateSet-setMode( GL_LIGHTING, osg::StateAttribute::OFF ); m_refStateSet-setMode( GL_BLEND, osg::StateAttribute::ON ); m_refStateSet-setMode( GL_CULL_FACE, osg::StateAttribute::OFF ); m_refStateSet-setTextureAttributeAndModes( 0, m_refTexPencil, osg::StateAttribute::ON ); m_refStateSet-setTextureAttributeAndModes( 1, m_refTexCracks, osg::StateAttribute::ON ); m_refBillboard-addDrawable( m_refGeo ); m_refTexEnv = new osg::TexEnvCombine; m_refTexEnv-setCombine_RGB( osg::TexEnvCombine::MODULATE ); m_refTexEnv-setSource0_RGB( osg::TexEnvCombine::TEXTURE0 ); m_refTexEnv-setOperand0_RGB( osg::TexEnvCombine::SRC_COLOR); m_refTexEnv-setSource1_RGB( osg::TexEnvCombine::TEXTURE1 ); m_refTexEnv-setOperand1_RGB( osg::TexEnvCombine::SRC_COLOR ); m_refStateSet-setTextureAttribute( 1, m_refTexEnv ); m_refPat= new osg::PositionAttitudeTransform; m_refPat-setPosition( vecPos ); m_refPat-addChild( m_refBillboard ); Thx for Help. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15865#15865 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT problem - missing faces
Hi Robert, I can really understand your situation :-) Maybe someone else has a good idea? Greetings Mathias Robert Osfield wrote: Hi Mathias, I'm afraid I have way too much work on my plate to go investigating user applications. Robert. On Wed, Aug 5, 2009 at 2:44 PM, Mathias Buhrmathias...@gmx.de wrote: Thanks again Robert! I really appreciate it. I've build a small example which should help to demonstrate the problem. I removed the post processing since it is not reallly helpful nor the problem. I hope this helps Greetings Mathias Am 05.08.09 14:49, schrieb Robert Osfield: Hi Mathias, I can't really give you any recommendation as you are already doing custom code w.r.t FBO which means there is too many unknowns for me to guess at. Robert. On Wed, Aug 5, 2009 at 1:31 PM, Mathias Buhrmathias...@gmx.de wrote: Yes, thats exactly the plan but I need the images back in the FB to get the 3rd party stuff working. This means I have to call glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to distortion-code or the function won't work. This assumes the image in GL_BACK and GL_BACK has to be stored to the FBO afterwards. How to do this? Greetings MAthias Am 05.08.09 14:08, schrieb Robert Osfield: HI Mathias, Given your setup it's pretty clear that you'd need to not use the OSG in built stereo support (that is implemented internally using osgUtil::SceneView), and instead setup up two slave camera sets that do the render to texture/post render for each eye and in the final step do the checkboard stereo at the same time Robert. On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhrmathias...@gmx.de wrote: Hi Robert, thank you for your answer. I'll try to give some more details on the current setup: - multiple physical displays/projectors which overlap to produce a single (flat-)screen - alignment and blending of the displays is done with the 3rd-party stuff - the displays support checkerboard-stereo In mono-mode my integration of OSG and the 3rd party stuff works perfectly and all display do what they are supposed to do. The post-processing is done in the camera's postDrawCallback without any magic :) The problem starts when I enable OSGs checkerboard-stereo because the image-distortion in the postDrawCallback will result in an unusable checkerboard-frame. So basically I'm trying to get checkerboard-stereo to work. Due to the described problem, I need access to the left and right frames to distort them individually. Normally they are blend together via stenciling in osg::RenderStage::draw(). As far as I know, there is no direct access to these frames. I could either implement some kind of callback into OSG or implement a variant of checkerboard-stereo myself. Currently I'm trying to render both frames individually to an FBO and putting them together afterwards. In this case I would have control of both frames and I would be able to manipulate them with the help of the 3rd-party code. osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't able to do the trick since I've found no way to access the FBO OSG utilizes. Therefore I've tried my own implementation (currently on a single display) with the following setup and the given result in the post before (take a look at the attached picture). The current implementation is very similiar to the osgprerender example (stereo is not enabled) except that I'm creating my own FBO in a preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and is used as the rendertarget for the first (left) (RTT-)camera. RenderTargetImplementation for this camera has not been explicitly set. The texture is attached to a rectangular geometry, which is itself a child of the osgViewers camera. Unfortunately the result of the RTT looks like the attached image. The image was saved in the postDrawCallback. I'm pretty sure I've messed something up or missed something. RTT with OSGs FBO works fine and I've looked at the code but I didn't find anything. Does someone have an idea? Or maybe another way to implement checkerboard-stereo? It looks like some faces get culled away. If its useful I'll post some code. @Robert: I'm not using osgUtils low level stereo right now but I guess some of the code would later be useful to get the correct left and right camera-position-setup. Nice greetings and thanks for any help or hint! Mathias Buhr P.S.: I was already able to do the distortion with that implementation (with blitting the FBO-image back to the window-system provided FB to get the 3rd party stuff working). Am 04.08.09 19:14, schrieb Robert Osfield: Hi Mathias, You don't really provide enough info about your overall viewer setup to give a direct answer. It sounds like you are using the OSG's low level stereo support in osgUtil and combining this with a
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Hi, Brian R Hill wrote: Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? Yes. My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. This sounds OK to me, do you have problems with it? AFAIK you cannot change the order for a single FBO camera. The only other option I can think of (if you don't want to manually copy) is to create a second FBO camera solely for copying the result of the filtering (input texture to the second camera) to an osg::Image. Then you have draw - FBO1 - postdraw - FBO2 - to CPU jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi Brian, Brian R Hill wrote: Sorry about the multiple posts/wrong subjects. Another copy/paste artifact. Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do additional processing. Currently the image/texture copy occurs before the postdrawcallback resulting in the image/texture not having the postdraw effects. Is there a reason why the copy isn't after the postdrawcallback? Copy to where? In the postdrawcallback you have the result of the rendering to FBO copied back to the CPU (osg::Image) if an image was attached to your FBO camera. You can modify the data in the callback and then call dirty on the image and the texture would be updated on GPU. If you then use this texture you should see changes. The osgprerender example does exactly this. I'm not sure if you are expecting anything else? If so, please provide more details on what you want to do. cheers jp Thanks, Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • ___ 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. MailScanner thanks Transtec Computers for their support. ___ 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 -- 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glMultiTexCoord4f , OSG with OGL code
Hi, Ok, I've decided to follow your idea and do it with the osg shaders but I'm getting the next error Code: FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: (0) : error C: syntax error, unexpected $end at token EOF (0) : error C0501: type name expected at token null atom VERTEX glCompileShader FAILED VERTEX Shader infolog: (0) : error C: syntax error, unexpected $end at token EOF (0) : error C0501: type name expected at token null atom GEOMETRY glCompileShader FAILED GEOMETRY Shader infolog: (0) : error C: syntax error, unexpected $end at token EOF (0) : error C0501: type name expected at token null atom glLinkProgram FAILED Program infolog: Vertex info --- (0) : error C: syntax error, unexpected $end at token EOF (0) : error C0501: type name expected at token null atom Geometry info - (0) : error C: syntax error, unexpected $end at token EOF (0) : error C0501: type name expected at token null atom Fragment info - (0) : error C: syntax error, unexpected $end at token EOF (0) : error C0501: type name expected at token null atom Here I have where I initialize the shader: Code: osg::StateSet* brickState = node-getOrCreateStateSet(); osg::Program* brickProgramObject= new osg::Program; osg::Shader* brickVertexObject = new osg::Shader( osg::Shader::VERTEX ); osg::Shader* brickFragmentObject= new osg::Shader( osg::Shader::FRAGMENT ); osg::Shader* brickGeometryObject= new osg::Shader( osg::Shader::GEOMETRY ); brickProgramObject-addShader( brickFragmentObject ); brickProgramObject-addShader( brickVertexObject ); brickProgramObject-addShader( brickGeometryObject ); brickVertexObject-readShaderFile ( osg::Shader::VERTEX , /home/Pau/OSG/Test1/Debug/Shaders/TestG80_VS.glsl ); brickFragmentObject-readShaderFile( osg::Shader::FRAGMENT , /home/Pau/OSG/Test1/Debug/Shaders/TestG80_GS2.glsl ); brickGeometryObject-readShaderFile( osg::Shader::GEOMETRY , /home/Pau/OSG/Test1/Debug/Shaders/TestG80_FS.glsl ); brickProgramObject-setParameter( GL_GEOMETRY_INPUT_TYPE_EXT , GL_POINTS ); brickProgramObject-setParameter( GL_GEOMETRY_OUTPUT_TYPE_EXT , GL_TRIANGLE_STRIP ); brickProgramObject-setParameter( GL_GEOMETRY_VERTICES_OUT_EXT , 16 ); glGenTextures(1, triTableTex ); glActiveTexture(GL_TEXTURE2); glEnable(GL_TEXTURE_2D); glBindTexture(GL_TEXTURE_2D, triTableTex); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE); glTexImage2D( GL_TEXTURE_2D, 0, GL_ALPHA16I_EXT, 16, 256, 0, GL_ALPHA_INTEGER_EXT, GL_INT, triTable); float isolevel = 0.2; osg::Uniform* triTableU = new osg::Uniform(triTableTex, 0 ); osg::Uniform* isolevelU = new osg::Uniform(isolevel, isolevel ); osg::Uniform* vtxDecal0U = new osg::Uniform(vertDecals[0], osg::Vec3f( 0.0f, 0.0f , 0.0f ) ); osg::Uniform* vtxDecal1U = new osg::Uniform(vertDecals[1], osg::Vec3f( this-m_vStep.x , 0.0f , 0.0f ) ); osg::Uniform* vtxDecal2U = new osg::Uniform(vertDecals[2], osg::Vec3f( this-m_vStep.x , this-m_vStep.y , 0.0f ) ); osg::Uniform* vtxDecal3U = new osg::Uniform(vertDecals[3], osg::Vec3f( 0.0f, this-m_vStep.y , 0.0f ) ); osg::Uniform* vtxDecal4U = new osg::Uniform(vertDecals[4], osg::Vec3f( 0.0f, 0.0f , this-m_vStep.z ) ); osg::Uniform* vtxDecal5U = new osg::Uniform(vertDecals[5], osg::Vec3f( this-m_vStep.x , 0.0f , this-m_vStep.z ) ); osg::Uniform* vtxDecal6U = new osg::Uniform(vertDecals[6], osg::Vec3f( this-m_vStep.x , this-m_vStep.y , this-m_vStep.z ) ); osg::Uniform* vtxDecal7U = new osg::Uniform(vertDecals[7], osg::Vec3f( 0.0f, this-m_vStep.y , this-m_vStep.z ) ); brickState-addUniform( triTableU ); brickState-addUniform( isolevelU ); brickState-addUniform( vtxDecal0U ); brickState-addUniform( vtxDecal1U ); brickState-addUniform( vtxDecal2U ); brickState-addUniform( vtxDecal3U ); brickState-addUniform( vtxDecal4U ); brickState-addUniform( vtxDecal5U ); brickState-addUniform( vtxDecal6U ); brickState-addUniform( vtxDecal7U ); brickState-setAttributeAndModes(
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Hi JP, I was trying to determine if the current order (copy image, then call postdraw) was deliberate for specific reasons, or if it just got coded that way. I understand where you would want the copied image to be available in the postdraw, but I also understand where you would want the postdraw to apply to the image before the copy. It just depends on what the intended purpose of the postdraw is. Personally I feel the postdraw should occur before the copy and that the copied image should be accessed on the cpu side during the update phase. Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:27PM Subject: Re: [osg-users] RenderStage::draw order ofcopyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? Yes. My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. This sounds OK to me, do you have problems with it? AFAIK you cannot change the order for a single FBO camera. The only other option I can think of (if you don't want to manually copy) is to create a second FBO camera solely for copying the result of the filtering (input texture to the second camera) to an osg::Image. Then you have draw - FBO1 - postdraw - FBO2 - to CPU jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi Brian, Brian R Hill wrote: Sorry about the multiple posts/wrong subjects. Another copy/paste artifact. Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do additional processing. Currently the image/texture copy occurs before the postdrawcallback resulting in the image/texture not having the postdraw effects. Is there a reason why the copy isn't after the postdrawcallback? Copy to where? In the postdrawcallback you have the result of the rendering to FBO copied back to the CPU (osg::Image) if an image was attached to your FBO camera. You can modify the data in the callback and then call dirty on the image and the texture would be updated on GPU. If you then use this texture you should see changes. The osgprerender example does exactly this. I'm not sure if you are expecting anything else? If so, please provide more details on what you want to do. cheers jp Thanks, Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • ___ 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. MailScanner thanks Transtec Computers for their
Re: [osg-users] [vpb] OSGDem Question
Hi, Is there a way I can acquaint OSGDem not to do that or at atomic accomplish that atramentous accomplishments transparent, so I can seamlessly bury the map I created over a lower resolution map of the world. Thank you! Cheers, spike _ Call center software (http://www.inin.com) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15870#15870 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Hi, Brian R Hill wrote: Hi JP, I was trying to determine if the current order (copy image, then call postdraw) was deliberate for specific reasons, or if it just got coded that way. I think it was deliberate; however, I didn't write the code. I understand where you would want the copied image to be available in the postdraw, I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. but I also understand where you would want the postdraw to apply to the image before the copy. It just depends on what the intended purpose of the postdraw is. Personally I feel the postdraw should occur before the copy and that the copied image should be accessed on the cpu side during the update phase. Would it not be a frame late then? I understand your need for more flexibilty ito processing order and copying. I would suggest you have a look at osgPPU where you have more control over these things. jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:27PM Subject: Re: [osg-users] RenderStage::draw order ofcopyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? Yes. My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. This sounds OK to me, do you have problems with it? AFAIK you cannot change the order for a single FBO camera. The only other option I can think of (if you don't want to manually copy) is to create a second FBO camera solely for copying the result of the filtering (input texture to the second camera) to an osg::Image. Then you have draw - FBO1 - postdraw - FBO2 - to CPU jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi Brian, Brian R Hill wrote: Sorry about the multiple posts/wrong subjects. Another copy/paste artifact. Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do additional processing. Currently the image/texture copy occurs before the postdrawcallback resulting in the image/texture not having the postdraw effects. Is there a reason why the copy isn't after the postdrawcallback? Copy to where? In the postdrawcallback you have the result of the rendering to FBO copied back to the CPU (osg::Image) if an image was attached to your FBO camera. You can modify the data in the callback and then call dirty on the image and the texture would be updated on GPU. If you then use this texture you should see changes. The osgprerender example does exactly this. I'm not sure if you are expecting anything else? If so, please provide more details on what you want to do. cheers jp Thanks, Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • ___ osg-users mailing list
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Hi JP, I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. I've always thought of it as the last chance to draw something, essentially a hook into the drawing phase to integrate things that don't fit well in the scenegraph architecture. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. I guess I could do this. Create a custom drawable that call the 3rd party function. The difficulty will be guaranteeing it's the absolutely last thing drawn. The postdraw makes this easy. Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:53PM Subject: Re: [osg-users] RenderStage::draw order ofcopyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I was trying to determine if the current order (copy image, then call postdraw) was deliberate for specific reasons, or if it just got coded that way. I think it was deliberate; however, I didn't write the code. I understand where you would want the copied image to be available in the postdraw, I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. but I also understand where you would want the postdraw to apply to the image before the copy. It just depends on what the intended purpose of the postdraw is. Personally I feel the postdraw should occur before the copy and that the copied image should be accessed on the cpu side during the update phase. Would it not be a frame late then? I understand your need for more flexibilty ito processing order and copying. I would suggest you have a look at osgPPU where you have more control over these things. jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:27PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? Yes. My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. This sounds OK to me, do you have problems with it? AFAIK you cannot change the order for a single FBO camera. The only other option I can think of (if you don't want to manually copy) is to create a second FBO camera solely for copying the result of the filtering (input texture to the second camera) to an osg::Image. Then you have draw - FBO1 - postdraw - FBO2 - to CPU jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi Brian, Brian R Hill wrote: Sorry about the multiple
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Brian R Hill wrote on Wednesday, August 05, 2009 3:05 PM: I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. I've always thought of it as the last chance to draw something, essentially a hook into the drawing phase to integrate things that don't fit well in the scenegraph architecture. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. I guess I could do this. Create a custom drawable that call the 3rd party function. The difficulty will be guaranteeing it's the absolutely last thing drawn. The postdraw makes this easy. What about inserting a POST_RENDER Camera under the camera with the DrawCallback attached to it? -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:53PM Subject: Re: [osg-users] RenderStage::draw order ofcopyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I was trying to determine if the current order (copy image, then call postdraw) was deliberate for specific reasons, or if it just got coded that way. I think it was deliberate; however, I didn't write the code. I understand where you would want the copied image to be available in the postdraw, I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. but I also understand where you would want the postdraw to apply to the image before the copy. It just depends on what the intended purpose of the postdraw is. Personally I feel the postdraw should occur before the copy and that the copied image should be accessed on the cpu side during the update phase. Would it not be a frame late then? I understand your need for more flexibilty ito processing order and copying. I would suggest you have a look at osgPPU where you have more control over these things. jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:27PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? Yes. My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. This sounds OK to me, do you have problems with it? AFAIK you cannot change the order for a single FBO camera. The only other option I can think of (if you don't want to manually copy) is to create a second FBO camera solely for copying the result of the filtering (input texture to the second camera) to an osg::Image. Then you have draw - FBO1 - postdraw - FBO2 - to CPU jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi Brian, Brian R Hill wrote: Sorry about the multiple posts/wrong subjects. Another copy/paste artifact. Folks, I'm doing offscreen rendering using fbos with attached images. I'm also using the postdrawcallback to do
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Thrall, Bryan wrote on Wednesday, August 05, 2009 3:22 PM: Brian R Hill wrote on Wednesday, August 05, 2009 3:05 PM: I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. I've always thought of it as the last chance to draw something, essentially a hook into the drawing phase to integrate things that don't fit well in the scenegraph architecture. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. I guess I could do this. Create a custom drawable that call the 3rd party function. The difficulty will be guaranteeing it's the absolutely last thing drawn. The postdraw makes this easy. What about inserting a POST_RENDER Camera under the camera with the DrawCallback attached to it? Er... to clarify: insert a Camera under your main camera and set it to POST_RENDER. Then attach your DrawCallback to the POST_RENDER camera. The DrawCallback should happen before the main camera's FBO copy to Image. -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:53PM Subject: Re: [osg-users] RenderStage::draw order ofcopyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I was trying to determine if the current order (copy image, then call postdraw) was deliberate for specific reasons, or if it just got coded that way. I think it was deliberate; however, I didn't write the code. I understand where you would want the copied image to be available in the postdraw, I think this is the common case and I always understood postdraw to mean that the camera is done with rendering/drawing. So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. but I also understand where you would want the postdraw to apply to the image before the copy. It just depends on what the intended purpose of the postdraw is. Personally I feel the postdraw should occur before the copy and that the copied image should be accessed on the cpu side during the update phase. Would it not be a frame late then? I understand your need for more flexibilty ito processing order and copying. I would suggest you have a look at osgPPU where you have more control over these things. jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 03:27PM Subject: Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback Hi, Brian R Hill wrote: Hi JP, I'm using a 3rd party library to do filtering on the rendered image. They do all their magic using opengl in a function call from the postdrawcallback. Here's what it currently does: draw - FBO - copy to cpu - postdraw The postdraw operates on the FBO after it's been copied to the cpu and I never see it. Here's what I want to do: draw - FBO - postdraw - copy to cpu I want to access the image with the filtering effects included. Does this make it clearer? Yes. My fallback is to not attach an image to the FBO and do the copying myself in the postdrawcallback after the filtering. This sounds OK to me, do you have problems with it? AFAIK you cannot change the order for a single FBO camera. The only other option I can think of (if you don't want to manually copy) is to create a second FBO camera solely for copying the result of the filtering (input texture to the second camera) to an osg::Image. Then you have draw - FBO1 - postdraw - FBO2 - to CPU jp Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: J.P. Delport jpdelp...@csir.co.za Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/05/2009 02:17PM Subject: Re: [osg-users]
Re: [osg-users] OSG and shaders
And it deserves saying, if you can get your hands on an OpenGL Orange Book you'll be that many more steps ahead. I thought it was really good at explaining things in depth while also being easily navigated to drill in on target areas. I had complex shaders up and running in a few days with that book... I have had some embedded-style coding experience before, though. -Paul Maxime BOUCHER wrote: Well, I'm doing an internship too. At the beginning I didn't know osg at all, neither shaders. There are still an extraordinary amount of things I ignore about OSG (my advice: when you try to do or understand something, take a look at how it's done in OpenGL). Shaders aren't as hard to use as OSG, I discovered about one month ago and I can now write some modests but nice effects. The essential is to read code and tutorials. Don't try to go fast, it's the best way to misunderstand what you manipulate and to write bad code, failing your internship. You have 6 months, you can waste it OR spend 2 months to understand osg and shaders and then writting good code, masterizing your internship. Thus, first read a few osg tutorials (to understand how textures are mapped for example, it seems you don't), I think the 4 or 5 firsts should be enough. After, try to understand what is a shader (I guess you don't really). Then try to understand the shader tutorials from typhoonlabs, or this (http://www.siteduzero.com/tutoriel-3-8879-communiquer-avec-l-application-attributs-et-uniforms.html?bcsi-ac-20A76BC15DBD50F6=194870AE0303lbVE9ryZWUuZzrBgMzY7DS6IPWi9BwMAAMDCRwEQDgAAINVbBwA=), it's in french. I advice to look at osgshader example ONLY to understand (or copy the code) how to load and activate a shader, it's 5 lines. Don't take me for moralistic, I did these errors. Good luck and take your time, it's the best way to success. Cheers, Maxime -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15849#15849 ___ 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] Billboard problem
Hi, Have your textures got an alpha channel? Try setting the alpha of the black region to zero and set an alpha function of GEQUAL and a reference value of 0.05 So, declare a member variable: Code: osg::ref_ptr osg::AlphaFunc m_refAlpha; Then: Code: m_refAlpha = new osg::AlphaFunc(); m_refAlpha-setFunction( osg::AlphaFunc::GEQUAL, 0.05f ); m_refStateSet-setAttributeAndModes( m_refAlpha.get(), osg::StateAttribute::ON ); The billboard tutorial shows this. Cheers, Tony [/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15877#15877 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Importance Of Node Path List In Database Pager
Robert, I was just curious to see if anything was committed to the 2.9.x / 2.10 baselines for this. I know that you stated that you already had code in place to fix this issue. Thanks. Ryan H. Kawicki The Boeing Company Training Systems Services Software Engineer -Original Message- From: Kawicki, Ryan H Sent: Friday, July 24, 2009 10:44 AM To: OpenSceneGraph Users Subject: [osg-users] FW: Importance Of Node Path List In Database Pager Have you implemented a fix yet? If not I'll try to get to it while I'm still around this week/early next week. Unfortunately, we have not come up with a fix. If you like, I could come up with a solution and submit it, but I would hate to duplicate work if you already have it on disk somewhere. I will be out most of next week and would not be able to get to it until sometime the following week. Thanks for the continue support. Ryan H. Kawicki The Boeing Company Training Systems Services Software Engineer -Original Message- From: Robert Osfield [mailto:robert.osfi...@gmail.com] Sent: Friday, July 24, 2009 9:20 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Importance Of Node Path List In Database Pager Hi Ryan, On Fri, Jul 24, 2009 at 3:01 PM, Kawicki, Ryan Hryan.h.kawi...@boeing.com wrote: Would it be possible to store this information as a DatabaseRequest attribute? Curious, I thought I had already made such a change to DatabasePager - to move the NodePath acquisition to the DatabaseRequest set up, but now reviewing it this code isn't in svn/trunk. Weird. Perhaps I thought about implementing it and then got distracted or perhaps I did the experiment but not checked it in. Such a change would be appropriate - adding a RedNodePath to DatabaseRequest and set it inside the DatabasePager::requestNodeFile(). Unfortunately such a change would break the ABI for 2.8.x so would have to be merged with just the svn/trunk and the 2.9.x/2.10 series. The node path should be computed during the cull traversal. The problem here is that there is the possibility for a parent iterator to become invalidated when this operation traverses up the scene graph. Sorry about the confusion on the line number. I am referencing OSG 2.8.1. Thanks, I now understand the issue at hand. One I have previous thought about, but alas wrapped up this work... Have you implemented a fix yet? If not I'll try to get to it while I'm still around this week/early next week. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] OSGDem Question
spike inin wrote: Hi, Is there a way I can acquaint OSGDem not to do that or at atomic accomplish that atramentous accomplishments transparent, so I can seamlessly bury the map I created over a lower resolution map of the world. That didn't make much sense. OSGDem already supports laying small high-res DEM insets on top of lower-resolution data (potentially of the whole world). Cheers, -- 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] Visual Studio 2005
Hi Michael, Have you generated the solution file with cmake yet? Cory Michael W. Hall wrote: Since I am having issues with my linux box, I am tinkering with OSG in Visual Studio 2005. I am not having much luck. I was wondering if anyone can point me to some good example code for VS 2005. I am wanting to do C++/CLR. Thanks for any help. ___ 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] Billboard problem
Ok thx now it works -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15881#15881 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
Hi, recently got a chance to test it again, same thing [Image: http://i16.photobucket.com/albums/b15/Th3Flyboy/screenies/gv.jpg ] [Image: http://i16.photobucket.com/albums/b15/Th3Flyboy/screenies/sv.jpg ] error message CMake Warning (dev) at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 (SET): Syntax error in cmake code at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 when parsing string C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe Invalid escape sequence \P Policy CMP0010 is not set: Bad variable reference syntax is an error. Run cmake --help-policy CMP0010 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 (SET): Syntax error in cmake code at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 when parsing string C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe Invalid escape sequence \P Policy CMP0010 is not set: Bad variable reference syntax is an error. Run cmake --help-policy CMP0010 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): This warning is for project developers. Use -Wno-dev to suppress it. Check for working C compiler: C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe CMake Warning (dev) at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 (SET): Syntax error in cmake code at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 when parsing string C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe Invalid escape sequence \P Policy CMP0010 is not set: Bad variable reference syntax is an error. Run cmake --help-policy CMP0010 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): CMakeLists.txt:2 (PROJECT) This warning is for project developers. Use -Wno-dev to suppress it. Check for working C compiler: C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe -- works Detecting C compiler ABI info CMake Warning (dev) at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 (SET): Syntax error in cmake code at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 when parsing string C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe Invalid escape sequence \P Policy CMP0010 is not set: Bad variable reference syntax is an error. Run cmake --help-policy CMP0010 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): CMakeLists.txt:2 (PROJECT) This warning is for project developers. Use -Wno-dev to suppress it. Detecting C compiler ABI info - done Check for working CXX compiler: C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe CMake Warning (dev) at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 (SET): Syntax error in cmake code at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 when parsing string C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe Invalid escape sequence \P Policy CMP0010 is not set: Bad variable reference syntax is an error. Run cmake --help-policy CMP0010 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): CMakeLists.txt:2 (PROJECT) This warning is for project developers. Use -Wno-dev to suppress it. Check for working CXX compiler: C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe -- works Detecting CXX compiler ABI info CMake Warning (dev) at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 (SET): Syntax error in cmake code at D:/csp/devpack/Devpack 32 flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 when parsing string C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe Invalid escape sequence \P Policy CMP0010 is not set: Bad variable reference syntax is an error. Run cmake --help-policy CMP0010 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): CMakeLists.txt:2 (PROJECT) This warning is for project developers. Use -Wno-dev to suppress it. Detecting CXX
Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback
Hi Brian, Brian R Hill wrote: So, if you wanted to add things to be done before image copy, it should be part of the camera's subgraph. I guess I could do this. Create a custom drawable that call the 3rd party function. The difficulty will be guaranteeing it's the absolutely last thing drawn. The postdraw makes this easy. There is a new SortMode in RenderBin called TRAVERSAL_ORDER that might be able to help with this. jp -- 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
