Re: [osg-users] Proposal to change the way theColladapluginhandlesthe DAE object
Hi, The changes you proposed for dae-handling sounds ok to me. On Mon, Nov 26, 2007 at 12:59:00AM -, Roger James wrote: Here is the first pass at my proposed changes. I have not put the Google compatibility and transparency handling on output in yet but most of the other stuff is in there. I have cleaned up the file/URI handling and added support for UNC names. The reader now returns some extra information about scaling and orientation. Mattias, I am not convinced about the use of std::auto_ptr to return information from the plugin I have followed your convention but I still think passing things through a void pointer will cause memory leaks. I'm not completely happy with that auto_ptr neither, been thinking about making a submission for fixing this and adding more generalised data handling (Robert mentioned some about thison osg-submissions before), but I haven't gotten around to do it yet, been busy days lately. The reason for passing back that filename was that it could be stored under a different path (since the plugin had it's way with the filename). Now with your changes regarding file/uri handling the need for passing back the path to the document might no longer be needed (need to look more at the code before I can say for sure). Nice work. / Mattias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] small VirtualPlanetBuilder bug
Hi Robert and Jason, yes, there are different coordinate systems: texture - lat/long height - UTM 32N (WGS 84, meter) At the time I care about the optical aspect only thus I didn't test which coordinate system the output had. Unfortunately I can't send images since the data is not ours. I will do some testing with the Puget Sound data. Cheers, have a nice week Christoph On Nov 23, 2007 5:17 PM, Jason Beverage [EMAIL PROTECTED] wrote: Hi Christoph, Are your elevation and imagery in the same coordinate system? It's been awhile since I've looked at VPB, but if I recall correctly, the last input file on the command line is used to determine the coordinate system of the output database. So, if someGeoTiff_Height is in a geodetic projection and someGeoTiff_Texture is in a UTM projection, the first command will produce a database in geodetic and the second command line will produce a database in UTM. VPB should scale height values appropriately (at least it was at one point) if you are producing a geodetic database, but this is one explanation as to why your output would be different depending on the order of your command line arguments. Good luck! Jason On 11/23/07, Christoph Ehrler [EMAIL PROTECTED] wrote: Hi @ all VTP users and developers, Apparently it's not arbitrary how to arrange the data input for VirtualPlanetBuilder. The first commandline input produces a weired result with texture and heightfield matching but meshing of the heightfield corrupted. Every tile of the heightfield has only one central point to which all triangles converge. The second commandline produces perfect results though -d and -t statements are yust exchanged !?! osgdem -t someGeoTiff_Texture -d someGeoTiff_Height -l 99 -o output osgdem -d someGeoTiff_Height -t someGeoTiff_Texture -l 99 -o output Just to inform you because we spent hours believing it was the compression or the bit depth of the GeoTIFF !! Cheers Christoph ___ 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] wrong vertex attribute values when using setPrimitiveSet(...)
Hi Daniel, Could you please break up your text into more digestible chunks, as its really hard to follow single large paragraphs. The harder you make it for others reading your posts the less likely you'll find someone who understand your problem enough to respond. Robert. On Nov 25, 2007 6:14 PM, Daniel Holz [EMAIL PROTECTED] wrote: hi everybody, i implemented an algorithm which generates tracks, left behind by a car which drives on a terrain. the tracks are graphically represented by arbitrary primitiveSets (triangles, quads, polygons). to prevent the system from crashing when out of memory (driving for several hours, continously generating track polygons) i used the primitiveSetList in the osg::Geometry object like a queue, inserting newly created primitiveSets at position 0 (osg::Geometry::setPrimitiveSet(0, polygon)) when maxNumPolygons is reached. a simple queue. everything worked fine, but when i decided to associate an array of vertex attributes with the vertices (storing the current frame number for each vertex which is created and using this information to create a fade out effect for the tracks in a vertex shader) i got wrong vertex attribute values when the polygon queue was filled. all the other values like texture coordinates, and vertex positions are fine. in contrary when using no polygon queue (just pushing the new polygons into the vector) the vertex attribute values are correct. could there be a problem with some kind of caching of the vertex attributes? i also use an array of texture coordinates with new values inserted every frame and the values are always correct. i don't get it. perhaps somebody experienced a similar problem and can help me. cheers, daniel ___ 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] small VirtualPlanetBuilder bug
Hi Chistopher, The different coordinate systems is what is leading to the difference. When you don't specify a destination coordinate system VPB/osgdem has to choose one for you, and it takes the first entry in the source list as the destination coordinate system to use. If you do specify the coordinate system yourself then you'll avoid this ambiguity. Robert. On Nov 26, 2007 8:24 AM, Christoph Ehrler [EMAIL PROTECTED] wrote: Hi Robert and Jason, yes, there are different coordinate systems: texture - lat/long height - UTM 32N (WGS 84, meter) At the time I care about the optical aspect only thus I didn't test which coordinate system the output had. Unfortunately I can't send images since the data is not ours. I will do some testing with the Puget Sound data. Cheers, have a nice week Christoph On Nov 23, 2007 5:17 PM, Jason Beverage [EMAIL PROTECTED] wrote: Hi Christoph, Are your elevation and imagery in the same coordinate system? It's been awhile since I've looked at VPB, but if I recall correctly, the last input file on the command line is used to determine the coordinate system of the output database. So, if someGeoTiff_Height is in a geodetic projection and someGeoTiff_Texture is in a UTM projection, the first command will produce a database in geodetic and the second command line will produce a database in UTM. VPB should scale height values appropriately (at least it was at one point) if you are producing a geodetic database, but this is one explanation as to why your output would be different depending on the order of your command line arguments. Good luck! Jason On 11/23/07, Christoph Ehrler [EMAIL PROTECTED] wrote: Hi @ all VTP users and developers, Apparently it's not arbitrary how to arrange the data input for VirtualPlanetBuilder. The first commandline input produces a weired result with texture and heightfield matching but meshing of the heightfield corrupted. Every tile of the heightfield has only one central point to which all triangles converge. The second commandline produces perfect results though -d and -t statements are yust exchanged !?! osgdem -t someGeoTiff_Texture -d someGeoTiff_Height -l 99 -o output osgdem -d someGeoTiff_Height -t someGeoTiff_Texture -l 99 -o output Just to inform you because we spent hours believing it was the compression or the bit depth of the GeoTIFF !! Cheers Christoph ___ 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] I can't use VirtualPlanetBuilder..!
On Nov 25, 2007 7:50 PM, ümit uzun [EMAIL PROTECTED] wrote: Hi Robert; I wrote all thing what I have done! And I insert all my result in OSGDEM folder which you can download from http://rapidshare.com/files/72243472/OSGDEM.tar.gz.html . It is almost 15 MB! İf you download this folder you can look at images, step by step command and created pegout.osga database! Could you open pegout.osga with osgviewer and tell me what you see on your monitor? I only do what you say! But I can't find the problem! Thanks to all your help..! Argg... ignore advice and you will go wrong. The osgdem source data you are passing to to osgdem has no geospatial coordinate itself, and you are not specifying any yourself as layed out in the osgdem tutorial that started you off on this road. So... the result like your source data is undefined. Please use data that has geospatial coords or add them via gdal command line tools, or via the --xx etc command line options. And please re-read my earlier reply. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I can't use VirtualPlanetBuilder..!
Hi Umit, The time consumption is because you have not specified the number of levels to be generated and the default is 10 levels. You can reduce the time taken by specifying the number of levels and reducing it to 2 or 3. And the improper data generation may be due to the scaling factor.Since the data is of very low resolution try giving a scale factor in the range of around 10^(-3). Om ümit uzun wrote: Hi Robert; I wrote all thing what I have done! And I insert all my result in OSGDEM folder which you can download from http://rapidshare.com/files/72243472/OSGDEM.tar.gz.html . It is almost 15 MB! İf you download this folder you can look at images, step by step command and created pegout.osga database! Could you open pegout.osga with osgviewer and tell me what you see on your monitor? I only do what you say! But I can't find the problem! Thanks to all your help..! Umit UZUN Date: Sun, 25 Nov 2007 12:36:39 + From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I can't use VirtualPlanetBuilder..! Hi Umit, Big builds can take quite a long time, 2 days for the puget sound data is odd though, and the strips aren't normal either especially for such a small dataset as 1kby1k, this I'd expect to complete is seconds/minutes. As to what is up at your end, I have no clue. Robert. On Nov 24, 2007 2:05 PM, ümit uzun wrote: Hi All, I want to ask you simple question? I working to make my terrain database during a week but I cound'n do it! I only have stripted screen! I try to use osgdem -t -d -o command to 1kb images which stayes in http://www.cc.gatech.edu/projects/large_models/ps.html web site. When I use this command to make database it takes almost 2 days :) Is it normal period to make database? And when it finished I only see the strips on the screen! What is the problem I can't find? Thanks to Everbody... Ümit UZUN Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! Buraya tıkla! ___ 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 _ Yeni nesil Windows Live Servisleri’ne şimdi ulaşın! http://get.live.com ___ 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] I can't use VirtualPlanetBuilder..!
On Nov 26, 2007 9:55 AM, om [EMAIL PROTECTED] wrote: Hi Umit, The time consumption is because you have not specified the number of levels to be generated and the default is 10 levels. You can reduce the time taken by specifying the number of levels and reducing it to 2 or 3. And the improper data generation may be due to the scaling factor.Since the data is of very low resolution try giving a scale factor in the range of around 10^(-3). For point of reference when I run with Umit data and specified command line option it builds in: completed DataSet::writeDestination(pegout.osga) archive file = pegout.osga archive master file = output.ive Elapsed time = 429.688382 This is with a 2.4GHz intel quad core machine, but osgdem in this instance is only using one core. This is with the SVN version of VPB, but this shouldn't make too much difference with osgdem itself. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proposal to change theway theColladapluginhandlesthe DAE object
I'm not completely happy with that auto_ptr neither, been thinking about making a submission for fixing this and adding more generalised data handling (Robert mentioned some about thison osg-submissions before), but I haven't gotten around to do it yet, been busy days lately. The reason for passing back that filename was that it could be stored under a different path (since the plugin had it's way with the filename). Now with your changes regarding file/uri handling the need for passing back the path to the document might no longer be needed (need to look more at the code before I can say for sure). [Roger James] Mattias, I now pass back a URI to the document that has just been read or written rather than a file name. But only if the DAE object has been passed in and not internally created. This allows you to locate the correct document if the DAE object contains more than one. I will leave the auto_ptr stuff for you to look at. As far as I am aware because the pointer in the map in the options object is a void* then no destructor will be called on delete, so the auto_ptr will not work. On an unrelated topic has anyone noticed the strange goings on with the subject of this thread? It seems to be gaining and loosing spaces in a most peculiar fashion. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgAnimationPath
And should i write a small file like ADDITION.txt to explain what i have added or corrected . Sorry for late reply was hibernating :( On Nov 14, 2007 2:40 PM, Robert Osfield [EMAIL PROTECTED] wrote: On Nov 13, 2007 8:33 PM, Jeremy L. Moles [EMAIL PROTECTED] wrote: If this is a bug (I'm imaging it is) then you should probably submit it to osg-submissions. I remember working on this a few months back, but Robert is real busy right now and I'm not sure he'll be able to check it out any time soon... Yep, this is the thing to do, any bug fixes do it directly on the source and then submit the whole modified file(s) to osg-submissions. I'm taking a bit of breather from doing merges right now while I make progress with other work (you'll all hear about it soon:-), once I've got a major milestone on this work done I'll get back and review all the submissions. Cheers, 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] Offscreen rendering without visible window
Hi, i have some questions regarding Pbuffers, FBO, and offscreen rendering. I'm not showing the final render on a window but retrieving it with glReadPixels for CPU processing. 1) is there any method to create a Graphics Context without any visible window other than using pbuffer = true in traits (on Windows XP)? I have read that Frame Buffer Object (FBO) replaces much of the functionality of PBuffers (Simon Green slides about FBO) and that they have better performance. 2) Can FBO's be used without using PBuffer to establish the GraphicsContext? Since they need one, how? Since FBO's are established at camera objects, is there any method to read back the rendered pixels (other than doing it myself with glReadPixels)? Is perhaps Image the correct path? 3) If the desired size of the rendered result changes, i have to recreate the pbuffer manually creating a new graphics context with the new size. If i use FBO, will i have to manually resize it, or it is done by the camera? I have already achieved doing it with pbuffers, but i will do the rendering with FBO also and compare both methods (until replies, using pbuffer to create de GC). Thanks a lot. PD: StatsHandler fails to create the HUD camera if the main camera's graphics context is PixelBufferWin32 instead of GraphicsWindowWin32. It doesn't found a correct GraphicsContext. Is this perhaps a bug? PPD: Any ideas when will the programming guide book be available ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgAnimationPath
On Nov 26, 2007 11:25 AM, maruti borker [EMAIL PROTECTED] wrote: And should i write a small file like ADDITION.txt to explain what i have added or corrected . Sorry for late reply was hibernating :( No need for a separate .txt file, the changed source files zipped up, and an explanation of the motivation and the implementation of the changes in the body of the email would be fine. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Offscreen rendering without visible window
Hi Himar, Pbuffer is the normal way to render off screen without a window. FBO requirs an already createdd graphics context to work, they aren't a replacement of Pbuffer, just the render to texture support that FBO supplies. FBO's are just part of an OpenGL graphics context state, they don't have any window creation support themselves. Robert. On Nov 26, 2007 11:41 AM, Himar Carmona [EMAIL PROTECTED] wrote: Hi, i have some questions regarding Pbuffers, FBO, and offscreen rendering. I'm not showing the final render on a window but retrieving it with glReadPixels for CPU processing. 1) is there any method to create a Graphics Context without any visible window other than using pbuffer = true in traits (on Windows XP)? I have read that Frame Buffer Object (FBO) replaces much of the functionality of PBuffers (Simon Green slides about FBO) and that they have better performance. 2) Can FBO's be used without using PBuffer to establish the GraphicsContext? Since they need one, how? Since FBO's are established at camera objects, is there any method to read back the rendered pixels (other than doing it myself with glReadPixels)? Is perhaps Image the correct path? 3) If the desired size of the rendered result changes, i have to recreate the pbuffer manually creating a new graphics context with the new size. If i use FBO, will i have to manually resize it, or it is done by the camera? I have already achieved doing it with pbuffers, but i will do the rendering with FBO also and compare both methods (until replies, using pbuffer to create de GC). Thanks a lot. PD: StatsHandler fails to create the HUD camera if the main camera's graphics context is PixelBufferWin32 instead of GraphicsWindowWin32. It doesn't found a correct GraphicsContext. Is this perhaps a bug? PPD: Any ideas when will the programming guide book be available ? ___ 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] OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME and compiles in draw thread deprecated?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robert, In revision 7017, which introduced the ability to compile OpenGL buffers using pbuffers, it looks like you make GL object compilation happen in the pager thread if the pbuffers aren't available, and you override the checks for available time and maximum objects with compileAllGLObjects(). It would seem that these two things would guarantee dropped frames when paging in scenes that have large individual requests. Am I missing something, or is it vastly preferred to do the object compilation in pbuffers? I've only played with that a little, but wouldn't seem to be very useful unless you have more than two processors. Thanks, Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHSsXFeDhWHdXrDRURAnyeAKCNDtPuePzCo1QOqM02Fy7uCuROhQCfRgXM J5qt1lA9rZDO/axUCgGyyyE= =QMHg -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] OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME and compiles in draw thread deprecated?
Hi Tim, On Nov 26, 2007 1:10 PM, Tim Moore [EMAIL PROTECTED] wrote: In revision 7017, which introduced the ability to compile OpenGL buffers using pbuffers, it looks like you make GL object compilation happen in the pager thread if the pbuffers aren't available, and you override the checks for available time and maximum objects with compileAllGLObjects(). It would seem that these two things would guarantee dropped frames when paging in scenes that have large individual requests. Am I missing something, or is it vastly preferred to do the object compilation in pbuffers? I've only played with that a little, but wouldn't seem to be very useful unless you have more than two processors. You must be misreading the code, compilation of OpenGL objects can never happen from within the paging thread - it doesn't have a graphics context to do such a thing, the compilation is either done by any the threads running pbuffers that are available or the graphics threads drawing the actual graphics windows themselves. If one attempted to compile from within the paging thread then the app would crash. As for preference of pbuffers, we'll its not selected by default so there isn't a preference for it in terms of the OSG. In your own app you may find pbuffer and associated graphics threads are effective, this will depend upon the hardware you have, the quality of the OpenGL drives (and their ability to handle multi-threaded usage) and the nature of your models. In general paged databases with lots of geometry and textures to load per tile load will work better with a back ground compile context ( pbuffer and associated thread) if you have the CPU resouces to support it. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME and compiles in draw thread deprecated?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
Hi Tim,
On Nov 26, 2007 1:10 PM, Tim Moore [EMAIL PROTECTED] wrote:
In revision 7017, which introduced the ability to compile OpenGL buffers
using pbuffers,
it looks like you make GL object compilation happen in the pager thread if
the pbuffers
aren't available, and you override the checks for available time and maximum
objects with
compileAllGLObjects(). It would seem that these two things would guarantee
dropped frames
when paging in scenes that have large individual requests. Am I missing
something, or is
it vastly preferred to do the object compilation in pbuffers? I've only
played with that
a little, but wouldn't seem to be very useful unless you have more than two
processors.
You must be misreading the code, compilation of OpenGL objects can
never happen from within the paging thread - it doesn't have a
graphics context to do such a thing, the compilation is either done by
any the threads running pbuffers that are available or the graphics
threads drawing the actual graphics windows themselves. If one
attempted to compile from within the paging thread then the app would
crash.
That's what I thought, but starting on line 673 in DatabasePager.cpp, in the
run function:
if (gc)
{
osg::GraphicsThread* gt = gc-getGraphicsThread();
if (gt)
{
gt-add(new
DatabasePager::CompileOperation(this));
}
else
{
gc-makeCurrent();
compileAllGLObjects(*(gc-getState()));
gc-releaseContext();
}
}
As for preference of pbuffers, we'll its not selected by default so
there isn't a preference for it in terms of the OSG. In your own app
you may find pbuffer and associated graphics threads are effective,
this will depend upon the hardware you have, the quality of the OpenGL
drives (and their ability to handle multi-threaded usage) and the
nature of your models.
In general paged databases with lots of geometry and textures to load
per tile load will work better with a back ground compile context (
pbuffer and associated thread) if you have the CPU resouces to support
it.
Robert.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHSst1eDhWHdXrDRURAnzJAJ4vjiZ754/071XWhvXELDgEFJNqZgCfTmmC
IBrZT31nexF890gdQR9XvL8=
=Xs56
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Curved line
Hello osg users, I would like to draw a nice curved line between a number of x,y,z points. How do I do this? I can not find any spline or curve primitives. I know that gluNurbsCurve supports this. But I can not find a way how OSG does this. Hope you can help me Lambert Verhagen. Visit us at the Marintec China 2007, the All China Maritime Exhibition in Shanghai, from 27-30 November 2007 This e-mail and its content are subject to the disclaimer and General Conditions at www.marin.nl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] wrong vertex attributes in vertex shader
hi everybody, i have a problem when reading the values of user-defined vertex attributes in the vertex shader. THE SITUATION i implemented an algorithm which generates tracks, left behind by a car which drives on a terrain. the track of one wheel is logically represented in the following way: 1. an osg geometry: - osg::ref_ptrosg::Geometry trackGeom, carries the primitiveSetList consisting of arbitrary primitiveSets (triangles, quads, polygons), which are built from vertices in the associated vertex array (see below). 2. several binded arrays: - osg::ref_ptrosg::Vec3Array vertices : ... trackGeom-setVertexArray(vertices.get()); ... - osg::ref_ptrosg::Vec4Array colors : ... trackGeom-setColorArray(colors.get()); trackGeom-setColorBinding(osg::Geometry::BIND_PER_VERTEX); ... - osg::ref_ptrosg::Vec2Array texCoords : ... trackGeom-setTexCoordArray(0, texCoords.get()); ... to prevent the system from crashing when out of memory (driving for several hours, continously generating track polygons) i used the object 'trackGeom' like a queue: inserting newly created primitiveSets at position 0 ( trackGeom-setPrimitiveSet(0,polygon) ) when maxNumPolygons is reached. a simple queue. everything worked fine. but then i decided to implement a fade out effect of the tracks, using my own vertex shader: ( the idea, for better understanding: the idea was to associate a vertex attribute array with the vertex array, for each vertex storing the number of the frame in which it was created and obtain the 'relative frame age' of the vertex by comparing the number of the current frame with the number of the 'frame of creation'. the obtained 'relative frame age' is then used to calculate the alpha value of the vertex in the vertex shader. ) 3. the associated vertex attribute array: - osg::ref_ptrosg::Vec2Array frameTime : ... trackGeom-setVertexAttributeArray(9, frameTime.get()); trackGeom-setVertexAttribuBinding(9, osg::Geometry::BIND_PER_VERTEX); ... THE PROBLEM as soon as the polygon queue is filled i get wrong vertex attribute values, apparently. the other values like texture coordinates and color are fine. in contrary when using NO polygon queue (just pushing the new polygons into 'trackGeom' with ...-addPrimitiveSet(polygon)) the vertex attribute values are correct. could there be a problem with some kind of caching of the vertex attributes? perhaps somebody experienced a similar problem and can help me. thanks in advance, daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME and compiles in draw thread deprecated?
On Nov 26, 2007 1:34 PM, Tim Moore [EMAIL PROTECTED] wrote:
That's what I thought, but starting on line 673 in DatabasePager.cpp, in the
run function:
if (gc)
{
osg::GraphicsThread* gt = gc-getGraphicsThread();
if (gt)
{
gt-add(new
DatabasePager::CompileOperation(this));
}
else
{
gc-makeCurrent();
compileAllGLObjects(*(gc-getState()));
gc-releaseContext();
}
}
Ahh OK, this is the exception, more of an experiment than a code path
usually used. Normally the gc will be NULL, it only not be NULL if
you attach a pbuffer graphics context to do the compilation and it
doesn't its own graphics thread and this isn't the usual usage - if
you use a compile context then its typically used with its own thread.
If you don't use a compile context the old compile paths are used and
everything should behave as normal.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME and compiles in draw thread deprecated?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
On Nov 26, 2007 1:34 PM, Tim Moore [EMAIL PROTECTED] wrote:
if (gc)
{
osg::GraphicsThread* gt =
gc-getGraphicsThread();
if (gt)
{
gt-add(new
DatabasePager::CompileOperation(this));
}
else
{
gc-makeCurrent();
compileAllGLObjects(*(gc-getState()));
gc-releaseContext();
}
}
Ahh OK, this is the exception, more of an experiment than a code path
usually used. Normally the gc will be NULL, it only not be NULL if
you attach a pbuffer graphics context to do the compilation and it
doesn't its own graphics thread and this isn't the usual usage - if
you use a compile context then its typically used with its own thread.
If you don't use a compile context the old compile paths are used and
everything should behave as normal.
Got it. I didn't follow the GraphicsContext code far enough to see that
setCompileContext
isn't normally called for an active context.
Thanks for clearing up my confusion!
Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHSvYHeDhWHdXrDRURAsj5AKDWct5q3JYz4cZbrZeVLhAu0Cu3UACfWB3S
CZjiq0I/tQpjm6QI8gW2Ix4=
=Qt9d
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Autotransform Frustum Update
Hi, My scene graph has an Autotransform with a geode containing geometry for a textured quad to display an icon. The transform is set to auto rotate and scale to the screen. I am noticing two problems with this set up: - When the frustum changes (e.g. fov change), the icons no longer scale to the screen correctly. They get larger or smaller depending on whether the fov gets smaller or larger. - For a more dramatic changed in the frustum (e.g. going from windowed mode to full screen mode), the icons disappear entirely. I think these two problems may be related. I'm not sure if I'm mistaken on how the auto scale is supposed to work. I set the size of the icon in pixels, and it is my understanding that the auto scale mode should maintain the size of the icon in screen coordinates (as long as I've set up the viewport correctly, which I think I have). For the disappearing issue, I tried disabling culling for the autotransform node, but that did not help. Is there something I need to do to force the autotransform to update after I've changed the frustum? I've seen a couple of other posts that may have alluded to this issue, however they were related to culling and the advice given was to disable culling. Any information that anyone could offer on this would be very helpful. Thanks, Will ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Textures turning white
In a large cityscape of loaded .osg/ive high-rise textured building models (LOD, not PagedLOD), initially everything looks great flying in and out around all the buildings, then sometimes after a while some of the building texture faces turn white. I know that invalid/incomplete GL textures will be rendered white, but initially all the textures looked perfect. If the textures got paged out by the graphics pipe, I would expect to see a slight rendering delay when they get paged back in, but not turn white. But even more confusing is that on a single CPU WinXP laptop (2yrs old) with Nvidia(256MB videomem) it runs fine - no white textures; but on a brand new WinXP quad-cpu (not threaded - so we're only using 1 of them) with the latest Nvidia(768MB videomem) the white textures problem seems to be getting worse (more frequent) over time! Could the inconsistancy across various platforms be pointing to a GL driver issue (i.e. different versions), or is there something is OSG that I can be looking at to fix this, or at least isolate what the problem could be? Thank you. Bob. -- Robert E. Balfour, Ph.D. Exec. V.P. CTO, BALFOUR Technologies LLC 960 South Broadway, Suite 108, Hicksville NY 11801 Phone: (516)513-0030 Fax: (516)513-0027 email: [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Offscreen rendering without visible window
I'm not sure if it helps, but for my offscreen FBO rendering I created 1 pixel size window using the windows API and set it's handle as the output of the viewer. the RTT was fine rendering texture size images. I also tried making the window invisible and 0 pixels size but I don't remember what were the results :) (I guess it didn't work) Guy. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, November 26, 2007 2:51 PM Subject: Re: [osg-users] Offscreen rendering without visible window Hi Himar, Pbuffer is the normal way to render off screen without a window. FBO requirs an already createdd graphics context to work, they aren't a replacement of Pbuffer, just the render to texture support that FBO supplies. FBO's are just part of an OpenGL graphics context state, they don't have any window creation support themselves. Robert. On Nov 26, 2007 11:41 AM, Himar Carmona [EMAIL PROTECTED] wrote: Hi, i have some questions regarding Pbuffers, FBO, and offscreen rendering. I'm not showing the final render on a window but retrieving it with glReadPixels for CPU processing. 1) is there any method to create a Graphics Context without any visible window other than using pbuffer = true in traits (on Windows XP)? I have read that Frame Buffer Object (FBO) replaces much of the functionality of PBuffers (Simon Green slides about FBO) and that they have better performance. 2) Can FBO's be used without using PBuffer to establish the GraphicsContext? Since they need one, how? Since FBO's are established at camera objects, is there any method to read back the rendered pixels (other than doing it myself with glReadPixels)? Is perhaps Image the correct path? 3) If the desired size of the rendered result changes, i have to recreate the pbuffer manually creating a new graphics context with the new size. If i use FBO, will i have to manually resize it, or it is done by the camera? I have already achieved doing it with pbuffers, but i will do the rendering with FBO also and compare both methods (until replies, using pbuffer to create de GC). Thanks a lot. PD: StatsHandler fails to create the HUD camera if the main camera's graphics context is PixelBufferWin32 instead of GraphicsWindowWin32. It doesn't found a correct GraphicsContext. Is this perhaps a bug? PPD: Any ideas when will the programming guide book be available ? ___ 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] Diagnostics tools
Hi, any recommendations for diagnostic tools that don't consider the osg smart pointers allocations as memory leaks? thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LOD morphing in OSG
I understand that Creator has this feature LOD morphing but it does not seem to work in OSG. I am wondering whether OSG support LOD morphing or is it because I did not create the LOD morphing correctly. Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
