Re: [osg-users] OSG and Android
On 01/11/2013 04:48 AM, Jan Ciger wrote: On Fri, Jan 11, 2013 at 1:28 AM, Jason Daly jd...@ist.ucf.edu mailto:jd...@ist.ucf.edu wrote: Actually, we've got shared library loading working already. A lot of our software is plugin-based (using dlopen), and it's working fine on Android. There is a bit of JNI involved, but only enough to hook into the regular Android GUI/View stuff. Ah, that's good news then. Would you mind to publish any changes you needed to do to it? I would love to switch to shared lib too, because with the static linking the recompiles are taking ages every time. I will if I can. I doubt I'll be able to, though. I'm frantically trying to finish this up before I switch jobs next week, and I've got a few other things on the plate, too. My outside work time is pretty full too, with moving and stuff. I'm currently doing things like writing the Android.mk file manually for our specific build tree, which is fine for the guys here, but probably wouldn't do for OSG in general. If nothing else, I could give you what I end up with and you (or someone else) could massage it into a nice, CMake-friendly form if you like. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
On 01/11/2013 08:26 AM, Christian Schulte wrote: Hi, I think it is used as cross-checking method. Indeed, if the calculated number (using osg::Image) is less than the number of mipmaps specified in the dds file, the calculated value is kept. On the other hand if the theoretical number of possible mipmaps is higher than the number of mipmaps specified by the dds file, the number used is the one of the dds file. In my opinion, it seems to be possible to have dds files with wrong mipmap informations... Right, OpenGL requires a certain number of mipmap levels depending on the dimensions of the image. DDS likely doesn't enforce the same restriction. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
On 01/11/2013 09:00 AM, Lukasz Izdebski wrote: Hi, But for example we have 512x512 dds texture compressed with DXT1 and in header we have 4 mipmaps. In this example is meaningless to compute number of mipmaps, because OpenGL ,with my knowledge, does not generate mipmaps for compressed textures. So setting bigger number of mipmaps is wrong. Never mind what I said before :-) I think the check is to be sure that for some reason, the DDS file doesn't have too many mipmaps. The loader will take the number of mipmaps in the file, or the number of mipmaps that OpenGL can handle, whichever is less. osg::Image automatically sets the GL_TEXTURE_MAX_LEVEL parameter to the number of mipmaps that are loaded. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG and Android
Hi, all, I had a question about compiling OSG on Android. I understand that the current advice is to build static libraries instead of shared. I was just wondering why this was the case. Is there some reason that the OSG can't be built with shared libraries instead? The main reason I'm asking is that I'd prefer to avoid having to specify the plugins in the code, and use the normal dynamic loading mechanism, if possible. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and Android
On 01/10/2013 05:16 PM, Jorge Izquierdo Ciges wrote: Because the shared linker at execution time in Android works as hell on a bench. It just doesn't call the dependencies of a library... and also your shared libraries are not installed on the system... etc The system is just not friendly to use shared libraries. Can OSG be used as a shared library... if you modify it yourself yes. There are some crashes here and there but it's functional. But then you'll have to face all the other worryes of installing the shared libraries... where... for each application and create an ordered library opener. OpenCV had to create another program just to deploy it's own shared libraries. P.S. Oh and I was forgetting that the shared linker on Android when a library has failed to load then it won't try load that library even if you want to force him until he's forgotten the library (mainly when you kill your process) OK, if that's all it is, I'm going to give it a shot. After fighting a bit with the platform, we've had some luck with getting other libraries working as shared libraries, so I think we'll be OK here. It's compiling now and seems to be reasonably happy. Of course, as you pointed out, compiling and linking is the easy part :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and Android
On 01/10/2013 06:32 PM, Jan Ciger wrote: On 01/10/2013 11:49 PM, Jason Daly wrote: OK, if that's all it is, I'm going to give it a shot. After fighting a bit with the platform, we've had some luck with getting other libraries working as shared libraries, so I think we'll be OK here. It's compiling now and seems to be reasonably happy. Of course, as you pointed out, compiling and linking is the easy part :-) I think you will have most problems with actually using plugins (unless you keep them linked in statically). I don't think that there is a documented interface how to load shared libs at runtime from C/C++ on Android, you have to load the shared libs from within Java code. If you compile all of OSG into one large shared lib and try to load that at runtime instead of static linking, that should be possible without too much hassle - e.g. Qualcomm's Vuforia/QCAR is doing it, OpenCV is doing it, etc. Just make sure to set the lib up as prebuilt, so that it gets actually included in your APK and deployed on the device properly. Actually, we've got shared library loading working already. A lot of our software is plugin-based (using dlopen), and it's working fine on Android. There is a bit of JNI involved, but only enough to hook into the regular Android GUI/View stuff. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
I was about to ask why we aren't just using the log2 function here, but apparently Microsoft doesn't consider this C99-standard function to be important (ie: it's not included in Microsoft's math.h). Seems like cmath is indeed the best solution. --J On 01/09/2013 11:39 AM, Christian Schulte wrote: Hi Robert, I think the problem is linked indeed to a MS math.h problem, but in my opinion it is not linked directly to the floor function but could affect even other functions. I don't know what would be the consequences on the global OSG behaviour but I agree with you that replacing the math.h include would be the best solution. Maybe someone could try to compile my little test code with a Microsoft compiler to see if it is gcc linked or Windows linked. Cheers, Christian Le 09/01/2013 16:50, Robert Osfield a écrit : Hi Christian, Does this mean there is a bug in the MS version of math.h and the floor function it provides? Previously we haven't used cmath as some platforms didn't support it properly, I recall IRIX being a problem, but am not sure if it extends further than this. IRIX support has long been deprecated so won't be a constraint these days. So... using #includecmath could well be a viable solution, It does still concern me that the MS version of math.h is giving different results to cmath. Robert. On 9 January 2013 15:27, Christian Schultechristian.schu...@onera.fr wrote: Hi all, I have investigated a little deeper the problem... Indeed, on Windows platform, the number of mipmaps returned by osg::Image::computeNumberOfMipmapLevels( s, t, r ) is wrong, but it is correct on Linux platforms for the same dds file... Here is attached a little test program that explains why (it is more or less a computeNumberOfMipmapLevels with s=t=1024 and r=1), and it is not linked to OSG. Compile it on Windows 32 bits (works on Win7 and WinXP) (g++ main.cpp -o main.exe) You will see the following result : logf(wf) = 6.93147182464599609375 log(wd)= 6.93147180559945308431 logf(2.0f) = 0.69314718246459960938 log(2.0) = 0.69314718055994528623 logf(wf)/logf(2.0f)= 10. log(wd)/log(2.0) = 10. floor(logf(wf)/logf(2.0f)) = 9. - Here is the error, it should be 10 too... floor(log(wd)/log(2.0))= 10. floor(testf) = 10. floor(testd) = 10. Replacing the include of math.h by cmath results in : logf(wf) = 6.93147182464599609375 log(wd)= 6.93147180559945308431 logf(2.0f) = 0.69314718246459960938 log(2.0) = 0.69314718055994528623 logf(wf)/logf(2.0f)= 10. log(wd)/log(2.0) = 10. floor(logf(wf)/logf(2.0f)) = 10. floor(log(wd)/log(2.0))= 10. floor(testf) = 10. floor(testd) = 10. Under Linux both solutions give the second results. The problem is that osg/Math includes math.h and not cmath. I don't know which would be the best solution : Replace math.h by cmath in include/osg/Math Store the logf division (float testf = logf(wf)/logf(2.0f)) of osg::Image::computeNumberOfMipmapLevels( s, t, r ) in a float before computing the floor. Up to the list to give the answer... PS : this is also the solution to the discussion osgPlugins : dds problem on windows platform I launched 07/03/2011 Cheers, Christian Schulte Le 20/12/2012 15:15, Lukasz Izdebski a écrit : Hi, i probably have solution for this problem, i have found a bug in dds plugin ReaderWriterDDS.cpp Line 633 unsigned numMipmaps = osg::Image::computeNumberOfMipmapLevels( s, t, r ); when compute numMipmaps returns wrong number. this number is less then number of mipmaps in dds file( ddsd.dwMipMapCount ) . This bug makes that when dds mipmaps are loaded to opengl last mipmap (4x4) isn't loaded. and with combination with LINEAR_MIPMAP_LINEAR make this bug. the numMipmaps should be taken form ddsd.dwMipMapCount in attachment i send a corrected version of file. ... Thank you! Cheers, Lukasz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51653#51653 Attachments: http://forum.openscenegraph.org//files/readerwriterdds_204.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 ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Building OSG/Producer/OT 1.2 w/gcc 4.4.5
On 01/07/2013 04:25 PM, Conan Doyle wrote: Hi, I find myself in need of building OSG/Producer/OT 1.2 to support a legacy project. I am using gcc 4.4.5. I am getting numerous compile errors regarding undeclared functions such as memset, memcpy, getenv and so on. These seem easy enough to correct by adding the proper includes to the .cpp files in which the errors are found, but before I continue to do so, I thought I should ask if this was the correct or best approach and if I should expect any issues downstream in doing this or in general with building OSG/Producer/OT with 1.2 w/gcc 4.4.5. Hi, Conan, I vaguely recall having all kinds of problems with OSG 1.2 compiling with any version of gcc4. I think we ran into this when we upgraded our version of Red Hat in the lab, and the new version switched from gcc3 to 4. Our solution at the time was to go ahead and upgrade to OSG 2.0. The point being, there probably isn't a right way to do this. Whatever works best for you is probably the right way. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] R: R: a couple of questions about svg plugin (OSG 3.0.1)
On 12/14/2012 01:19 PM, Gianluca Natale wrote: Unfortunately it crashed with any version of cairo library (gotten from http://ftp.acc.umu.se/pub/gnome/binaries/win32), and any .svg file I tested. I ended up looking deeper at documentation of cairo library. Specifically, since the crash happened (as shown here below in yellow) when it tries to free the memory allocated for a cairo_surface_t, I looked at cairo.h, and found this comment: * Memory management of #cairo_surface_t is done with * cairo_surface_reference() and cairo_surface_destroy(). So, I tried to replace the call (at yellow line here below): free(cairo_surface); with a: cairo_surface_destroy(cairo_surface); I rebuilt osgdb_svg.dll, and now it seems to work. I can load any .svg file and use as a texture with no crash. But I still wonder if that replacement really deallocates the memory allocated for the cairo surface. Hi, Gianluca, This change has already been made in SVN (r12945, by Jason Beverage). The log indicates the change was made because it was causing a crash in Windows. From my experience in using cairo for several years, this is the correct way to destroy a cairo surface. Using free was a bug from the beginning, as cairo surfaces (like all cairo objects) are internally reference counted. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions about mip maps
On 12/14/2012 06:08 PM, Aurelien Albert wrote: Hi, I have a set of pre-computed procedurals textures, and my texture generation system can produce high-quality downsampled textures. So I would like to use them as mipmaps for my textures : - is it possible to allocate and load mipmaps from CPU, just like we load an osg::Image into an osg::Texture2D ? Yes. As far as I know, the way to do it is to pass the entire set of images (with the mipmaps) to osg::Image::setData(), then call osg::Image::setMipmapLevels() with a vector indicating the byte offset to the start of each of the mipmaps. - is there any example of that ? The only example I know of off the top of my head is in the DDS plugin (search for the call to setMipmapLevels to see where). There are probably others, too. - is it mandatory that each mipmap level is exactly half size of the previous ? Not exactly, but each successive level should be an integer quotient of the previous level's size and two. They don't need to be powers of two either, as long as you're targeting relatively recent hardware. Essentially, you take the floor of size/2 to get the size of the next level. Say you start with a size of 999. The mip levels would then be 499, 249, 124, 62, 31, 15, 7, and 3. The textures also don't need to be square. The mip levels stop when any of the dimensions reaches 1, so you shouldn't create any mipmaps that are, for example, 4x1. Hope this helps! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions about mip maps
On 12/14/2012 07:16 PM, Jason Daly wrote: The textures also don't need to be square. The mip levels stop when any of the dimensions reaches 1, so you shouldn't create any mipmaps that are, for example, 4x1. Actually, this isn't exactly correct. You should create mipmaps until you get to a size with a 1 pixel dimension, and then you should stop, so, for example, a 63x21 texture would have mipmaps of 31x10, 15x5, 7x2, and 2x1 (but not 1x1). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating texture coordinates
On 12/10/2012 08:06 AM, Anders Backman wrote: Hi all. Does anyone know about sample code for creating texture coordinates for a general triangle mesh? OpenGL can do this when using TexGen, but if I would like to generate this myself given coordinates, indices (and normals), is there a library that someone knows about that does this? I don't know about a library, but the math involved isn't too difficult. The OpenGL spec gives all of the equations in the Texture Coordinate Generation section (Section 12.1.3 in the most recent spec for the OpenGL 4.3 compatibility profile). Indeed, TexGen is even deprecated in the core profile, as you're expected to do the work in your shaders instead nowadays. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Status of Collada Reader (November, 2012)
On 11/20/2012 09:50 AM, Jeremy Moles wrote: Hey guys--anyone using OSG with the Collada reader on Linux? Although I doubt this is a Linux-centric issue. I've tried the 2.2 (won't even build), 2.3 and 2.4 (neither of which work with the OSG code) to no avail. Is there something obvious I'm missing here? The wiki indicates I should use the 2.2 DOM, but that won't even build on its own; something about missing domAsset.h, which doesn't even exist in the 1.4 tree. It exists in 1.5, but our plugin doesn't work with that yet. I don't use it regularly, but I do have OSG compiled with the 2.2 DOM. I just tested it (osgviewer on a .dae file), and it still seems to be working. I do remember a little bit of pain in getting the 2.2 DOM to compile, but I don't recall the details. I do remember that I only built the dom directory (I don't use Cg, so I skipped the fx directory, and I didn't care about the viewer or rt features). For what it's worth, my copy of the 2.2 DOM does have a dom/include/1.4/dom/domAsset.h file. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] TIFF plugin fails when TIFF is compiled with JPEG compression support
On 11/02/2012 02:53 AM, Bob Smith wrote: Hi, I compiled the TIFF library with JPEG compression support. When I now build OpenSceneGraph, the plugin tiff fails because it has linker errors and cannot find JPEG library... Is there a workaround? The CMakeLists.txt for the TIFF plugin only links against TIFF library, not JPEG... VS2012, OSG 3.1.1, but I guess it should apply to all version... I suspect that OSG's TIFF plugin never expected to support JPEG compression or require the JPEG library to be linked. I'd think that most folks will use a .jpg file if they want JPEG compression (is there an advantage to using a TIFF container for JPEG data?) If you want this feature for TIFF files, you'll probably have to edit the CMake files to link in libjpeg when compiling the tiff plugin. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projective Multi-Texturing
On 10/27/2012 02:09 AM, Christoph Heindl wrote: This sounds like a clever idea, but I have to keep exporting the mesh in mind. When exporting I think I should have the UV coordinates ready on the CPU. Is there a way to transmit the output of the shader (i.e vertex ST coordinates) back to the CPU? You can do this with transform feedback. I'm not sure how good OSG's support for this feature is, though. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projective Multi-Texturing
On 10/26/2012 01:19 PM, Glenn Waldron wrote: For cases where the ST coordinates can't be computed in object or eye coordinates then you'll need to rely upon the UV coords that you've computed. The OSG supports as many texture units as the underlying OpenGL implementation supports and will scale up to 8 without problem on most hardware/drivers. Going this route would be the most straight forward. Another idea is to use a TextureArray (GL_EXT_texture_array). This removes the limit on the number of textures, but adds the constraint that they all must be the same size and that you need GL 2.0. From what I can tell, the main issue isn't the number of textures, it's the number of varying parameters between the vertex and fragment shader. If there are too many textures being applied at once (each with their own set of texture coordinates), it may be possible to run out of these, depending on what else is being interpolated between shader stages. On my machine (Geforce GTX 260): GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS=96 GL_MAX_VARYING_FLOATS=60 So, 96 textures, but only 60 floats for varying parameters. This seems like a lot, but if there are 64 textures on the mesh, it's not even close to enough. Of course, newer cards than mine probably have more... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projective Multi-Texturing
On 10/25/2012 12:17 PM, Christoph Heindl wrote: I think you'd need to do an initial pass to see which photos cover which vertices, then divide up the mesh accordingly. Only one (maybe two or three) textures will need to be active for each patch, which means you'd only need at most three sets of texture coordinates for each vertes. This should be exportable to one of several modern formats. Yes, you'll have some duplication of vertices along the boundaries, but this isn't really a huge problem. The vertex processing most likely isn't going to be your bottleneck here. I agree, but I think for further mesh processing duplicate vertices could be problem (decimation, ...). That's possible. If you're relying on a single mesh for your decimation process, then it could very well present difficulties. The decision will probably have to be based on what combination of techniques presents the fewest difficulties :-) Maybe someone smarter than me can come up with a solution that doesn't require splitting the mesh, but I don't see one... Just one more thought. In my research I found that most modelling software support UV unwrapping (not sure if it is the right term). What I mean is that the user marks a seam on the mesh and the mesh is then unfolded along that seem into individual patches that can be mapped to the UV space. Do you know how such seams are handled by the rendering engine? It seems naturally to me that at seems one need to split the mesh and duplicate vertices. I'm not a modeler, but I think I've seen the tool you're referring to. It's typically used to allow a digital artist to design a texture atlas for the specific mesh. The tool creates a blank texture atlas with all of the texture coordinates mapped appropriately, and then the artist simply paints the desired imagery onto that blank atlas. In your case, you've already got imagery that you're trying to map onto a mesh, so you'd have to warp your photos to fit the texture atlas. Plus, you indicated you'd be needing to blend between textures at the photo borders. With this in mind, I don't know if that tool will be more likely to help or hinder you, to be honest. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projective Multi-Texturing
On 10/24/2012 03:03 AM, Christoph Heindl wrote: Thanks for the hints. From browsing the documentation it seems though that this would also texture non-visible triangles (i.e backfacing triangles)? This however would lead to messy texturing, since I have photos from around the mesh. Shouldn't be a problem if you don't render back faces (which is the default). The fragment shader won't even run for those pixels, as they'll already have been culled. Once you're familiar with that technique, you'll probably be able to come up with a specific technique that works better for your situation. Another benefit of using shaders is that you'll be able to do any blending, exposure compensation, etc. that you might be needing to do really easily as part of the texturing process. I think I'd need a starter sample for how to use EYE_LINEAR in combination with a shader. Here's a page from the nVidia Cg tutorial that talks about projective texturing, including the texture coordinate generation. The example code is in Cg, but it shouldn't be too hard to port to OpenGL (vec4 instead of float4, things like that). Best I could do in a few minutes. http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter09.html If you Google around a bit, I'm sure you can find other examples. Your photo texture samplers will be one set of uniforms, and you'll need another set to encode the photo position and orientation, as these will be needed to calculate the texture coordinates. You won't need to pass texture coordinates as vertex attributes, because you'll be generating them in the vertex shader. As long as you don't have more than a few photos per vertex, you shouldn't have any issues with the limited number of vertex attributes that can be passed between shader stages. That sounds interesting. You don't have an example at hands? Afraid not, I've never actually done it myself :-) There is probably at least a basic example online somewhere, though. A rather related problem is the export of meshes. Using the shader approach, how would one deliver such a textured mesh? Wouldn't it make more sense to pre-calucate the UV coordinates for each vertex/foto infront (incl. visibility detection) and pass this to the shader (possible?), so that I could decide on file export (based on the format chosen) to either - split the mesh if the format does not support multiple texture layers (.ply/.obj maybe). - don't split the mesh if the format supports multiple layers (.fbx) Ah, yes. If you want to end up exporting the mesh, then a real-time shader might be a problem. It's not impossible, as there are formats like COLLADA that allow you to embed shaders, but from my experience, run-time systems don't often fully support those features. If you do need to export to a static format (like fbx), then I don't see a way around splitting the mesh. If your maximum photo count is 64, there's no way you can have all of the textures enabled and statically mapped at the same time (that would mean you'd need 64 sets of texture coordinates, and no graphics card supports that many vertex attributes). I think you'd need to do an initial pass to see which photos cover which vertices, then divide up the mesh accordingly. Only one (maybe two or three) textures will need to be active for each patch, which means you'd only need at most three sets of texture coordinates for each vertes. This should be exportable to one of several modern formats. Yes, you'll have some duplication of vertices along the boundaries, but this isn't really a huge problem. The vertex processing most likely isn't going to be your bottleneck here. Maybe someone smarter than me can come up with a solution that doesn't require splitting the mesh, but I don't see one... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
On 10/24/2012 05:28 AM, Daniel Schmid wrote: Since the material code is unique within geometries, so actually I would need to transfer it only once per Geometry. If I change to BIND_OVERALL, the data is no longer transferred, or at least my shader cannot detect it anymore. I thought i should maybe reduce the VertexAttribArray (l_Array) to one single entry, but this doesn't work either. What is the correct way of passing general or common data, on a per geometry (and not vertex) basis? I don't think BIND_OVERALL is valid for generic attributes. Sergey's right, use a Uniform. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
On 10/24/2012 11:35 AM, Jason Daly wrote: On 10/24/2012 05:28 AM, Daniel Schmid wrote: Since the material code is unique within geometries, so actually I would need to transfer it only once per Geometry. If I change to BIND_OVERALL, the data is no longer transferred, or at least my shader cannot detect it anymore. I thought i should maybe reduce the VertexAttribArray (l_Array) to one single entry, but this doesn't work either. What is the correct way of passing general or common data, on a per geometry (and not vertex) basis? I don't think BIND_OVERALL is valid for generic attributes. Sergey's right, use a Uniform. Scratch that, I'm wrong... From the man page for glVertexAttrib: If a generic vertex attribute bound to an attribute variable in a vertex shader is not updated while the vertex shader is executing, the vertex shader will repeatedly use the current value for the generic vertex attribute. So it seems that BIND_OVERALL should be working just fine. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] speed up the loading
On 10/22/2012 11:15 PM, wh_xiexing wrote: i have hundreds of millions of points to render. i think the Geometry 's setVertexArray (Vec3Array) is time consuming . for every point , it must construct a Vec3 class, and put it into the array. Not true, you can create a Vec3Array out of an array of floats with nothing but a type cast. The Vec* and Vec*Array classes were designed to line up data contiguously in memory so that OpenGL could use it directly and efficiently (note that there are no virtual methods in the Vec* classes). There's no reason to modify OSG to do what you want: // Construct an array of floats float * lotsOfPoints = new float[count]; // Fill up the float array with point data ... // Construct a Vec3Array out of the float data ref_ptrVec3Array array = new Vec3Array(count/3, (Vec3 *) lotsOfPoints); // Assign the Vec3Array to Geometry ref_ptrGeometry geom = new Geometry(); geom-setVertexArray(array); --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projective Multi-Texturing
On 10/23/2012 02:35 AM, Christoph Heindl wrote: After a bit of research I stumbled upon the following approaches to multi-texturing - using ARB_multitexture extension. Seems to be limited by available hardware units. - using GPU multitexturing using separate texture units. Also limited by available texture units on hardware There's no difference between these two. ARB_multitexture is a 15-year old extension that simply provides the specification for how multitexturing is done. Multitexturing has been part of standard OpenGL since version 1.3. - using multi-pass rendering. Probably slower but not limited by hardware. I doubt you'll need to resort to this, but with the vague description of what you're doing, I can't be 100% sure. Question 1: Is there a way to generically supply the textures and UV coordinate sets and let OSG choose the best rendering technique from the list above? Again, I can't be sure what you're trying to do from your brief description, but it sounds like you already have a mesh generated from photos and you now just want to project those photos (which have a known location, orientation, etc) onto the mesh. If this is true, you can generate the texture coordinates directly from the position/orientation of the photo and the positions of each vertex in the mesh. Read up on projective texturing to see how this is done. OSG can do this easily if you write a shader for it, or you can use the osg::TexGen state attribute to handle it for you (it works just like glTexGen in regular OpenGL). The other thing you'll need to do is divide up the mesh so that only the faces that are covered by a given photo or photos are being drawn and textured by those photos. This will eliminate the need for you to have as many texture units as there are photos. There may be regions of the mesh where you want to blend two or more photos together, and this is the only time where you'd need multitexturing. You should be able to handle this mesh segmentation with a not-too-complicated preprocessing step. Hope this helps, --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projective Multi-Texturing
On 10/23/2012 11:59 AM, Christoph Heindl wrote: Hi Jason, On Tue, Oct 23, 2012 at 5:27 PM, Jason Daly jd...@ist.ucf.edu mailto:jd...@ist.ucf.edu wrote: There's no difference between these two. ARB_multitexture is a 15-year old extension that simply provides the specification for how multitexturing is done. Multitexturing has been part of standard OpenGL since version 1.3. Ok I see, I stumbled upon this terms when looking at http://updraft.github.com/osgearth-doc/html/classosgEarth_1_1TextureCompositor.html - using multi-pass rendering. Probably slower but not limited by hardware. I doubt you'll need to resort to this, but with the vague description of what you're doing, I can't be 100% sure. Actually what I do is that I have a mesh that is generated from depth-maps. In a post-processing step I want to apply photos (taken by arbitrary cameras, but with known intrinsics) as textures. What I know is the position of which the photo was taken (relativ to the mesh) and the camera intrinsics. OK, that makes sense. It doesn't change what I said earlier, you can still do this with projective texturing. How can TexGen and a shader help here? Would it allow me to calculate the UV coordinates for a given photo (camera position etc.) and the mesh? The more I think about it, the more I think you'll want to use a shader for this. The basis for your technique will be the EYE_LINEAR TexGen mode that old-fashioned projective texturing used, so you'll probably want to read up on that. There's some sample code written in pure OpenGL here: http://www.sgi.com/products/software/opengl/examples/glut/advanced/source/projtex.c The equation used for EYE_LINEAR TexGen is given in the OpenGL spec. You can also find it in the man page for glTexGen, available here: http://www.opengl.org/sdk/docs/man2/xhtml/glTexGen.xml Once you're familiar with that technique, you'll probably be able to come up with a specific technique that works better for your situation. Another benefit of using shaders is that you'll be able to do any blending, exposure compensation, etc. that you might be needing to do really easily as part of the texturing process. I wanted to avoid splitting the mesh, at least for the internal representation (which I hoped included visualization). Pros and cons have been discussed in this thread (in case you are interested) https://groups.google.com/d/topic/reconstructme/sDb_A-n6_A0/discussion You might not need to segment the mesh. If you don't segment the mesh, it means that you'll have to have all of your photo textures active at the same time. Most modern graphics cards can handle at least 8, decent mid range gaming cards can handle as many as 64, and the high-end enthusiast cards can even hit 128. If you're photo count is less than this number for your hardware, you'll probably be OK. You'll just need to encode which photo or photos are important for each vertex, so you can look them up in the shader, you'd do this as a vertex attribute. Your photo texture samplers will be one set of uniforms, and you'll need another set to encode the photo position and orientation, as these will be needed to calculate the texture coordinates. You won't need to pass texture coordinates as vertex attributes, because you'll be generating them in the vertex shader. As long as you don't have more than a few photos per vertex, you shouldn't have any issues with the limited number of vertex attributes that can be passed between shader stages. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about Optimizer and FLATTEN_STATIC_TRANSFORMS
On 10/19/2012 09:28 AM, Michael Schanne wrote: Hi, I have a model that I converted from an .stl file to .osg. I wanted to apply a scaling to the model, so I added a MatrixTransform with a scaling matrix above the model's root node. For maximum efficiency I wanted to apply the transform directly to the vertices, so I tried to run the .osg file through osgconv a second time, with the OSG_OPTIMIZER env variable set to FLATTEN_STATIC_TRANSFORMS. However, the new file was identical to the previous file, with the parent MatrixTransform still in place. I set the DataVariance of the transform to STATIC, and it had no effect. Is there something else that could interfere with the Optimizer flattening the transform, or am I expecting FLATTEN_STATIC_TRANSFORMS to do something that it's not intended to do? Hi, Michael, The structure of the scene itself can sometimes prevent the transform from being flattened away. What happens if you try FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS (sometimes, you just need a bigger hammer :-) ). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] _OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS
On 10/05/2012 04:55 AM, paul graham wrote: Hi all, we've been having some intermittent deadlock issues and as part of my investigation I noticed that our (albeit quite old - 2.9.8, we shall be upgrading imminently) OSG libs were being compiled with _OPENTHREADS_ATOMIC_USE_MUTEX. On further investigation, it appears that the test for availability of _OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS on our particular architecture (Linux RH 5.6) requires the additional compiler argument -march=i686 in order to pass and hence not default to using mutexes. Hi, Paul, Coming from previous RHEL 5 experience, yes, you are correct. The gcc version on RHEL5 doesn't assume a 686 architecture, and hence, won't enable the atomic builtins unless you explicitly ask. Would I be right in thinking that building with _OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS instead of _OPENTHREADS_ATOMIC_USE_MUTEX should provide significant 'general' performance improvement? It certainly won't hurt. Whether you see a noticeable improvement will depend on your application. On a related note - our investigations into these deadlocks has proved very difficult since typically the thread stacktraces recorded at the point of deadlock can't be traced further back beyond libGL.so - if anyone has experience of similar situations, I'd welcome any advice. Sorry, can't help with this, other than to say that an upgrade to version 3.0.1 (or later) would be a good idea, as there have been some fixes related to intermittent deadlocks since the version you're running. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer takes over my standard input
On 09/25/2012 12:04 PM, Christoffer Pettersson wrote: hmm ok. I tried the code on another computer with specifications between the two computers mentioned before. This one running Slackware as well. And the code ran fine on this one. Theyre using the same terminal and as far as I know they also use the same compiler. As I mentioned before, Writing a proper gui is not an option. The framework needs to be controlled from the terminal. Hi, Christoffer, As Robert has hinted at, the OSG isn't really designed to be used from the command line, and as such, it doesn't provide any interfaces to do so. That usage model is rather antiquated and graphical interfaces are by far the norm these days. As luck would have it, however, I recently implemented a tool that was also required to be console-driven. The easiest way to handle it is to use a separate thread to wait for and read your input (this way, stdin can block as usual while waiting for a command, while the main viewer threads can proceed merrily on their way). I'll send you my console app (off-list), so you can have an example to follow. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer takes over my standard input
On 9/25/2012 5:01 PM, Christoffer Pettersson wrote: Hi Jason, That is pretty much what I'm doing, just the other way around. The main thread is responsible for handling standard inputs, while the second thread is responsible for handling the renderer. I didn't see the code you posted earlier (just looked it up on the forum). I'm a bit confused as to why you're reading from cin in both threads. That is definitely going to cause a problem. You should only be reading from cin in the main thread in your case. I'd expect the viewer thread to be hanging up on that cin call in the run() function on every frame. Another potential issue I saw is that you're not protecting your _nodes vector at all. You could theoretically be trying to add a model to it in the main thread at the same time as you're pulling models off of it in the renderer thread. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer takes over my standard input
On 9/25/2012 5:27 PM, Christoffer Pettersson wrote: The cin in the thread is only there for demonstration purposes. It was used to test the blocking of the cin function. If i write cin in the render thread then the program is halted. If i write it in the main thread it is not halted. The model code is also just for demonstration. That part of the code works. It's essentially just there to recreate the cin problem Maybe I'm missing your point, but that behavior is exactly what I would expect. If you try to read from cin in the same thread that you're using for the OSG rendering, it will block waiting for input every time. As far as I know, there's no way for it to not block. The way to get around this is to read commands from cin in a different thread and store the commands in a buffer, and then process the buffered commands in the render thread between frames. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer takes over my standard input
On 09/25/2012 05:45 PM, Christoffer Pettersson wrote: The cin in the render thread is not supposed to be there. They were just put there to see if they would block or not, which they did. The problem i have is that if i write cin in any other thread than the render thread, then the thread containing the cin command does not block. It jumps over the cin command giving me an empty buffer. This happens on 1 out of the 3 computers i have tested the code on. On the other 2, the cin command succesfully blocks. Ah, OK, now I understand the problem. Thanks :-) Not sure about your case, but usually when std::cin doesn't block, it means that there's something left to be read from the stream. What happens if you switch to using std::getline() instead? You can then process the entire line of input using a stringstream, and there's no chance a stray \n will get stuck in the stream. It's usually better to process console input in a line-oriented way. Take a look at this question on Stack Overflow: http://stackoverflow.com/questions/11354936/why-doesnt-stdgetline-block --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph Newbie: PErformance question
On 09/11/2012 09:41 AM, Sergey Polischuk wrote: Hi you can take a look at Geometry::computeFastPathsUsed() source and check yourself. As a general rule you are going to be slow, if your geometry uses separate indices in osg::Geometry for vertex attribs (not those in DrawElements*** primitive sets, but those set with osg::Geometry::set***Indices() ) or if binding for any vertex attribute is set to BIND_PER_PRIMITIVE. Not fast path is basically glBegin glEnd style stuff, so it supposed to be slow for high-poly geometries. In this case, the teapot example is using calls to glMap* and glEval*, which takes spline curve data and converts it into vertices, normals, and texture coordinates (on the CPU side), before passing the mesh data on to the rest of the pipeline (using glBegin/glEnd-style calls). I'd guess that this is about as slow path as you can get :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 3.1.3 developerrelease
On 09/07/2012 05:28 AM, Robert Osfield wrote: Hi All, I plan to tag a developer release this afternoon, but before I do I'd like some feedback from testing out in the community to make sure that it's building a running OK. This dev release won't contain all the submissions that have accumulated over the last couple of months, if you one that is pending please be patient. After taking things easy w.r.t open source dev over the summer I'm now steadily going through submissions, it's quite a backlog so it'll take me a few weeks to review them all. During this period I plan to keep making dev releases rather than wait till all submissions have been processed. If you feel a submission had been missed out/overlooked please don't be shy in checking up on progress on it, sometimes submissions I've actually responded to and await a response that hasn't forth coming so it's worth checking up just in case there is something else I need from the submission. Thanks you help in test :-) Robert. To whom it may concern, I noticed that the CDash site (cdash.openscenegraph.org) seems to be broken. Not sure how long it's been that way. Anyway, current SVN builds fine on RHEL 6.2. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Safe downcast
On 08/20/2012 09:00 AM, Peterakos wrote: Hello. In the example osganimationviewer in main there is the following line: osg::Group* node = dynamic_castosg::Group*(osgDB::readNodeFiles(arguments)); How safe is this if i use only 1 model in arguments and it is not Group ? osgDB::readNodeFiles inserts a group at the root if there's more than one model loaded, but not when only a single model is loaded. There's a (rather slim) chance that your one model might not contain a Group (or Group descendant) at the root and that the dynamic_cast would result in a NULL. If you wanted to be absolutely sure, you could put in a check for this. Practically, almost every useful model (especially models with animations) will have some kind of group at its root. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is there any way to preload textures/geometry?
On 08/13/2012 05:26 PM, Nick Jones wrote: Hello, I am experiencing a performance decrease when OSG culls new objects into view for the first time. My current assumption is that the objects' textures and/or geometry must be pushed down to the GPU before it can be used. Once they are cached in the GPU, the performance returns to normal. Does anyone know of a way I can tell OSG to preload textures and/or geometry to the card during my load time? If I can preload all my data at load time, I won't have any performance decrease at run time. I am working on a real time system and I cannot afford the performance hits that I am getting. You probably want to take a look at osgUtil::GLObjectsVisitor --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Parallel Rendering Problems using NVidia GPU cards in Windows
On 06/25/2012 12:59 AM, GeeKer Wang wrote: Hi, all I want to use two GTS 250 cards to do the parallel rendering job based on OpenSceneGraph。 In my experiment, a scene full of complex models is split to 2 parts according to viewport。 The 2 parts are rendered in seperated windows (actually two slaves). I hope the LEFT part is rendered in the first screen and by the first GPU, and the RIGHT part in the second screen and by the second GPU。 The results are a little wierd and disappointing. Hi, Bob, The additional card will only help if your application is GPU-bound (that is, waiting on the GPU to finish rendering a frame before the next can start). Another possibility is that it is CPU bound (the CPU is taking most of the time and the GPU is waiting on it), and another is that it is interconnect bound (the bus between the CPU or RAM and the GPU is the bottleneck). Just adding another card will not help if you're CPU-bound or interconnect bound, and it can actually make things worse if your scene isn't set up in an optimal way. You might end up trying to cram twice the amount of data down the bus in order to try and keep both GPUs fed, and this will kill performance even more than with a single card. One quick fix you can try is to run the osgUtil::Optimizer on your scene with the option VERTEX_PRETRANSFORM | INDEX_MESH | VERTEX_POSTTRANSFORM. This will optimize the vertex data for the vertex cache common on modern GPUs, and may help with bus bandwidth. The other key is to be sure that your scene is organized and subdivided spatially, so that when you're viewing the scene, you don't end up duplicating draw calls across the GPUs. Hope this helps, --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ambient Issues
On 06/06/2012 11:34 PM, Jordan Sparks wrote: Hi, I work in a research lab that uses a CAVE. We were recently given a large 3D model made in Google SketchUp to work with by a client. Unfortunately, we keep having issues when running it in the CAVE on OSG. The model seems to have it's ambient light amped up as it keeps glowing white and yet sometimes, if the camera is far enough, this light will fade (leading me to believe this might be a light attached to the camera. I'm not sure what it is, but the effect seems similar to when you ramp up the ambient light attribute of a model. I know not everyone works with CAVEs but does anyone think they know what the issue is? It might be that your model's normals are getting scaled. Try something like this: osg::StateSet *ss = model-getOrCreateStateSet(); ss-setMode(GL_NORMALIZE, osg::StateAttribute::ON); --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tessellation
On 06/05/2012 05:50 AM, Bob Slobodan wrote: Basically yes. My problem is that I don't really get how the tesselation works and how to create new polygons using the geometry modified by the tessellation. I thought that the tesselation would simply add new PrimitiveSet such as DrawArrays and that I could have created my new polygons using the getFirst() and getCount() function of DrawArrays with my vertexArray. Unfortunately, when I look at my geometry after the tesselation, it only has DrawElementsUByte, and I don't see how I could get a list of triangles from this PrimitiveSet. I've looked at the DOC, the headers and the source but I don't see what to do. Note that DrawElementsUByte essentially is-a std::vectorGLubyte which stores indices into the vertex attribute arrays. Traverse the vector to get the indices, then look up the specific vertex position, normal, etc, in the appropriate vertex attribute array. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Uniform arrays.
On 05/10/2012 08:26 PM, Jonathan Diaz wrote: Hi, I am having the same problem with uniform vec4 arrays with new nvidia driver. We are still back on a pretty old version of osg, 2.8.3. Which files from the current subversion contain the fix. Program, Uniform, some others? Hi, Jonathan, The fix is in Program.cpp, in the Program::PerContextProgram::linkProgram method. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking and render to texture
Hi, Janosch, Picking works based on traversing the scene, and not necessarily just what's drawn on the screen. You said that you render part of your scene to a texture. Are you sure you're not picking from that same scene? --J On 05/22/2012 03:47 PM, Janosch Machowinski wrote: Hi, sorry I just figured out that I didn't make my problem clear. I can pick ghost objects. Even if nothing is drawn at a particular position on my screen, I get picks to objects that were rendered to the texture. Greetings Janosch On 22.05.2012 20:48, Janosch Machowinski wrote: Hello, I got a problem with picking and render to texture. I use an osg::Camera to render a part of my graph to a texture and display it in an HUD. My problem now is that when I pick, I can also pick objects that were rendered to the texture. My question would now be how could I avoid that any object of the subgraph that is rendered to the texture gets picked ? Alternatively it would be ok, if I could pick on the quad showing the texture and get the object that was rendered to it. Greetings Janosch ___ 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] Manipulator and selection
On 05/10/2012 07:21 AM, Bob Slobodan wrote: Hi, First of all, thank you for your answer. I took a look at osgscribe and I tried to do the same thing, but it doesn't really work. I tried many things but this is my last attempt: You may need to tweak the factor and units numbers for your particular application. Here's a link that might help you understand what they're trying to do: http://www.opengl.org/archives/resources/faq/technical/polygonoffset.htm I also have another question for the manipulator. I want to enable the user to switch from a perspective view to an orthographic view. Everything works fine, but at some point, I need to force the computation of the new clipping planes. I can't wait for the auto computation and I'm not sure of how to do that. After some researches I found out that the cull visitor would be perfect for that, but how can I attach a cull visitor to the camera ? I read in the FAQ that the Camera was a subclass of cullVisiotr, but it doesn't seem to wright. Does anyone have a clue? osg::Camera inherits from CullSettings, not CullVisitor. CullVisitor also inherits from CullSettings (via CullStack), so they're related, but neither is a direct ancestor or descendant of the other. If you can't wait for the Viewer to adjust the clipping planes for you, another possibility is just to use a fixed set of clipping planes (one for perspective and one for ortho), and set the Camera to not compute the planes automatically. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Manipulator and selection
OK, disregard everything I said about using osgscribe and Polygon Offset. Having just read the link I posted myself, I realized that glPolygonOffset only works for filled polygons and not lines or points. Sorry for the misdirection. Unfortunately, you'll have to come up with something a bit more clever for those. I don't have any suggestions off the top of my head, but the FAQ entry does mention a couple of possibilities using the depth range or the stencil buffer. There might also be a vertex shader solution. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47642#47642 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Inconsistent behaviour with a set of Pseudo Loaders
On 05/10/2012 02:42 PM, Scott Wasinger wrote: osgviewer: No match. then the viewer promptly exits without rendering even the booster model. Hi, Scott, The No match error suggests to me that you're on some kind of UNIX-style system, and that the command line shell is trying to do regex-style substitution for you with the square brackets. For example, in some command shells rm [ab].txt would delete files called a.txt and/or b.txt. What happens if you put quotes around the sustainer.flt argument? osgviewer booster.flt sustainer.flt.[35.54,0,0].rot --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph - voxel/terrain rendering
On 05/06/2012 02:38 AM, Pete Black wrote: How suitable will OpenSceneGraph be for this kind of task? - i would have up to 5 million triangles visible at once (though a large number of these will be overdrawn) , and this dataset could be split into arbitrary-sized chunks, to optimise batch size. The triangles are textured with a single 'atlas' texture, and the vertices are specified in their final global coordinate locations, so no transforms are needed for each chunk. I pretty much have CPU to burn for state-sorting and culling. I'd say it would at least be worth a look. If you organize your scene into an octree, you could minimize the section of the scene hierarchy that would change from frame to frame, which would keep update and cull traversals manageable. Basically, does OSG have features for: a) updating OpenGL buffers/arrays in a separate thread Yes, although I'm not sure how well your particular use case will work here. OSG requires you to specify which sections of the scene are dynamic and which are static. The Update/Cull thread(s) then traverse the dynamic objects in the scene while the Draw thread waits. Once all the dynamic objects have been traversed, the Draw thread begins doing its work. In your case, you'll probably be marking almost all of the scene dynamic, so I'm not sure how much speedup you'll get from the multithreading. b) optimised rendering by eliminating unnecessary state changes, compared to something like Ogre3d Yes. This is historically where OSG gets most of its speedup. OSG employs state sorting and lazy state updating in the draw dispatch. I'm guessing that with something like MineCraft, you'll have a lot of geometry, but a relatively small number of state sets. OSG would be perfect for this. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Uniform arrays.
On 05/09/2012 05:37 AM, Eldar Insafutdinov wrote: Well, adding [0] actually did the trick! Mismatch of the array sizes did not matter in the end(I want to pass arrays of variable length to glsl with sizes up to 20 elements, so that's fine with me). Not sure why my drivers don't work here, I'm on Linux with NVIDIA card and fairly up to date drivers. Thanks for helping me out! Hi, Eldar, The problem actually only occurs with recent NVIDIA drivers (older versions didn't have this issue). As David mentioned, the latest SVN and the most recent developer releases also include this workaround, so you won't need to add the [0] yourself if you use one of those. Obviously, it'll be in the next public OSG release, too. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Manipulator and selection
On 05/09/2012 07:34 AM, Bob Slobodan wrote: I finally figured out what was the problem with the camera. It was just that I had really large coordinates (for example : 510, 510, 100). So I finally subtsracted an offset (510, 510, 0) to all my points and the manipulator now works just fine. It also solved part of the selection problem. And now that I use a PolytopeIntersector instead of a line segment intersector, I can select what I want. The last problem that I have now is to figured out how to make the point appear in front of the lines and the lines in front of the surfaces. Does anyone have a clue of how to do that ? Hi, Bob, Take a look at the osgscribe example. It shows how to use osg::PolygonOffset to show lines on top of surfaces. You can probably extend that to handle the points as well. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building JNI wrapper for OSGdem
On 05/09/2012 12:39 PM, Sean K wrote: Hi Rafa Thank you so much for looking at the problem -- having a second set of eyes look at a problem is so valuable. You were right -- The OSG and VPB -- I was using release builds. But my own DLL -- I had it in the DEBUG build. After I changed to RELEASE build, the crash did not happen anymore -- and my DLL was able to successfully build the output OSG file. Thank you for helping. Just curious though -- what is the issue behind mixing debug and release binaries that causes something like this to crash? I noticed in the original crash that it was involved in the c++ deconstructor for strings or some other C++ POJO. I am thinking about what could have been implemented in those destructors or runtime libraries that is confused with either debug or release binaries. Maybe the function signatures are switched between debug or release mode? That seems very dangerous. Maybe the size of the heap objects used for strings are different between the release and debug? Just curious why the mix up for non-debug and debug libraries causes this kind of crash. The main source of the issue is the Microsoft C runtime library. The debug version of the CRT and the release version are two separate DLLs and they occupy different areas in memory when loaded. The heap managers are also very different (the debug heap includes a lot of extra data to help debug memory allocation/initialization issues), so if you create an object on the debug heap and later free it from the release heap, you'll have heap corruption. Details about the issue are here: http://msdn.microsoft.com/en-us/library/ms235460%28v=vs.80%29.aspx There are also likely to be countless differences in the code itself (ever seen #ifdef _DEBUG in the header files?) The topic has been discussed many, many times on this list, too. You can skim through the archives for more info. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can not read some osg examples?
On 05/02/2012 07:38 AM, Helen Wang wrote: Thank you for your reply. I have set OSG_FILE_PATH environment variable and checked the graphic card driver. does it mean that the only sultion is to change a better graphic card? My current graphic card is quite poor, but since my models is quite simple, my model is working ok Yes, the functions that are mentioned are part of OpenGL 1.5 or later. If your graphics card doesn't support those, it's either very, very old or very, very incapable. You can spend less than $50 to get a card that is several generations better. If you are going to be working with OSG, I'd highly recommend it. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG RotateToPoint
On 04/27/2012 01:46 PM, dan marshal wrote: Hi, I am porting a java3d app to OSG and have to implement RotateToPoint. My model is an airplane and I have its location and the point I want to rotate to. Is there an OSG function similar to RotateToPoint? Have you seen a good example of this implementation? I'm not entirely sure what you're trying to accomplish, but you might want to take a look at the makeLookAt method in osg::Matrix. If you're trying to rotate the plane to aim it at a particular point in space, that should do it for you. You can use the resulting osg::Matrix in an osg::MatrixTransform node. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] libjasper with jpeg decoder for jp2plugin
On 04/27/2012 03:55 PM, Thomas Lerman wrote: Hi, I am trying to get JasPer to work with osg so I can have the jp2 plugin. I have tried the standard distribution from their website and the modified files in this thread. I am getting the following linker errors (I am only showing the errors from release mode, debug is similar but not the same) preventing me from building the plugin. It appears to be a conflict with what both are linked with. Before I spend too much time, I figured I would post in hopes of someone with an answer. Any help is greatly appreciated. It looks like Jasper and OSG may be compiled with different C runtime libraries. Jasper is compiled with LIBCMT (/MT option to the compiler), while OSG is compiled with MSVCRT (/MD option). You'll want to change Jasper to use /MD (or /MDd in debug mode). That should take care of it. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] colours in Android OSG
Hi, Maurizio, It probably comes from the fact that you're using ShapeDrawables for your geometry. ShapeDrawable was never intended for serious work, and as such, probably wasn't high on the list for support when OSG was ported to work with OpenGL ES. If you converted your geometry to use actual osg::Geometry drawables, you might have better luck. --J On 04/25/2012 10:47 AM, Maurizio Lodo wrote: Hi Jorge and thanks for your reply. The file I am loading in the viewers is cell.osg (attached), which on Windows/Linux appears like screen_shot_0_0.jpg In the OSG android viewer example it appears like osgAndroidLightOn.jpg and if I toggle the light with the corresponding button I get osgAndroidLightOff.jpg. no message in LogCat about lights, the only message is about arial.ttf missing. I know I am probably showing how daft I am, but I thought the viewers would have shown the same model in the same way. Thanks Maurizio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47289#47289 Attachments: http://forum.openscenegraph.org//files/osgandroidlightoff_208.jpg http://forum.openscenegraph.org//files/osgandroidlighton_123.jpg http://forum.openscenegraph.org//files/screen_shot_0_0_185.jpg http://forum.openscenegraph.org//files/cell_100.osg ___ 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] colours in Android OSG
If you're just using one overall color per drawable, try switching that
for an osg::Material with the DIFFUSE color set to the same color. You
might have better luck that way.
--J
On 04/25/2012 01:08 PM, Maurizio Lodo wrote:
Thanks Jason,
true, I was using ShapeDrawables. However, I was already working on converting
the geometries to use osg::Geometry. I have not done the cylinders yet; however
I have converted the cubes, and, unfortunately the results are exactly the
same. The code used to generate the cube geometry is pretty basic. Here it is:
Code:
osg::Geometry* CCubicPore::createCubeGeometry( const osg::Vec3 halfLengths, const
osg::Vec4 color)
{
const float xMin( -halfLengths[ 0 ] );
const float xMax( halfLengths[ 0 ] );
const float yMin( -halfLengths[ 1 ] );
const float yMax( halfLengths[ 1 ] );
const float zMin( -halfLengths[ 2 ] );
const float zMax( halfLengths[ 2 ] );
osg::Geometry* cube = new osg::Geometry();
osg::ref_ptr osg::Vec3Array vertices = osg::ref_ptr
osg::Vec3Array( new osg::Vec3Array );
osg::ref_ptr osg::Vec3Array normals = osg::ref_ptr osg::Vec3Array(
new osg::Vec3Array );
osg::ref_ptr osg::Vec4Array colors = osg::ref_ptr osg::Vec4Array(
new osg::Vec4Array );
// front face
vertices-push_back( osg::Vec3(xMin,yMin,zMax) );
vertices-push_back( osg::Vec3(xMax,yMin,zMax) );
vertices-push_back( osg::Vec3(xMax,yMax,zMax) );
vertices-push_back( osg::Vec3(xMin,yMax,zMax) );
normals-push_back( osg::Vec3( 0.0, 0.0, -1.0 ) );
// back face
vertices-push_back( osg::Vec3(xMax,yMin,zMin) );
vertices-push_back( osg::Vec3(xMin,yMin,zMin) );
vertices-push_back( osg::Vec3(xMin,yMax,zMin) );
vertices-push_back( osg::Vec3(xMax,yMax,zMin) );
normals-push_back( osg::Vec3( 0.0, 0.0, 1.0 ) );
// left
vertices-push_back( osg::Vec3(xMin,yMax,zMax) );
vertices-push_back( osg::Vec3(xMin,yMax,zMin) );
vertices-push_back( osg::Vec3(xMin,yMin,zMin) );
vertices-push_back( osg::Vec3(xMin,yMin,zMax) );
normals-push_back( osg::Vec3( -1.0, 0.0, 0.0 ) );
// right
vertices-push_back( osg::Vec3(xMax,yMax,zMin) );
vertices-push_back( osg::Vec3(xMax,yMax,zMax) );
vertices-push_back( osg::Vec3(xMax,yMin,zMax) );
vertices-push_back( osg::Vec3(xMax,yMin,zMin) );
normals-push_back( osg::Vec3( 1.0, 0.0, 0.0 ) );
// bottom
vertices-push_back( osg::Vec3(xMax,yMin,zMax) );
vertices-push_back( osg::Vec3(xMin,yMin,zMax) );
vertices-push_back( osg::Vec3(xMin,yMin,zMin) );
vertices-push_back( osg::Vec3(xMax,yMin,zMin) );
normals-push_back( osg::Vec3( 0.0, -1.0, 0.0 ) );
// top
vertices-push_back( osg::Vec3(xMax,yMax,zMax) );
vertices-push_back( osg::Vec3(xMax,yMax,zMin) );
vertices-push_back( osg::Vec3(xMin,yMax,zMin) );
vertices-push_back( osg::Vec3(xMin,yMax,zMax) );
normals-push_back( osg::Vec3( 0.0, 1.0, 0.0 ) );
cube-addPrimitiveSet( new osg::DrawArrays( osg::PrimitiveSet::QUADS, 0,
vertices-size() ) );
cube-setVertexArray( vertices );
cube-setTexCoordArray( 0, vertices );
cube-setNormalArray( normals );
cube-setNormalBinding( osg::Geometry::BIND_PER_PRIMITIVE );
colors-push_back( color );
cube-setColorArray( colors );
cube-setColorBinding( osg::Geometry::BIND_OVERALL );
return cube;
}
then I use osg::PositionAttitudeTransform to move the cubes to the correct
position.
Cheers,
Maurizio
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47295#47295
___
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] colours in Android OSG
On 04/25/2012 03:21 PM, Rafa Gaitan wrote: Hi Maurizio, I think the problem could be that glColorMaterial is not supported in OpenGLES 1.1. When you use ColorArray in a Geometry, I think it uses glColorMaterial to enable lighting using the color of the geometry. If you want to use Colors + Lighting in OpenGL ES 1.1, you need to setup an osg::Material in the StateSet of the Geometry. There is an osgmaterial example that you could use for reference. Yeah, that's what I was trying to say. Thanks for translating for me, Rafa :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why no games with OSG?
On 04/24/2012 01:24 PM, Terry Welsh wrote: And I recall seeing screenshots for Pirates of the XXI Century, but I don't know if that game was ever finished. Anyone know what happened to it? I was going to mention it, but I couldn't find any active links for it either. I saw it being demoed in nVidia's booth at SIGGRAPH one year. I don't know if it ever was finished, but it seems that the developer Diosoft is now out of business. It was a gorgeous-looking game, though. There are some screenshots here: http://www.gamershell.com/pc/pirates_of_the_xxi_century/screenshots.html --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in OverlayNode.cpp
On 04/24/2012 03:21 PM, Chris Long wrote: Hi, I'd like to request that someone patch OverlayNode with this one-line fix. We are still having to work around it in our OSG application. You'll probably get quicker results if you patch the file yourself and post it (the whole modified file) to the Submissions forum. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building new website, assistance appreciated!
Hi, Robert, On 04/12/2012 06:39 AM, Robert Osfield wrote: Hi All, Those who haven't received their activation email I have used the joomla admin pages for the registered users to activate and enable the accounts for you. We still need to sort out the issue with the mails being eaten as spam, but at least this hurdle shouldn't stop you from joining in the experiment. Thanks, I can log in now. My e-mail finally came at nearly 3:00 am EDT. Checking the route in the header, Dreamhost received it at 11:30, shortly after I registered, and it seems to have taken 15 hours to get from Dreamhost to my mail server here. Of course, when I clicked the link, I was informed that it had expired. In any case, I don't think there's anything you could do at your end to fix my particular issue. The next step will be to identify what bits of the website are most critical for populate and they get these pages dealt with, either by me or by others who'll I grant access rights to. The question is what rights should we open to to whom. See below for the list of different groups that Joomla has be default. Public |— Manager |—|— Administrator |— Registered |—|— Author |—|—|— Editor |—|—|—|— Publisher |— Super Users Right now all those who've registered are listed Registered, except for me and I'm listed as Super User. I'm guessing that we'll have a small number of Administrator/Managers and then a wider set of Authors, Editor and Publishers. Those who've worked on Joomla websites will know a bit more about what types of rights are required so let us know your experiences and recommendations. Our sites have always been pretty small, so we've only ever had the Super User have the ability to do administration, create articles, etc. I know Joomla can handle it, but I've not seen how it works myself. This article explains the different default user groups (you can also create custom groups) http://docs.joomla.org/Changing_user_groups --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quick questions about assigning render bins
On 04/12/2012 07:34 PM, Preet wrote: I need to render a bunch of different objects using layer data and I'm doing it by disabling depth test and specifying a render bin to control render order... something like myObject-getOrCreateStateSet()-setMode(GL_DEPTH_TEST,osg::StateAttribute::OFF); myObject-getOrCreateStateSet()-setRenderBinDetails(11,RenderBin); * Should I be doing this on a per-object basis, or would I see better performance if I created group nodes with the right renderbin setup and then added the objects to the group nodes (assume hundreds of objects, but 10-20 layers)? (I don't know how OSG sorts/orders the scene graph nodes before rendering) By default, OSG sorts each render bin by state, so your drawables in each bin would be sorted according to the StateSets applied to them such that state changes are minimized. I'm not sure how much of an improvement (if any) you'd see by organizing your drawables into groups and applying the render bin state that way. I doubt it would be all that significant, but I'm not sure. * Some of my objects have transparency, but again, I'm specifying render order. So is it okay to put those objects in the RenderBin renderbin as opposed to the DepthSortedBin? If Objects A and B are both transparent, both in RenderBin (10) and RenderBin (11) respectively, and A is behind B, I should see object A through B correct? This is what some preliminary test code seems to indicate (and in that code switching from DepthSortedBin to RenderBin doesn't result in any changes). If you're disabling the depth test and doing your own sorting anyway, then yes, specifying DepthSortedBin won't do much for you :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building new website, assistance appreciated!
FWIW, I'm in the same boat as Paul. I registered around 11:30 and still haven't gotten the activation e-mail. I've checked the spam filter. I'll keep an eye out for it... --J On 04/11/2012 01:05 PM, Paul Martz wrote: Well, I'm glad it's working for most people. Happy website editing! :-) -Paul On 4/11/2012 10:05 AM, Jordi Torres wrote: Hi all, I just registered and the email was in the spam folder in my gmail account. Cheers. 2012/4/11 Thrall, Bryanbryan.thr...@flightsafety.com mailto:bryan.thr...@flightsafety.com Paul Martz wrote on 2012-04-11: Has anyone successfully registered an account yet? I went through the registration process and was informed I would be sent an email with an activation link. That was about 1/2 hour ago; still no email... I just successfully created an account, activated it, and logged in. Check your spam filter? -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.commailto:bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi Torres Fabra gvSIG 3D blog http://gvsig3d.blogspot.com Instituto de Automática e Informática Industrial http://www.ai2.upv.es ___ 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] s there some documentation on what gets dumped outif you set OSG_NOTIFY_LEVEL to various things?
On 04/11/2012 04:57 PM, Zachary Hilbun wrote: Hi, Would still like to know the answer to this question. I'm not aware of any documentation on this, other than the source code itself. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building new website, assistance appreciated!
On 04/11/2012 07:17 PM, Thomas Hogarth wrote: Also on the subject of accounts, are we planning to use the joomla accounts to login to MediaWiki? Not sure what the plan is myself, but there's a Joomla extension that provides this functionality: http://goo.gl/b4kLk --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] .ive acronym?
I remember it being something more generic (interactive virtual environment, or something like that), and not tied to any kind of history. I vaguely recall the e-mail thread about what to call the format, but I can't remember any specifics. We don't seem to have mail archives that go back that far anymore, either. The logs show that the format was added in 2003 (around version 0.9.6 of OSG), a while after the Inventor .iv format had become largely irrelevant. --J On 04/06/2012 11:34 AM, Paul Martz wrote: I believe it has something to do with OSG's early relationship to Inventor. -Paul On 4/6/2012 8:00 AM, Akilan Thangamani wrote: hi I could not find the acronym of .ive. Every where it is said that it is OSG truncated binary format. But from where these three letters have been taken?? ___ 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] Website, Version control and Server migration
On 04/02/2012 10:57 AM, Robert Osfield wrote: Hi All, I am currently looking at Joomla, while I read up about it, has anyone else out there worked with Joomla? Thoughts? Hi, Robert, We use Joomla for pretty much all of our web presence here in our lab, as well as for some additional work we do with the UCF programming team. The basic web stuff is pretty straightforward in Joomla. We've also written some Joomla extensions to support the programming team work (we run programming contests completely within the Joomla environment). One thing we've not really done is host a software repository as part of the site itself, but I don't think that would be difficult. Feel free to take a look at our sites if you like: http://www.irl.ucf.edu http://www.ucfprogrammingteam.org You might also want to check out joomlashack.com for templates and extensions. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Wiki
On 03/22/2012 04:29 PM, Robert Osfield wrote: I can also just submit the app if that's the preferred way of doing it. You could just send the entry text and link to me and I could add it for you. Hi, Robert, I sent these to you last week (off-list). No rush it getting it posted, but I just wanted to make sure that you did actually receive them. Thanks again, --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] constant size overlay
On 03/26/2012 09:03 AM, Michael Schanne wrote: Hi, I want to use OSG to create an overlay where I have different symbols marking certain points in my scene. I want these symbols to remain a constant size in screen coordinates until crossing certain thresholds (for example, they are size A when at a distance X from the camera, then change to size B once distance X). It’s a little different than a HUD because I want the symbols to move as I pan the camera, so that they stay at the same world coordinates. I am using an orthographic projection where the camera is directly overhead in the Z direction, and it will only pan in the X-Y plane. I took a look at the OverlayNode class, but the description didn’t sound like what I wanted. The LOD class sounded more like what I need, so I could switch between multiple sized children based on the camera distance, but I’m still not quite sure how to make each child have a constant size within its camera distance range. Does anyone have any suggestions for me? Hi, Michael, There's not an existing OSG construct that will do exactly what you want, but you might take a look at AutoTransform to see if you can build what you want based on that. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Wiki
On 03/26/2012 12:44 PM, Robert Osfield wrote: Hi Jason, On 26 March 2012 16:43, Jason Dalyjd...@ist.ucf.edu wrote: On 03/22/2012 04:29 PM, Robert Osfield wrote: I sent these to you last week (off-list). No rush it getting it posted, but I just wanted to make sure that you did actually receive them. I got it thanks. Presently trying to work where is the best place for it. We have Applications page liked to off the Community section: http://www.openscenegraph.org/projects/osg/wiki/Community/Applications I'm open to suggestions. That's the page that the customer suggested, too. If you're OK with it, that would be perfect. Thanks! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Wiki
I'm finishing up some work for a sponsor, and they'd like me to contribute the application I ended up writing to the community. I'd like to post it on the Community/Software page of the wiki. How would I go about doing that? I tried editing the page myself, but my account (username: lyceel) doesn't seem to have the required permissions. I can also just submit the app if that's the preferred way of doing it. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Retrobooster - OSG-based game
Very nice, Terry! Looks like the human characters need a stop drop and roll behavior, though... ;-) --J On 03/21/2012 01:50 PM, Terry Welsh wrote: At the risk of sounding like a shameless self-promoter, here's level playthrough video from a hobby project I've been working on. I'd be grateful to hear any critiques or ideas anyone has. Plus, I thought people might get a kick out of seeing a pretty involved OSG project in development. http://www.youtube.com/watch?v=VkVbq4jIr2k -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.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] [osgPlugins] My PNG plugin in missing after building OSG V 3.0.1
ZacharyH wrote: You mentioned that you need the libpng development libraries installed on your system. The closest thing I have to that is ReaderWriterPNG.cpp under OpenSceneGraph-3.0.1/src/osgPlugins/png. Is that it? If not, where would I download what I need for my version of OGS? Is it documented anywhere that you have to do this if you want to do PNG? ReaderWriterPNG.cpp is the source code for the osgdb_png.so plugin. Many of the OSG plugins rely on a 3rd-party library to do their work (the PNG plugin need libpng, the JPEG plugin needs libjpeg, etc.) The 3rd party libraries are listed here: http://www.openscenegraph.org/projects/osg/wiki/Downloads/Dependencies Since you're on a Linux machine, your Linux distribution should have packages for most of these. Be aware, though that there are usually two packages for each library. One just lets you run programs that use the library, the other lets you develop programs to use the library. You need the development one. Usually, these packages have a -devel or -dev suffix. ZacharyH wrote: Doing a search in Synaptic Package Manager it shows packages such as linpng12-dev and linpng++-dev but I have no idea if those are compatible with OSG. That's the development package for libpng. That's the one you want. Since you're also developing for Qt, you want to make sure you have the -dev version of the Qt packages installed, too. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46266#46266 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
I typically just use the mailing list instead of the forum. I guess the Mail2Forum gateway doesn't handle attachments very well. Here it is... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46206#46206 Attachments: http://forum.openscenegraph.org//files/human_125.osg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/13/2012 07:14 AM, Ethan Fahy wrote: Jason, it looks like something went wrong with your last post since it's awaiting approval. There was a file attached but it was identical to the last file. Was there something important in that message that I missed? Thanks again. No, it's fine. It looked to me like my attachment from the mailing list didn't make it through the gateway to the forum properly, so I went ahead and logged onto the forum to post it directly there. Of course, by the time I got through with that, the original attachment had shown up just fine. But then, of course, my post was flagged for approval because I'm a new user on the forum :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/13/2012 12:52 PM, Christian Buchner wrote: Attention, almost anything that is BIND_PER_PRIMITIVE will force osg into a slow render path that does make use of immediate draw calls. I mentioned this up a bit higher in the thread. The question of whether or not it will be slow is different than whether or not it will (or should) work properly at all. As far as I can tell, OSG implements the necessary glVertexAttrib() calls that you'd need for this to work, so I don't know why the attributes fail to make it to the vertex shader. Sure, it's generally not a good idea to rely on PER_PRIMITIVE bindings at all, but for a particular use case where, say, scientific data is being visualized, the visualization lends itself to per-primitive attributes, and there are few enough primitives that performance isn't a problem, is there a reason why OSG wouldn't handle this? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG within web browsers?
Chris Hanson wrote: I would think the osg4web work is the best place to start as it claims: Currently the supported browsers are Firefox and IE and the OS platform is Windows XP-Vista. Nevertheless, most part of the code is OS neutral. There's also osg.js (osgjs.org), which approaches it differently, providing an OSG-like JavaScript API on top of WebGL. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46232#46232 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stack overflow error with derived osg classes
On 03/02/2012 02:32 PM, Antony Tomarelli wrote: (Sorry, couldn't figure out how to be specific but concise with the title) I created a class (called Test) that derived from PositionAttitudeTransform which would control the position of a shape (so a geode) in the scene. I wanted to then update it by setting that class as the geode's user data, and then having it update via a callback (which is irrelevant to the problem (as far as I can see)). However, when I add an instance of Test as geode's user data a stack overflow occurs when the viewer calls realize(). No stack overflow if I don't. I see that addChild() is virtual, but I don't know if that would cause problems - I'm still rather a novice to OSG and C++. Can anyone explain the problem? A stack overflow usually means some kind of infinite recursion is happening. A method is calling another method, which calls another method, and so forth, until eventually the original method is called again. This cycle continues forever until the system runs out of stack space (there's no more room to keep track of all the method calls). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] My PNG plugin in missing after buildingOSG V 3.0.1
On 03/13/2012 06:04 PM, Zachary Hilbun wrote: Hi, This is a Linux machine and I am using Eclipse for development of a Qt app. I installed OSG V 3.0.0 and found it did not have the Qt integration in it. I then downloaded and built OSG V 3.0.1. I need to read a PNG image but find that I have no osgdb_png.so in my 3.0.1 directory which is under /usr/local/lib/osgPlugins-3.0.1. I do have it under my home directory /OpenSceneGraph/lib/osgPlugins-3.0.0. Can I just copy the 3.0.0 plugin to my 3.0.1 directory or is there a version problem? Why didn't my osgdb_png.so get placed in the 3.0.1 plugin directory along with the rest of the plugins? How can I get it there? What needs to be set up in order for the plugins to be found? I now have 2 OSG versions on my computer. Can I safely get rid of the 3.0.0 version? How can I do that? I'm guessing you installed OSG-3.0.0 from a package in your Linux distribution. If so, you can use the regular package management system for your distribution to remove OSG-3.0.0 (if you can tell us which Linux distribution you have, we can probably give you more specific instructions). In order to build the osgdb_png.so plugin, you need the libpng development libraries installed on your system (most likely, you only have the runtime libraries, which doesn't include the headers needed for development). If your distribution has a package called libpng-devel or libpng-dev, you'll need to install that. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] write to collada
On 03/12/2012 08:49 AM, David De Weerdt wrote: Hi, I have the following osg file. If I load this in my application, it loads fine. If I use osgDB::writeNodeFile to write the scenegraph to a collada (.dae) file, the cube is not added to the collada file. I do not get any errors/warnings and I have other osg files that I can convert to .dae perfectly fine. So it is probably something specific with this file. Your file includes a ShapeDrawable. This doesn't mean anything to anyone except for OSG itself. If you want to export a cube to COLLADA, you'll need to change that ShapeDrawable cube to be a Geometry with all the necessary vertices, indexes, etc. In general, it's best to avoid ShapeDrawables except for quick tests and toy applications. They often lead to problems like this :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/12/2012 10:04 AM, Ethan Fahy wrote:
Thanks Jason,
I understand about the interpolation. I have been operating under the
assumption that if I use a node visitor to loop over each primitive in my
object, create a floatArray of index numbers of size=size(primitive array), and
then bind_per_primitive, then I shouldn't have to worry about interpolation of
those index numbers within the shader. Is that correct?
If you're trying to get the same value for all fragments on a primitive,
then yes, this will work. Be aware, though, that rendering geometry
with per-primitive binding is going to be quite slow compared to overall
or per-vertex binding.
As an alternative, you could specify your floatArray at
size=size(primitive array) * 3 (assuming you're rendering triangles) and
just specify the same index for all three vertices of each triangle.
Then, you could use per-vertex binding and not fall off the fast path.
I noticed that in Christian's code snippet that the osg::Program that he
created was not attached to the geometry's stateset. Without attaching it, you
will still have a floatArray stored in the 6 position, but it will not have a
name and therefore I don't think you can access it from the shader.
In either case, when i try to add my floatArray to the 6th vertex attribute, my
shaders stop working. I don't get any glsl errors printed to screen, but even
if I try to do something simple like assign all color values to black, the
shader just spits out the underlying object colors and ignores my shader
commands. If I don't attach the osg::Program to my object's stateset, the
shader commands do work again but I can't access my 6th vertex attribute
because it wasn't named.
Here is the stateset that was added to my object.obj's geometry:
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Program {
name targetIndices
GeometryVerticesOut 1
GeometryInputType TRIANGLES
GeometryOutputType TRIANGLE_STRIP
AttribBindingLocation indices 6
num_shaders 0
}
}
I'm assuming most of these things are default values since I never specified
GeometryVerticesOut, GeometryInputType, GeometryOutputType, or num_shaders when
I created my osg::Program. Are these defaults the cause of my problems?
The defaults are probably fine (they apply to geometry shaders, which I
don't think you're using). The attribute binding for indices at
attribute 6 looks good as well. However, it looks as if there are not
any shaders attached to your Program (num_shaders 0), which isn't
going to work at all. You need to create an osg::Shader (specifying the
type of shader, vertex, geometry, or fragment), add the shader's source
to it, and then add the shader to the Program. Then, you can attach the
program to the StateSet and everything should work:
shader = new osg::Shader(osg::Shader::FRAGMENT);
shader-setShaderSource(source);
program-addShader(shader);
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/12/2012 01:15 PM, Ethan Fahy wrote: Does that mean that an osg::StateSet can only have one osg::Program? I have one application that uses a nodeVisitor to assign my generic vertex attribute and sets a program with the generic vertex names. After saving the result as an ive file I have another application that reads in that ive file and attaches a shader program and renders the node. Is it possible to either have multiple osg::Programs per stateset or to combine osg::Programs? Yes, there can be only one GLSL program active at any time (this is an OpenGL rule), hence there is only one osg::Program allowed per StateSet. Currently, there is no provision in OSG for combining Shaders or Programs (though I believe this is on the to-do list). For now, though, you'll have to do the combining yourself. There are several tricks you can use to get different code to execute from the same shader. One simple method is to define an if/else block and switch code paths based on the value of a Uniform. You can also define a function in one shader, and have it called from another shader. This way, you can switch behavior by using different implementations of the same function. Shader A implements the shader's main() function and defines the prototype for function foo(), which is called in main(). Function foo() is implemented in both shader A and shader B, using the prototype defined in shader A, but each having different code. In one case, you attach shaders A and C to the program, and in the other case, you attach shaders B and C. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access thevertex color in a shader, is there a loss of precision?
On 03/12/2012 02:02 PM, Jason Daly wrote: You can also define a function in one shader, and have it called from another shader. This way, you can switch behavior by using different implementations of the same function. Shader A implements the shader's main() function and defines the prototype for function foo(), which is called in main(). Function foo() is implemented in both shader A and shader B, using the prototype defined in shader A, but each having different code. In one case, you attach shaders A and C to the program, and in the other case, you attach shaders B and C. Hang on, I messed that up :-) I meant shader A defines main() and the prototype for foo(). Shaders B and C each define an implementation of foo(), with different sets of code. In one case, you attach shaders A and B to the program, and in the other, you attach shaders A and C. This allows foo() to behave differently, depending on which shader (e.g.: which implementation of foo() ) is attached to the program. Sorry for the confusion :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/12/2012 02:21 PM, Ethan Fahy wrote:
Thanks Jason,
So, since I can't combine programs (I didn't necessarily mean multiple shaders,
I just meant multiple programs), I decided to take this line of code:
program-addBindAttribLocation(indices, 6);
and move it to where I assemble my shader program and attach it to the node's
stateset. This way my nodeVisitor can still set my generic vertex array in
position 6 and my osg::Program's shader can access those index values by
including the following line in the frag shader:
in float indices;
I looked at the osg file that I wrote to disk and verified that my stateset's
program contained this line:
AttribBindingLocation indices 6
However, when I use indices in my shader, the resulting value is always equal
to 0.0, even though my VertexAttributeArray values range from 0.0 to 124.0. I
don't want to impose on you too much since you've already helped me out a great
deal, but I'm going to go ahead and attach an osg file that demonstrates this
behavior. The file is a simple human shape with 125 primitives. I created a
generic vertex array with index values sequential from 0-124. I also attached
a simple shader that paints everything green if the indices = 0 and red
otherwise. As you can see by opening this file in osgviewer, all values are
green. If you have time to look at it that would be fantastic but I completely
understand if you don't. Thanks again,
Yeah, it's green for me, too.
One problem appears to be that while your VertexAttribArray on attribute
6 looks fine, you have a vertex shader defined that isn't passing the
value down to the fragment shader. The fragment shader will never
receive your attribute data this way.
I did a quick try to get the vertex shader to pass the data down, but I
couldn't get it working in the five minutes I spent. I attached my
attempt to hopefully inspire you to get to the real solution :-)
Note that I went back to the GLSL 1.2-style of attribute and varying
instead of the in and out qualifiers that were introduced in OpenGL 3.
If I get some time, I'll try to play with it some more.
--J
Geode {
nodeMask 0x
cullingActive TRUE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode USE
binNumber 6
binName RenderBin
GL_LIGHTING OFF
Program {
name Environment
GeometryVerticesOut 1
GeometryInputType TRIANGLES
GeometryOutputType TRIANGLE_STRIP
AttribBindingLocation indices 6
num_shaders 2
Shader {
type FRAGMENT
code {
varying float fIndices;
void main(void)
{
vec4 color = gl_Color;
if( fIndices == 0.0 ){
color.r = 0.0;
color.g = 1.0;
color.b = 0.0;
}else{
color.r = 1.0;
color.g = 0.0;
color.b = 0.0;
}
gl_FragColor = color;
}
}
}
Shader {
type VERTEX
code {
attribute float indices;
varying float fIndices;
void main(void)
{
gl_FrontColor = gl_Color;
gl_Position = ftransform();
fIndices = indices;
}
}
}
}
textureUnit 0 {
}
textureUnit 1 {
GL_TEXTURE_2D ON
Texture2D {
UniqueID Texture2D_0
wrap_s CLAMP_TO_EDGE
wrap_t CLAMP_TO_EDGE
wrap_r CLAMP_TO_EDGE
min_filter NEAREST
mag_filter NEAREST
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo FALSE
shadowComparison FALSE
shadowCompareFunc GL_LEQUAL
shadowTextureMode GL_LUMINANCE
}
}
}
num_drawables 1
Geometry {
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 125
{
DrawElementsUInt QUADS 4
{
0 1 2 3
}
DrawElementsUInt QUADS 4
{
3 4 5 0
}
DrawElementsUInt QUADS 4
{
1 6 7 2
}
DrawElementsUInt QUADS 4
{
5 4 7 6
}
DrawElementsUInt QUADS 4
{
8 9 10 11
}
DrawElementsUInt QUADS 4
{
9 12 13 10
}
DrawElementsUInt QUADS 4
{
10 16 17 11
}
DrawElementsUInt QUADS 4
{
10 13 18 16
}
DrawElementsUInt QUADS 4
{
13 14 19 18
}
DrawElementsUInt QUADS 4
{
17 20 22 11
}
DrawElementsUInt QUADS 4
{
22 20 21 23
}
DrawElementsUInt QUADS 4
{
23 21 19 14
}
DrawElementsUInt
Re: [osg-users] If I set a vertex color using floats and access thevertex color in a shader, is there a loss of precision?
On 03/12/2012 03:40 PM, Jason Daly wrote:
On 03/12/2012 02:21 PM, Ethan Fahy wrote:
Thanks Jason,
So, since I can't combine programs (I didn't necessarily mean multiple shaders,
I just meant multiple programs), I decided to take this line of code:
program-addBindAttribLocation(indices, 6);
and move it to where I assemble my shader program and attach it to the node's
stateset. This way my nodeVisitor can still set my generic vertex array in
position 6 and my osg::Program's shader can access those index values by
including the following line in the frag shader:
in float indices;
I looked at the osg file that I wrote to disk and verified that my stateset's
program contained this line:
AttribBindingLocation indices 6
However, when I use indices in my shader, the resulting value is always equal
to 0.0, even though my VertexAttributeArray values range from 0.0 to 124.0. I
don't want to impose on you too much since you've already helped me out a great
deal, but I'm going to go ahead and attach an osg file that demonstrates this
behavior. The file is a simple human shape with 125 primitives. I created a
generic vertex array with index values sequential from 0-124. I also attached
a simple shader that paints everything green if the indices = 0 and red
otherwise. As you can see by opening this file in osgviewer, all values are
green. If you have time to look at it that would be fantastic but I completely
understand if you don't. Thanks again,
It seems that generic vertex attributes don't work in PER_PRIMITIVE mode
(at least not with shaders). Changing the binding to PER_VERTEX (and
adding enough values to cover all the vertices) makes it work. Have a look:
--J
Geode {
nodeMask 0x
cullingActive TRUE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode USE
binNumber 6
binName RenderBin
GL_LIGHTING OFF
Program {
name Environment
GeometryVerticesOut 1
GeometryInputType TRIANGLES
GeometryOutputType TRIANGLE_STRIP
AttribBindingLocation indices 6
num_shaders 2
Shader {
type FRAGMENT
code {
varying float fIndices;
void main(void)
{
vec4 color = gl_Color;
if( fIndices == 0.0 ){
color.r = 0.0;
color.g = 1.0;
color.b = 0.0;
}else{
color.r = 1.0;
color.g = 0.0;
color.b = 0.0;
}
gl_FragColor = color;
}
}
}
Shader {
type VERTEX
code {
attribute float indices;
varying float fIndices;
void main(void)
{
gl_FrontColor = gl_Color;
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
fIndices = indices;
}
}
}
}
textureUnit 0 {
}
textureUnit 1 {
GL_TEXTURE_2D ON
Texture2D {
UniqueID Texture2D_0
wrap_s CLAMP_TO_EDGE
wrap_t CLAMP_TO_EDGE
wrap_r CLAMP_TO_EDGE
min_filter NEAREST
mag_filter NEAREST
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo FALSE
shadowComparison FALSE
shadowCompareFunc GL_LEQUAL
shadowTextureMode GL_LUMINANCE
}
}
}
num_drawables 1
Geometry {
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 125
{
DrawElementsUInt QUADS 4
{
0 1 2 3
}
DrawElementsUInt QUADS 4
{
3 4 5 0
}
DrawElementsUInt QUADS 4
{
1 6 7 2
}
DrawElementsUInt QUADS 4
{
5 4 7 6
}
DrawElementsUInt QUADS 4
{
8 9 10 11
}
DrawElementsUInt QUADS 4
{
9 12 13 10
}
DrawElementsUInt QUADS 4
{
10 16 17 11
}
DrawElementsUInt QUADS 4
{
10 13 18 16
}
DrawElementsUInt QUADS 4
{
13 14 19 18
}
DrawElementsUInt QUADS 4
{
17 20 22 11
}
DrawElementsUInt QUADS 4
{
22 20 21 23
}
DrawElementsUInt QUADS 4
{
23 21 19 14
}
DrawElementsUInt QUADS 4
{
17 16 24 25
}
DrawElementsUInt QUADS 4
{
16 18 26 24
}
DrawElementsUInt QUADS 4
{
18 19 27 26
}
DrawElementsUInt QUADS 4
{
25 28 20 17
}
DrawElementsUInt QUADS 4
{
20 28 29 21
}
DrawElementsUInt QUADS 4
{
29 27 19 21
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/09/2012 02:08 PM, Ethan Fahy wrote:
So I decided to go again and try to use a generic vertex attribute to store my
index numbers. I noticed from another osg forum thread that there is currently
a problem using int values for vertex attributes but that floats are working
and can be converted to ints in the shader. With that in mind, I implemented
Christian's code snippet up to the part where I've already added a vec2 float
vertex attribute to the 6th position. I have a couple of questions though:
1. in osg there is no Vec1Array (which makes sense), but then if I only wanted
to store 1 float value for each vertex, what would I use? osg::array ?
Close, osg::FloatArray :-)
2. I need to access the vertex values from a frag shader instead of the vertex
shader as seen in Christian's code snippet. If I have a generic vertex shader
like this:
Code:
void main(void)
{
gl_FrontColor = gl_Color;
gl_Position = ftransform();
}
then can I access the vertex attribute in the frag shader like this?
Code:
in vec2 indices;
void main(void)
{
//get index from vertex attribute 6
vec2 index = indices;
}
Depends on what you're after, but I'm guessing not. The fragment values
will be interpolated between the vertices, so if you have a value of 6.0
on one vertex and 8.0 on another, the value for the fragment halfway
between those vertices will be 7.0. If you're drawing triangles, and
you want all of the fragments on a particular triangle to have the same
value, you can specify flat shading in the fragment shader:
flat in vec2 indices;
which might give you what you're looking for (without knowing how your
geometry is laid out and how you're using the indices, I can only guess).
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] exception with cullVisitor-traverse(*_camera) after manually creating a geode
On 03/07/2012 04:15 PM, Renato Oliveira wrote: Hi, I am having a problem in which i get an exception when OSG is trying to render my manually created geode. The crash happens in sceneView.cpp when calling cullVisitor-traverse(*_camera). Does anyone have any ideias what might be? Hi, Renato, We're going to need a lot more specific information than I get an exception and my manually created geode before any of us can come close to helping you. Take a look at this link and try again: http://catb.org/esr/faqs/smart-questions.html --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] exception with cullVisitor-traverse(*_camera) after manually creating a geode
On 03/07/2012 04:42 PM, Renato Oliveira wrote: Hi, sure i understand, sorry about that. i just wanted to know if someone already experienced the same issue before. what i am actually doing is i created a obj loader similar to the obj loader plugin from openscenegraph (the mojoraity of the code of copied directly just for test). once i have loaded the file, i create a mesh using all the information loaded and set the vertices, normals, texture cordinates, and primitive set. no problem there. than i attache my mesh to the a viewer like anyother example of the osg and run. like i said before, the crash happens when the cullvisitor's traverse function gets called when its building the sceneview. If the CullVisitor is crashing in the traverse() method, it's very likely that you've given the Viewer an invalid mesh to render. That method is used every frame by every OSG program in existence. It's extremely unlikely that it's the cause of your problem. You'll need to dig into your reworked .obj loader and figure out where the problem is. Make sure the vertices, normals, and texture coordinates all have the right number of items. Make sure that the primitives you create make sense (e.g. don't create a triangle with two or four vertices). Check for NaN's along the way. Things like that. I'd suggest starting with an .obj file that creates a single triangle. Test that, and work up from there. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/06/2012 07:39 AM, Ethan Fahy wrote: I was also wary of using generic attributes after reading the bottom of this page: http://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/attributes.php Just seemed like more trouble than it was worth. But I'm really just learning OpenGL and osg so it could be that using a generic vertex attribute is the way to go. That information is outdated. Nvidia cards since the GeForce 8 series, I believe, have not had the aliasing issue. Indeed, the traditional vertex attributes (normal, color, texture coordinates) are even deprecated in OpenGL since version 3. There shouldn't be any reason to worry about using generic vertex attributes. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3D Frame Packing with OSG
On 03/06/2012 10:56 AM, Jan Ciger wrote: From what I've read in several forums. If you create the 1280x1470 format (or 1920x2205 format) directly, you can get a GeForce card to render 3D content on a 3D monitor. Jason, could you post links to this info, please? I am interested in that as well. I am afraid that the OpenGL driver on a GeForce will refuse to generate the correct HDMI signal tags for the monitor to recognize, because you aren't running Quadro. If it was possible, it would be quite trivial to bypass the no stereo on GeForce crippling by Nvidia. Hi, Jan, I don't have links, nor do I have personal experience. I haven't actually read the HDMI 1.4a spec either, so I very well may be wrong. That said, most of the information I Googled came from the bino project. There were several reports in their forums of folks using custom ModeLines in the xorg.conf that allowed them to generate packed-frame 3d from their video cards. The precise contents of the xorg.conf were given in at least one post, so you should be able to try it yourself. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/06/2012 11:58 AM, Ethan Fahy wrote: Thanks for the info guys. I'll have to think about the best way forward a bit. I'm still hesitant to add generic vertex attributes just because it seems like it would add to a given node's memory usage and since I don't use the node's color values for anything other than lookup table purposes I might as well store stuff in those colors since everything I draw is going to have to have memory allocated for colors no matter what. I would also like to think that the code I'm writing will always be used on newer GeForce cards, I don't think that I can know that for certain as it would ultimately be distributed to some not-so-powerful computers to run on. I understand your hesitance. Most of the tutorials are written with the more traditional vertex attributes, and when you're just starting out, it can be simpler to think in those terms. If it works for you, then by all means, go with it. As you continue to learn, though, I'd just encourage you to keep in mind that modern cards don't have any distinction between different kinds of vertex attributes anymore. Every attribute, whether it's labeled normals, colors, texture coordinates, or whatever, is simply a per-vertex value that is used by the vertex shader (there's always a vertex shader running under the hood, even if you don't specify your own). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3D Frame Packing with OSG
On 03/06/2012 01:42 PM, Jan Ciger wrote: OK, it is this thread: http://lists.nongnu.org/archive/html/bino-list/2011-03/msg00058.html Interesting stuff, if this works, a 3D projector or TV could be an interesting option these days. Here's another one with specific ModeLine values: http://lists.gnu.org/archive/html/bino-list/2011-06/msg0.html The poster claims to be using these with a GeForce GT240 and a Samsung TV. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3D Frame Packing with OSG
On 03/03/2012 10:38 AM, Christian Buchner wrote: Geforce cards support stereoscopic 3D through HDMI as part of the 3DVision support for DirectX gaming only. It is called 3DTV Play and it isn't free (there's a 14 day trial version available). And this does not include OpenGL. Sure, but that's a different animal than what Erin is after. 3DTV play assumes the game wasn't written for 3D output and synthesizes the left and right channels based on the depth buffer. It also provides a Blu-ray 3D player (and I'm sure the fee is at least partly to cover Nvidia's licensing costs for this). From what I've read in several forums. If you create the 1280x1470 format (or 1920x2205 format) directly, you can get a GeForce card to render 3D content on a 3D monitor. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/05/2012 10:54 AM, Ethan Fahy wrote: If I were to set the color of a vertex of an osg::Node using floats between 0-1 and then accessed the color of that same vertex in a GLSL shader, would I get back the exact same floating point value? I am worried that at some point in the pipeline that float would be scaled to an 8 bit unsigned int between 0-255 and then rescaled back to a 0-1 float when accessed using GLSL. The reason I ask is that I am hoping to use the floating point value to carry a scaled index number for a lookup table in the shader instead of a color, so precision would be important. Hi, Ethan, If you're talking about vertex attribute data, you're likely get the same value back that you originally specified. The vertex attributes will remain in float form until you actually rasterize the vertices. Only at that point will they need to be converted to fit the data format of the framebuffer. That said, it's generally not a good idea to rely on floating point values to be exactly the same from one call to the next. I'd recommend trying to come up with a different way to do what you're attempting, or at least use an epsilon value in your comparison. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/05/2012 03:17 PM, Ethan Fahy wrote: Thanks Jason, I may do some testing with floats to see if they work out, but most likely I'll play it safe and use unsigned ints for r,g,and b and come up with an indexing scheme that can theoretically host up to 16.7 million discrete values. Just curious, Is there some reason you're specifying a scaled index for a look-up table as a color? Any reason you can't just pass your scaled index to your shader as a 32 bit generic integer vertex attribute? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3D Frame Packing with OSG
On 03/01/2012 05:01 PM, Erin Morrow wrote: Hi, I am trying to get OSG to output in 720p 3D frame packed format. My understanding is that this requires a screen resolution of 1280x1470 ( 2x(1280x720) + 30 buffer) but I must be missing something as the Sony HMD I am sending the output to is not recognizing it as a 3D format although it is displaying a down-sampled 1280x1420 desktop. I have been using the OSGViewer with command line arguments to specify a stereo mode of vertical split and am setting the screen resolution with: Code: osg::GraphicsContext::WindowingSystemInterface* wsi = osg::GraphicsContext::getWindowingSystemInterface(); wsi-setScreenResolution(osg::GraphicsContext::ScreenIdentifier(screenNum), 1280, 1470); If anyone has some experience with this I would be grateful for some pointers. I don't have any direct experience with that particular HMD, but here are some thoughts... Your code sounds like it's about right, although the vertical split mode won't give you the 30-pixel gap that you need by default. You might have better luck by setting up two slave cameras with the needed parallax for stereo, and adjusting the viewports to provide the 30-pixel gap ( 0,0-1279,719 and 0,750-1279,1469). I'd guess that the bigger issue, though, is that your video card probably isn't able to support a resolution of 1280x1470 (at least not without some low-level timing adjustments). If you're on Linux, there are a few hits on Google if you search for 720p frame packing 3d. Here's one promising link: http://forums.nvidia.com/index.php?showtopic=213574 --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3D Frame Packing with OSG
On 03/01/2012 07:58 PM, Erin Morrow wrote: Jason, Thanks for the response. That link is helpful and i have done some research on the anatomy of modelines but no success yet. I am running my code on windows and while we occasionally build for Linux I'm hoping I don't NEED to go that route to crack this problem. It appears that my graphics card (qaudro something or other, not in front of it right now) can output 1280x1470 as I can see a desktop with that resolution in the HMD when testing it as a custom resolution. Yeah, if you're on Windows, the link I gave you isn't going to be much help (not directly at lease). It's good that you can configure that resolution on your card. One hurdle out of the way. The osg viewer is launching without complaint at that resolution as well. Unfortuntely the HMDis not recognizing it as a 3D source. I will try your suggestion of forcing the black band between viewports. I wonder if the HMZT1 processing box is actually looking for black pixels in the middle of the source when it is determining if it should consider it a 3D format? I am having trouble finding this type of information for both the format and the device itself. You might want to look up the HDMI 1.4a specifications on the packed stereo format to see what exactly is required to meet them. It may be more than just having the right resolution and the 30 pixel gap. Good luck! --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering without calling osgViewer::frame
On 02/28/2012 10:49 PM, Sean O'Connell wrote: I'm currently working on a project where I have to integrate library into a 3rd party application's source code. The library consists of a custom osg Camera that takes 9 snapshots of the user's scene. The headache's I've run into are the following: 1. I cannot seem to turn off the 3rd party app's main camera in the osgViewer class. I set nodeMask(0) on the camera but then my camera doesn't render. Having the main camera enabled adds unnecessary overhead. So it sounds like your application has a single camera on an osgViewer::Viewer, and you're adding 9 slaves to it to handle your rendering. Is that correct? I'm wondering if you couldn't just grab the app's main camera, replace it with another camera that doesn't render anything (making it the new master camera for the Viewer), and then add the app's camera back to the Viewer as a slave. Then, add your other 9 cameras as additional slaves. This way, you could disable the app's camera without affecting your 9 other cameras. No idea if this is feasible or not (if there are manipulators or other controls for the app's camera, you'd need to move those over to the new master camera... things like that). 2. The process of taking the 9 snapshots has additional overhead from having to re-process and re-run the update, event, cull and render traversals for each snapshot. Since each view orbits about the same point in space, I'd like the ability to only run the update, event and cull traversals once and only call the render traversal for each snapshot. Event and update only run once as it is. Cull has to be run either per camera or per context, because the cull traversal is what sets up the various render objects that do the actual rendering of each context. Each view is potentially different, and thus has a different set of geometry to render. If you have access to the Viewer, you can try different threading modes (such as CullThreadPerCameraDrawThreadPerContext) to adjust how culling is done. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_TRANSFORM_FEEDBACK_BUFFER_NV in OSG
On 02/29/2012 09:22 AM, Martin Großer wrote:
Hello,
I tried this in my camera draw callback:
virtual void operator()(const osg::Camera camera) const
{
// GL-Context-ID
GLuint gcID = _gc-getState()-getContextID();
// GL-Program-Handle
osg::Program::PerContextProgram* pcp = _program-getPCP(gcID);
GLuint prID=pcp-getHandle();
const char* varyings[1] = { vPosition };
glTransformFeedbackVaryings(prID, 1, varyings, GL_SEPARATE_ATTRIBS);
}
But when I want to compile this, I get the error glTransformFeedbackVaryings isn't
defined. I searched in my includes and it is in the glext.h and glew.h defined.
What is wrong?
On Linux, you might need to #define GL_GLEXT_PROTOTYPES
On Windows, you have to look up the function with wglGetProcAddress
In both cases, it's generally a good idea to test for the extension
first (OSG normally does for you in osg::GLExtensions).
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Terrain texture brush implementation
On 02/26/2012 06:58 AM, Cao Wenjie wrote: Hi, As OSG newbie, I'm working on a terrain texture brush task. My goal: Use mouse controlled brush paint grass area on a prebuild terrain(has original texture) Progress: Now I successfully complete a demo, but the method I use seems unattractive. My implementation now: (Use OverlayNode method) 1. Load prebuild terrain(T1) and it to scene. 2. Duplicate the terrain node(Terrain T2). 3. Change the texture of T2, make is full of grass texture. 4. Use T2 as OverlaySubgraph, T1 as child to OverlayNode, so now, in the scene, I can see a single terrain full of grass. 5. Set color of each vertex in T2, make it complete transparent. 6. handle my mouse brush area, calculate effected vertices of T2 in brush area, and raise the transparent value of those vertices. 7. now the brush area will gradually show grass texture. I did some search about the question, seems multi-texture is another way, but I didn't figure out how. As I need control blend on individual vertex(brush area), I only found functions to change the blend of whole texture units. Any tip of a smart way will be grateful :-) Hi, CaoWenjie The Source engine (used by Half Life 2) uses a multitexturing technique to achieve what you're trying to do. I implemented a viewer for Source engine .bsp files a while back. If you look in src/osgPlugins/bsp/VBSPReader.cpp, starting around line 803, you'll see a way to do this using TexEnvCombine operations on two texture units. The first combiner (on texture unit 0) does the interpolation between the two textures. The second combiner (on unit 1) just does the normal modulation between the combined color from the first unit and the vertex color. In this case, the first combiner uses the Alpha value from the vertex color (SRC_ALPHA) to decide how much to blend between the two textures (that's Operand2 in the INTERPOLATE operation). In your case, you'd want to set Operand2 based on your brush value. Note that your graphics card needs to support the ARB_tex_env_crossbar extension for this to work (most modern cards do). Hope this is useful... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to prevent resize of viewer window (WindowsandLinux)
On 02/28/2012 04:04 PM, Cary, Karl A. wrote: I would be very interested in this as well. I have been having this issue for a long time. Our development systems all have one widescreen monitor at 1920x1080 and then one SD monitor at 1280x1024. If we want to run a 1280x1024 window on the widescreen as the left monitor, all is fine. However if you want it to run on the 1280x1024 monitor and it is the left most monitor, only 75% of the time it's fine. The other 25% go between showing up on the wrong screen and running at 1280x1024 inside of a 1920x1080 full screen window. Hi, Karl, Sounds like you've got a different problem to me. My patch is only for preventing the interactive resizing of the window (i.e: by clicking the mouse on the window's border and dragging it). I've seen problems like you mention before (I'm guessing you're on Linux). Usually, some combination of options to the xorg.conf file can be set to fix it, or at least make it behave consistently. If you're using the NVIDIA proprietary driver, check the driver's README.txt file for a list of options you can set. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering without calling osgViewer::frame
On 02/28/2012 06:20 PM, Sean O'Connell wrote: In my application I have a bunch of cameras that render to textures. Is there a way for me to trigger them to render without calling osgViewer::frame or going through the osgViewer class? Ideally I could simply call camera-renderView() or something similar. Is this possible? Hi, Sean, Short answer: In theory, it's possible, but I wouldn't recommend it. What are you trying to accomplish, in more broad terms? There's probably a better way to do what you're trying to do (have you looked at osgPPU yet?) Long answer: The main problem with this is that the cull and draw traversals are normally spawned off into separate threads, with the exact configuration depending on the threading model in use. If you look at the implementation of the frame() method (in the base class implementation ViewerBase.cpp), you'll see that it's a pretty simple method that calls: advance(simulationTime); eventTraversal(); updateTraversal(); renderingTraversals(); If you then look at the renderingTraversals() method, you'll see it's a lot more complicated, since it has lots to do, and it needs to be able to deal with each of the different threading models that could be in use. You might be able to write your own version of renderingTraversals() to handle your specific use case and only render the cameras that you want, but you're likely to run into all kinds of problems. As I said earlier, there's probably a better way to do what you're trying to do. If you explain your task at a higher level, someone might be able to come up with a solution for you. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Release built OSG libs with debug built app...
On 02/27/2012 02:12 PM, Chris Hanson wrote: On Mon, Feb 27, 2012 at 11:34 AM, Shayne Tueller shayne.tuel...@hill.af.mil mailto:shayne.tuel...@hill.af.mil wrote: All, I believe this issue has been addressed before but I can't find the previous discussion. Therefore I will ask again... Is there a way to get Release-built OSG libs to play nicely with an app that is built with Debug? Right now if I link with Release-built OSG libs, my app (built with Debug option) doesn't work. If I link with Debug-built OSG libs, things work fine. If I built my app with Release, then it also works fine. Here is an explanation of why this doesn't work... http://msdn.microsoft.com/en-us/library/ms235460%28v=vs.80%29.aspx The article talks about the differences between msvcrt.dll and msvcrversion.dll, but the same problem exists when you mix debug and release runtime libraries. You can't pass a pointer generated by your app in debug mode (using the debug version of the C runtime) to OSG in release mode (using the release version of the C runtime). The key is the C runtime flag sent to the compiler. Either compile everything with /MD (Multithreaded DLL) or /MDd (Multithreaded debug DLL). Mixing them is bad. However, I believe you could build a release build of your app with no optimization and with all debug symbols included. This should allow you to debug your code (though not as completely as a full Debug build) from within a release build. Yeah, this works (sort of). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to prevent resize of viewer window (Windows and Linux)
On 02/23/2012 10:53 PM, John Simpson wrote: Jason I know it's possible if I dig into the windowing system for a specific platform, but I was hoping to do it using an OSG cross-platfom method (see first post). I think you misunderstood me. What I meant was that OSG should be able to provide the ability to disable resizing in a cross-platform way (because all of the underlying platforms support it). If it's not doing that properly, then something needs fixing. If you can create a simple example, like Robert suggested, I can try to help with the Linux and Windows implementations. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to prevent resize of viewer window (Windows andLinux)
On 02/24/2012 04:13 AM, Robert Osfield wrote: You should be able to do the cross platform route, but if there is a bug on the OSG side on one particular platform we as a community just need to fix it. I just have access to Linux, and have very little Windows experience so can't help out with debugging the Windows side, so have to rely on Windows dev to get things working perfectly under Windows - this normally works out pretty well. To resolve the issue the best route would be to create a small example that illustrates the problem so that others can reproduce, confirm the problem and then work to fix it. Modifying an existing osg example would probably be a good place to start. I found a little program I can test with. It looks like the MWM property for resizing is being set correctly, just the window manager (Metacity, in my case) is ignoring it. I'm putting together a submission that uses the ICCCM hints instead. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Counting OpenGL Draw calls in Stats
On 02/23/2012 05:22 AM, Robert Osfield wrote: The OSG doesn't have any stats collection on individual OpenGL draw calls, such low level instrumentation would be rather expensive to implement code wise and expensive w.r.t run-time cost. The best solution for this type of low level instrumentation is to use a wrapper around the OpenGL driver as suggested by others in this thread. Hi, Robert, I was afraid you'd say that :-) Thanks for the reply. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to prevent resize of viewer window (Windows and Linux)
On 02/23/2012 10:20 AM, John Simpson wrote: Hi, I still haven't got to the bottom of this. Use the source? Hi, John, You mentioned this is going to be cross-platform. Is your code not working on any platform? I looked at the relevant code in GraphicsWindowX11.cpp, and it seems like it should work (I haven't had time to test it myself, though). Bottom line is that every desktop platform has a way to mark a window as not resizeable, so this should be possible. If it's not working, it can be made to work. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
